Different styles of testing
I like art and enjoy drawing and painting. When I first get started, I was a bit lost in art museums with all the different art styles - impressionism, expressionism, neoclassical and so on. I had to read some books about art history to understand it.
This same thing happened when I was into testing for first several years. There are quite a few school of thoughts about testing and everyone seems to have their own option about it - ISQTB, Rapid Software testing, Model-based testing, Risk-Driven testing, Agile/Shift-left testing, TDD, BDD and so on. Unfortunately there is no book talking about testing history, at least not that I am aware of. The fact there is no proper university level education about testing makes it more complicated.
Years later after my struggling in this field, I have realised that each of these styles are coming from the software development methodology at the time period where this style started and the background of the people who started it. For example, ISQTB was found around 2002 where waterfall was still dominate and the industry needed a set of practice to quantify the testing process and make it applicable universally. It then slowly transitioned itself into agile testing world when agile and lean development models became popular beyond 2010s. In contrast, James Bach and Michael Bolton believe that the testing should be context-driven and the testers should adapt the testing approach base on the project and team context. They have developed a set of practice utilising heuristics and exploratory testing and called it Rapid Software testing.
Around the same time period, Kent Beck from school of Extreme Programming "re-discovered" TDD from an ancient programming book from 1960s as a way of coding practice. In response to TDD, Daniel Terhosrt-North pioneered BDD as a way to bridge business and development/testing.
When agile and lean development became dominate in the industry, people started to borrow the ideas from them and adjust the testing process. For instance, the so-called shift-left testing suggests that the testing should be embedded into each step of DevOps process. People also starts to utilise Lean business techniques such as impact and value stream analysis.
Much like art, testing is ubiquitous and almost impossible to quantify. However, like anything else in IT world, people tries to categorise and standardise things to make them more manageable including testing. Organisations such as IEEE, ISO and others have defined several standards - ISO/IEC 24755:3007, 29119, ISO 9241 and so on. The most commonly referenced one are ISO 9126 and its successor which describe the attributes of quality. In my view, the reason why it is referenced so often is because it gives a nice umbrella overview and has been embedded in ISQTB training.
With the cloud being more and more popular, the understanding of testing starts to shift again. With testing starting to move to production and daily operations, new buzzwords like test-on-production and shift-right-testing are coming our way. Similar to studying art history, one way to not get lost in all these buzzwords is to understand the context behind them. This could be the time period where they came from, the problems they tried to address and the background of the people who pioneered them.