The QA team starts testing a software/product and there are “way too many” defects. Every other scenario is failing, new flows are explored & clarifications sought. What would be the strategy now?
Adopting technology is important, but blind adoption is different than logical application of Technology. When I see it – looks like everyone wants to fit the tech-term anywhere in the test process and call it tech-driven QA. But how do you measure the ROI from client perspective? Do you compare Super-Tech.QA vs. Functional QA? Or Super-tech-tools are cheaper than the required man power? Nah! Everyone says “All these are long-term benefits, no short-term advantage”, but then eventually forget to measure the ROI in the long run as well 😛 On the other hand, due to all this fuss we have somewhere neglected the original Tester.
How come you are able to find defects in already-tested flows? As an end-user there are numerous possibilities of inputting invalid data and then expecting correct behavior.
Recently one of my LinkedIn discussion gained much traction. Although I don’t know the reason – may be it was uncommon OR way too common among testing enthusiasts. The post got reactions from the who-and-who of the QA world – ranging from Testers to Managers up to VP Products. So thought of sharing the insights to a larger audience via a blog post. In this article, we will look at the options available to a QA team if there are ‘way too many’ defects in the application. Here we go…
The world is driven by beliefs. It may be in God or Technology. Over a period of time every society lay down a set of philosophies or values for better organization & operation. Similarly, any technology has its own fundamental principles which have been proven right as the time elapsed. ‘Software Testing’ is no different – it also has a set of 7 fundamental principles that are proven right over the time.
Agree or not, once in a while every one of us enjoy criticizing something – a person or a situation. A conflict between a developer & a tester is not new – it has been there since the inception of Software Testing. After all, nobody likes it when their mistakes are pinpointed & written on the wall. What they don’t understand is – it’s not about ‘You’, it’s about the ‘Software’!
This topic may seem simple to many, but despite of hundreds of web articles – Smoke, Sanity, Retesting & Regression are the most misunderstood topics in Software Testing. There is enormous amount of literature on the subject, but most of them are confusing. The following article makes an attempt to address the confusion. Before understanding these terminologies, first & foremost you need to understand the concept of Software Build.