1)
Firstly, tester attend release planning and estimation, break down epic to story card. Then attend iteration (normally two weeks for one iteration) tick off, and working with BA to write Acceptance Criteria for each story card. Paring with developer when necessary to write automation test.
2)
when developer finish coding story card, he or she need to show tester what he has done which is call hand over.
3)
After that tester need to do exploratory testing against finished story card. If everything works fine, the final thing need to do for tester is show story to stake-hold (BA, business).
4)
By the end of each iteration, tester need to run regression testing as well.
Example:
-- story card --
As a Search Engineer,
I want to limit the number of results that are returned
So that too many results are not displayed that are not relevant to my search.
Testing Exp with Dave
one question
"• Ability to manage multiple tasks in the order of importance and relevance to the business"
if someone ask me how to manager ultiple task
what i should reply
Dave says:
very important. "Prioritisation"
GRACE says:
according to what
then which one is high prirotiy?
Dave says:
it's more test manager level that needs to do that. You always have competing interests. The important thing is that you keep people informed of priorities
GRACE says:
ok
Dave says:
but generally, at Freshtel for example, critical production issues were always highest priority, especially billing related issues
GRACE says:
yep
Dave says:
Then for projects, there was constant discussion about which were the highest priority
These depend on the companies strategic direction
so for ftel, mobile projects were high. But so were TEsco projects
GRACE says:
ok
excellent answer! thanks Dave
Dave says:
what made it hard was the Sales guys always wanting stuff done at the last minute
coz they never planned anything or understood that small changes are not always easy
GRACE says:
Another question, for system test, what should be focus on ? different to UAT or regression?
find most of the bug ?
Dave says:
when they ask about UAT, you need to stress that you're testing from the end users perspective. So if there's any business requirements doco, you go back over that & understand what they want the system to achieve
system testing is from your perspective, knowing what it should do functionally but also how it's put together technically
never say "testing is about finding bugs"
that's a very simplistic view of it
"• Ability to manage multiple tasks in the order of importance and relevance to the business"
if someone ask me how to manager ultiple task
what i should reply
Dave says:
very important. "Prioritisation"
GRACE says:
according to what
then which one is high prirotiy?
Dave says:
it's more test manager level that needs to do that. You always have competing interests. The important thing is that you keep people informed of priorities
GRACE says:
ok
Dave says:
but generally, at Freshtel for example, critical production issues were always highest priority, especially billing related issues
GRACE says:
yep
Dave says:
Then for projects, there was constant discussion about which were the highest priority
These depend on the companies strategic direction
so for ftel, mobile projects were high. But so were TEsco projects
GRACE says:
ok
excellent answer! thanks Dave
Dave says:
what made it hard was the Sales guys always wanting stuff done at the last minute
coz they never planned anything or understood that small changes are not always easy
GRACE says:
Another question, for system test, what should be focus on ? different to UAT or regression?
find most of the bug ?
Dave says:
when they ask about UAT, you need to stress that you're testing from the end users perspective. So if there's any business requirements doco, you go back over that & understand what they want the system to achieve
system testing is from your perspective, knowing what it should do functionally but also how it's put together technically
never say "testing is about finding bugs"
that's a very simplistic view of it
TABLE 1.2 Testing principles
Principle 1: Testing shows Testing can show that defects are present, presence of defects but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.
Principle 2: Exhaustive testing Testing everything (all combinations of is impossible inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
Principle 3: Early testing Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
Principle 4: Defect clustering A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures.
Principle 5: Pesticide paradox If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
Principle 6: Testing is context Testing is done differently in different dependent contexts. For example, safety-critical software is tested differently from an e-commerce site.
Principle 7: Absence-of-errors Finding and fixing defects does not help if fallacy the system built is unusable and d
Principle 2: Exhaustive testing Testing everything (all combinations of is impossible inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
Principle 3: Early testing Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
Principle 4: Defect clustering A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures.
Principle 5: Pesticide paradox If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
Principle 6: Testing is context Testing is done differently in different dependent contexts. For example, safety-critical software is tested differently from an e-commerce site.
Principle 7: Absence-of-errors Finding and fixing defects does not help if fallacy the system built is unusable and d