Software Quality Assurance Myths or “Why it takes so much/long”

Myth 1 — We do not need testers, the development team should write without bugs.

  • Missing requirements errors. Requirements testing is additional specific activities and it is needed to know rules on how to perform it effectively.
  • They do not look at the product as a completed system as END user/tester does.
  • They may not know the specific integrations of modules and functions, but only those parts that they develop themselves.
  • Delivery deadlines — people can work worse due to the need to quickly complete a project.
  • System and integration complexity may not be taken into account during testing and End to End cases are not carried out.
  • Defects accumulate with the growth of the product and the scope of necessary regression testing increases. Developers have their direct responsibilities to develop features, and the goal to meet the deadlines will lead to skipping important regression testing.
  • They may miss changes in requirements.

Myth 2 — Why will testing take so much time? We just add one button.

  1. The product is in the pre-release phase. All functionalities have been developed and the client wants to change something. In this case, the tester will check not only the button and its functionality, but they will also look for potential disruptions that may happen as a result of these changes, connected functionality or modules to avoid regression issues (issues in previously developed and working functionalities) appearing. Nothing should be broken by the changes the developer has made.
  2. The product is in production (users are working with it) and we are expanding it. Here, the tester’s focus is not only on the button (functionality) but also on the fact that users can perform ALL operations that are important to them. We will not release a separate feature — every time we will release the WHOLE PRODUCT (specifics of the development process). It is important to check that users can still work with it as before and without any new problems.

Myth 3 — Testing should be 30% from development estimation

  • reading and reviewing specifications and requirements;
  • preparing test documentation;
  • planning needed testing activities;
  • preparing needed test data.

Myth 4- You said that testing will take 4 hours — why don’t I have a finished product even after a week? Or why don’t you fit that into your testing estimation?

Myth 5 — Automation is an unjustified investment — is it better to add one more tester to the team?

  1. The product will be developed for more than six months
  2. Many environments/browsers/platforms to maintain and test.
  3. There are many routine operations in testing product functionality, test data preparation, test environment setup.

Myth 6 — Why should I increase the size of the testing team if my development team does not grow and we have been working like this for half a year?

What exactly can be included in the Quality Assurance estimation

  1. Requirements review and testing, as well as deep-diving into the project idea. Software Quality Assurance can find issues in requirements that can save a lot of money before release.
  2. Communication — QA tester is a full-fledged team member, who should know what is going on or what will be changed in the project to get ready for testing or to prepare questions for the team that will avoid issues in the future.
  3. Functional testing — reviewing that implementation is being performed according to the functional specifications.
  4. Test-data preparation, planning of testing activities, test-documentation preparation.
  5. Describing identified issues in the issue-tracking system for all team members. This action is needed to have a review of the actual product quality and make correct business decisions about the upcoming release.
  6. Cross-browser and cross-platform testing for the product being reviewed on different devices and in different environments.
  7. Defects validation to review fixed defects in the code and regression testing to check that code changes did not add new issues in the already tested parts.
  8. Reporting.
  9. Non-functional types of testing — security, performance, automation testing.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store