Key Behaviors of Testers to Be Successful in Agile Projects

Testers in an Agile team have the primary responsibility of performing various testings to meet the Definition of Done and therefore contribute to the continuous value creation that the team strives to deliver over repeated iterations. It is vital for the testers to possess an agile mindset, in the absence of which, they might not be able to decisively plan, prioritize and execute their tasks and therefore inadvertently affect the team’s ability to meet the iteration goals. The agile mindset is a prerequisite for the testers to exhibit the right behaviors that lead to the performance acceleration of the team as a whole.

To be successful in an agile project a tester should focus on  some of the behaviors listed below:

1. Attitude Over Anything Else

Testers in a team might not come with an agile background or automation skills or rich testing experience - that is still fine as long as they possess the right attitude to be a part of an agile team. A right attitude would reflect in the behaviors such as – belief in the agile manifesto and practices,  trust the coaching and follow it dedicatedly,  openness to new leanings and changes, clear articulation, and transparency,  commitment to the activities that matter to the team, taking the initiative to improve and get better over the period, etc.

Agile, automation, testing, or other training, can go hand in hand for a person having the right attitude.

According to my experience, testers who brought the rigid mindset at work slowed down the iteration progress. Some behaviors were – testing the defects only when the status had been updated in the ALM tool,  sitting idle but not performing the sanity testing at local-hosts when the test environments were down,  thinking in the interest of testing activities alone during meetings, insisting on the formal communication from team members on deployments, blocker resolutions and intimations, etc.

On the contrary, testers who came with an open mind transformed themselves to serve the team and contributed in every possible way, e.g., some of them wrote Junit cases to help the developers in the idle time, learned to write services to mock the test environments, stayed flexible to adjust their plans and testing approach in a highly dynamic environment.

2. Prioritize Iteration Goal Over External Assignments

In a matrix organizational structure, testers work with a ScrumMaster in an agile team but they report to a line manager in testing practice or a test manager in the same project. These tests or line managers, who drive the overall testing across agile teams, might assign the testers with many ad-hoc tasks that are not in alignment with the team’s iteration plan.

In my multiple experiences with tester’s, I found them struggling to strike a balance between two sides-  one that controlled their performance appraisals and the other where they were committed to working. Most of them were tempted to take up external tasks, without informing their agile team because they didn’t want to make the line managers unhappy. Some who understood that it affects the on-going iteration activities, stretched outside the working hours to complete these assignments but others compromised with iteration activities. Because of this compromise, they were unable to deliver to the iteration goal that resulted in regular spill-overs of the user stories and also impacted the trust and cohesion level of the team. 

What should testers do in such situations? The answer is – iteration activities should always be prioritized over anything else. However, if they can complete the external tasks in their capacity without affecting the iteration goal then they can go ahead! But if the external task has the potential to affect the iteration goal, then they should consult the team for collective agreement or disagreement and keep the line managers informed about the decision.

3. Equal Partners in a Cross-Functional Team

One of the challenges faced with the testers in an agile project is their lack of ownership of the overall plan and activities because of the limited perception of their role in testing alone.

“I couldn’t test a user story because the developer didn’t deploy it”, a tester says in the daily scrum and the developer replies “sorry, it slipped from my mind but you should have reached to the other developer”. This scenario highlights the lack of collaboration and ownership of the team. Driving a user story to completion and removing intermittent blockers is just not an individual’s responsibility but a team effort and testers being a part of the team are no exception to it.

Certain behaviors of the testers that can help in expediting the delivery are - engaging the point of contacts (POC) on the blockers promptly whether it is related to the testing or not, syncing-up with developers quite often rather than expecting email communication, actively participating in scrum meetings to enhance team’s decision making capability, staying abreast with team’s plan to align their activities accordingly, etc.

I noticed some testers who over-socialized with other teams and lent their test environments preferred to pick-up low priority tasks. In another instance, they spent hours troubleshooting other team’s issues at the cost of their work – this behavior was outside the periphery of being an equal partner in a cross-functional team.  Team members should focus on solving their problems on priority, if needed extending help to other teams should be a secondary goal.

4. Assumptions Can’t Be a Choice

At times, the review comments from stakeholders revealed that the team went with some unwarranted assumptions around the acceptance criteria. Assumptions can’t be a choice especially for the testers because testing is the last activity in the workflow and therefore the last opportunity for anyone in the team to validate the requirements. Moreover, a tester’s expertise lies in finding a faulty deliverable.

I understood some of the root causes which trap a tester into unwarranted assumptions. These causes are -  fear to be judged for their ability to raise the right questions,  not getting a proper response on their previous queries, poor communication skills abstaining them from taking any chance, lack of a safe environment to openly challenge the acceptance criteria or ignorance during the backlog refinement sessions and not raising queries to clarify.

The cost of assumptions is too high in an agile project as the product increments are quickly rolled out to the end customers – any defects delivered would affect the return on investment (ROI) and would require rework, consuming more budget than the functionality deserved.

A thorough analysis of these root causes by the Iteration manager, ScrumMaster, or coaches using the techniques like 5-Whys will be very beneficial in devising an effective coaching plan and controlling these behaviors in the subsequent iterations.