RSS

Tag Archives: Study

Evaluating exit criteria and reporting


Evaluating exit criteria is the activity where test execution is assessed against the defined objectives. This should be done for each test level, as for each we need to know whether we have done enough testing. Based on our risk assessment, we’ll have set criteria against which we’ll measure ‘enough’. These criteria vary for each project and are known as exit criteria. They tell us whether we can declare a given testing activity or level complete. We may have a mix of coverage or completion criteria (which tell us about test cases that must be included, e.g. ‘the driving test must include an emergency stop’ or ‘the software test must include a response measurement’), acceptance criteria (which tell us how we know whether the software has passed or failed overall, e.g. ‘only pass the driver if they have completed the emergency stop correctly’ or ‘only pass the software for release if it meets the priority 1 requirements list’) and process exit criteria (which tell us whether we have completed all the tasks we need to do, e.g. ‘the examiner/tester has not finished until they have written and filed the end of test report’). Exit criteria should be set and evaluated for each test level. Evaluating exit criteria has the following major tasks:

kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Test Strategy Template


These are the most common sections:

1.Objectives
State the objectives of this document at a high-level.

2.Scope
State the scope of the testing strategy, what will the testing concentrate around, at high-level; leave details for the Testing Scope.

3.Test Deliverables
State the testing activities and what documents result from these activities; for example a testing activity is Test Planning and the document resulting is the Master Test Plan or Test Plan.

4.Testing Schedule
Give the timelines around which the project is planned and where testing fits in this schedule.
I find that a diagram has a high-impact on the user (a Georgia rule of thumb is that I use color and diagrams to break the boredom of the text).
Describe the diagram in words.

5.Test Scope
The Project Charter or Master Test Plan usually state all the items in scope, just copy and paste from these documents. Add anything that’s missing or has changed from the last review.
Then state any items that are Out of Scope.

6.Risk Analysis
State all the risk that you envision, the higher the risk – the higher the test priority.
When you start testing you will want to start with the high-priority items, then test medium-priority and if time permits test low-priority functionality.Risk Analysis is very important from this point of view because it drives the whole test strategy. When giving the risk state how to you plan to mitigate (to alleviate, to make less severe) and what is the contingency plan (back-up plan in case this happens).Additionally you may want to say what is the impact of each risk.

kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

System Test Strategy Template



Provided by Rex Black Consulting Services

  1. Product, Revision and Overview

Describe the product and revision designator.

Describe briefly how the product works. Reference other material as appropriate.

  1. Product History

Include a short history of previous revisions of this product. (3-4 sentences). Include defect history.

  1. Features to be tested

List all features to be tested. Organize the list in the way that makes most sense- user features, or by level:

Application
Demo software
Client substrate
Server
Network (this may be more layers)
  1. Features not to be tested

Describe any features not to be tested

  1. Configurations to be tested and excluded

I recommend a table showing which hardware configurations will be tested with which software.

  1. Environmental requirements

Enumerate hardware, firmware, software, networks, etc. required to carry out the testing.

  1. System test methodology.

Brief description of work items to be performed from the beginning to the end of the product development.

  1. Initial Test requirements

Test strategy (this document), written by test personnel, reviewed by product team, agreed to by project manager.

  1. System test entry and exit criteria
kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

test case format -sample


unique-test-case-id: Test Case Title

Purpose:

Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions.

Prereq:

Assumptions that must be met before the test case can be run. E.g., “logged in”, “guest login allowed”, “user testuser exists”.

Test Data:

List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combinationof values. These values are written in set notation, one per line. E.g.:loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty}password = {valid, invalid, empty}

Steps:

Steps to carry out the test. See step formating rules below.

  1. visit LoginPage
  2. enter userID
  3. enter password
  4. click login
  5. see the terms of use page
  6. click agree radio button at page bottom
  7. click submit button
  8. see PersonalPage
  9. verify that welcome message is correct username

Notes and Questions:

  • NOTE
  • QUESTION
kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Weekly Status Report



Writing effective status report is as important as the actual work you did! How to write a effective status report of your weekly work at the end of each week?

Here I am going to give some tips. Weekly report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis. Even using these reports you can track the team performance to some extent. From this report prepare future actionables items according to the priorities and make the list of next weeks actionable.

So how to write weekly status report?

Follow the below template:
Prepared By:
Project:
Date of preparation:
Status:
A) Issues:

kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Test summary Report


  1. Test summary Report Identifier

<Unique ID here for the report here>

  1. Summary

<Summarize the evaluation of the test items>

<Identify the items tested, indicating their version/revision level>

<Indicate the environment in which the testing activities took place>

<For each test item, supply references to the following documents if they exist: test plan, , test breakdown or test cases, test item transmittal reports, test logs, and test incident reports.>

  1. Variances

<Report any variances of the test items from their design specifications>

<Indicate any variances from the test plan, test breakdown or test cases>

<Specify the reason for each variance>

  1. Comprehensive Assessment

<Evaluate the comprehensiveness of the testing process against the comprehensiveness criteria specified in the Test Plan>

<Identify features or combinations that were not sufficiently tested and explain the reasons>

  1. Summary of Results

<Summarize the results of testing. Identify all resolved bugs and summarize their resolutions. Identify all unresolved bugs>

  1. Evaluation

<Provide an overall evaluation of each test item including its limitations. This evaluation shall be based upon the test results and the item level pass/fail criteria as stated in the Test Plan.>

<Include acceptable failures details; ID, Summary, Approver>

<An estimate of risk related to deploying to live may be included> Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Test Strategy


Document Detail

Title: <Formal name for the Strategy with reference to the area it covers>
Version: <Current Version>
Date: <Date of issue of current version>
Electronic File Name: <Document file name.doc>
Electronic File Location: <SharePoint URL>
Author: <Your Name>
Contributors: <Add names of anyone reviewing or providing information>

Change Control

Issue Date Version Details Author
<Issues date> v0.1d Working Draft, not yet for review <Your Name>
kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

test case format style


unique-test-case-id: Test Case Title

Purpose:

Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions.

Prereq:

Assumptions that must be met before the test case can be run. E.g., “logged in”, “guest login allowed”, “user testuser exists”.

Test Data:

List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combinationof values. These values are written in set notation, one per line. E.g.:loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty}password = {valid, invalid, empty}

Steps:

Steps to carry out the test. See step formating rules below.

  1. visit LoginPage
  2. enter userID
  3. enter password
  4. click login
  5. see the terms of use page
  6. click agree radio button at page bottom
  7. click submit button
  8. see PersonalPage
  9. verify that welcome message is correct username

Notes and Questions:

  • NOTE
  • QUESTION
kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Minimum require to bug report


1.Bug id
2.Test case id
3.Test case name
4.Priority and severity
5.Status
6.Email of devloper
7.Attachments if any
8.Assign to(Decided by Test lead)

kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Bug report templete


Bug Template

I’m a staunch advocate of keeping a small text file template on your desktop to paste bugs into just so that you can easily fill out all pertinent information. The following is similar to the one I use, but broader so that you can alter it for your own specific project.

Server Config:

Platform: <List Windows, Unix, and so on.>

Build: <Give the build number.>

Test Bed: <Give a test bed identification or topology name.>

Client Config:

OS: <List Windows 2000, Macintosh, and so on.>

Browser: <List browser and version IE 5.5, NN 4.76, and so on.>

Description:

<Brief description of the problem, more than the title, but not too much>

kevalshah.in

Read the rest of this entry »

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

 
%d bloggers like this: