Table of Contents

• 1. Planning Testing Requirements
• 2. Planning Test Cases
  • Smoke or Build Verification Test
  • Field Validation Test
  • Mistake Proofing Test
  • Performance Testing
• 3. Fixing Defects

In today’s highly competitive world, businesses do not get much time to test a product before releasing it into the market. With the competitor’s product out in the market, you have to quick-fire your production to provide an innovative set of features or updates.

Studies reveal that most of the companies spend ½ of the project budget on testing. To leverage resources and stay ahead in the competition, companies should develop a proper QA strategy that prioritizes testing requirements.

In general, the following are the three important things that project or businesses should follow from ‘Testing or QA’ perspective. In fact, these three items are already the fundamental ‘testing’ related tasks generally done in any project :

• Planning Testing Requirements
• Planning Test Cases
• Planning Defect Fixing

1. Planning Testing Requirements

Consider an instance wherein you are planning to publish a software release. You have to create a sprint or iteration. While doing so, you have to choose priority levels for each requirement. While a requirement might be critical, there are some features that are desired but not critical. So, take time to mark the priority levels of each requirement.

The idea here is to emphatically work on critical issues in the development phase and spend less time on low-priority requirements. Else, developers might spend more time on the first requirement and then run out of time when working on critical issues.

• P1 – Vital requirement (the product cannot be released without developing these features)
• P2 – Desired but not a compulsory requirement
• P3 – Trivial requirement (Can be added if time permits)

When you plan your development requirements, it is important to provide your requirements plan to developers so that they can put more effort on prioritized items.

2. Planning Test Cases

The second important aspect is to test each requirement of your itinerary or sprint. Each module should be error-free and produce desired results. Test cases are to be prioritized as well based on how well they eliminate bugs and add value to the product. Here is the best order to do so :

Smoke or Build Verification Test

First of all, perform a smoke test to check the basic functionality of the module or code. For instance, you have to create a registration page for a website. The page should allow users to enter details and then store the details of the users in its database. As a first step, you can run a smoke test that checks if all fields contain valid data.

Field Validation Test

The next thing is to perform the field validation test. This test case checks if the code requires all fields to be filled with valid data and not a single field can be left empty. At the same time, the field width is checked as well. If there is a limit of 100 characters for a name field, the user should not be able to enter more than that. Thirdly, this test case should check if the field contains values that fall inside a specific range.

Mistake Proofing Test

Negative tests allow you to check if the web page rejects negative entries and warns the user to correct the entry. For instance, the user tries to register his account. The minimum age limit of the registration is 13 years. So, the date of birth should not allow the user to register if his age falls below 13 years.

Performance Testing

If the code passes basic steps, you can go ahead and dig it deeper. By subjecting the page to extreme traffic loads, you can do performance testing and ensure that the site always works fine.

3. Fixing Defects

The third aspect to prioritize is defect planning. When you run a test case, there are several defects that creep up. While some of them do not affect the functionality of the system, there are certain bugs that crash the system and needs immediate attention.

To manage service levels and publish the release on time, it is important that your developers spend more time on fixing critical defects.

So, the best thing to do is to check the severity of the defect and prioritize them accordingly. You may call it a ‘risk-based defect triaging‘.With a properly designed software QA strategy, businesses can ensure that testing resources are leveraged to produce effective results.

The post How To Create The Right Software QA Strategy appeared first on Automation Dojos.

Software QA is not about finding mistakes in a code. It is about enhancing the quality of the product to meet objectives while delivering consistent performance at a higher level.

Whether the project is in the analysis phase, design mode or the implementation stage, there are different types of software QA practices that are followed by organizations in recent times. These ‘mistake proofing techniques‘ reduce errors at the development stage. One such practice that doesn’t allow mistakes to happen is Poka-Yoke.

Honestly speaking I personally did not get the opportunity to implement any of these so-called QA processes formally, but based on some research/readings done recently, am excited to share some interesting points.

What is Poka-Yoke?

The Japanese term Poka-Yoke, introduced by Shigeo Shingo, is a mistake-proofing technique that eliminates inadvertent errors. Literally, Poka means mistake and Yoke means to prevent. In simpler words, it talks about preventing mistakes. It is a safe practice that uses an automated system to disallow errors or alert you when an error occurs. By eliminating human data input errors, this mistake-proofing technique allows businesses to fail-proof the system. The rear part of a CPU is an example of Poka-Yoke systems wherein each port comes in different sizes and colours to make the assembling task easier.

Initially, Poka Yoke was designed to implement mistake proofing techniques in the manufacturing industry. A SIM card slot that does not allow you to insert the SIM in a wrong way is a good example of this concept.

Today, the modern software development segment is greatly in love with this innovative concept. The increasing popularity for this concept is because web applications are created in huge numbers in recent times. While these web applications are designed with self-explanatory help content, there are several people who make mistakes while feeding data or using navigation features. For instance, the password field warns you when you enter characters less than 8.

What is FMEA?

‘Failure Mode and Effective Analysis‘ or FMEA is an analysis that helps you identify root causes of defects in a product, in the design stage or in the production stage.

In other words, failure mode refers to areas wherein the product can fail and the effective analysis refers to the effect caused by each failure. When a defect is identified, remedial methods are suggested. By implementing these changes, businesses can eliminate defects in the functionality of a product. As this is an on-going process, FMEA is documented and followed throughout the life of the product.

How is FMEA different from Poka-Yoke?

While FMEA is an analysis that identifies root causes of product failures using a top-down analysis, Poka-Yoke is a technique that makes the product fail-proof. Both of these procedures work similar to some extent as they envisage and identify detects in a product. However, Yoka-Poke is more about human failures that can occur due to lack of knowledge, fatigue or carelessness. FMEA documents may contain Poka-Yoke techniques.

The increased use of Poka-Yoke systems in recent times has effectively reduced errors in product functionality caused by various issues. On the other hand, FMEA envisages these errors at the development stage to eliminate them. By suggesting remedial measures, FMEA ensures that these mistakes are not carried into the development phase. As the entire project specifications are determined before the development takes off, it is critically important to identify any issues with the product in the early stages to avoid expenses. In fact, FMEA identifies areas wherein Poka-Yoke is required. So, FMEA and Poka-Yoke techniques work well when they are perfectly coordinated in product development projects to save time and money.

Be it Poka-Yoke, FMEA or any other software QA practice, businesses need to ensure that highest quality is maintained while developing a product. By ensuring that best software development practices are followed throughout the software development lifecycle, businesses can optimize resources while improving productivity levels.

The post How is Poka Yoke different from FMEA? appeared first on Automation Dojos.