SOFTWARE TESTING LIFE CYCLE

It contains 6 phases.

1. TEST PLANNING.

2. TEST DEVELOPMENT.

3. TEST EXECUTION.

4. RESULT ANALYSIS.

5. BUG TRACKING.

6. REPORTING.

TEST PLANNING

Plan:

Plan is a strategic document, which describes how to perform a task in an effective, efficient and optimized way.

Optimization:

Optimization is a process of reducing or utilizing the input resources to their maximum and getting the maximum possible output.

Test Plan:

It is a strategic document, which describe how to perform testing on an application in an effective, efficient and optimized way. The Test Lead prepares test plan.

CONTENTS OF THE TEST PLAN

1.0 INTRODUCTION.

1.1 Objective.

1.2 Reference Document.

2.0 COVERAGE OF TESTING.

2.1 Features to be Tested.

2.2 Features not to be Tested.

3.0 TEST STRATEGY.

3.1 Levels of Testing.

3.2 Types of Testing.

3.3 Test Design Technique.

3.4 Configuration Management.

3.5 Test Metrics.

3.6 Terminology.

3.7 Automation Plan.

3.8 List of Automated Tools.

4.0 BASE CRITERIA..

4.1 Acceptance Criteria.

4.2 Suspension Criteria.

5.0 TEST DELIVARABLES.

6.0 TEST ENVERONMENT.

7.0 RESOURCE PLANNING.

8.0 SCHEDULING.

9.0 STAFFING AND TRAINING.

10.0 RISKS AND CONTINGENCES.

11.0 ASSUMPTIONS.

12.0 APPROVAL INFORMATION.

1.0 INTRODUCTION.

1.1 Objective.

The main purpose of the document is clearly described here in this section.

1.2 Reference Document.

The list of all the documents that are referred to prepare the test plan will be listed out here in this section.

2.0 COVERAGE OF TESTING.

2.1 Features To Be Tested

The list of all the features with in the scope are mentioned here in this section

2.2 Features Not To Be Tested

The lists of all the features that are not planed for testing based on the following criteria are mentioned here in this section.

Ø Out of scope features

Ø Low risk areas

Ø Future functionalities.

Ø The features that are skipped based on the time constraints.

3.0 TEST STRATEGY

It is defined as an organization level term, which is used for testing all the projects in the organization.

TEST PLAN

It is defined as a project level term, which is describes how to test a particular project in an organization.

Note:

Test strategy is common for all the projects. But test plan various from project to project.

3.1 Levels of Testing

The list of all the levels of testing that are maintained in that company are listed out here in this section.

3.2 Types of Testing

The list of all the types of testing that are followed by that company are listed out here in this section.

3.3 Test Design Technique

The list of all the techniques that are followed by that company during the test case development are listed out here in this section.

Ex: BVA (Boundary Value Analysis)

ECP (Equivalance Class Partition)

3.4 Configuration Management

3.5 Test Metrics

The lists of all the tasks that are measured and maintain in terms of metrics are clearly mentioned here in this section.

3.6 Terminologies

The list of all the terms and the corresponding meanings are listed out here in this section

3.7 Automation plan

The list of all the areas that are planed for automation in that company are listed out her in this section.

3.8 List of Automated Tools

The list of all the automated tools that are used in that company are listed out here in this section.

4.0 BASE CRITERIA

4.1 Acceptance Criteria.

When to stop testing in a full pledged manner thinking then enough testing is done on the application is clearly described here in this section.

4.2 Suspension Criteria.

When to stop testing suddenly and suspended the build will be clearly mentioned here in this section.

5.0 TEST DELIVERABLE.

The list of all the documents that are to be prepared and deliver in the testing phase are listed out here in this section.

6.0 TEST ENVIRONMENT.

The customer specified environment that is about to be used for testing is clearly describes here in this section.

7.0 RESOURCE PLANNING.

Who has to do what is clearly described here in this section.

8.0 SCHEDULING.

The starting dates and the ending dates of each and ever task is clearly described here in this section.

9.0 STAFFING AND TRAINING.

How much staff is to be requited what kind of training is to be provided is clearly planned and mentioned here in this section.

10.0 RISK AND CONTINGENCES.

The list of all the potential risks corresponding solution plans are listed out here in this section.

Risks

1. Unable to deliver the software with in the dead lines.

2. Employees may leave the organization in the middle of the project development.

2. Customer may impose the dead lines.

3. Unable to test all the features with in the time.

4. Lake of expatriation.

Contingences

1. Proper plan ensurance.

2. People need to be maintained on bench.

3. What not to be tested has to be planed properly.

4. Severity priority based execution.

5. Proper training needs to be provided.

11.0 ASSUMPTIONS.

The list of all the assumptions that are to be assumed by a test engineer will be listed out here in this section.

12.0 APPROVAL INFORMATION.

Who will approve what is clearly mentioned here in this section.

TEST DEVELOPMENT.

Use Cases:

Use case is a description of functionality of certain features of an application in terms of actors, actions& responses

Input information required for preparing the use case Document: -

i.Screen shot

ii.Functional requirements

iii.Special requirement/Business rules/Validation

iv.Template

ii. Functional Requirements: -

a. Login screen should contain username, password, Connects To fields and login, clear, cancel buttons.

b. Connect to is not a mandatory field but when ever user requires it should allow him to select a data base option.

c. Up on entering valid username, valid password and clicking on login button corresponding page must be displayed.

d. Up on clicking on the clear button the information present in all the fields must be cleared and the cursor must be available in the user name field

e. Up on clicking on the cancel button login screen must be closed.

iii. Special requirements/Business rules/Validation: -

a. Initially whenever the login screen is Invoked Login, clear buttons must be disabled.

b. Cancels Button must be always enable.

c. Up on entering user name and password the login button must be enabled.

d. Up on entering some information in to any of the fields the clear button must be enabled

e. The Tabbing order must be user name, Password, Connect to, Login, clear, cancel.

iv. Use Case Template:

Name of the Use Case :

Brief Description of Use Case :

Actor’s Involved :

Special Requirements :

Pre Condition :

Post-Conditions :

Flow of Events :

v. Use Case Document:

Name of the use case: Login use case.

Brief Description of use case: It describes the functionalities of all the features present in the login screen.

Actors Involved: Normal user, Admin User.

Special Requirements: There are two types of special requirements

1. Explicit requirements

2. Implicit requirements

1. Explicit Requirements: -

The Requirements that are directly given by the customer are known as explicit requirement.

2. Implicit Requirement: -

The requirements that are analyzed by the business analyst feeling that they will add the value (user friendliness) to the application are known as implicit requirements

List of Explicit requirements: -

· Initially whenever the login screen is Invoked Login, clear buttons must be disabled.

· Cancels Button must be always enable.

· Up on entering user name and password the login button must be enabled.

· Up on entering some information in to any of the fields the clear button must be enabled

· The Tabbing order must be user name, Password, Connect to, Login, clear, cancel.

List of Implicit Requirements: -

· Initially whenever the login screen is invoked the cursor must be available in the user name field

· Upon entering in valid username, valid password and clicking on log in button an error message should be displayed “Invalid username Please try again”

· Upon entering valid username, In valid password and clicking on login button an error message should be displayed “Invalid Password Please Try again”

· Upon entering Invalid username, Invalid password and clicking on login button an error message should be displayed “Invalid user name and password Please try again”.

Pre-Conditions: Login screen must be available

Post-Conditions: Either home page or admin page for the valid user and error message for the invalid users

Flow of Events: There are three flows for the application

1. Main Flow

2. Alternative Flow

3. Exceptional Flow

1. Main Flow:

Action Response

1. Test Engineer invokes the application.

2. Test Engineer enters valid user name, Valid password and clicks on login button.

3. Test Engineer enters valid user name, valid password, selects a database option and clicks on login button.

4. Test Engineer enters invalid user name Valid password and clicks on login button.

5. Test Engineer enters valid user name, Invalid password and clicks on login button.

6. Test Engineer enters both username and password invalid and clicks on login button.

7. Test Engineer enters some information in to any of the fields and clicks on clear button.

8. Test Engineer clicks on the cancel button.

1.Login Screen is displayed with the following fields

Username, Password, Connect to, Login, Clear& cancel.

2. Either home page or admin page is displayed depending up on the Test Engineer entered by authentication.

3. Authenticates, Either home page or admin page is displayed depending up on the action entered with mentioned data base connection.

4.Go to Alternative flow table 1

5.Go to Alternative flow table 2

6.Go to Alternative flow table 3

7.Go to Alternative glow table 4

8. Go to Alternative flow table 5.

1. Alternative flow table 1: - (Invalid User name)

Action Response

Test Engineer enters invalid user name, valid password and clicks on login button

It displays an error message is displayed “Invalid User name Please Try again”.

2. Alternative Flow Table 2: - (Invalid Password)

Action Response

Test Engineer enters valid user name, invalid password and clicks on login button

It displays an error message is displayed “Invalid Password Please Try again”.

3. Alternative Flow Table 3: - (Invalid username & Password)

Action Response

Test Engineer enters invalid user name, invalid password and clicks on login button

It displays an error message is displayed “Invalid User name and password Please Try again”.

4. Alternative Flow Table 4: - (Clear Click)

Action Response

Test Engineer enters some information in any of the fields and clicks on clear button

All the fields are cleared and cursor is placed in the user name fields

5. Alternative Flow Table 4: - (Cancel click).

Action Response

Test Engineer Clicks on the cancel button.

3. TEST EXECUTION.

During the test execution phase the test engineer will do the following.

1. He will perform the action that is described in the description column.

2. He will observe the actual behavior of the application.

3. He will document the observed value under the actual value column.

4. RESULT ANALYSIS.

In this phase the test engineer will compare the expected value with actual value and mention the result as pass if both are match otherwise mentioned the result as fail.

5. BUG TRACKING.

Bug tracking is a process in which the defects are identifying, isolated and managed.