How QA has changed steadfastly..

My first exposure to QA as a program manager more than a decade ago, was to think of QA as a Quality control organization that needed to be brought in towards the tail end of all the execution. Even though planning and estimation was done to include QA, they were inadvertently brought in, as a “Just in time” team.

This reflects the traditional mindset of how QA teams started their journey! And being on the other side of the fence for the last decade, has made me realize how misconstrued sometimes job roles are when seen at a distance

Today QA is more of a mindset, than just an organization. Since what clients expect out of QA, is to “Collaborate to win”. When they say they want QA’s, they want somebody to understand the domain and business well, understand the soft spots of the system and test for it, and while at it, use the latest in technology and tools to make it happen.

Infact, the birthplace for many an “automation” started off from the QA arena, and has slowly enveloped the whole of the IT organizations and market place and the span has extended beyond just automation in the QA phase, to “Automation anytime, anywhere”, and that which helps to achieve efficiency and speed to market.

QA today is not just about the organization that flashes the report card for programs. They do not solely exist to track metrics, highlight the defects and serve as an application conscience check before turning into the production region. QA today has transformed itself to become QE, the teams and organization that help you add in the strength to the code base, the minor tweaks that make the development quality stronger and superior, and in the process avoid the spillover of defects to the subsequent phases, whether it is integration or QA.

Think of it this way - When all of us started our studying, what we used to do is self-study, then reviews and revisions, and if comfortable, group studies and reiteration. All these rounds of preparation made sure that our success rate to come out of the exams in flying colors is greatly enhanced. Typical to how QA started as an independent organization and was involved with many cycle runs of testing, to ensure that the production quality was perfect

And then the education system itself changed, such that the outcomes mattered a lot more than before. This meant that self-study and group study was not sufficient and so we had to engage more creative learning in standards such as 10th and 12th, to ensure we reflect more deeply and prepared more effectively. Part of the things if you remember, was involved in going through many prior year question papers, to ensure that we were thoroughly prepared for the journey. Much like how QA had to “Shift Left” and the smoke and regression test cases used to be shared upfront or concepts like TDD or ATDD was adopted to make sure we knew the answers for canned questions.

Now as the complexity of the exams increased, and the competition became nationwide, and international so too had to be the refresher courses for the exams. So a lot of times whatever was learnt for a year, had to be “crash coursed” as “entrance exam” trainings to get exam ready. And that is how automation started gaining traction. Regression automation, was considered a corner stone, to make sure that all that was fixed, was done rightly, without causing breakages in the system.

As time moved on, and when we fast forward to today, the education system feels that we should catch them early, meaning that we cannot wait for a FIIT JEE or a NEET training towards the tail end of the academic curriculum in the 12th grade. If we need to make students speed to success faster and stronger, then we would have to start the “FIIT and NEET trainings” in parallel with their 9th grade itself. Similar to how with the advent of Agile, stakeholders do not want to wait for Smoke and regression automation suites, to separate right from wrong. They would rather resort to “Functional automation”, to find newer ways of discovering bugs even while test cases and code was being written.

 While this blog only explains the process change, a much larger change has already evolved with the “Work force transformation”. Stay tuned in to know more of the same.

Just a closing note is that, the QA phases and processes are as effective as we make them to be. So if you want strong “quality outcomes at speed”, go ahead and empower your QA organizations. They are sure to work wonders for you, and make you look good before your very important stakeholders in the organization!