Minutes of meeting template

Minutes of meeting template

1. Enter the details of the meetings conducted
2. Enter the action items to be tracked
3. Action items can be tracked to closure

Download MOM template here

Test case template

Test case template

Steps to be followed to use the Test Case template are as below

1. Please dont add/delete columns in the "testcases" sheet and "data" sheet of the template
2. Add the list of features in the "data" sheet and the list will be populated in the "feature" column of the "testcases" sheet. Fill all the required columns in the "testcases" sheet
3. Run the macro
4. Results will be populated in the top table of the "testcases" sheet and the graph will be updated in the "Graphs" sheet. These details can be used in reporting to the customers or management
5. Fill the summary sheet for maintenance purpose

Download Test case template here

Defect Report Best Practices

Defect Report Best Practices

1. Defect report should have all the below items

   a. Summary of the defect: It should read the high level description of the defect.
    Example: Installation failed on Win 7 OS

   b. Description: Describe all the steps to be followed to reproduce the defect in detail along with the Expected result and Actual result.

    i. Steps to be followed: These would describe the exact sequence of steps to reproduce the defect
    ii. Expected result: The outcome that is expected by following the above steps
    iii. Actual result: The outcome of the steps while running the test case or following the steps at that point in time

   c. Environment details: Specify the test environment details including the OS, Browsers or any other specific hardware or software used.

    d. Reporter: Your email id or name should be mentioned. If any tool is being used, this field is automatically filled in with the logged in user details

    e. Version: Mention the exact version of the product in which the defect arise

    f. Component: This is the name of the module or feature.

    g. Priority: When bug should be fixed? Priority is generally set from P1 to P3. P1 is the highest priority and P3 being the lowest priority.

    h. Severity: This depicts the impact of the defect on the application. Types of Severity include the below:

    Blocker: No further testing work can be done.
    Critical: Application crash, Loss of data.
    Major: Major loss of function.
    Minor: Minor loss of function.
    Trivial: Some UI enhancements.
    Enhancement: Request for new feature or some enhancement in existing one.

i. Status: The status of the defect which can be one of the below

    a. New
    b. Assigned
    c. Fixed
    d. Invalid
    e. Deferred
    f. Closed
    g. Reopen
    h. Duplicate

j. Screen shots: Enclose the entire required screen shot so that the developers can understand the behavior.

k. Assigned to: Mention the name of the person to whom this defect is to be assigned for further processing.
 
2. Do not use any abusive language.

3. Reproduce the defect more than twice before reporting it.

4. Check if the defect is already reported to avoid duplicate defects.

5. Write a good summary.

6. Last but not the least report the defect immediately.

Test case authoring best practices

1. Every test case should be accurate and tests what it is intended to test with clearly mentioned preconditions, steps to be followed and the expected result.

2. Language should be simple and any person should be able to understand.

3. There should be no ambiguities as these would be distributed across other testers who are unaware of the functionality of the product and can only understand by going through the test cases.

4. There should be no hidden information with any mention to environment details. Example: The website to be tested on all browsers. Here there should be a reference to the browsers to be considered.

5. It should be reusable. As the product has different versions, the test cases written for the first version should be in a reusable format for the earlier version also.

6. It should be traceable to requirements. This gives the coverage details as to what requirements were covered.

7. It should be compliant to regulations.

8. Each test case should be independent.

9. Every condition/flow should have a separate test case.

10. Always write small test cases.

Test Case

Definition

A test case is a set of steps with input values, expected output and the preconditions for testing a functionality.

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

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.

Objectives behind writing and executing the test cases:

    1. To maintain the knowledge on the product in one place.
    2. To maintain the track of features tested.
    3. Understand the coverage of testing.
    4. Analyze the most buggiest feature.
    5. Maintain traceability across requirements, test cases and defects.
    6. Compliance with processes.
    7. Help management to make software delivery decisions.

Defect Life Cycle

Definition:

Simple Wikipedia Definition Of Bug Is:

“A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result.

Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.”

Other Definitions Can Be:

An unintended behavior of the application or software.
It can also be defined as a failure to conform to specifications.

Life cycle of Bug:

1. When a defect is identified by the tester, it is reported with the Summary, steps to be reproduced, test environment details, screen shots if any,
assigning to, status. The status of the defect is NEW and is assigned to the Test lead.

2. Test lead would assign the defect back to development lead and the status of the defect will be ASSIGNED.

3. Development leads would again assign the defect to the exact develop responsible for fixing the defect with a priority.

4. The assigned developer would explore the defect and can do any of the below
a. Fix the defect and assign it back to the tester to retest the fix with the status as FIXED
b. Change the status to DEFERRED if the plan is to fix it in the next release
c. Change the status to INVALID if the defect reported is not a valid one

5. For the FIXED defects, the tester would retest it and can do any of the below
a. Change the status to CLOSE if the defect is not reproducible
b. Change the status to REOPEN if the defect is still existing

6. INVALID defects can be REOPEN if it is reproducible with specific steps mentioned

Defect reporting

What Is Defect?

A Defect is a non-conformance of deliverables against requirement specification. Defects can be found by testers, project team members or end user or developers.
All defects have to reported and tracked to closure no matter who identifies it. Hence, the defects are to be stored in Defect Tracking System that is centralized and accessed by all stake holders.