In a world without an Agile Testing Manifesto

Today, the Agile methodology and its components have become second nature to so many organizations. So much so, that thinking of a world without Agile is almost impossible today. But, it is human nature to not appreciate something truly until we feel its absence.  So, let’s go back in time and take a look at what the software development world would be without Agile and one of its core components – Agile Testing. 

Flashback to Feb 2001, no ski resort gathering and no invention of the Agile manifesto. People are still trying different methods, frameworks and practices for improving the state of the software industry. There is nothing called as Agile values and principles.

No invention of Agile means no invention of the Agile Manifesto and the invention of the Agile Testing Manifesto is out of question as it draws parallels with the Agile Manifesto, but with dedicated focus on the testing aspect.

Let’s dig deeper into the world without the Agile Testing Manifesto -

Fix-defect-then-release OVER Release working components

Traditional methodologies usually involve long delivery cycles where the product is first developed and tested at a later stage, even if this means a delay in the time-to-market time. The focus is on delivering a bug-free product even if it means releasing the product after it becomes obsolete, given the rapid changes in technologies and the dynamic market environment.

In contrast, Agile believes in nullifying this issue by implementing two-week delivery cycles and generally quarterly release cadences. This helps especially since most markets and competition are moving too fast forcing companies to deliver products to the market faster.

Delivering in smaller increments also facilitates the opportunity to tweak the product as per the requirement of the end customers. This means that the functional and usable software is valued over comprehensive but unusable documentation. Though this is more directed to upfront requirement specifications and design specifications, this can be true for test plans and test cases as well.

For example: One of our client, an insurance services company has a platform to address accident related procedures. The platform has 20+ applications that are categorized as – Front-office apps, back-office apps and administration apps. More than all these apps, the section- ‘Business rules engine’ on the platform is the most critical component due to the number of financial transactions involved. Naturally, our testing strategy was to test that section first and release it and also test the business rules engine through automated regression testing.

Whereas the traditional methodology would have demanded to check every component of the platform before releasing it.

Testing as separate phase OVER Continuous testing

Testing is always kept as the last phase in traditional settings. In this case, the focus is more on getting the product developed and then testing the entire product for bugs. As you can guess although it may seem straight-forward and obvious at first, the process is quite tedious and time-consuming. Moreover, there is a possibility of a major bug setting a project back by months as it may affect the entire code base. which can prove to be very expensive.

Whereas, with Agile Testing, a continuous feedback and seamless coordination between the tester and the developer helps the developer to write error-free code. A successful tester facilitates this by perfectly articulating the requirements, testing continuously with automation testing, getting results and giving timely feedback. Almost immediate feedback is possible when testers and developers are working on the same team. This lets the developer fix the bug while the code is still fresh in his mind. In case of Agile testing, these bugs are fixed at the earliest and thus can save a lot of time, money & resources.

Testers’ responsibility for quality OVER Team responsibility

When we decide to buy software, the very first thing that comes to our mind is the quality of the software. Without high quality, any software is just a piece of junk for which nobody wants to pay or use. So, somebody needs to take the responsibility for thoroughly testing the software, right? After all, an ownership always comes with the responsibilities.

The traditional methodology follows the same philosophy and considers the tester to be the sole person responsible for quality. However, this is bound to backfire since testing an entire software, from start to end, may prove to be a daunting task for one or just a couple of people and fallacies ensue.

In Agile Testing, quality is a shared responsibility among the testers, developers and other team members in an organization.

Programmers write the technology-oriented tests but they may need help from the testers, database designers, system administrators, configuration specialists, etc. from time to time. Even though the testers take primary charge of the business-oriented tests simultaneously with the customers, the programmers actively participate in designing and automating the tests, the usability and other experts also might be called in as needed. Therefore, quality becomes the responsibility of the team as opposed to just the tester’s responsibility.

For example, you may find one tester working with a team of developers. The developers often write unit tests as they add more features and then use these tests to test the app continuously as they keep adding features.

Detailed test planning at the start OVER Incremental test planning to absorb changes

Incremental test planning means accepting changes as being natural and responding to them without being afraid of them. Although it is nice to have a plan beforehand, in the world where requirements are changing frequently, it may not be nice to stick to a plan, at whatever the cost and even when situations have changed.

Traditional methodologies tend to make the same mistake.

Let’s say you write a test case, which is your plan, assuming a certain requirement. Now, if the requirement changes, you promptly adjust your test case to validate the changed requirement instead of lamenting over the spent time, money and effort, unlike in the traditional methodology, like in the Agile testing.

For instance:  One of our client, a digital media agency that works for an eCommerce startup client, initially had a plan to develop just a web application. Keeping this scenario in mind, we developed a strategy to test the website, its responsiveness and compatibility with various browsers.

But, a few months down the line, the e-commerce startup received some more funding that enabled them to build a mobile application as well. In such a situation, simply implementing the initial plan would not have been fruitful.

So, we adjusted the initial strategy such that it also included testing of the mobile application and its compatibility with the various mobile operating systems as well.

Specialization OVER Multi-dimensional skills

Specialized, systematic and rigid are some of the basic characteristics of traditional software development methodologies.  Such kind of software development utilizes rigid processes and tools to get the desired results. Such characteristics often make it difficult to achieve the results in a defined time.

On the other hand, Agile Testing values flexible people, multi-dimensional skills and communication over rigid processes and tools. However, people usually have the misconception that Agile Testing ignores processes and tools. In fact, Agile Testing is built upon very simple, strong and reasonable processes such as the daily standup meetings, automation tools, etc. These processes are basically inherited from the Agile philosophy, Nevertheless, it is the testers who drive the output and not the tools. 

The world without an Agile Testing Manifesto was quite complicated and slow, wasn’t it?  No wonder, several projects ended up being cancelled partway through, and even became obsolete by the time they reached the market.

Thank heavens, Jon Kern, an aerospace engineer in the 1990s, became increasingly frustrated with this and finally invented a more timely and responsive methodology with 17 software thought leaders at the Snowbird meeting in Utah in 2001.

Like the Agile Manifesto, my intention behind curating the Agile Testing Manifesto is to align the software development with business needs. There are a lot of advantages of adopting Agile Testing. Implementing Agile Testing efficiently can result into saved time and resources, both of which are critical, especially for small businesses.  

Moreover, Agile projects are customer focused and encourage customer guidance and participation. Nowadays, Agile Testing has a huge contribution in helping businesses deliver faster, get an early ROI, build the right products, reduce risk early in the product cycle, ensure assured quality and respond to customer needs much faster than ever before.