From Aches to Agility: Revolutionizing Software Testing in the Agile Era

Are you getting software testing pains? 

Testing pains are nothing new. In our past experiences, we found that some degree of tuning of our clients’ existing testing process and competencies could acceptably reduce the discomfort. Recently, however, software testing pains have recently become more common and intense, particularly as the mature adoption of Agile and DevOps methodologies spreads. We have reached the conclusion that to alleviate these types of suffering, it is necessary to prescribe some quite fundamental changes to the software testing approach.  

If your organization has already transformed its software delivery organization and processes to improve your ability to deliver quality software at speed, you might now be experiencing some resultant testing pains and wondering how to treat them. Alternatively, if you are about to embark on such a transformation, recognizing the importance of valuable software in enabling your organization’s continued business success, we would strongly advise that prevention is better than a cure. It is wise to prepare changes to your testing process in advance.  

A dull, unpleasant ache we have somehow learned to live with 

For a long time, some organizations have viewed software testing as a nuisance. IT management would typically respond by either attempting to eradicate the problem, reluctantly tolerating it, or addressing it by increasing resources and competence. Testers have become accustomed to rumours about the imminent demise of their profession as they will be replaced by (expensive) test automation tools, replacement by cheaper unskilled resources, or, most recently, AI. Some organizations have tried to ignore the pain and continued to approach testing in the same, unfortunately unprofessional, manner. However, fortunately, the testing profession as a whole has worked continuously and assiduously for decades to improve the effectiveness and efficiency of software testing.  

Yet, the pain never completely subsided, and in recent years it seems to be intensifying. This is due to the fact that the fundamental approach to software testing has remained largely unchanged, while the IT context within which it exists has undergone a significant transformation. 

Some might argue othat there has been a revolution in software testing in the past 5-10 years with the adoption of test automation and the expectation that software testers have ‘technical’ skills. While this is true, I would still argue that no fundamental change has occurred. In many organizations software testers are still found fulfilling their traditional role. They may now be using more tools, perhaps executing some testing against the API rather than the UI and some of those tests may be automated, even integrated into the CI/CD pipeline. But, they are still essentially executing their test cases against the built software product.  

This is like a police detective examining a crime scene. It is important and necessary work. But metaphorically speaking, the crime has already occurred, and the victim is lying dead on the floor. The ‘crime’ in this analogy is having designed and built software with inadequate quality – software that fails to deliver business value and is not ‘fit for purpose’. Moreover, it has all been done inefficiently, resulting in increased costs and risk of burn out when deadlines loom and increasing pressure to get the job done from senior management.  

The most significant issue is the costly and time-consuming rework needed to rectify these problems. Traditional testing, much like traditional police work, is ineffective at preventing ‘crime’. 

We all understand that prevention is better than a cure and that building quality in from the start is preferable to fixing it later. Despite knowing this for a long time, we have remained stuck with the “testing silo” at the end of the iteration or release cycle. Why? Because until recently, there hasn’t been a big enough pain to really compel us to radically change our ‘lifestyle’. 

The modern challenge of high-performance software delivery 

Why are software testing pains intensifying? It is because the traditional detective-style role of testing breaks down in high-performance software delivery. In such contexts, the primary goal is to deliver value to the business by producing quality software at speed. High-performance software delivery was once the exclusive domain of a few elite, pioneering organizations. Now, however, Agile and DevOps methodologies have become ‘mainstream.’ Most organizations are well into the process of adopting these methodologies, but the real change and accompanying testing pains do not manifest immediately.  

According to Tuckman’s Stage of Group Development, organizations must progress beyond the Forming (focus on facts and methodology) and Storming (characterised by resulting emotions, doubts, frustrations) phases, and move into to Norming and Performing phases. It is in these latter stages where the fundamental change in mindset (values and actions) occurs in both teams and management. Merely changing organization charts and adopting Agile rituals is not enough for Agile to really work. 

Test automation is not the silver bullet 

The adoption of test automation is a reaction to these changes. Traditional ‘manual’ testing was seen as ‘slow’. It was believed that the faster delivery of quality software could be achieved by faster testing. Consequently, test automation was touted as the silver bullet. However, this is a fallacy. The primary cause of a slow ‘testing phase’ is not the speed of test execution (which is typically the only aspect of testing accelerated by automation) but rather the poor quality of the result of the software delivery process. As Jerry Weinberg described in 2008, what we see is not a long and slow testing phase, but a long and slow fixing phase. 

Although not the silver bullet, test automation, when properly implemented, can contribute significantly to alleviating testing pains. Its adoption is now widespread, but, unfortunately, it has achieved varying levels of success. In some organizations, it may actually exacerbate the pain, reducing overall productivity and increasing quality risks. 

A better way forward 

In the software testing world, we’ve known for years the root causes of software failing to be fit for purpose. These include poor requirements, poor design, poor programming, and, not least, poor testing. These all stem from inadequate human cooperation, which leads to misunderstandings and miscommunication.  

High-performance software delivering is now offering us an opportunity for a fundamental change in our approach towards quality assurance. In the past couple an increasing number of voices in the software testing industry are describing a fundamental shift from software testing to Quality Engineering. While traditional software testing and QA practices remain critical, there is a movement towards a preventative mindset and a focus on built-in quality, based upon Agile, DevOps and Lean principles. 

  • Shift-Left (or more accurately “Shift-Everywhere”)  
  • Proactive quality assurance 
  • Close collaboration and shared responsibility within cross-functional teams 
  • Continuous testing and quality assurance closely integrated into the DevOps ‘infinity loop’ and continuous integration and delivery (CI/CD) pipelines 
  • Automating everything that makes sense to automate 
  • Early and continuous feedback 
  • Continuous learning and improvement 

Implementing these principles requires good organization, effective processes or guidelines, and skilled people with right mindset. Adopting them can enable organizations to deliver valuable software to the business at speed.  

Author: Phil Royston

Together with the company's other co-founder, Marcel Veselka, he sets the overall direction for Tesena. As CEO, together with our leadership team, Phil takes overall responsibility for implementing our strategy, improving the quality of our services and functioning of the company, and for keeping our Teseners as satisfied and engaged as possible.