The year 2010 not only marked the start of a new year but also a new decade. With this, the world said Good bye to another significant decade in the world history. Virtually every news channel, new paper, websites ran special series on the important events, happenings and people of the decade gone by. All this got me wondering, Software Testing as a profession too completed a rather eventful and a positive decade. It made me look back on time gone by and caused me to grow in realization that most of the things about our profession have indeed changed and evolved for good.
The text that follows this paragraph is the experience nuggets as i have observed. These are no way the researched facts but just the way i have seen Software Testing evolve.
Scope of Testing:
Start of the decade: We will develop the product and the Testing team can test the UI.
Towards the end of the decade: I need separate testing teams for Security Testing, Functional Testing, Automation, Globalization Testing etc.
It was quite apparent in the early days of the decade that the Test team was usually associated with testing the Functionality or the UI part. Even for doing that part, there were enough doubters in the organizations. I remember an instance when Development team used to come and say- please log more logic related bugs. Well they were not all that wrong here; the focus indeed had been more on testing the UI. The bottom line then was that due to various factors, the test team was not trusted to test anything beyond what is visible to the user. Performance Testing, Security Testing etc. did not even feature in the overall scheme of things.
I was recently in a discussion with a professional who said that legacy code that’s written for some of the applications 10 years back, there was no special consideration given to the Security aspects. The situation now is very different and it has evolved in alignment with the customer's expectations. Apart from superior product functionally, today's customer demands the product to be secure and working with optimum performance. While several factors have led to the transformation of expectations but after-effect has been that this change has been positive for Software testing profession. Security Testing and Performance Testing has become buzzwords and the testing streams that are based on specialized skills.
Start of the decade: I don’t have time now. Please come later for any clarifications.
Towards the end of the decade: Please do some unit testing on the private fix. I don’t want this bug to be rejected after I introduce this fix.
Just imagine the scene- A tester has been tasked to test a very complex product. But there was no documentation. Still the tester manages to test the product, finds a seemingly good bug and then rushes to the Developer to give the news. The Typical developer staring at a screen without a blink of eyelid, does not notice the tester, falls deaf ears to tester's enthusiasm and just says- "I don’t have time now. Please come later.....". I won’t say every Developer had such an attitude then but most of them did have and each generally had different ways to "Ignore" the testers. Some even referred Software QA Engineers as "Questions and Answer" Engineers (rather than Quality Assurance).
The situation that i witnessed towards the end of decade is a lot better. The Software testing job commands a certain respect and the developers community by far realizes that they would not want to release the product to market without having gone through the eyes of a skilled tester. One of the instances that confirms me this fact is that the Developers requested Testers to test the Private binaries to ensure that the bug is fixed and it wont cause the internal builds to fail. Now, thats what i call as "Paradigm Shift".
Start of the decade: Test team should only be involved after the product is developed fully.
Towards the end of the decade: Have you included the Product Requirements document to be signed off by the Software Testing team?
Testing is something that’s done towards the tail-end of the Software Development Life cycle- That is what one of the super bosses of the one of the earlier projects i was involved in said. Well, not really well said. Things actually worked on the assumption that Software testers would be involved in the Project Life cycle only after builds are integrated and ready to test. When i say "Involved" in the last sentence, i meant even the knowledge acquisition of new features, any preparatory activities would start after the build is ready to test. This may be hard to believe now but certainly was the case.
Now, the things are different for good. The projects do not ideally proceed unless Product requirements are formally signed-off by the Software Testing stakeholders. The V-model being followed in essence helps ensure that the test team gets ample space to plan and do what they do the best- Find bugs and provide quality related information.
Start of the decade: We will do lots of adhoc testing on the Release candidate build. We have to stop this release by finding bugs.
Towards the end of the decade: I need to find bugs timely for the quality release. Finding late bugs won’t reflect well on me.
One of the early instances that i remember was testers saving their best for the last i.e. testing the product loosely in early phases and when the release approaches put all the "testing skills" to optimum use and find critical crashes and bugs that would eventually "Stop" the release. And what’s more there was a certain sense of pride when boasting to others as if Testing team had some God given Power to make or break the releases at will. Howsoever naive it might sound now; this was one of the situations in the early days.
Now, of course the tester's mission is more clear and defined, and finding late bugs are not a good reflection on test strategy. By late bugs i mean, the bugs that could have been found earlier. Of course, regressions can occur at anytime in the product life-cycle. But the whole fact of the matter is with some rightful advances in Software Testing Education, the overall expectations are better communicated and known.
Start of the decade: Test only during weekdays.
Towards the end of the decade: Weekend testing. Are you game for it ?
Passion is key to success in Software Testing like in any human endeavor. Well, in early days of the decade too there were people with immense passion for the craft. Testers were willing to go that extra-mile to learn something and evolve in the profession.
All i can say is that during the later part of decade, this has only gone better. Training methods have evolved and there are many success stories that the testers of current genre can look upto. The recent initiative of Weekend Testing community only takes this passion to a higher levels.
Start of the decade: Its good to try and be big fish in a small pond.
Towards the end of the decade: Well, now we are talking about a sea.
"Its good to try and be big fish in a small pond and be a small fish in the big pond" this is how one of the testers in the earlier days of the decade remarked when i was having a conversation about why he chose Software Testing as a field. Small pond as a metaphor for Software testing was indeed short-lived. Probably the reason it became a metaphor at all was because of lack of awareness of the depth this profession possess.
Now, the perception is changed to "Welcome to the sea, folks!". Its indeed a sea, how much ever you learn, there is always something more to learn, explore and eventually master.
Also, in the early part of the decade, the folks used to join Software testing only because they were not considered to be good in Software Development. There were numerous instances that i know of when an Engineer was moved from Development to Testing only because he/she was not good at Development, as it was taken for granted that such a person will be fit enough for testing. I don’t say that we are over this mentality altogether but for sure there has been positive change. People join Software Testing profession thinking of a long term career.
Books on Software Testing:
Start of the decade: Few books on Software Testing.
Towards the end of the decade: Dedicated Shelves of books on Software Testing.
Looking back, the book stores hardly used to have the specialized books on Software Testing at the start of the decade. The literature definitely existed but the information was not as readily available as it is now. Most referred to a book by Roger S Pressman to read about Software Testing, Testing types etc. Also, not to forget the first Software Testing book that i ever held- Software Testing Techniques by Boris Beizer.
Moving on, things are much much better now. I was recently at a book shop and seeing a separate Shelf on Software Testing books, it made me feel good about the visibility this profession has gained over the years. A little glance into the future, i can only foresee this aspect getting better.
Start of the decade: The work that develop does is more significant and hence should be paid more.
Towards the end of the decade: Testing is equally important to the project, there is no reason why Software Test engineers should not be paid equally.
Pay and Salaries are always a sensitive issues. In the early days of the decade, Software Testing was treated as a poor cousin of Software Development by many holding the plum positions in the organizations. And this led to being given the special treatment to Software Development team not only in terms of pay but also in terms of rewards and recognition. I remember once, in one of the projects that i was involved- there was a discussion on whether Testers name should be included in product's Easter Egg or not as if Testers did not have any meaningful contribution to the projects.
The better sense has prevailed in the recent times. A lot of organizations believe in equality in terms of rewards and recognition and the bridge that existed earlier between Software Development and Software Testing in these terms has been narrowed and vanished altogether in many cases. I see less and less of this sort of preferential treatment.
Start of the decade: We sell our Software only in US. There is no reason to testing multiple languages.
Towards the end of the decade: For our business to survive, we need to go Global. Please equip yourselves to test in various languages.
I would perceive the advent of Globalization testing also an important event in this decade. Earlier on the focus was majorly on the single language speaking markets. But declining profit margins and market share has prompted Software organizations to look into diverse geographical markets and this has led to Software Globalization Engineering taking the center stage. The more Globalization specific changes are introduced, the more it has become mandatory to test them and this has resulted in evolution of Globalization testing as a specialized form.
Do you have anymore experiences to share ? Please share it across.
As a closing note, it makes me wonder why our profession does not have “Software Tester of the decade” recognition. Any ideas?