Error Guessing

What is Error Guessing?

This is a Test design technique where the experience of a tester is used to find the components of software where defects might be present.

It is mostly done by experienced tester's who can use their past experience to find defects in software.

Error guessing has no rules for testing, it only uses the tester's previous skills.

In error guessing tester's can think of situations where software will fail.
 
For example:

    1. Division by zero.
    2. Pressing submit button on form without filling any entries.
    3. Entering wring data in the fields and checking software behavior.

Use Case Technique

Before explaining Use case Testing lets first understand what is a Use Case?

1. A Use case is a description of a particular use of the system by the end user of the system.

2. Use cases are a sequence of steps that describe the interactions between the user and the software system.

3. Each use case describes the interactions the end user has with the software system in order to achieve a specific task.

What is Use case Testing?

Use case testing is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish.

Use cases are defined in terms of the end user and not the system, use case describe what the user does and what the user sees rather than what inputs the software system expects and what the system outputs.

Use cases use the business language rather than technical terms.

Each use case must specify any preconditions that need to be met for the use case to work. Use cases must also specify post conditions that are observable results and a description of the final state of the system after the use case has been executed successfully.

Boundary Value Analysis

A boundary value is a value on the edge of an equivalence partition. Boundary value analysis is all about testing the component at the boundaries.
For example: Consider the same example that is considered for equivalence partitioning.

There is an Age field that should accept a range of values from 0 to 100 only. For this the boundaries would be 0 and 100. Testing at the boundary would yield 3 data values at each end that should be used for testing. So for 0 the boundary the values would be -1, 0 and 1 (It is to have a value less than the boundary value, the boundary value and the next value) and the values for next boundary 100 are 99, 100 and 101

All the 6 values have to be used to test Age field.

Test closure

After completion of all the test execution cycles and user acceptance test, the test lead prepares the final test summary report containing all the deliverables.

Defect reporting

After the test execution is done, the testing team prepares a defect summary sheet.

What is a defect?

In general with specific to a project, anything that varies from the actual requirement/functionality is a defect.

Defect Reporting Format

As per the IEEE 829 format a defect report must contain the following

a. Defect Id
b. Description
c. Module
d. Test case name
e. Reproducible
f. Status
g. Severity
h. Priority
i. Reported by
j. Reported on
k. Assign to
l. Build number
m. Fixed by
n. Resolved by
o. Resolved on
p. Resolution type
q. Approved by

Test execution

Once the test case authoring is done and reviewed thoroughly, testing team concentrates on build release from development side/client and test execution on that build.

Test Execution levels:

Once the testing team receives a new build different levels of executions are done.

Level 1 (Smoke Test/Build Verification test/Tester acceptance test/sanity test:

After receiving the initial build, test engineers verify if the basic functionality of the build to estimate the stability for complete testing. In smoke testing only a few test cases from the actual test case suite are selected for execution. If the test engineers find that the build is unstable they reject the build for testing.

Level 2(comprehensive testing)

Once the smoke testing is done and the build is stable, comprehensive testing is done on the build. In this one cycle of execution covering all the test cases is performed. Defects log report is prepared after the execution and sent to development team for fix.

Level 3(Regression Test)

After comprehensive testing is done the initial build and defects are reported. The development team fixes the defects and sends a new build (with defects fixed) to the testing team. The testing team performs regression testing on the new build to verify if the defects are fixes and if any new defects are found because of the previous fixed defects.

Test design

Test design involves authoring of test cases. What is a Test case?

IEEE Standard 610 (1990) defines test case as follows:

“(1) A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

“(2) (IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.” Test Case Design Techniques

Black box Design Techniques:

a. Equivalence Class Partitioning
b. Boundary Value Analysis
c. Decision Table Testing
d. State Transition Testing
e. Use Case Testing
f. Error Guessing Technique

White Box Design Techniques:

a. Control Flow Testing
b. Data Flow Testing
c. Decision Coverage
d. Statement coverage
 
Key Points to be followed in Designing

A Test case should
    a. Start with the word verify or check
    b. Contain a maximum of 15 steps
    c. Specify what the tester has to perform
    d. Give consistent results irrespective of testers
    e. Be divided into positive and negative scenarios
    f. Has a name and number
    g. Should be reusable
    h. Should be simple and easy to understand
 
Test Case Format

As per the IEEE format a test case should contain the following
a. Test case Id
b. Requirement ID
c. Test Case priority
d. Test Case Authoring Status
e. Authoring Date
f. Test Case Title
g. Pre-Condition
h. Test Data
i. Test Steps
j. Expected Result
k. Actual result
l. Execution status
m. Defect Id
n. Defect Severity
o. Execution Date
In general it can be as follows
Ex: A Test Case to open Note pad

Step no	Steps to perform	Expected Result	Actual Result
1	Click on ‘Start’ Menu on the Left hand bottom of the screen	A window containing ‘all programs’ is displayed	Same as Expected
2	Click on ‘Run’	A run window is opened with label ‘open’	Run window is successfully opened
3	Enter ‘Notepad’ in the text box and click on ok button	Notepad is opened with File, Edit, Format, View and help menu	Note pad is successfully opened