понедельник, 5 сентября 2011 г.

Agile Tester's Bible | Agile Testing Book

I have done it. The 500 of pages with a lot of sense and practical experience. The place where I got the latest ideas for the process improvements working in the company.
The book started with the explanation why authors created this book, who is the audience and what is Agile Testing anyway. A good explanation of Interaction of Agile roles, showed on the picture below. The main difference from traditional process is awareness from "Quality  Police" philosophy. The Whole Team Approach says "We don't think of "departments", we just think of the skills and resources we need to deliver the best possible product". After thinking this way everyone on an agile team gets "test-infected". And start thinking about testability from the beginning (building infrastructure and design). The best example of 'whole team approach' I got there. "If it's the last day of the sprint and some stories aren't tested, the whole team should stay late to finish the testing, not just the testers."
 Agile Testing says that you need to use automated testing on each levels to have more time for much greater values-add areas like exploratory testing, usability, and testing the app in ways developers hadn't originally anticipated. Agile teams work closely with the business and have a detailed understanding of requirements. "Testers don't set and wait for work; they get up and look for ways to contribute through the development cycle and beyond". 
Agile Testers tend to have good technical skills, know how to collaborate with other to automate tests and are also experienced exploratory testers. They're willing to learn what customers do so that they can better understand the customer's software requirements. So the Agile Tester should be the customer-focused team player. He or she should continually looking for improvement in process and quality of released software.

Lisa and Janet defined 10 principles for Agile Tester:
Provide Continuous Feedback
Reports, Daily status
Deliver value to the customer
Understand what customer really need
Enable face-to-face communication
Help to develop project own jargon. Using “Power of Three”
Have courage
We need courage to make mistake, because that’s only way to learn the lesson. We need courage to ask for help
Keep it simple
Use simple solution for the problem
Practice continuous improvement
Always try new technologies on practice
Respond to change
Add changes during iteration
When build fails team should self organize to fix this asap
Focus on people
Agile team give team members equal weight
Work as one team and love what you are doing

The book says that when company implement agile development, the testing or QA team often takes the longest to make the transition. Because testers tend to learn a lot new sings and how to be working with the development team side-by-side.  Lisa showed the example of Testers Bill of Right that I started to use on company's projects:
  • Bring up issues related to testing, quality and process at any time
  • Ask questions of your team members and receive timely answers
  • Ask help from everyone on the team(s)
  • Estimate testing tasks and have these included in the story estimates
  • The tools you need to perform testing tasks
  • Expect your entire team, to be responsible for quality and testing
After applying this in the company I started to think about test team as community of testers and organized monthly QA Meet Up's. The same way as authors recommends. The QA Manager in this process looks like practice leader in the organization. The person who is able to teach the skills the testers need to became stronger and better. 
The main idea of the book is described in the "Agile Testing Quadrants" section. 

The picture showed this quadrants and what they are using for.

The main idea of the approach is to cover all activities by testing. From the code to business level. The main awareness is team could have no skills to do this. Than managers should budget the trainings, books, environment to help team archive the goals. The main part of Agile Testing is Test Automation with pushing test to lower levels as possible. The lower tests are - the ROI is higher.

In some cases Q2, Q3 and Q4 tests cannot be automated. Then manual verifications should be used as well as Exploratory Testing. Doing this still not forget to communicate with customer about Acceptance Criteria and Acceptance Story Tests(Positive Path Tests) that should be defined before or during story development. To store the test cases authors recommend: checklists, mind maps, spreadsheets, mock-ups, flow diagram and software-based tools.
After the project increasing you should not forget the Big Picture to test not only the stories. For this the Q3 quadrant is using with such technics as: end-2-end scenarios, exploratory and usability testing.
Also Lisa and Janet shared a lot of information about automation and choosing a right tool for each level. Good examples from experts in different companies showed how it works on practice.  The latest part "An Iteration in Life of Tester" showed how all this stuff working on a real project. And how the theory is helping to deal with problems.

This book shown for me that all I was doing during my Agile experience is on the right way. And the way our company live is totally correct with Agile.  After reading I've started to add new values into my daily activities. And it works fine, sometimes with small customizations. I will recommend this book to all my colleagues, friends and people who are interesting in Agile development.
The full Contents you can find on the mind map below.

This is the new testers' bible, after the Cem Kaner

The Mind Map is too big to set it as a picture here. Download PNG file.