Wednesday, February 7, 2018

Testing: The impediment to Agile delivery?

For the majority of organizations, even those applying cutting-edge methodologies, Testing seems to be "the" impediment to getting the software delivered.  Based on the Theory of Constraints (read "Impediments"), anything that impedes immediate result after an action is taken is considered an impediment.  Testing required to ensure that a feature is done (completed user story) or a release is ready for production deployment (includes regression testing) is an impediment, and in most organizations, the biggest impediment.  We may have become so numb that we simply accept that impediment as part of the cost to doing business, and as reasonable, but it is clearly the LEAST Agile aspect of how we deliver software.

This discussion was primarily identifying and describing the testing impediments that organizations are experiencing, and at the end describing some approaches to addressing those impediments.  The notes contain well all the impediments described by the participants (all thanks to Jameson).  

Following are some of the ideas I've utilized which result in greatly reducing testing (both manual and automated) as the primary impediment to Agile delivery.

Working Agreement
 - include a statement that the entire team (rather than just the test engineer) is responsible for execution of necessary manual testing

Definition of Ready
 - include the requirement that all Acceptance Criteria are expressed as a "test", and verify one specific aspect of the feature described; if more than one aspect is being verified, consider breaking the feature into other (more cohesive) user stories

Definition of Done
 - all testing (sans regression pass) has been been executed and passed

 - QA specialist on each team takes the lead in ensuring the test-related DOR items are met
During Sprint
 - QA specialist documents test steps in tool being used for manual testing, in a manner that makes them easily found and executed by any member of the team
 - QA specialist updates any manual Regression suite to include the Acceptance Criteria from each user story
 - Developer pairs with an Software Development Engineer in Test (or another developer) to develop ALL automated tests, from unit tests to system integration tests, and just enough of the solution (in the systems under test) to result in all tests passing (during this time, each test will go from "red" to "greed"); test projects maintained in the same repositories as system/application code
 - Developer completes development of the solution ensuring that all tests remain "green"
 - As the build is deployed to various environments, the appropriate automated suites are executed

 - When the code gets to the appropriate environment to be validated for Production release, QA specialists execute any manual Regression testing that remains to be done

1 comment:

  1. Session Host:
    Craig A. Stockton
    Practice Architect
    TEKsystems Global Services QMS