Checklist for Agile Testing

During a recent test team discussion, we reviewed the key features of agile software testing.  As a team, we all have a good idea of what is important with agile testing and how it is different from conventional testing.  We worked on the checklist to give us a tool for keeping our agile test mindset fresh.

Use the checklist to question your own agile test performance.  It is good for a self examination or a discussion with your project team.  For example, you can use it to share your vision of agile testing with a team that is new to agile development.

For most of the questions, "yes" is the best answer.  It is doubtful that you will answer "yes" (or whatever the best answer is ) for all the questions -- use the questions and answers to provoke thought.

Leadership

o       Am I taking items off the mental shelf space for the lead programmer, scrum master, and/or business user?

o       Am I the scrum master for the project? If not, could or should I have been?

o       Did I help the scrum team understand risks?

o       Do I organize work for the project?

o       Have I made decisions in the best interest of the project?  Did I give up ownership and did I take on ownership of right things to make the project successful?

o       Did I help new team members learn the project?

Analysis

o       Am I documenting the project, opening tickets and describing requirements?

o       Am I writing user stories?

o       Did I come up with any of the requirements for the project?  This is an indication that you are actively participating in the project.

o       Did I define and/or develop tests at the beginning of the sprint? Early work is good work.

Collaboration

o       Are other members of the scrum team helping with testing?  In agile, any member of the team should be able to test.

o       Do I feel like I am up to date with programmers and business users throughout the sprint?  A catch-up period later in the sprint is a bad sign.

o       During meetings, do I write on the white board?  This is an indication that you are actively thinking, communicating, and  participating in the project.

o       Have I sat with a programmer while he or she wrote code for the project?

o       Have I sat with the business users? 

o       Have I tested on the programmer’s workstation recently?  This is key to providing really immediate feedback.

o       Is there a lot of scrum team chatter?  Teams that talk to each other are more agile than those that don’t.

Testing

o       Am I giving really fast feedback to programmers on the most important things?

o       Am I known as “Fast Feedback [your name]” or “Quick Test [your name]?”

o       Are the programmers comfortable coding for the full sprint? Good agile testing can directly increase the productivity of the programmers.

o       Did I add value as a testing expert?  For example, did I help business users perform good test analysis?

o       Did I build any tools to help verify the project?

o       Did I update existing automated tests that changed because of my project work?

o       Did I use the simplest solutions for the problems I worked on?

o       Did we get user acceptance feedback very early and very often in the sprint?

o       Have I built regression tests for new functionality before or while it is being built?

o       How long are issues sitting with me before I turn them around?  Issues should sit no longer than a day or two.

o       How old are the bugs we are finding on the project?  The only good bug is a dead bug, and the best dead bug is one that didn't live long.

o       Is a lot of testing taking place at the end of the sprint?  Best answer is "very little."  Make an effort to test early and regularly throughout the sprint.  If you are testing a lot at the end, you are probably not being very agile.

o       Was more than one person involved in user acceptance sessions?  Do the users I worked with represent the user community well?