This month, we have a special post from our tester Pramod, from India. Read on as he tells us a little about himself and his testing experience, and explains the Seven Principles of Software Testing, a set of well-known principles used by the ISTQB (International Software Testing Qualifications Board) to certify software testers.
Hi, I am Pramod L. from India, a nation known as the land of festivals. We enjoy celebrating festivals throughout the year, and I celebrate being a software tester similarly. For every assignment I undertake, I determine why the client is looking at getting their product tested, and enjoy finding defects that bring smiles to their faces. I do not possess any formal qualification in the field of software testing but have been a part of the industry for more than a decade and a half now, and have enjoyed every minute of my journey. Presently, I am working in managerial capacity for a leading Indian IT MNC.
About Software Testing
So, what exactly is software testing? You would most probably come back with textbook definitions of the subject, including related topics like validation and verification. But let me ask you a question. Do you remember your school days? We had to appear in exams periodically, and based on our performance, we were either promoted to the next grade, or made to study in the same grade again. So, what was happening there?
We were being evaluated for the level of knowledge we had gained throughout the year. These exams were also called ‘tests’ informally, right? So, we were being ‘tested’ against some specified criteria. And this is what testing (and more specifically, software testing) is all about. We evaluate software against some specified criteria (no matter whether it is specified explicitly or implied, documented or communicated verbally).
Principles of Software Testing
Now that we know what software testing is, let us try and understand a few basic principles of the subject.
1. Testing can never ensure the absence of defects: Always remember that testing can only detect defects present in a program. In case no defects are detected, it does not mean that no defects are present in the program.
2. Exhaustive testing is impossible: Testing all combinations of inputs and outputs for a program is impossible, except for the most trivial of programs. Use risk analysis in order to prioritize application areas for testing.
3. Early testing is beneficial: The earlier in a SDLC (System Development Life Cycle) you start testing, the better the results will be. Early testing helps in removing defects earlier, thus saving time as well as effort.
4. Defects are likely to be clustered: Concentrate more on testing those areas of the application where a large number of defects have been found earlier.
5. Test cases become redundant over a period of time: If you are trying the same tasks on successive versions of an application repeatedly, they will eventually become ineffective. So, innovate. Change the way you execute individual test steps contained in tasks (test cases), or use different test data. You should actually benefit from executing test cases every time.
6. Testing is context dependent: Always remember that context matters. The type of testing you are likely to perform for an MCA (Mission Critical Application) is going to be significantly different from what you would perform for a routine run-of-the-mill application. Compare your comfort level in boarding a flight (whose navigation software has not been tested thoroughly) to your comfort level in using a software for choosing the best shade of paint for your home (that has been tested similarly). Obviously, you would never want to risk your life by boarding a flight being navigated using insufficiently tested software.
7. Testing cannot help if the product being tested is not what has been requested: This principle termed ‘Absence-of-errors fallacy’ is really the simplest of them all. Regardless of the amount of testing you perform on a calculator application, it will not help if the user wanted a computer and not a calculator. So, concentrate on understanding client’s needs and requirements unambiguously, and accordingly, proceed with testing.
My advice to my friends in the software testing industry would be to never lose sight of the objective for which testing is being performed. Always understand the test objective and test requirements thoroughly before starting with testing. Secondly, do not ever blame any member of the development team personally for any defect. Instead, work with them in order to identify the root causes of observed defects, and resolve them. Finally, never ever give up. If you are encountering a defect and the development team is not able to reproduce it, it may be a kind of infrequent bug (sometimes called a Heisenbug after the famous Heisenberg’s Uncertainty Principle). Listen to your heart and log every defect you find, don’t be discouraged by metrics that say otherwise!
A big thanks to Pramod for sharing his story and software testing advice! If you want to hear more from Pramod, we recommend that you check out his blog about software testing here.