It’s been close to 18 years I am involved in software testing and learning something new all along. It was interesting all along! When I remember those early days when I started testing software verses how I test now – change is really surprising. Those were days when testing was considered as separate activity in software development. Typically someone not ‘preconditioned’ by program was preferred to perform testing so that he/she can look at it critically, from user’s perspective rather that from programmer’s glasses knowing design limitations. This also in a way promoted testers to keep away from code since knowing the code was synonym for being preconditioned with design limitations.
Typically it was more of manual testing with lot of repeat runs till the time software reached stage which was acceptable for production release. Was it enjoyable? Answer is yes and no. Yes – for the part of test design and first exploration of feature, No – for the part where repeat execution of same bunch of tests was involved which typically occupied majority of duration of test cycles. More frustrations were evident when customers reported critical issues. Testers were considered as “most responsible citizens” for such defects and needed to prove their innocence with elaborate test designs/ test plans/ reported defect list. Other aspect of this style of testing is unhealthy competition between developer and tester. This would many time reflect in poor quality of code. Testers were more happy in finding a bug in order to score their performance appraisals than really worrying about quality. They were also promoted by management as overall philosophy those days was – keeping these two groups fighting is good for quality. Though it may work sometime overall it was extremely costly. Also it never fostered culture where everyone can do well. If testers are doing good means developers are not so good and vice versa. I personally never liked that sort of environment. Testers were really struggling in those days since only way they could prove their talent was “number of issues” they could find, as if developers were criminals and testers were secret agents trying to prove their crimes. Repeated runs after each defect fix was another pain.
Then there came an era where people tried solving “Repeated Run” problem using user actions record replay tools. This was sort of relief for testers since they got an activity where they could also develop something, automate their regression tests. This way – not so interesting part of repeated manual regression was addressed and test design as well as test automation both now sounded pretty interesting pieces. However it came with it’s own baggage. Most prominent was instability. Testers typically started automating their manual regression scenarios having business logic, integration, workflow, navigation, user interface validations everything using record replay tools. Changes in any of these areas would result in failure of such automated tests. At any given point 30 to 40 percent of these tests would be on ventilator because of software changes. Since these were assets of testers and failures were coming later when software is already delivered for testing there was seldom time to fix them. So this approach though reduced manual regression to some extent was not really true relief. Teams tried solving this problem by keeping dedicated people who would just add/fix existing scripts. This was really strange role since it does not involve real product development nor having test design flavor of classic tester. It created new “automation expert” category which was good in record and replay tool however far away from having domain knowledge as well as contribution in product design, development. Other baggage with this approach was it’s speed of execution & resource requirement. Though faster than manual regression still it was far away from being giving feedback earlier enough. Overall – regression though improved somewhat from being purely manual still not really bringing enough benefits which everyone were aspiring for.
Then came Agile. Frequent releases to production became need to keep one ahead in the game. Regression testing became even more challenging. However Agile brought with it upside down change in approach to deal with quality problem. It made developers as responsible as testers. It innovated ways to automate tests and make them more and more faster / cheaper and still effective in doing their job. Developers started investing heavily in Test Driven Development / Behavior Driven Development. Testers started heavily collaborating with developers in order to ensure tests are automated at right place. Unit test coverage became key and software designs started considering “Testability” as important criteria to enable quick and effective automation.This also brought testers more close to code. Testers involvement in white box testing/code reviews increased. In some of the leading organizations boundaries between developers and testers almost faded. Testers are now more like domain experts having development skills. This has made them more valuable than anytime in past. While test automation made sure that all repetitive and regression tests are no more manual testers also got more time to do more and more exploratory testing which added more value to test coverage.
Overall innovations in software engineering has made lot of positive impacts on Quality and people who are involved in building Quality. I also keep hearing debates whether we need separate role of tester anymore. Some companies take pride in mentioning they have no testers. I would argue this because what they are saying is just from designated role perspective. What they mean really is they do not have “tester” designation. Testing is still there and mostly done by people who are developing. I am sure developers in such organizations are spending close to 30/40% of their time in designing and writing automated tests. There may be some chunk of people doing this for 100% of their time and called as Developer. Another important aspect of this argument is mindset. Testing requires critical mindset around quality and not all people have it. Software development needs some people who have creative mindset and some people who have critical mindset. Typically critical mindset people become better testers. It doesn’t matter if you want to call them tester or not.
I personally like testing mindset because it somehow resembles to detective who is trying to find real culprit. It challenges my mind. It allows me think in different ways. It brings me end user perspective and now a days it also requires me to learn latest technologies to automate. Indian mythology has three principle roles Brahma – who creates, Vishnu who maintains and Shiva who identifies/destroys evil. I believe these represent three mindsets and tester mindset represents Shiva. We need all type of mindsets to be successful and it does not matter what we call them.
Tester mindset have immense opportunities now, what they need is to identify what empowers them to be faster and deeper and start learning!