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.
Comments
Post a Comment