DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • JavaFX Goes Mobile
  • Reducing Network Latency and Improving Read Performance With CockroachDB and PolyScale.ai
  • Google Becomes A Java Developer's Best Friend: Instantiations Developer Tools Relaunched For Free
  • Conditional Breakpoints: A Guide to Effective Debugging
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Key Behaviors of Testers to Be Successful in Agile Projects

Key Behaviors of Testers to Be Successful in Agile Projects

It's vital for testers to be agile, so they can effectively plan, prioritize, and execute tasks which affects the team's ability to meet iteration goals.

Ajeet Singh user avatar by
Ajeet Singh
CORE ·
Sep. 10, 20 · Opinion
Like (2)
Save
Tweet
Share
4.79K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile scrum

Opinions expressed by DZone contributors are their own.

Trending

  • JavaFX Goes Mobile
  • Reducing Network Latency and Improving Read Performance With CockroachDB and PolyScale.ai
  • Google Becomes A Java Developer's Best Friend: Instantiations Developer Tools Relaunched For Free
  • Conditional Breakpoints: A Guide to Effective Debugging

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: