{Youtube could not be open in China network, to reduce the bandwidth, I remove the video demostration here. Please refer to link to watch it}
It is difficult to explain to the people who don't understand why there is anybody who think testing is fun. But I can find it so exciting.
Key messages I got from the speaker
- ST’s role in the team - is supporting the team, both developer and customer.
We help customer to see whether the software is acceptable. And tell THIS is what the software should do. We support developer that “I agree with what you’ve done. Well done, thank you very much.”
- Basic agile concept is we are all the team. We are not independent departments. We are all responsible for the outcome. The most lessons is calling agile project, but almost doing the traditional thing. It’s the answer of
“None of the staffs I’m doing have been tracked with the rest of the project.”
- In agile team, “I (ST)” am a junior programmer, and a senior tester.
- Under the agile context, testing should be considered as the same way of priority as any other infrastructure development task.
- Agile model is raised up from product manager. Developer and ST don’t get quite benefit on it. You have to find a way to reduce your pain. There are lots of good examples that they have self-interest on the things.
Before looking into what's agile testing is, let's have a look at the traditional testing.
l Traditional testing
With great optimism and the best of intentions, the project plan is announced,
Analyst, Design, Code
Test/Bug fix
Complete code signed off to ST
Release!
After 6 months analyze/design/code, you are told “it’s your responsibility to assurance the quality. There are 3 days for test, then we gonna release.”
Agile testing looks like this
l Agile testing
Iterative approaches mean we can trade features for time instead of sacrificing quality.
Maybe it’s a baby code, it doesn’t do much. But what it does is we can test them.
Keep the documentation simple
1. Capture the essence, not the details
Step-by-step instructions cost time without providing values (usually). Waste is not necessary; we got maximum value with minimum waste. No customer ever sees its value up.
2. Point to other project documents
If it's in the user guide, requirements, specs, etc. leave it there.
3. Centralize the generic tests in a checklist
Try this: count the number of times common condition, like invalid dates or null strings, are documented in the test docs. More than once is too many.
Reduce handoffs: integrate test efforts
Testing is not a phase. It’s a way of life.
1. Agile teams are test infected.
The question, “how will we test it?” is as important as “how will we build it?”
2. Co-locate testers and programmers
But sitting side by side does not ensure communication.
3. Track testing status and programming status all together
Show tests run-passed-failed together with features/stories done and left to do.
Different testing goes with different purpose
- Unit test
Does It do the developer expected I do?
Plan ahead, but not too far ahead
A little planning is good, more is not better.
· Plan for the current iteration design tests for the features or stories to be done in the near term. Speculative planning means rework.
· Use catalogs of reusable tests. Don’t redesign the same tests over and over. Instead, keep reusable checklists.
· Keep an up-to-date, prioritized risk list. What kind of information are the testers looking for? The risks list covers it. Keep the documentation simple.
Test automation on the agile project
· Use different types of automated tests for different purposes
§ xUnit tests for unit testing
§ FIT/Fitness or domain specific languages for Acceptance testing
· Collaborate with programmers on test infrastructure code
· Use test automation to support early exploratory testing
Agile testing practices evolving
------------------------------------------------------- Within an Interaction -------------------------------------------------------