• Internet
• 20.02.2019
• EN

yellowpencil: Testing - Testing - 1-2-3

A 3 minute read, written by Erin
December 18, 2013
 

Recently, the U.S. government launched HealthCare.gov (aka the “Obamacare” website), a web application to be used by its citizens who don’t have health insurance. The idea is to allow Americans to compare pricing on various health insurance plans that are offered in their particular state, start enrolling in the plan they find most suitable as well as find out if they qualify for any healthcare subsidies. We all know what happened when the site went live on October 1, 2013.

A major reason for the failure of the site was inadequate testing. The company disclosed that they “would have liked to have months” to perform integration testing between the various pieces of the project. However, the team only spent two weeks.

Here at Yellow Pencil, we value quality. As a certified tester on the QA Team, it’s my job to ensure quality occurs throughout a project’s lifecycle. How do I do that? Through effective and efficient testing.
 

But first, what IS testing?

Testing exists in all the project lifecycle activities. It involves planning and preparation to evaluate work products to determine that they satisfy business and user requirements. Testing demonstrates that those requirements are fit for purpose as well as detecting defects.
 

What do we use to test?

We use test cases and test scripts, which are organized into test suites. Test suites are then grouped together by project. Some projects might have only one test suite, while others may have several.

Test cases and scripts are sets of instructions used to verify that the project’s requirements have been met. These requirements can be anything from “Registration button should appear three times on the Welcome page” to “User can cancel an order from Account Management.” Both sets of instructions contain preconditions, input values (such as login information in the form of a variable), expected results, and post-conditions. The big difference between a test case and a test script are the type of instructions. A test case is very general and does not contain specific steps to complete the task. A test script is very detailed, with a specific set of steps needing to be carried out in exact order.

For the requirement “Registration button should appear three times on the Welcome page,” a tester would create a test case with instructions to verify the number of times the Registration button appears on the Welcome page.

However, for a more complicated requirement such as “User can cancel an order from Account Management,” a tester would create multiple test scripts. Why don’t we write one test script with steps on how to cancel an order from Account Management? Because there are other scenarios that could occur. How should the system behave if the user doesn’t have an order to cancel? If an order has multiple states, such as “Received,” “Pending,” and “Completed,” test scripts will need to be written to verify an order that is “Received” can be canceled but one that is “Pending” or “Completed” cannot.
 

Why do we do all of this? Who are test suites for?

We do it to be organized, to be efficient, and to continue producing high-quality products.

Test suites allow us to centralize information to increase visibility and transparency within the team. That doesn’t include just us – that includes you as well! A test suite can be used by anyone on the team, not just testers:

• Business analysts can use test suites to perform gap analysis and requirements traceability.
• Developers and designers can use test suites for reference when fixing defects.
• Project Managers can deliver test suites as deliverables. It’s proof that the system works as expected in the way it is supposed to.

How do testers use test suites?

We use them throughout the entire lifecycle of the project, from beginning to end and even after the project.

• We use them during requirements gathering to determine if we need to write new scripts or update existing ones. Why re-invent the wheel?
• We use them during design and development cycles to verify the system’s design and functionality. By testing early on, we can detect defects earlier on when they are less expensive and much easier to fix.
• We use them for regression testing! Regression testing allows us to ensure fixing existing functionality or adding new features doesn’t break other sections of a system.
• After a project has been deployed to Production, we clean up the test suite, archiving or deactivating scripts whose requirements have been updated.

Saving project time and budget!

In 2002, the National Institute of Standard Technology (NIST) published a study comparing the hours to fix a bug found in development versus fixing the same bug if found in production.

How long did it take to fix a bug found during development? Five hours. To fix the same bug found in production – after deployment? Fifteen hours!

That’s not all! The Systems Sciences Institute at IBM has reported that the cost to fix an error found after a product release was 4-5 times as much as one uncovered during design, and up to 100 times more than one identified during maintenance!

It’s an investment!

Testing isn’t something done at the end of a project. Testing should be done throughout every phase of the project; from discovery to design, development to deployment. It can be daunting to look at a project plan and see so many testing tasks, but in the end it’s worth it.

Source: Testing, Testing 1-2-3

© copyright 2013 by yellowpencil