Five Test Automation Mistakes to Avoid - Must watch for testers!

How to be successful QA leader? - Future leaders, QA Leads and Managers


Saturday, May 30, 2015


12:11:00 PM Posted by Prashant Hegde 12 comments

Myth 1: It is the testing team’s mistake that the defect was missed. 

Reality: Whenever a defect is missed the QA are assured to get blamed. Most of the times the development phases run long and QA never gets enough time to test with the rush to release. It makes no sense to expect the testing team to test all possible scenarios in the short period with allocated resources.

Everyone is equally responsible for the defect being missed. The factors like changing and poor requirements, insufficient time for testing, aggressive schedule, last minute changes, lack of resources, lack of project management etc might be the reason the bug was missed.This myth is still believed by many stakeholders and even testers themselves. Many testers do not realize what their role is and blame themselves for a missed bug.
So testers don’t blame yourself for a missed bug it is not your fault. It does not make you a bad tester (AB De Villiers misses a catch! Does that make him a bad fielder?). 

Ensure that you introspect and try to figure out why the bug was not caught and try to increase your test coverage.

Myth 2: Testing is easy and anyone can test software.

Several people assume that testing is an easy job as there is no/less coding involved and anyone can be a tester.

Reality: Software testing is a challenging job it demands traits like understanding testing methodologies, creativity, problem solving, planning, eye to detail, patience, communication and lot more. It is never easy to come up with scenarios to break the system.

This myth is still deep-rooted in the minds of people. You often see the developers who failed to deliver being pushed to testing with no formal training by the management assuming that anyone can test. Software testing is a passion and everyone cannot excel in it. It’s our responsibility as a tester to convince the management that they are wrong.

Myth 3: Testing team alone is responsible for assuring quality.

Reality: The objectives of testing include finding and preventing defects, gaining confidence on the system under test, providing information related to app quality to the stakeholders so that they can decide whether or not to have a release.
Quality is not solely the responsibility of the QA. Quality is everyone’s responsibility. Developers are responsible for the quality of code they write. A defect is never a QA issue.Testing provides information regarding the quality. Testing process cannot improve the quality unless the bugs reported are fixed.

Myth 4: We can test everything and we can have a 100% bug free software after testing.

Reality: “Exhaustive testing is impossible” this is the one of the basic principles of testing. Testing all the input combinations and preconditions is not feasible. The bugs will remain in the software even after the testing is done. Testing can show the presence of defects but cannot prove that there are no defects. Even if testing cannot find bugs it’s not the proof that the software is bug-free. As a tester one can focus his tests and uncover the defects based on project risks, priorities and project constraints (like time, budget).

Myth 5: Test Automation will replace manual testers and we can automate everything.

Reality: Automation tools are available to assist manual testers to automate their repeated tests and not to replace them. Everything cannot be automated. Automation is not feasible when the requirements are changing and it’s never wise to automate the feature that needs human intelligence and intuition. An automation tool cannot tell if the look and feel is good, if the app is usable etc

Myth 6: Developers need not have to test, there are QA to catch bugs.

Reality: Developers need to perform tests on their code to make sure that it’s functional and ensure that they have created a quality feature. Developers usually perform unit test and integration tests to ensure that their module is working independently and when integrated. Several issues that are caught in unit tests may never be found when tested manually. Developers ideally need to perform functional sanity tests before giving the build to QA.
It’s often said that developers cannot be good testers as they have parental feeling about their code and inability to think as an end-user. But good developers know how to test their code, they remain self-critical,they find and remove defects before others find it. Software development methodologies insist on developers designing tests before they start coding and executing those tests continuously as they change the code. This approach promotes early testing,early defect detection and is cost effective.

Myth 7: The software testers are paid lesser than the developers. There are no growth opportunities if I choose software testing as my career.

Reality: Those days are no more when the developers were paid more than the testers. The testers have equal opportunities to grow in their career. An efficient tester can even draw more salary than the developer of similar experience.

These days quality of the product directly effects the brands reputation. The users will get negative opinion on the brand itself if their app or website performs poorly. So no one is ready to compromise on quality. Organizations are always looking forward to work with energetic testers.
According to a recent report by Fortune magazine- Software testing is the one among the top 10 in-demand careers of 2015.

Saturday, May 23, 2015


11:07:00 AM Posted by Prashant Hegde No comments

In rapid development processes like agile methodology its important to identify and prevent the bugs in earlier stages of the product development. QA activities should start earlier in the product life cycle.  Pair testing is one of the techniques that can detect the bugs in early stages of development.

What is Pair testing?

Pair testing also called as Buddy testing is an approach where two team members sit together for an exploratory testing session by sharing a single computer and they test the same application.  One of the member executes the test (Has the control of the keyboard and mouse) and the other suggests ideas, notes the observations, record the bugs etc. A pair testing session can last from 60-90 minutes.

Between 2 Testers- Testing-Tag team

Here two testers sit for an exploratory session sharing a single screen. They test a feature by mutually sharing ideas.The two testers involved may or may not be of the same knowledge level. It can be the Test lead and a Jr tester. Pair testing can benefit both of them. The junior tester can learn and explore the application with the expertise of his senior. The junior tester can come up with different test ideas than his senior who has been testing the same module for long time. This helps the senior to update the test ideas and look at the application in a different angle.

How does it mutually benefit?

  • Pair testing ensures that there is exchange and generation of new ideas.
  • Pair Testing is the best approach to mentor and train the newbies in the team.
  • Testing in pairs increases coordination between the testers.
A tester working alone may jump to incorrect conclusions but in pair testing there will always be another person who can verify it. Two pairs of eyes are always better than one.

Between Tester and a Developer

When a developer develops a feature, he runs the unit tests and also a quick round of testing to ensure that the feature is working. He then invites the tester to test the functionality on his machine. If the tests pass then developer commits the code to the master. The tester performs further tests in the testing environment. If the tests fail then the developer continue to fix the issues. In this way pair testing saves a lot of time and identify the bugs in early stages.

There is a huge contrast in the mindset of a developer and a tester. The best part of pair testing is that it eliminates the barrier between the tester and the developer. The tester need not have to log the bug and explain the steps to replicate since the communication is direct it saves lot of time.

How it helps Developer
  • The developer can learn more about the application by exploring with the tester.
  • PT session will make the developer to come up with great testing scenarios by their own. 
  • PT session helps to analyze and find the root cause of the bug.

How it helps the tester

As a tester you will encounter weird bugs that are inconsistent and occur randomly. In a Pair testing session with a developer you might find a pattern with the developers knowledge.The developer can then link between the issues as its his own code.
Developer can find out which portion of the source code is affected by the bug. This can help you to focus your testing on impact areas in the future tests.
There can be several other people that can be be a part of pair testing session based on the project needs (Like a business analyst and a tester).Pair testing is effective when a developer and tester are teamed.


Pair testing has proven to be successful when the deadlines are close and we need a quality product in a short span. Pair testing can help the team to get together, share ideas and be benefited by each others strengths. 
It's really cool when a tester and a developer work together to ensure one common goal "a quality product".

Popular Posts

Total Pageviews