Tuesday, March 7, 2017

Most Common Myths about Quality Assurance and Testing | David Tzemach

תוצאת תמונה עבור ‪Myths about testing‬‏

Myth no’1 – QA and testing are the same thing

There are some fundamental differences between the two, Quality Assurance is all about the process that we will use throughout the different phases of the software development lifecycle (SDLC), starting from the first phase (Requirements Analysis) and all the way until the end phase (Maintenance).

During a QA process, we will use many techniques, methods, and processes that will increase the quality of the application.

Now, testing is just one phase of the overall QA process, just look at the traditional “Waterfall” methodology and you will see that we have a dedicated phase (Testing/implementation) that belongs specifically to “Testing”.


Myth no’2 – Testing can be ignored

Testing is not necessary in the case of:
  • You can ignore the verification and Validation phases during the SDLC.
  • You have customers that willing to buy a product that was not tested.
  • You can absorb the loss of your company reputation.
  • You do not need to build a confidence in the product.
  • You do not care about the quality of the product.
  • You are willing to absorb the costs of engineering while fixing defects after the release of the application.

Myth no’3 – It’s easy to test/anyone can be a software tester

Sometimes, the level of testing is so basic, so you can think that this myth is true, most people think that testing is all about reading some documents and execute tests, but it’s just one task that involves in the testing process, to be a real tester, someone that can really deal with the effort that is involved in testing large complex applications that worth billions of $, you must possess some critical characteristics and qualities, such as: 
  • You must control the different test approaches, tools, and methodologies.
  • You must know the main aspects of the SDLC.
  • The correct personality and technical skills.
  • You must add value to the testing effort.
  • A broad perspective on the project.
  • You must be familiar with the theoretical materials of “How” to execute and build the tests.
  • You must have a wide technical knowledge (depends on the application that under test).
  • You must know the Business goals and the quality standards that are expected from you.

Myth no’4 – Testing can Guarantee 100% code coverage

Never, there is no way that we can guarantee 100% of code coverage, and to be honest, there is no need to do saw. In any project, there are three main factors that are calculated Quality, Project timelines, and costs.

If you try to provide 100% code coverage in dedicated test cycles, you will increase the costs and timelines. As you probably know, the software industry is brutal when it comes to the software release, the competitors, technology and customer demands will not allow long and slow releases.

Therefore, most companies will prefer to release more products, reduce the costs and take more risks about the quality of their products.  

As I mention prior, there is no real need to provide 100% code coverage, a good testing process is good enough to provide a great quality (Although it’s not a “100%”), depends on few basic factors such as:
  • Available resources (Test environment, Testers, developers).
  • Automation framework that is used to execute the test.
  • The quality of documentation (SRS, MRD, PRD, etc.).
  • The quality and experience of the testing team.
  • Collaboration among the engineering teams.
  • Prioritization of the testing effort.
  • Development methodology.
  • Type of tests and tools.
  • Risk Management.

Myth no’5 – Testing will allow you to release software that is Defect-free

Based on my experience among small, medium and large-scale testing projects, there is always a chance to miss a defect, no matter the quality of the testing process that was performed.

In addition, always remember that no matter what is the quality of the code, there is always a chance that there is a single scenario or dependency that will be ignored/miss by the QA team.

A good testing process will not Guarantee that you release the application free of bugs, but it must provide the following goals: 
  • Increase the customer reliability in the product.
  • Build the Confidence in the product.
  • Increase the quality of the product.
  • Reduce the maintenance costs.
  • Keep the company reputation. 
  • The application is verified and validated against the user expectations and requirements.

Myth no’6 – QA = More Costs | QA = Project Delays

QA will increase the costs and will delay the product release, but isn’t it obvious that the alternative will cost you ten times more? Let’s think about what could happen…

In the Short term,
Yes, you will release the software faster to the market,
Yes, you will reduce the costs (During the SDLC) because you are ignoring a mandatory phase.

In the long term,
Costs -The amount of money that you will spend on Fixing defects that returned from your customers, will be multiplied by the thousands of the costs of the same defect that could be found at earlier stages by the QA team.

In addition, let’s add additional costs like Developers time to fixing the bugs, Technical support team that should help the client, Delays on other projects and much more side effects that are relevant to this issue.

Do you really save Time when ignoring testing?  NO! Each defect that will return from the field will cause major delays on any current project, and that is not even the biggest problem! The biggest problem is that you just cannot predict when the problem occurs and how severe the problem really is.

Business reputation – is it really necessary to explain the critical affect on the reputation of the company?

Testing is not overhead, it’s a critical phase of any major project, keep in mind that you just cannot ignore it!

Myth no’7 – QA is the only team that responsible to perform testing

QA teams have the main responsibility to design and execute the best Test plan (TP) as possible, that is a fact. But if we want to achieve the best quality of a product, the responsibility is divided to many other teams and individuals that belong to the project.

Few examples of a collective effort that can increase the overall quality:
Product managers – Should provide well informative requirements and specifications to help the QA effort.

Project manager – should make sure that the test team has the relevant keys to perform the test they need (Test Environment, Test Tools, Etc.).

Development – Should test their code with both Unit and component tests to provide an additional safe net to the quality effort.

Myth no’8 – More Tests will lead to higher quality

It’s not about the number of tests that you create, it’s about the quality and thinking of each test that makes the difference in addition to: 
  • You use the relevant test methods (Equivalence partitioning, Boundary analysis, etc.).
  • The experience of the testers that will know the weak spots of the application.
  • Tests that were written once the tester understands the Risks.
  • Every test adds real value to the overall test effort.
  • You write the tests when you have a full understanding of the software, supported platforms and the technology that the software uses.
  • Every test is based on real use case.
  • Each test is prioritized.


Myth no’9 – You can leave testing once development has been completed

Big mistake, no matter what is the selected methodology that you use (Traditional or Agile), testing should be carried out throughout all phases of the SDLC. As earlier you start to test, the better it is.

And the benefits:
  • QA will estimate the work effort and Risks that involve in this type of project.
  • QA can affect the application design when performed in earlier phases.
  • It is a basic fact that fixing bugs is cheaper in earlier phases.
  • QA can raise the risks that other teams cannot predict.
  • QA has a specific method that they can use to test the software without the need of the actual code, it’s called “Static” testing (reviews, inspection, Etc.) that performed during the verification process.

Myth no’10 – Software testing is relatively new in the software industry

let’s think about it for a second, when you write a code, no matter if you do it today or 40 years ago, you will test your code in one way or another, so we can say that testing exists from day one on some level or another, 

In addition, I can be more specific and say that testing is part of the software industry since the middle of the fifties  (Just read the following section on Wiki: https://en.wikipedia.org/wiki/Software_testing#cite_note-17)


Myth no’11 – All tests should be automated

No, although that there is a Hugh benefit in automated testing (I have written more than one article about this issue, look for it on my blog), you just cannot ignore the importance of manual testing.

You're testing effort must combine both manual and automation testing, this is how you will increase the effectiveness and quality of your testing. 

Keep in mind:
  • A mistake that was made in an automated test scenario will be kept forever (Until you will get this bug from one of your clients).
  • There is no replace to the human eye.
  • Automation is not relevant to all projects (Depends on the complexity, timelines, and resources).
  • Manual tests allow the tester to interact with the software in a way that automation cannot.
  • Exploratory testing is executed manually (in some cases with the assistance of scripts/Auto-Tools), and for me, it’s the best testing method that you can use as a tester.

Myth no’12 – Testing is boring

The old days were testers performed single and methodical operations are almost no longer exists, Just review these basic activities that are involved in a testing process:
  • Use your mind to think about complex scenarios that other people failed to think about.
  • Interact with different resources (Client, developers, support, etc.).
  • Investigate the application requirement.
  • Guaranty that quality of an application.
  • Understand the supported platforms.
  • Design and execute test cases.
  • Design and create test scripts. 

No comments:

Post a Comment

My Presentations