Scribd
Upload
37 views

Writing Tests and Defects Standards

The document provides guidelines for writing tests and defects. It recommends that tests include the functionality being tested, circumstances, and expected result. Tests should follow the format "Verify that...". Good tests have unique IDs and include descriptions, assumptions, test data, steps, expected results, actual results, and pass/fail status. Defect reports should define the issue, research the root cause, include supporting documentation formatted clearly.

Uploaded by

Fabian Oniț
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
37 views

Writing Tests and Defects Standards

The document provides guidelines for writing tests and defects. It recommends that tests include the functionality being tested, circumstances, and expected result. Tests should follow the format "Verify that...". Good tests have unique IDs and include descriptions, assumptions, test data, steps, expected results, actual results, and pass/fail status. Defect reports should define the issue, research the root cause, include supporting documentation formatted clearly.

Uploaded by

Fabian Oniț
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Tests & Defects Standards

How we write tests

Writing tests and defects need to comply with the following naming and writing conventions

Tests are an important part of any project and should be written to the same standards. We will cover how you can use a test naming convention
to help keep your test names clear and easy to understand.

What makes a good test name?

A good test name should provide the following information:

1. What functionality is being tested


2. Under which circumstances is is being tested
3. What is the expected result

Having all this information provided in the test names prevents you and other project members from having to read through the test to determine
what is being tested.

Test naming format: Verify that ……

Eg. Verify that a creator can register a new account

How to write good tests?

Test cases have a few integral parts that should always be present in fields. However, every test case can be broken down into 8 basic steps.

Step 1: Test Case ID

Test cases should all bear unique IDs to represent them. In most cases, following a convention for this naming ID helps with organization, clarity,
and understanding.

Step 2: Test Description

This description should detail what unit, feature, or function is being tested or what is being verified.

Step 3: Assumptions and Pre-Conditions

This entails any conditions to be met before test case execution.

Step 4: Test Data

This relates to the variables and their values in the test case. In the example of an email login, it would be the username and password for the
account.

Step 5: Steps to be Executed

These should be easily repeatable steps as executed from the end user’s perspective.

Step 6: Expected Result

This indicates the result expected after the test case step execution. Upon entering the right login information, the expected result would be a
successful login.

Step 7: Actual Result

As compared to the expected result, we can determine the status of the test case. In the case of the email login, the user would either be
successfully logged in or not. The post-condition is what happens as a result of the step execution such as being redirected to the email inbox.

Step 8: Pass/Fail

Determining the pass/fail status depends on how the expected result and the actual result compare to each other.

Same result = Pass


Different results = Fail

How we write defects


Writing easily readable, detailed, and complete software defect reports is an essential skill for quality assurance, developers, and support
personnel. All software development team members need to take their defect reports seriously, providing thorough research and detailed
reporting to make the development job easier and more productive.

Defect Format

Defect naming format: [Functionality being tested - User type/Environment]: Problem detected described in clear and concise words

Eg. [Registration - Web 2 User]: User is unable to register a new account using a new email

The defect report checklist

Your defect report checklist should include these four items:

Define the defect

State the platform and version


Log in and examine data (client, creator)
List any nonstandard configuration settings with values
State the workflow direction through the application

Research to narrow down the root cause and get beyond the defect symptom

Retest until you have the exact steps in the correct order to reproduce the defect
Define the who, what, where, when, and how you found the defect
Execute database queries if applicable
Scan error logs
If the defect is intermittent, say so

Add support documentation

Screenshots
Video
Step recording files
Error log data
Database query results

Format all text for readability and easy understanding

Stick to a known and familiar format when possible


List using bulleted or numbered lists
Keep textual descriptions succinct and direct
Facts only; no opinion, no suggestions, no accusations, no blame

You might also like