Agile Testing - Google Tech Talk (notes)
2010-08-13 20:49
183 查看
{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!
It’s exact familiar. But it never happens. If we live in the perfect world, it happens. This happens,
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 -------------------------------------------------------
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,
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 -------------------------------------------------------
相关文章推荐
- Google Code Jam Notes - Moist - Java
- Google Talk Testing(早期版本)
- Jon's Tech Notes: Invoking a console from a deployed JRuby WAR file
- Google 招聘 Tech Lead/Manager - Beijing
- Google Code Jam Notes - Minimum Scalar Product - Java
- Google发布IM软件--Talk
- Google发布IM软件--Talk
- Notes : The Google File System - MIT 6.824
- Google Code Jam Notes - File Fix-It - Java
- Google发布IM软件--Talk
- Google发布IM软件--Talk
- How do I configure Miranda for Google Talk
- Google Code Jam Notes - Cross The Maze - Java
- Google Code Jam Notes - Captain Hammer - Java
- Google Code Jam Notes - Meet And Party - Java
- log my tech notes
- Google Code Jam Notes - Bad Horse - Java
- No Logo Google Talk
- 第3方client连接talk.google.com的一些注意之处
- Instagram技术透析:Mike Krieger, Instagram at the Airbnb tech talk, on Scaling Instagram