Thursday, October 4, 2007

How to Do Manual Testing ?




MANUAL TESTING




‘Testing’ is a Process in which the defect are identified, isolated, subjected for rectification and ensure that the product is defect free in order to produce a quality product in the end and hence customer satisfaction.


BIDDING THE PROJECT



‘Bidding the Project’ is defined as request for proposal, estimation and Sign-Off.


KICKOFF MEETING:
‘Kick-Off Meeting’ is the initial meeting held in the software company soon after the project is Sign-Off in order to discuss the overall view of the Project and to select a Project Manager.
NOTE: Project Managers (PM), Team Managers (TM), Software Quality Managers, Test leads and High level Management will be involved in this meeting.

SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE)
There are 6 phases in the development cycle.




1. Initial Phase / Requirement Phase.
2. Analysis Phase.
3. Design Phase.
4. Coding Phase.
5. Testing Phase.
6. Delivery & Maintenance Phase.



1. INITIAL PHASE:
TASK : Interacting the customer and gathering the Requirements.
ROLES: Business Analyst (BA), Engagement Manager (EM).
PROCESS:
First of all the Business Analyst will take an appointment from the customer. Collect the template from the company and meets the customer on the appointed date and gather the requirements with the help of ‘Template’.
If at all any requirements are given by the customer then the Engagement Manager is responsible for the excess cost of the Project. He also responsible for prototype demonstration.

‘Template’ is a predefined format which is used to prepare any document.
‘Prototype’ is a roughly and rapidly developed model which is used for gathering the clear requirements and to win the confidence of a customer.

PROOF: The proof document of initial phase is FRS (Functional Requirement Specification). This doc can also be called as
CRS (Customer Requirement Specification)
BRS (Business Requirement Specification)
BDD (Business Development Document)
BD (Business Document)
NOTE: Some Company will be putting the Business overall flow of the application in the BRS and detailed requirement information in FRS.

2. ANALYSIS PHASE:
TASK: Feasibility Study, Tentative Planning, Technology Selection, Requirement Analysis
ROLES: SA (System Analyst), PM (Project Analyst), TM (Team Manager)

‘Feasibility Study’ is a detailed study of the requirement in order to check whether the requirements are possible or not.

‘Tentative Planning’ is Resource planning and time planning is temporarily done here in this session.

‘Technology Selection’– All the technologies that are required to accomplish the project successfully will be selected and listed out in this session.

‘Requirement Analysis’ What are all the requirements that are require to accomplish the project successfully will be analyzed and listed out here in this session.

SRS (System Requirement Specification):– The proof Document of Analysis Phase is SRS; requirements may be Hardware requirements or Software requirements.
3. DESIGN PHASE:
TASK : High Level Designing (HLD), Low Level Designing (LLD)

ROLES : HLD is done by CA (Chief Architect)
LLD is done by TL (Technical Lead)
PROCESS:
‘High Level Designing’ is a process of dividing the whole project in to the modules with the help of some diagrams.
‘Low Level Designing’ is a process of dividing a module in to sub modules with the help of some diagrams.

NOTE: These diagrams are designing by using a language called Unified Modeling Language (UML).

The Proof Document on this phase is ‘Technical Diagram Document’ (TDD). TDD contains some diagrams and ‘Pseudo Code’.

PSEUDO CODE:
‘Pseudo Code’ is not a real code, but a set of English statements which are very much used by the developers to develop the actual code.

4. CODING PHASE:
TASK : Developing.
ROLES: Developers.
PROCESS:
The developers will develop the actual code using the pseudo code and following the coding standards with proper indentation, color coding and proper commenting, etc.

5. TESTING PHASE:
TASK : Testing.
ROLES: Test Engineers.
PROCESS:
1. FRS Review.
2. While reviewing if at all the test engineers gets any doubts, he will list out all the doubts in review report.
3. He will send the review report to the Author of the Document for the clarification.
4. After Understanding the requirements very clearly he will take the test case template and write the ‘Test Cases’.
5. Once ‘Built’ is released, he will execute the Test Cases.
6. If at all any defects are identified, he will isolate them. Once the defect profile is ready he will send it to the development department.
7. Once the next Built is released, he will ensure whether the product is defect free by re executing the Test Cases. This process continues till the product is defect free.

THE PROOF OF TESTING PHASE IS QUALITY PRODUCT.

6. DELIVERY & MAINTENANCE PHASE:
DELIVERY:–
TASK : Development (Installation)
ROLES : Deployment Engineer or Senior Test Engineer.
PROCESS : A Deployment Engineer will deploy the application in to the client’s environment by following the guidelines by given by the development department in the deployment department.
MAINTENANCE:–
Whenever the problem arrases that problem becomes a task depending upon the problem the corresponding role is appointed based on the problem. The problem will be defined and the problem is solved.
Q) Where exactly testing comes in to practice? What sort of testing you are expecting?
A: There are 2 sorts of Testing.
1. Unconventional Testing. 2. Conventional Testing.
‘Unconventional Testing’ is a process of testing conducted on each and ever out come document right from the initial phase by the Quality Assurance people.
‘Conventional Testing’ is a process of testing applications in the testing phase by the engineers.
‘Test Case’ is a check list of all the different presumptions of a test engineer to test a specific future of functionality.

TESTING METHADOLOGY

TESTING METHODS OR TESTING TECHNIQUES:
These are 3 methods of testing.

1. BLACK BOX TESING:
If one performs testing only on the functional part of an application without having any structural knowledge then that method of testing is known as ‘Black Box Testing’. It is usually done by Test Engineers.

2. WHITE BOX TESTING:
If one performs testing on the structural part of an application then that method of testing is know as ‘White Box testing’. It is usually done by Developers of Test Engineers.
3. GRAY BOX TESTING:
If one performs testing on both functional and as well as structural part of the application is known as ‘Gray Box Testers’.
NOTE: Gray Testing is done by the Test Engineers with structural knowledge.

LEVELS OF TESTING
There are 5 levels of Testing.
1. Unit level Testing.
2. Module level Testing.
3. Integration Testing.
4. System level Testing.
5. User Acceptance Testing. (UAT)
1. Unit level Testing:–
‘Unit’ is defined as a smallest part of an application.

If one performs Testing on a Unit, then that level is known as ‘Unit Level Testing’. It is a White Box Testing and usually done by White Box Testers or Developers.

2. Module level Testing:–
If one performs Testing on a Module then that level of Testing is known as ‘Module level Testing’. It is a Black Box Testing and usually done by Test Engineers.

3. Integration Testing:–
Once the Modules are ready they will be integrated with the help of inter phases (linking Program) by the developers and those inter phases are tested by the developers in order to check whether the modules are integrated properly or not.
It is a white Box Testing and usually done by the developers. The developers will integrate the modules in following approaches.
 Top Down Approach. (TDA)
 Bottom Up Approach. (BUA)
 Hybrid Approach.
 Big Bang Approach.


Top Down Approach Bottom Up Approach Hybrid Approach
(TDA) (BUA)

• In TDA the parent module are linked with the sub modules.
• In BUA the sub modules are linked with the parent module.
• In Hybrid Approach is a mixture of both TDA and BUA.

Big Bang Approach: – Once all the modules are ready at a time integrating the modules is known as ‘Big Bang Approach’

STUB
While integrating the modules in TDA if at all any mandatory module is missing then that module is replaced with a temporary program known as ‘STUB’.

DRIVERS
While integrating the modules in BUA if at all any mandatory module is missing then that module is replaced with a temporary program is known as ‘DRIVER’

4. System Level Testing:–
If one performs testing on a complete application after deploying in to the environment then it is known as System Level Testing.

5. User Acceptance Testing:–
If one performance the same system testing in the presence of user then it is known as ‘User Acceptance Testing’ (UAT). This is a Black Box Testing and done by Test Engineers.

Verification:
Verification is a process of checking whether the product is being developing in a right manner or not.

Validation:–
Validation is a process of checking whether the product is right or not.


ENVIRONMENT

Environment is a combination of 3 layers.

A. Presentation Layer
B. Business Layer
C. Database Layer

TYPES OF ENVIRONMENT

There are 4 types of Environment.

1. Stand alone Environment [or] One tier Architecture.
2. Client Server Environment [or] Two tier Architecture.
3. Web Environment [or] Three tier Architecture.
4. Distributed Environment [or] N-tier Environment.

1. Stand alone Environment [or] One tier Architecture

If at all the three layers are present in a single system of single then it is known as ‘Stand alone environment’

PL
BL
DBL

2. Client Server Environment

In this environment clients resides in one tire and the Database Server resides in another tire. Client will be containing the presentation layer as well as the Business layer. So that the corresponding layer logic will be installed. The Database server contains the Database layers. So that the corresponding logics can be installed.

PL+BL

3. Web Environment

This environment contains 3 tires. Client resides in the first tire, application server resides in the middle tire and the Database server resides on the other tire. Client contain presentation layer. Application contain Business Layer, Database Layer contains Database. So, that corresponding logics are installed.



4. Distributed Environment

‘Distributed environment’ is just similar to Web environment. But number of Application servers is increased in order to distribute the business logic. So, that number of layers will be distributed.

NOTE: Each and every application server should be representing in one tire.

N= Number of Application Servers + 2

TYPES OF TESTING

1. Build Verification Testing (BVT) [or] sanity testing

BVT is a type of testing in which a Test engineer will perform the overall testing on the released Build in order to check whether every thing is available and proper for further detailed testing.


2. Regression Testing

‘Regression Testing’ is a type of testing in which one will perform testing on the already testing functionality once again. It is usually done in 2 scenarios.

a. Whenever the test engineers raise the defect, developer rectifies it. Next build is released to the testing department then the test engineer to the testing department then the test engineer will test the rectified functionality as well as the related functionality once again in order to ensure while rectifying the defect related functionality is not affected.
b. Whenever the new changes are proposed by the customer incorporated by the developers and the build is released to the testing department. Then the test engineer will test the already tested related functionality in order to ensure that the old functionality remains same despite of new change.


3. Re-Testing

It is a type of testing in which one will perform testing on the already tested functionality again and again with multiple sets of data in order to ensure the functionality is working fine or the defect is reproduced with multiple sets of data.


4. Alpha (α) Testing

It is a type of User Acceptance Testing done in the company by our test engineers.

Advantage: –If at all any defects are identified, there is a chance of rectified them immediately.

5. Beta (β) Testing

It is also a type of User Acceptance Testing done in the clients place either by the 3rd party test engineers or by the end users.

Disadvantage:–If at all any defects are identified there is a chance to rectify them immediately.

6. Static Testing

It is a type of testing in which one will perform testing on application or its related factors whenever it is not been executed.

Ex: Doc Testing, Code Analysis, GUI Testing

7. Dynamic Testing

It is a type of testing in which one will perform testing on the application whenever it is being executed.

Ex: Functionality Testing.

8. Installation Testing

It is a type of testing in which a test engineers will try to install the application in to the environment by following the guidelines given in the deployment by developers. If the installation is successful then he will come to a conclusion that the guide lines are correct. Otherwise he will conclude that there are some problems in the guidelines.

9. Compatibility Testing

It is a type of testing usually done for the products in which a test engineer may have to deploy the application in to the environments prepare with multiple combination on environmental components in order to check whether it is compatible with those environment or not.

10. Monkey Testing [or] Gorilla Testing

It is a type of testing in which one will perform abnormal actions intentionally on the application in order to check the stability.

11. End to End Testing

It is a type of testing in which one will perform testing on a complete transaction or an end to end scenario.

Ex : Login → Balance Enquiry → Withdraw → Balance Enquiry → Logout


12. Usability Testing

It is a type of testing in which one will concentrate on the user friendliness of the application.

13. Exploratory Testing

It is a type of testing in which one will perform testing on the application with out any requirement document support by exploring the functionality usually it is done by the domain experts.

14. Port Testing

It is a type of compatibility testing done at the clients place after deploying the application in order to check whether it is compatible with that environment or not.

15. Security Testing

It is a type of testing in which one will concentrate on the following areas.
Authentication, Direct URL testing, Firewall Testing.

16. Reliability Testing (Soak Testing)

It is a type of testing in which one will perform testing for longer period of time in order to check stability.

17. Mutation Testing

It is a White Box Testing done by the Developers where they do some changes to the program and check for its performance. Since it is associated with multiple mutations, it is known as ‘Mutation Testing’.

18. AD HOC Testing

It is a type of testing in which one will perform testing on the application in his own style after understanding the requirements very clear.

19. Functional Testing:
Testing developed application against business requirements. Functional testing is done using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team. Functional testing covers


STLC
[Software Testing Life Cycle]



STLC contains 6 phases.

(1) TEST PLANNING
(2) TEST DEVELOPMENT
(3) TEST EXECUTION
(4) RESULT ANALYSIS
(5) BUG TRACKING
(6) REPORTING

TEST PLANNING

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

Test Plan: – It is a strategic document which describes how to perform testing on an application in an effective and optimized way.

Optimization: – It is a process of reducing the inputs and gathering the same output or even more output.

NOTE: Test Plan is prepared by the Test Lead.


TEST PLAN INDEX [or] CONTENTS




1.0 INTRODUCTION
1.1 Objective.
1.2 Reference Doc.
2.0 COVERAGE OF TESTING
2.1 Feature to be tested.
2.2 Feature not to be tested.
3.0 TEST STRATEGY
3.1 Levels of Testing.
3.2 Types of Testing.
3.3 Test Design Techniques.
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 ENVIRONMENT
RESOURCE PLANNING
8.0 SCHEDULING
9.0 STAFFING & TRAINING
10.0 RISKS & CONTIGENSIS
11.0 ASSUMPTIONS
12.0 APPROVAL INFORMATION




1.0 INTRODUCTION
Objective: – The purpose of the test plan doc is clearly describes here in this session.
Reference Document: – The list of all the documents that are referred to prepare the test plan will be listed out here in this session.
2.0 COVERAGE OF TESTING
Features to be Tested: – The lists of all the features that are with in the scope are listed out here in this session.
Features not to be Tested: – The list of all the features that are not planned for testing based on the following criteria will be listed out here in this session.
o Features out scope
o Low risk features
o Features that are to be skipped based on the time constraints.
o Features functionality.
3.0 TEST STRATEGY
It is an organization level term which is used for testing all the projects in the organization.
NOTE: Usually test strategy is common for all the projects. But upon costumer request there may be slight changes in it.
Test Plan: – Test Plan is defined as project level term which is used for testing a specific project.

Levels of Testing: – The list of all the levels of testing that are followed by that company are listed out here in this session
Types of Testing: – The lists of all the types of testing that are followed by that company are listed out here in this session.
Test Design Techniques: – Technique is some thing that is used for accomplish a complex task in easy manner.
The lists of all the techniques that are followed by that company are listed out here in this session.

Boundary Value Analysis (BVA)
Equivalence Class partition (ECP)

Configuration Management: –


Test Metrics: – The list of all the metrics that are maintained in the organization that are listed out here in this session.
Terminology: –The list of all the terns that are followed in that company along with the meaning will be listed out here in this session.
Automation Plan: – The list of all the areas that are planned for automation listed out here in this session.
List of Automated Tools: – The list of all the automated tools that are used by the company are listed out here in this session.
4.0 BASE CRITERIA
4.1 Acceptance Criteria: – When to stop testing in a full-fledged manner is clearly describe here in this session.
4.2 Suspension Criteria: – When to reject or suspend testing is clearly described here in this session.
5.0 TEST DELIVERABLES – The List of all the documents that are about to be delivered are listed out here in this session.
EX: TEST CASE DOC, REVIEW REPORT, DEFECT PROFILE DOC…….
TEST ENVIRONMENT – The client specified environment is clearly described here in this session.
7.0 RESOURCE PLANNING – ‘Who have to do what?’ is clearly describes in this session.
8.0 SCHEDULING – The starting dates and the ending dates of each and every task is clearly describes in this session.
9.0 STAFFING & TRAINING – How much staff is to be recruited what kind of training should be provided for the newly recruited staff and for the existing employee to accomplish this project successfully will be clearly described in this session.
10.0 RISKS & CONTINGENCES – The list of all the potential risks and the corresponding solutions are listed out here in this session.
RISKS – Unable to deliver the project with in the deadline.
– Customer imposed deadlines.
– Employees leave the company in the middle of the project.
– Unable to test all the features with in the time lake of expertisation.
CONTINGENCES FOR SOLUTION
– Proper plan ensure.
– What not to be tested will be increased in case of customer imposed deadlines.
– People should be maintaining on the Bench.
– Severity priority based execution.
– Training should be provided.
11.0 ASSUMPTIONS
What are all the things that a test engineer should assure is mentioned here in this session.
12.0 APPROVAL INFORMATION
Who has to approve what is clearly describe here in this session.

TEST DEVELOPMENT PHASE

‘Use case’ is a description of functionality of certain feature of an application in terms of actors, actions and responses.

INPUT INFORMATION REQUIRED FOR PREPARING THE USE CASES

APPLICATION


Functional Requirements:
1. ‘LOGIN’ screen should contain Username, Password and Connect to fields, Login, Clear and Cancel Buttons.
2. ‘Connect To’ is not a mandatory field but it should allow the user to select a database object.
3. Upon entering the valid user name, password and click on ‘Login’ button the corresponding page must be displayed.
4. Upon entering some information into any of the fields and clicking on ‘Clear’ button all the fields must be clear and the cursor should be placed in the user name field.
5. Upon clicking on ‘Cancel’ button login screen should be closed.

Special Requirements [or] Validations [or] Business Rules:
1. Initially whenever the login screen is opened ‘Login’ and ‘Clear’ buttons must be disabled.
2. ‘Cancel’ button must be always enable.
3. Upon entering the user name and password the ‘login’ button must be enabled.
4. Upon entering information into any of the fields clear button must be enabled.
5. The tabbing order must be User Name, Password, Connect to, Login, Clear and Cancel.

TEMPLATE OF THE ‘USECASE’
1. Name of the Use Case.
2. Brief description of the Use Case.
3. Actors involving.
4. Special Requirements.
5. Pre Conditions.
6. Post Conditions.
7. Flow of Events.

USE CASE DOCUMENT

1. Name of the Use Case: – ‘Log in’ Use case
2. Brief Description Of the Use Case: – This is Use Case is used for describing the functionality of all the features in the Login screen.
3. Actors Involved: – Admin, Normal User.
4. Special Requirements: –
a) Explicit Requirement – Copy the requirements which are given by the client.
b) Implicit Requirement – Implicit requirements are the requirements that are analyzed by the Business Analyst in order to provide the value to the Application.
Ex: Once the login screen is invoked, the cursor should be placed in the user name field.
5. Preconditions – Login screen must be available.
6. Post conditions – Either Home page or Admin page for the valid user and error message for the invalid user.
7. Flow of Events





MAIN FLOW


Action

− Actor invokes the application.
− Actor enters valid user name, Password and clicks on login button.
− Actor enters valid username valid password selects a database option and click on the login button.
− Actor enters invalid username, valid password and clicks on login button.
− Actor enters valid username, invalid password and click on login button.
− Actor enters invalid user name, password and click on login button.
− Actor enters some information into any of the fields and click on ‘clear’ button.
− Actor clicks on ‘Cancel’ button.
Response

− Login screen is displayed with the following fields.
User Name 2. Password 3. Connect to.
− Authentication either Home page or Admin page is displayed depends on the actor entered.
− Authentication either Homepage of Admin page is displayed with a mentioned data base connection depending upon the actor entered.
− Go to Alternative flow Table ‘1’.
− Go to Alternative flow Table ‘2’.
− Go to Alternative flow Table ‘3’.
− Go to Alternative flow Table ‘4’.
− Go to Alternative flow Table ‘5’.

Alternative Table 1: [Invalid User Name]

Action
− Actor enters invalid username valid password and click on login button. Response
− Authenticates Error message is displayed. “Invalid User name, Please Try Again”



Alternative Table 2: [Invalid Password]

Action
− Actor enters valid username invalid password and click on login button. Response
− Authenticates Error message is displayed. “Invalid Password, Please Try Again”

Alternative Table 3: [Invalid Username & Password]

Action
− Actor enters invalid username and invalid password and click on login button. Response
− Authenticates Error message is displayed. “Invalid Username & Password, Please Try Again”

Alternative Table 4:

Action
− Actor enters some information in to any of the fields and click on ‘Clear’ button. Response
− All the fields are cleared and the cursor is placed in the username field.

Alternative Table 5:

Action
− Actor clicks on ‘Cancel’ button. Response
− Login screen is closed.


The Guide Lines to be followed by a test engineer to develop the Test case from a given Use Case.



1. Identify the Module to which the Use case belongs to.
– Security Module.
2. Identify the functionality of the Use case with respect to the total functionality of the application.
– Authentication.
3. Identify the functional points and prepare the functional point doc.
4. Identify the action involved.
– Admin, Normal User
5. Identify the inputs require to perform the use case.
– Valid and Invalid Input.
6. Identify whether the Use Case is linked with any other Use Case.
– Home Page, Admin Page.
7. Identify the ‘Pre condition’
– Login screen must be available.
8. Identify the ‘Post condition’
– Home page or Admin page for valid users and ‘Error message’ for in valid Users.
9. Understand the main flow of the Use case.
10. Understand the alternative flow of the use cases.
11. Understand the special requirements of Business rules.
12. Document the Test Cases for the Main flow.
13. Document the Test Cases for the Alternative flow.
14. Document the Test Cases for the Special requirements.
15. Prepare the cross reference Matrix. (Traceability Matrix).
Functional Point: –

FRS
FRS Functional Point Document Master Test Case Doc Detailed Test Case Doc Defect Profile Doc
UCD
User Name Entry
Password Only
D.B entry

Validation login, connect to, cancel, clear

Traceability Matrix
UCD FPD MTCD DTD DPD


Functional Point: – The point where the user can perform action can be considered as functional point.

Traceability / Cross requirements: – Traceability is a table which contains some information used for tracing back for the reference by linking the corresponding documents in any kind of obvious situation.

Types of Test Cases: – The Test Cases are broadly classified in to 2 types.

(i) User interface Test Cases. (ii) Functional Test Cases.

The functional Test cases are further classified in two types.

(i) +ve Test Cases. (ii) -ve Test Cases.

Guidelines for developing the user interface Test Cases.

1. Check for the availability of all the objects.
2. Check for the alignments of the objects.
3. Check for the consisting of the objects [Size, Color, Font, Type.]
4. Check for the Spelling & Grammar.

Guidelines for developing the +ve Test Cases.

1. A Test engineer should have the +ve perception.
2. A Test engineer should consider the +ve flow of the application.
3. He should always use only the valid inputs.

Guidelines for developing the –ve Test Cases.

1. A Test engineer should have –ve perception.
2. A Test engineer should consider the –ve flow of the application.
3. He should use the invalid inputs.

TEST CASE TEMPLATE

1. Test Objective.
2. Test Scenario.
3. Test Procedure (Functional level term used to test particular functionality).
4. Test Data.
5. Test Cases.

1. Test Objective: – The main purpose of the document is described in this session.
2. Test Scenario: – The situation that are to be tested described in this session.
3. Test Procedure: – It is a functional level term which describes how to perform testing on functionality.
4. Test Data: – The Data that is required for testing is described in this session.
5. Test Cases



TEST CASES

T.C T.C Type Description Expected Value Actual Value Result Savoir Priority Reference
1 UI Check for the availability of all the objects. All the objects must be available as per the OBJ Tab All the objects are available as per the OBJ Tab
Pass
2 UI Check for the consistence of all the objects. All the objects must be consistence. All the objects are consistent. Pass
3 UI Check for the spellings of all the objects. All the objects must be spelled properly as per the OBJ Tab All the objects spelled properly as per the OBJ Tab. Pass
4 UI Check for the enable property of login, clear and cancel buttons. Login, clear buttons must be disabled and cancel button must be enable. Login, clear and cancel buttons are enable Pass
5 UI Check for the curser placement in the application Curser must be placed in the username field. Curser is placed in the user name field Pass
6 +ve Enter username , password as per the V I T and click on login button Corresponding page must be displayed as per the V I T. Corresponding page displayed as per the V I T. Pass
7 +ve Enter Username, password as per the V I T, select a database option and click on login button. Corresponding page must be displayed as per the VIT with the mentioned database connection. Corresponding page displayed with the mentioned database connection. Pass
8 +ve Enter username, password and check for the enable property of login button. Login button must be enabling. Login button is enabling. Pass
9 +ve Enter some information in to any of the fields and check for the enable property of clear button. Clear button must be enabling. Clear button is enable. Pass
10 +ve Enter some information in to any of the fields and click on clear button. All the fields must be clear and the curser should be placed in the username field. All the fields are cleared but the curser is not placed in the username field. Pass
11 +ve Click on the cancel button. Login screen must be closed. Login screen is closed. Pass
12 +ve Check for the tabbing order. Tabbing order must be username, Password, connect to, login, clear and cancel. Tabbing order is working properly. Pass
13 –ve
Enter username, password as per the IVIT and click on login button. Corresponding error message should be displayed as per the IVIT. Corresponding pages are displayed as per the IVIT. Pass
14 –ve Enter either username or password or select a database option and check for the enable property of login button. Login button must be disabled. Login button is enabled. Fail



OBJ TABLE

S.no Object Type
1 User Name Text Box
2 Password Text Box
3 Connect To Combo Box
4 Login Button
5 Clear Button
6 Cancel Button

VALID INPUTS TABLE

S.no User Name Password Expected Page Actual Page
1 Suresh QTP Admin Admin
2 Santos Bunny Homepage Home page
3 Admin Admin Admin Admin
4 Madhav Mmd Home page Home page

INVALID INPUTS TABLE

S.no User Name Password Expected Page Actual Page
1 Sures QTP Invalid Username Please try again Error message displayed.
2 Santos Bun Invalid Pass word Please try again
3 Test Test Invalid Username & Password Please try again


TEXT EXCUTION PHASE


In this phase the test engineers will do the following actions.

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 of the test case document.

RESULT ANALYSIS PHASE


In this phase the Test engineer will compare the actual value with the expected value and both are matched he will mention the result as pass otherwise failed.

BUG TRACKING

‘Bug tracking’ is a process in which the defects are identified, isolated and maintained.

1 2 3 4 5 6 7 8 9 10 11



(1) Defect ID.
(2) Defect Description.
(3) Steps for reproducibility.
(4) Submitter.
(5) Date of Submission.
(6) Build Number.
(7) Version Number.
(8) Assigned to.
(9) Severity.
(10) Priority.
(11) Status.

(1) Defect ID: – The sequence of defect numbers will be there in this session.
(2) Defect Description: – What exactly the defect is clearly describes here in this session.
(3) Steps for reproducing: – The lists of all the steps that are followed by the test engineer to identify the defect are listed out here in this session. So, that the developer will follows the same steps in order to reproduce the defects.
(4) Submitter: – The name of the test engineer who submitted the defect is mentioned here in this session.
(5) Date of Submission: – The date on which the defect is submitted is mentioned.
(6) Build Number: – The corresponding build number will be mentioned here in this session.
(7) Version Number: – The corresponding version will be mentioned here in this session.
(8) Assigned to: – This field is not filled by the Test engineer, but it is filled by the Project Manager or Project Leader with the name for where the defect is assigned.
(9) Severity: – Severity describes how serious the defect is this is classified in to 4 types.
a) Fatal b) Major c) Minor d) Suggestion.

a) Fatal: – If at all the problem is related to the navigational block or unavailability of the functional then such types of problems is treated to be ‘Fatal’.
b) Major: – If at all the major functionality is not working fine then such type problems treated to be ‘Major’ defects.
c) Minor: – If at all the problems is related to the feel of ‘Look and Feel’ of the application. Such type of defects is treated to be ‘Minor’ defects.
(10) Priority: – The priority defines the sequence in which the defects has to be rectified. Priority is classified in to 4 types.
a) Critical. b) High. c) Medium. d) Low.

Usually the ‘Fatal’ defects are given ‘Critical Priority’.
‘Major’ defects are given ‘High Priority’.
‘Minor’ defects are given ‘Medium Priority’.
‘Suggestion’ defects are given ‘Low Priority’.
But there are some situations where in the priority change.
Case 1: – Low severity High Risk. In case of client visit all the look and feel defects are given highest priority.
Case 2: – High severity Low priority. Whenever the functionality unavailable the test engineer will raise it as a ‘Fatal defect’. But, if that functionality is under development and it taken some more time and that such situation is ‘Low priority’ given by Project Manager or Project Leader.

BUG LIFE CYCLE

New/ open: – Whenever the test engineer identifies the defect newly for the first time then he will set the states as new/open. But some companies will say it as new and once the developer accept as defect he will set as open.
Fixed for verification: – Whenever the test engineer raises the defects and the developer rectifies it the he will set the status as of the defect as ‘Fixed for verification’ before releasing the next build.
Reopen and Closed: – Whenever the defects are rectified and next build is releasing to the testing department then the test engineer will check whether the defects rectified properly or not if they feel the defects is not rectified properly then they will wet the status as ‘Reopen’ if at all they feel that the defect is rectified properly then they will set status as ‘Close’.
Hold: – Whenever the developer is in a confusion situation to accept or reject the defect in such situation he will set the status as ‘Hold’.
As per Design: – Whenever the new requirements are given by the development team and the developers incorporated those new fields and release to the testing department. As the test engineers are not aware of those new changes he will raise as them defects. But the developers will set the status as ‘As per Design’.
Testers Error: – If at all the developer feels it is not at all a defect then he will set the status as ‘Tester Error’.

REPORTING PHASE

(1) Classical Bug Reporting Process:


Drawbacks: – Time consuming, Redundancy, insecurity.

(2) Common Repository oriented Bug reporting Process:


Drawbacks: – Time consuming, Redundancy.

(3) Bug Tracking Tool oriented Bug Reporting Process:
Bug Tracking Toll is software which can be accessed by the authorized persons only. It is used for complete bug tracking process.

TEST DESIGN TECHNIQUES

Whenever the test engineer is developing the test cases he may face some difficulties. In order to overcome those difficulty and complete the tasks easily there are some techniques known as ‘Test Design Techniques’

(1) Boundary Value analysis: – Whenever the test engineer need to develop the test cases for a range kind of the input, then he will use a technique called ‘Boundary value analysis’.
Using this technique one will



(2) Equivalence Class Partition: – It is a technique used by the test engineer in order to develop the +ve and –ve test cases easily for a functionality which has more number of validations. Using this technique one can divide the valid class inputs and invalid class inputs.


Case Study: – Develop the test cases to test a Text Box which has the following validation.

(a) It should accept minimum 4 characters and maximum of 20 characters.
(b) It should accept small a – z only.
(c) It should accept special symbols ‘@’ and ‘_’ only.

Grab this Widget ~ Blogger Accessories