Why Still Processes and Tools Matter in Agile Testing?

“Learn agile and practice agile” continues to be a heavily discussed, opinionated and debated topic in the software industry. The testers play a pivotal role in the “Scrum Team” who weaves the entire storyline to be presented at the Sprint’s Demo. Thus, getting adapted to the agile manifesto is a necessity. However, according to the first agile manifesto, we may have to have a trade-off between “individuals and interactions” over the “processes and tools” (I was extremely careful to pick the verb form here as it is possible to have a blend of these factors to suit the needs of your team). This made me think about how one could ignore the importance of processes and tools in supporting “agility” from testing perspective.

Let me build my rationale here with my two cents. First, what is the process? The simplest form that I can define a process is “a series of inter-connected actions which produce a pre-defined outcome or outcomes at the end”. Then let me give some weight for “tools” as well. Tools are the “pieces of software which enable their users to perform their tasks, which otherwise may consume hours”. Next how can we measure the efficiency and effectiveness of processes and tools in agile? Are KPIs valid in agile testing? Let me define KPI in testing as well here. A KPI is a measurable value that demonstrates the robustness of process/es with the help of tools in achieving key test objectives (may be measured within each sprint).

Let’s move into discussing “developing insanity” towards individuals and interactions over processes and tools. Go back to the “Reactance Theory” introduced by Brehm. According to him, individuals are not passive receivers but respondents and they perceive freedom a lot. By combining freedom with agility, it is possible to build adaptive environments which allow each person to contribute unique value. In such instances the results can be very powerful. However, what will happen if the freedom is misused by a tester? Can the absence of testing processes and the KPIs allow room to assess the damage? Do we have any idea what to stop, what to continue and what to start in order to improve from how the previous sprint was conducted? 

I suggest a light-weight process framework along with a set of well-defined KPIs and supported tools should take precedence in such situations to overcome the obstacles and speed up delivery. We may not able to define it upfront over one night but it is very much possible to implement this as a gradual process by collecting and accommodating what we hear at “Retrospective” meetings.

The next concept is interactions. Interactions make the progress of the project transparent and ensures the customer's voice is heard closely and frequently. Yet, don’t you think, interactions should also happen in a controlled space in order to avoid miscommunications? Extensive communication and too many channels of communication could also bombard and delay the “Shippable Product”. Thus, this should be carefully considered while empowering decision makers to act swiftly upon certain situations by trusting their knowledge and skills. 

Nevertheless, if you value processes and tools, the benefits should be clear and well-understood by everyone involved and should not be an overhead to realize greater benefits.