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.