Oftentimes, we see that an application’s development and testing are divided into Functional and Non-Functional areas. In this blog, let us look at the latest software development and testing processes, dangers of dividing testing efforts into functional and non functional testing, and the alternative approaches to such division.
When devising a testing strategy, the approach that is generally taken is to decompose the testing into various types. Traditionally, it has been beneficial to split testing into functional, performance, security, integration, interoperability, system, solution, and other types of testing based on the needs of the system-under-test. This was only done for the operational convenience of focusing on a specific aspect of testing so that as a whole, the product would be of a good quality.
Unfortunately, such division has let to unintended negative consequences. The functional aspects of the application is usually separated from the other aspects and the other aspects are clubbed as “non-functional“. While this may not look serious, the team formation and the cultural impact of such an organisation seriously impact the quality of the software. Engineers involved with the ‘functional’ aspects of the application do not think about, plan, and design taking into consideration aspects like performance and security. This leads to silos of software development and testing, and broke the software because the ‘non-functional’ aspects are not considered upfront and leads to multiple unnecessary iterations of software development and testing.
There are ways to address this. With talks about Built-In Quality and Ensemble Programming, every aspect of the design considerations and other considerations can be considered while developing code. This will lead to things getting discussed right upfront and can avoid wasteful iterations of software development and testing. If someone got to be ‘Lean’ in their software development process, then why not be lean in the no. of iterations and the associated testing so that significant amount of time, money, and effort can be saved?
It’s possible, and it’s about getting the right people in discussions while collecting requirements, designing, and developing code. It is about not postponing design decisions on various aspects to a future point of time.
Feel free to chat with me about various considerations in Software Testing.