Throwing keywords and calling to Shift – to the left and to the right, towards Software Quality ad infinitum in Software Engineering, have only confused people and has not delivered the results that they have promised, so far. These keywords serve very well for SEO and make great LinkedIn title phrases, but are they being practiced? Let’s take a look at what shift in testing is required at the moment.
To find and prevent defects / mismatch as early as possible has always been the endeavor of Software Testers. In an organisation with good culture and best practices, testers get involved right from the requirements, and sometimes even in discussions during conceptualization – to assess product’s suitability to market. I am not sure why ‘Shift-Left’ or ‘Quality Built-In’ or ‘Quality Engineering’ should be new buzzwords for already existing best practices. I suspect that this is happening because of the new generation of app startups which want to develop products (without testing), where the idea to prevent bugs earliest is being sold as old wine in a new bottle.
The ultimate goal should be to have a better product. But by making the cycles smaller, the value of having better products seems to be getting lost. Software Engineering and Software Testing are commoditized into 3-months involvement, with engineers moving from domain to domain within a short span, with the only constant being the testing tools that they use. This is especially prevalent in software services. If an engineer shifts their domain so quickly, how much understanding and knowledge would they have on that domain, and how are they expected to build better products? The intention of these organisations seem to be get the automation scripts in place, so that any engineer who comes in can run the scripts and quickly get the product out. The reasoning is that engineers come and go, but I got to have the scripts which can be used and maybe even ported to other projects. So, engineers are the commodities and the scripts are the assets!
I had already written about the sorry state that our apps are in. We definitely need a shift in our thinking, not ‘shift-left’ or ‘shift-right’ to be clear. Not to take testing off the pipeline (because for some, that seems to be the only hindrance in the “Back to the future” ride). So, what kind of shift is required?
The shift that’s desired is to have intentions about better product which is built with rationality, judgement, and analysis, with sufficient time spent on development and testing. We could say that ‘testing’ can be testing of an hypothesis, that the product would work in a certain way, as per set expectations. There would be several such hypothesis during the development of the product, which need to be tried and tested to be suitable for the market. If so, there would be a need for both internal and external testing – internal, to test if the product meets the customer expectations, and external, to get feedback from the end-users. By removing the internal testing (which is done by humans), not only we are putting the organisation’s brand under risk, but also putting the product and the lives of people who are using it under risk. We should internally test more before product reaches the customer.
Let’s test thoroughly before we deliver.
For detailed consulting on shift in testing in Software Testing, feel free to contact me.