Ways to evenly engage Testers and enforce discipline throughout the Sprint
Quite often I see Agile teams where Test Engineers sit relatively idle during initial days of sprint and struggle hard to complete testing tasks towards the end of sprint. Although Scrum teams follow Agile principles and practices, still at times, teams experience huge delays in Development and Testing which result in spill over of user stories to next sprint or delay in release dates. Typically, Test Engineers focus on following activities during the first few days:
1. Understanding User Stories
2. Write Sprint Test Plan
3. Authoring Test Cases
4. Follow up on approvals (Test Plan & Test Cases)
Test Engineers are supposed to allocate initial 20-25% of sprint duration for the above mentioned tasks and then start Test Execution & Reporting. Mostly, Test Engineers author Test Plan, Test Cases and wait till Programmers deliver code for testing. The problem becomes even worse when majority of functionality is deployed to Test Environment towards the end of sprint, leaving Test Engineers with very limited time to test. Eventually, this results in an application with poor quality!
Question: How to evenly engage Test Engineers and enforce discipline throughout the Sprint in an Agile team?
Solution: Understand agile team dynamics and check whether any of the following can be implemented.
1. Check the programmers & testers pace [i.e. production (development) of functionality by programmers and consumption (functional testing) by testers]. If the programmers and testers pace are not properly aligned then implement Work In Progress (WIP) limit at Development and Testing phases to keep a tab on work.
2. If both development and testing teams are co-located I recommend testers to collaborate with programmers and start testing early by checking the functional changes on either development boxes/machines or Dev environment, instead of waiting for entire functional changes to get deployed onto QA environment(s).
3. Motivate testers to start contributing for unit testing (white box testing) in a small way (i.e. come up with Unit Test Cases or review Unit Test Cases written by programmers or execute unit test cases after every build, etc.)
4. Set up Progressive Automation infrastructure (i.e. TDD/BDD) and train functional testers to start automating as soon as authoring of test cases is complete. Let the Progressive automation scripts drive both (manual and automation) functional testing.
5. Encourage all team members to participate in Agile Scrum Ceremonies.
6. Suggest team to come up with a Sprint Activity Scheduler (SAS) with details on when what needs to be done in ‘n’ weeks sprint.
7. Enforce discipline to Programmers & Testers. Recommend Agile team to come up with the deployment and test completion dates for all user stories committed to the sprint during Sprint Planning meeting (i.e. on the 1st day of sprint). Any delay in development or testing must be discussed collectively and resolved as a team.
8. If testers are more knowledgeable than Dev & business team we suggest testers to educate newly joined developers on the functionality, business rules, etc. by doing pair programming/testing (vice-versa).
9. Arrange periodic knowledge sharing sessions between scrum teams and production support teams where testers from Production Support share recent changes with Release team and vice-versa.
10. Suggest the team (programmers & testers) to discuss and come up with an agreed upon development dead line for sprints (i.e. for 3 weeks (15 days) sprint fix 12th day as code freeze and do not allow any major development work unless it is business critical).
11. Create Regression test suite, configure and schedule Regression test suite to run daily (nightly job) at a specified time and trigger an email with automation test execution report by the time team (programmers & testing) start actual work.
12. Look for Proactive ways of identifying issues rather than reactive ways to avoid last moment rush.