9 Blunders Made by Software Tester

January 5, 2021

1. Not making Test cases before development starts

Making Test cases is an important part of development and this should be done before starting the development. If developers do not know what use cases they need to program, they will certainly miss out many points and it will be iterative and it will delay the work flow to cover up these test cases.

Successful completion of testing requires a well-structured plan which describes every actions step by step. Each mobile app/website under test must have its own test plan and cases which states what test to execute and this will help programmers to plan the way they code. Therefore important elements like, scope of testing and requirements must be first defined.

There is a saying that two products in the same horizon are not built the same. So every tech product has its own story, use cases, plan and requirements that fulfill user’s purpose.

In order to prevent such mistakes, it is recommended to write an in-depth description of the project target, project cases and its target consumers, requirements, test cases and the expected result of test cases.

2. Using same test data every time

Regression testing is the most crucial thing in the test life cycle but executing the same unchanged regression tests will not find new bugs. It is the same as Muscle training in the gym – Same exercise and reps are not long term benefits therefore either we try more reps or advance versions of it.

When a tester is using an unchanged test scenario for several iterations then a moment comes when these scenarios wont detect new bugs.
There is a saying – Insanity is doing same thing and expecting different results.

3. Not working as a Team

Communication is as important as any other skill. Efficient teamwork is a key element in project management with quality assured.

During a conversation with teammates, a QA must play the role of a team player who is finding rare use cases and help developers to improve the product. Blaming developers and their work can create a tense and toxic atmosphere and it could delay the project.

A Tester should be diplomatic and a team player, very often people forget that a program is developed with thousands of lines of code and it is common to miss one or another scenario while coding. So a team player should point out developer’s mistakes in a positive way to ensure the quality of the product.

4. Skipping regression testing after new feature

It is awesome when a feature being added works perfectly, but you cannot ignore the rest of the functionalities. A tester should do regression testing each time after adding a new feature to make sure that it has not caused any new defects and the basic functionalities of the modules are still working.

Often, many testers forget about this rule and do not perform regression tests as they think it is not that significant for old functionalities that always work. You cannot assume that if something was working earlier, that is still working.

5. Avoiding automated testing

If a website has 500 pages, Its tiring and time consuming to test each page for 4xx errors, so the best way to do it is to automate these unit tests. Every framework used in modern time provides automated testing methods within. Some QA may not know how automated testing works but it is worth learning.

It is advisable to learn automation and keep learning if you want to make testing and the product relevant.

6. Ignore a bug when you see it and thinking it’s not that important

As testers you must address any situation you’re facing, even if one doesn’t have any immediate solution for these bugs. It is better to note them down in bug tracking software and park it under KIV (Keep in View) for future discussions rather than acting like it is not important.

7. Making assumptions without asking questions or asking help

As a QA, you should never make assumptions!
Best way is to ask out all the questions, it will help you to understand the product requirements and features, what needs to be tested, what was added or how the app under test is supposed to behave.
Most of the time we are scared of being judged or afraid of looking stupid in front of our team members which results us in trying to find solutions to our problems by our own. It is not a bad thing but as a rule above – “Communication is as important as any other skill”

8. Not thinking as an end user and skipping negative testing

It is better to put your feet into the user’s shoes and imagine how he will use and feel the application you are testing. It is known that the end user is the best tester which finds critical bugs.

9. Not describing the problem in detail & not providing additional information.

Many people may find it hard to follow the requirement for describing the test. We testers use “What? Where? When?” rule. This rule serves to quickly and completely portray the substance of the mistake, where it happens and under what conditions. It is a general rule, an algorithm for compiling a description of an error. Usually, the absence of any part makes the description less informative.

A frequently made mistake, a bug can be duplicated distinctly under specific conditions, for example, a particular program and form, screen goal, working framework and so forth. To reproduce and correct an error, it is extremely important to know in which version of the browser and on which operating system etc, a bug was found.

Click here for more about: