What Role Do Test Engineers Play in Agile Projects?

2022-03-14 14:09:07
Chen Qi
Original 997
Summary : Testers in the agile team are mainly responsible for performing various tests to meet the definition of "completed" to contribute to the continuous value creation that the team strives to deliver in repeated iterations. For testers, having an agile mindset is crucial. Without an agile mindset, they may not be able to decisively plan, prioritize, and execute their tasks, which will inadvertently affect the team's ability to meet iteration goals. An agile way of thinking is a prerequisite for testers to demonstrate correct behavior, which can accelerate the whole team's performance.

Testers in the agile team are mainly responsible for performing various tests to meet the definition of "completed" to contribute to the continuous value creation that the team strives to deliver in repeated iterations. For testers, having an agile mindset is crucial. Without an agile mindset, they may not be able to decisively plan, prioritize, and execute their tasks, which will inadvertently affect the team's ability to meet iteration goals. An agile way of thinking is a prerequisite for testers to demonstrate correct behavior, which can accelerate the whole team's performance.


Testers should focus on the following practices to succeed in Agile Projects:

1. Attitude Is the Most Important

Testers on the team may not have an agile background, automation skills, or extensive testing experience—This is still possible as long as they have the right attitude to be part of an agile team. The correct attitude will be reflected in the following behaviors, such as believing in agile manifesto and practice, trusting the coach and following it wholeheartedly, being open to new learning and change, being clear and transparent, committed to activities important to the team, taking the initiative to improve and become better during this period, and so on.


Agile, automation, testing, or other training can be carried out simultaneously for people with the right attitude.

Based on experience, testers who use rigid thinking in their work slow down iteration progress. Some behaviors are—Defects are tested only when the status is updated in the ALM tool; When the test environment is shut down, it is idle and does not perform soundness test on the local host; Consider testing activities separately during the meeting; During deployment, adhere to the formal communication of team members, prevent resolutions and hints, etc.


On the contrary, testers who come with an open mind change themselves, serve the team and contribute in all possible ways. For example, some of them write Junit cases in their spare time to help developers, learn to write services to simulate the test environment, and flexibly adjust plans and test methods in a highly dynamic environment.

2. Prioritize Iteration Objectives over External Assignments

Testers work together with Scrum Masters in the agile team in the matrix organizational structure. Still, they report to the line manager of the test practice department or the test manager on the same project. These test managers who drive comprehensive testing in agile teams may assign testers many particular tasks inconsistent with the team's iteration plan.


In many contacts with testers, I found it difficult to strike a balance between performance evaluation and commitment to work. Most of them try to take on external tasks without informing the agile team because they don't want to upset their direct leaders. Some people know that it will affect ongoing iteration activities, so they complete these tasks by extending working hours, that is, working overtime, but many people also sacrifice iteration activities. Because of this compromise, they cannot deliver iteration goals, which leads to the conventional overflow of user stories and affects the team's level of trust and cohesion.


What should testers do in this case? The answer is - iterative activities should always take precedence over any other activity. If they can complete the external task without affecting the iterative goal, they can move on! However, if external tasks are likely to affect the iteration objectives, they should consult the team for collective agreement or disagreement and inform the line manager of the decision.

3. Relationship Equality in Cross-Functional Teams

"I can't test this user story because the developers didn't deploy it," one tester said at the daily scrum meeting. The developer replied, "sorry, I forgot it, but you should also contact other developers to complete it." This scenario highlights the team's lack of collaboration and ownership. It is not the individual's responsibility to promote the completion of a user story and eliminate intermittent obstacles. Still, the efforts of the team and testers who are part of the team are no exception.


Some behaviors of testers help speed up delivery—Whether it is related to testing or not, we need to pay attention to the obstacles; Often synchronize with developers instead of communicating via email; Actively participate in scrum meetings to improve the team's decision-making ability, keep consistent with the team's plan, to keep their activities consistent, and so on.

Some testers who over interact with other teams prefer to pick low-priority tasks. Because they need to spend hours solving the problems of other teams at the expense of their work, this behavior goes beyond the edge of being an equal partner in a cross-functional team. Team members should prioritize solving their problems, and if necessary, helping other teams should be a secondary goal.

4. Assumption Is Not an Option

Sometimes, stakeholder reviews reveal that teams make unnecessary assumptions about acceptance criteria. Assumptions are not a specific choice for testers, as testing is the last activity in the workflow and, therefore, the last chance for anyone on the team to validate the requirements. Additionally, testers specialize in finding problematic deliverables.


I understand some of the root causes that put testers into unreasonable assumptions. These reasons are fear of being judged for their ability to ask the right questions, lack of appropriate answers to their previous questions, poor communication skills, so that they can't seize any opportunities, lack of a safe environment to openly challenge the accepted standards, or ignorance during the backlog work improvement meeting and don't ask questions to clarify.


In Agile Projects, the assumption cost is too high because product increments will soon be introduced to end customers. Any defect in delivery will affect the return on investment (ROI) and require rework, and the budget consumed exceeds the value of the function.


A thorough analysis of these root causes by the iteration manager, Scrum Master, or coach using techniques such as the five whys helps design effective coaching plans and control these behaviors in subsequent iterations. 


--


Author bio


Chen Qi, a senior agile test consultant. As a team member of ZenTao, a well-known domestic project management software in China, he is mainly responsible for the open-source automated test management framework-the development of ZTF. With more than ten years of practical experience in the agile process, he is now committed to the practice and research in test automation and DevOps.


Write a Comment
Comment will be posted after it is reviewed.