English | EN 
I remember an Egyptian saying I heard: “Because we focused on the snake, we missed the scorpion.”
How true for our current technological advancements.
Today, as an industry we are still in the digital era, and as we know software development is the underlying enabler for the same. Despite having been here for over a decade, agile/DevOps have become widespread across the industry only in the last few years. We are already talking about the fourth revolution that is the cyber revolution which basically dials down to merging the capabilities of humans and machines amongst other things.
Most of the service industries today have adopted to the same, but what is missing is the real value that we derive out of these newer methodologies. Why is that?
As a practitioner for over two decades in the so-called software testing or the quality engineering field, my personal POV is that we have left the basics far behind while chasing the advancements in technology. Let me give an example from my own experience – I have been a marathon runner for some time now. When I ventured into the sport many years back, we went into it without proper training or gear. The only thing that I initially knew as a runner, thanks to my fellow runners and the Internet, was to have a proper warmup before you step out for a run, be at a short or a long one. The importance and impact of the warmup on our muscles, both pre and post-run was unparalleled. We were not specially trained for running not that we have high and gadgets like Garmin or Fitbit that helped in measuring our heart rate level in beats per minute and other key indicators to help us perform better, methodically. But even for those who wear a Garmin and train with it, you still have to do your basic warmup before every single run; this is a clear and simple example which explains that basics cannot be forgotten or else it impacts your overall performance. Today, in the world of agile/ DevOps way of working, out of the three critical dimensions of the quality engineering (Or software testing) – people, process, and tools, we are totally focused on the tools and people parts. Somewhere we have completely lost on the Process dimension, which is the basics.
Today, while we have SDETS that can work on multiple technology or tools, we fail to focus on coaching or people on the basic principles of quality engineering. I have personally encountered issues like teams jumping on to developing automation scripts without focusing on the importance of having a checklist for self-review of course, peer review (you can even use tools), understand the whole process that would impact the automation framework, challenges is the flakiness of test, etc. The impact is that we are not able to deliver what is expected and when we bring in an architect to review the whole engagement the major issues that come out are on the third dimension of the process -how well the team is managed, whether enough time is given for reviews or not, whether the team members get inducted well before they start delivering, whether they understand the bigger picture.
Today, most of the practitioners in quality engineering teams struggle with defining the right level of KPI – not only defining but also understanding the importance and measures that are needed to be taken. Example: I have personally seen teams not clear with differences in KPI to measure efficiency versus effectiveness. We are still focused on requirement coverage with respect to test cases per requirement. With the advancement of technology, the measurement of coverage (basics) stays, but the needle has moved from defining coverage with respect to the requirement to more around code coverage or coverage based on production analytics (eg: from a normal watch to Garmin).
The famous quote by Grady Booch –“ A fool with a tool, is still a fool” is apt for this situation; unless you know how to use the tools along with the right level of processes, it will never give us the optimal output. For example, in the software community, everyone has access to the same set of tools (automation) like Tosca, selenium, USD, or say other DevOps pipelines. How is it that only a few sets of these firms or institutions are capable to push changes to production every hour while many still struggle to get the changes to production on a monthly basis?
To summarise I would like to say quality should be built in and not tested and for that, the basic principle in the software engineering process (of course the new avatar wrt technology advancements) are of utmost importance – not miss the scorpion.
