Wednesday, November 03, 2010

Tester and Developer Pairing

I know at STPcon Lanette Creamer gave a session on "Pairing with Developers".  In hind site I truly wish I had attended that session. 

Currently one of our development teams is pushing out two releases per week.  There are a couple of issues in that the code is actually complete in the previous sprint and it takes test 1-2 weeks to execute regression.  This is not meeting the needs of the business, so we have added in "quick releases" with minimum code changes and minimal testing.  On top of that we are also injecting releases where we are conducting A/B testing (more on that latter).  In order to keep up an efficient pace, the team is now considering daily releases.  Wow!

This is essentially a shift to Kanban.  If you listen to Kent Beck, moving to this type of SDLC a team would essentially remove the testers.  I respectively disagree.  Testers can still play a critical role in the reporting of quality and making sure the releases are meeting business and customer needs.  As I ponder this paradigm shift, I believe "Pairing with Developers" becomes essential.

Developer grabs the next story and pairs with an experienced tester.  They work together design the unit tests.  As the developer implements the unit tests, the tester designs the acceptance tests (Cucumber) and developer does a code read.  As the developer writes the code, the tester implements the acceptance tests.  The tester should also collaborate with the developer to design and implement any browser facing tests (Selenium).  Integration tests should also be considered.  At the end of the day the code should be complete and all of the tests pass.  If all tests pass, then automated deployment pushes the release for UAT.  UAT Testers evaluate the functionality in a non-customer facing production environment.  If the user acceptance tests pass, then switch the environment to be customer facing.  In the A/B world we can expose only 20% of the customers to the new feature.  If there are no issues raised by the customers, then we push live. 

There may be other ways to complete the test automation, but this paradigm makes sense to me.  Not all testers have automation experience, so this places the emphasis on education and training.  How quickly will we get there? I do not know.  Is it possible?  Absolutely!

I am looking forward to this challenge.  If any of you are actively doing this style of rapid development please share you thoughts.

Gotta LOVE testing!

No comments: