VIKRAM

MANUAL TESTING

Manual Testing
Introduction:
Project: Project is something that is developed based on the particular customers requirements and used by that customer only. Product: Product is something that is developed based on companys specifications and used by multiple customers. Note: In case of product company will decide the specifications by gathering the requirements from so many customers who has the need of such type of product. Testing: Testing is a process in which the defects are identified, isolated, subjected or reported for rectification and ensure that the product is defect free in order to product a quality product in the end and hence customers satisfaction. Bidding the project: Bidding the project is defined as request for proposal, estimation and signoff. Kickoff Meeting: It is an initial meeting conducted in the software company soon after the project is signed off in order to discuss the overview of the project and also to select a suitable project manager. Usually high level management, project managers, technical managers, quality managers, develop leads, tech leads and sometimes customer representatives will be involved in this meeting * Any kind of startup meeting can be considered as Kickoff meeting. PIN (Project Initiation Note): It is mail prepared by project manager and sent to the CEO of the software company as well as to all of his core team members in order to intimate them that they are about to start the actual project activities.

Software Development Life Cycle (SDLC):

There are 6 phases in the SDLC 1. Initial or Requirement Phase. 2. Analysis Phase. 3. Design Phase. 4. Coding Phase. 5. Testing Phase. 6. Delivery & Maintenance Phase.

Initial or Requirement Phase:

Task: Interacting with the customer and gathering the requirements. Roles: Business Analyst (BA), Engagement Manager (EM)

Page 1 of 21

VIKRAM

MANUAL TESTING

Process: First of all the BA will take an appointment from the customer, collect the template from the company, meets customer on the appointed date and gathers the requirements with the help of the template and will come back to the company with requirements document. EM will go through the requirements and will try to find the extra requirements and confused requirements. If at all any extra requirements are found he deals with the excess cost of the project. If at all any confused requirements are found then he will asks his corresponding team to build a prototype, collects the prototype demonstrates it to customer, gathers the clear req. and will finally handover the requirement document to the BA. Proof: The proof document of this phase is Requirement document. This document is called with following names by different companies FRS Function Requirement Specification SRS Software Requirement Specification URS User Requirement Specification CRS Customer/Client Requirement Specification BRS Business Requirement Specification BDD Business Design Document BD Business Document * Some companies will maintain 2 documents in the initial phase, 1 for overall business flow information and the other is for detailed function information. * Some companies will maintain both the information in a single document. Template: It is defined as predefined format which is used for preparing a document very easily and perfectly. Prototype: It is a roughly and rapidly developed model which is used for demonstrating to the client, gathers the clear requirements and also to win the confidence of customer.

Analysis Phase:
Tasks: 1. Feasibility study. 2. Tentative planning. 3. Technology selection & environment confirmation 4. Requirement analysis Roles: System Analyst (SA), Project Manager (PM), Technical Manager (TM) Process: Feasibility study: It is a detailed study conducted on the requirements document in order to check whether all of the requirements are possible or not within the given time, budget and resources. Tentative planning: Resource planning as well as scheduling will be done temporarily in this section. Technology selection & environment confirmation: The list of technologies required for developing that project successfully will be analyzed as well as the suitable environment for that project also will be analyzed.

Page 2 of 21

VIKRAM

MANUAL TESTING

Requirement analysis: The list of all the requirements like human resources, softwares and hardware required to accomplish that project successfully will be clearly analyzed here in this section. Proof: The proof document of this phase is System Requirement Specification (SRS).

Design Phase:
Tasks: 1. High-level designing 2. Low-level designing Roles: Chief Architect (CA) will do high-level designing Technical Lead (TL) will do the low-level designing Process: CA will divide the whole product into modules by drawing some diagrams using UML (Unified Modeling Language). The TL will divide the modules into sub modules by drawing some diagrams using same UML. code. They will also design the GUI part of the application and also develop the pseudo

Proof: The proof document of this phase is Technical Design Document (TDD).

Coding Phase:
Tasks: Developing the actual code. Roles: Developers or programmers. Process: The developers will develop the actual source code with the help of technical design document as well as by following the coding standards. Proof: The proof document of coding phase is Source Code Document (SCD).

Testing Phase:
Tasks: Testing. Roles: Test Engineers. Process: 1. The testing people will receive the requirement document and will start understanding the requirements. 2. While understanding the requirements if at all they get any doubts, then they will list out all the doubts in the Requirements Clarification Note (RCN). 3. They will send the RCN to the BA and will wait for clarifications. 4. Once the clarifications are given then they will take the test case template and will write the testcases. 5. Once the first build is released, they will execute the testcases. 6. If at all any defects are found, they will list out all the defects in the Defect Profile and will send it to the development department. 7. Once the next build is released, they will execute the required testcases and will try to find the defects. 8. If at all any defects are found they will update the defect profile, send it to development department and will wait for next build. 9. Once the next build is released they will repeat the same process till they feel the product is defect free.

Page 3 of 21

VIKRAM

MANUAL TESTING

Proof: The proof of the testing phase is Quality Product.

Delivery & Maintenance Phase: Delivery:

Task: Delivering the application to the client. Roles: Deployment Engineer Process: Deployment engineer will go to the client place, install the application into their environment and will handover the original software to the client. Proof: Finally the customer and the software company will have an official agreement that agreement is the proof.

Maintenance: Once the application is delivered and the users started using it if at all
any problems are found then that problems will become tasks, based on the problems corresponding roles will be appointed. And they will define the process and solve the problem; this is known as normal maintenance. But some customers will expect continuous maintenance in such situations a team of members from the software company will be going to the clients place daily and takes care of that software.

Sorts of Testing:
There are two sorts of testing 1. Conventional Testing 2. Unconventional Testing Conventional testing: It is a sort of testing in which the test engineer will test the developed application or its related parts are working according to the requirements or not, right from the coding phase of SDLC to the end. Unconventional testing: In this the quality assurance people will check each and every outcome document in order to confirm whether all the roles in the organization are working according to the companys process guidelines or not.

Testing methodology or techniques:

Basically there are 2 types of testing 1. Black box testing 2. White box testing Black box testing: It is a method of testing in which one will perform testing only on the functional part of an application without having the knowledge of structural part. Usually the black box test engineer will perform this. White box testing: It is also called as Glass box testing or Clear box testing; it is a method of testing in which one will perform testing on the structural part of an application. Usually the developers or white box testers will perform it. Grey box testing: It is a method of testing in which one will perform testing on both functional as well as structural part of an application. Usually the test engineer who has knowledge of structural part will perform it.

Levels of Testing:
There are five levels of testing 1. Unit level testing

Page 4 of 21

VIKRAM

MANUAL TESTING

2. Module level testing 3. Integration level testing 4. System level testing 5. User acceptance level testing Unit level testing: Unit is defined as smallest part of an application (program), in this stage the white box testers will check each and every developed program as well as combination of programs are working according to the expectations or not. Module level testing: Module- it is defined as group of related features to perform a major task. In this stage the black box testers will test the functional part of a module. Integration level testing: In this stage the developers will develop interfaces in order to integrate the modules. The white box testers will check whether the interfaces are working properly or not. Developers follow one of the following approaches in order to integrate the modules. 1. Top-down approach: In this approach one will develop the parent module first and then corresponding child modules will be integrated.

2. Bottom-up approach: In this approach child modules will be developed first and then the corresponding parent modules will be developed and integrated.

Page 5 of 21

VIKRAM

MANUAL TESTING

3. Hybrid or Sandwich approach: This is a mixture of both top-down and bottom-up approaches. 4. Big bang approach: In this approach one will wait till all the modules are developed and will finally integrate the modules at a time. Stub: While integrating modules in top-down approach if at all any mandatory module is missing then that module is replaced with a temporary program known as stub. Driver: While integrating modules in bottom-up approach if at all any mandatory module is missing then that module is replaced with a temporary program known as driver. System level testing: In this stage the black box test engineers will perform so many types of testing like load testing, performance testing, compatibility testing, system integration testing etc. System integration testing: It is a type of testing in which one will perform some actions at one module and check for the reflections in all the related modules. User acceptance level testing: In this stage the black box test engineers will test the user desired areas in the presence of user in order to make him accept the application.

Environments: It is defined as group of hardware components with some basic

softwares where one can install presentation logic, business logic and database login. (OR) Environment is a combination of presentation layer, business layer and database layer which can hold the presentation logic, business logic and database logic. Types: There are 4 types of environments 1. Stand-alone environment or 1-tier architecture 2. Client-server environment or 2-tier architecture 3. Web environment or 3-tier architecture 4. Distributed environment or N-tier architecture Stand-alone environment: In this environment 1-tier will be there, all the three layers that is presentation layer, business layer and database layer will be present in that tier only. Whenever the applications need to be used by a single user at a time then a stand-alone environment is suggested. Client-server environment: In this environment 2-tiers will be there, one is for clients and other is for servers. Presentation and business layers will be present in clients and database layer will be present in servers. Whenever the application needs to be used by multiple users with centralized data and also need to access application in single premises very fastly then the client-server environment is suggested. Web environment: In this environment 3-tiers will be there, one is for clients, middle one is for application server and the other is for database server. Presentation logic is present in clients, business logic will be there in application server and database layer will be there in database server. Whenever the application needs to be used all over the world by limited number of people then the web environment is suggested. Distributed environment: This environment is similar to web environment but the number of application servers are increase in order to distribute the load and increase the performance.

Page 6 of 21

VIKRAM

MANUAL TESTING

Whenever the application needs to be used all over the world by huge number of people then the distributed environment is suggested.

SOFTWARE DEVELOPMENT MODELS:

Waterfall Model:

Advantages: It is a simple model, project monitoring and maintenance is very easy. Drawbacks: Cannot accept the new requirements in the middle of the project.

Prototype Model:

Advantages: Whenever the customer is not clear with his requirements then this is the best suitable model. Drawbacks: 1. It is not a full fledged process development model.

Page 7 of 21

VIKRAM

MANUAL TESTING

2. It is slightly time consuming model. 3. Company should bare the cost of the prototype. 4. User may limit his requirements by sticking to the prototype.

Evolutionary Model:

Advantage: Whenever a customer is evolving the requirements this is the best suitable model. Drawbacks: 1. Time consuming model. 2. Costly model. 3. Cannot define the deadlines. 4. Project and maintenance is difficult.

Spiral Model:

Page 8 of 21

VIKRAM

MANUAL TESTING

Advantages: Whenever a risk based project need to be developed then this is best suitable model. Drawbacks: 1. Time consuming model. 2. Costly model. 3. Risk analysis is a difficult task. Verification: Its a process of checking conducted on each and every role in the organization in order to confirm whether all of them are doing their work according to the companys process guidelines or not. Validation: Is a process of checking conducted on the developed product or its related parts in order to confirm whether they are working according to the requirements or not.

V-Model:

Advantages: As verification, validations are done as well as test management process is followed the outcome will be quality product. Drawbacks: Time consuming and costly model.

Page 9 of 21

VIKRAM

MANUAL TESTING

Types of Testing:
Build Acceptance Testing (OR) Build Verification Testing (OR) Sanity Testing:
It is a type of testing in which one will perform overall testing on the released build in order to confirm whether it is proper for conducting detailed testing or not. Usually they check the following in this type of testing 1. Whether the build can be properly installed into the environment or not. 2. Whether one can navigate to all the pages in the application or not. 3. Whether all the important objects are available and properly arranged or not. 4. Whether all the required connections are properly established or not. Some companies even call this type of testing as Smoke Testing, but some companies will say that before releasing the build the developers will conduct overall testing on the build that is know as smoke testing and once it is released whatever the testers are doing is known as BAT or BVT or Sanity testing.

Regression Testing:
It is a type of testing in which one will perform testing on the already tested functionality again and again. Usually it will be done in two scenarios 1. Whenever the testers identify the defects sent to the development department, next build is released then the test engineers will check the defect functionality as well as related functionality once again. 2. Whenever some new features are added to the application, next build is released to the testing department then the test engineers will check the related features of those new features once again in order to confirm whether they are working fine as previous or not.

Retesting:
It is a type of testing in which one will perform testing on the same functionality again and again with multiple sets of data in order to come to a conclusion whether it is working fine or not. Note: 1. Regression testing starts from the 2nd build and continues up to last build. 2. Retesting starts from 1st and continues till last build. 3. During regression testing also retesting will be done.

Alpha Testing:
It is a type of user acceptance testing conducted in the software company by the test engineers in the presence of the user just before delivery.

Beta Testing:
It is a type of user acceptance testing conducted in the client place either by the end-users or by the third party testing experts just before actual implementation.

Static Testing:
It is a type of testing in which one will perform testing on the application or its related parts without doing any actions. EX: GUI testing, document testing, code review and etc.

Page 10 of 21

VIKRAM

MANUAL TESTING

Dynamic Testing:
It is a type of testing in which one will perform testing on the application or its related parts by doing some actions.

Usability Testing:
It is a type of testing in which one will perform testing on the user-friendly ness of the application.

Installation Testing:
It is a type of testing in which one will install the application into the environment by following the guidelines provided in the installation document in order to confirm whether those guidelines are perfectly suitable for installing the application into the environment or not.

Compatibility Testing:
Its a type of testing in which one will install the application into the multiple environments prepared with different combinations in order to confirm whether the application is compatible with those environments or not. Usually this type of testing will be conducted on products rather than projects.

Monkey Testing:
It is a type of testing in which one will intentionally performs abnormal actions in order to check the stability of application.

Exploratory Testing:
Exploring: Having some basic knowledge about a concept, doing something and knowing more about the same thing is known as exploring. Its a type of testing in which the domain experts will perform testing on the application just by exploring the functionality without having knowledge of requirements.

End-to-end Testing:
Its a type of testing in which one will perform testing on the end-to-end scenarios of the application. Ex: Login Balance Enquiry Deposit/withdrawal Balance Enquiry Logout

Security Testing:
Its a type of testing in which one will perform testing on the application in order to confirm whether the application is properly protected or not. To do the same usually the black box test engineers will perform the following types of testing 1. Authentication testing. 2. Direct URL testing. 3. Firewall leakage testing or user privileges testing. Authentication testing: It is a type of testing in which one will enter different combinations of user names and passwords in order to confirm whether only the authorized users are accessing the application or not.

Page 11 of 21

VIKRAM

MANUAL TESTING

Direct URL testing: It is a type of testing in which one will enter direct URLs of secured pages in order to confirm whether the application properly protected or not. Firewall leakage testing: Its a type of testing in which one will enter into the application as one level of user and will try to access beyond its limits, in order to confirm whether the application is properly protected or not.

Port Testing:
Its a type of testing in which one will install the application into the clients environment and check whether it is compatible with that environment or not. It is used in V-model.

System Integration Testing:

Its a type of testing in which one will perform some actions at one module and check for the reflections in all the related modules.

Reliability Testing (or) Soak Testing:

Its a type of testing in which one will test the application continuously for long period of time in order to check its stability.

Mutation Testing:
Its a type of testing in which one will perform testing on the application or its related parts by doing some changes to it.

Adhoc Testing:
Its a type of testing in which one will test the application in their own style after understanding the requirements clearly.

Software Testing Life Cycle (STLC)

STLC 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 storage document which contains some information that describes how to perform a task in an effective, efficient and optimized way. Optimization: Its a process of utilizing the input resources to their level best and getting the maximum possible output. Test Plan: It is a strategic document which contains some information that describes how to perform testing on the application in an effective, efficient and optimized manner.

* Test plan will be prepared by the Test lead. Contents of test plan:
1.0 Introduction: Objective: The purpose of the document will be clearly mentioned in the objective. Reference documents: The list of all the documents referred while preparing this document will be mentioned here in this section.

Page 12 of 21

VIKRAM

MANUAL TESTING

Ex: System requirement specification, project plan. 2.0 Coverage of testing: Features to be tested: The list of all the features that are with in the scope and need to be tested will be mentioned here in this section. Features not to be tested: The list of all the features that are not planned for testing will be mentioned here in this section. Ex: 1. Features that are out of scope. 2. Low risk features. 3. Features that are planned to be incorporated in future. 4. Features that are skipped based on the time constraints. 3.0 Test strategy: Its an organizational level term, which is common for all the projects in the organization. Test plan: Is a project level term which is specific to a particular project in the organization. Levels of testing: The list of all the levels of testing that are maintained in that company will be mentioned here in this section. (Unit, module, integration, system and user acceptance). Types of testing: The list of all the types of testing that are performed in that company will be mentioned in this. Test design techniques: The list of all the techniques that are used in the company while designing the test cases will be mentioned here in this section. Ex: BVA (Boundary Value Analysis) ECP (Equivalence Class Partition) Test Metrics: The list of all the tasks that will be measured in that company will be listed out here in this section. Terminology: The list of all the terms that are used in that company along with their meanings will be mentioned here in this section. Automation plan: The list of all the areas that are planned for automation testing in that company will be mentioned here. Automated tools: The list of automated tools used by that company will be mentioned in this section. 4.0 Base criteria: Acceptance criteria: When to stop testing on the application will be clearly mentioned here in this section. Suspension criteria: When to suspend the build will be clearly mentioned here in this section. 5.0 Test deliverables: The list of all the documents that are to be prepared and delivered during the testing process will be mentioned in this section. 6.0 Test environment: The clear details of the environment that is about to be used for testing will be mentioned in this section.

Page 13 of 21

VIKRAM

MANUAL TESTING

7.0 Resource planning: Who has to do what will be clearly mentioned here in this section. 8.0 Scheduling: The starting dates and the ending dates of each every task will be planned and mentioned in this section. 9.0 Staffing and Training: How much staff is to be recruited and what kind of training is to be provided to accomplish that project successfully will be clearly mentioned here in this section. 10.0 Risks and Contingencys: The list of all the potential risks and corresponding solution plans will be listed out here in this section. Ex: 1. Risks- Employees may leave the organization in the middle of the project. 2. Time- Unable to deliver the project with in the deadline. 3. Customer may impose the deadlines. 4. Unable to test all the features with in the given time. Contingencies: 1. Employees need to be maintained on bench. 2. Proper plan insurance. 3. What not to be tested should be imposed in case of deadlines. 4. Priority based execution. Assumptions: The list of all the assumptions that a test engineer need to assume will be mentioned here in this section. Approval information: Who has approved this document and when it is approved will be clearly mentioned here in this section.

Test Development:
Requirement documents: High level information, Low level information and Screen shots Use cases, sample snapshots. Use-case: Its a description of functionality of certain features of an application in place of certain actors, actions and responses.

Input information required for preparing the use cases:

Screenshot-Login Window

User Name Password Connect to LOGIN CLEAR CANCEL

Page 14 of 21

VIKRAM

MANUAL TESTING

Functional Requirements: 1. Login screen should contain username, password, connect to fields, login, clear and cancel buttons. 2. Connect to fields is not a mandatory field but it should allow the user to select a database option when ever required. 3. Upon entering valid data into username and password fields and clicking on login button corresponding pages must be displayed. 4. Upon clicking on clear button all the fields must be cleared and the cursor must be available in the username field. 5. Upon clicking on the cancel button login screen should be closed. Special Requirements: 6. Upon invoking the application login and clear buttons must be displayed. 7. Cancel button should be enabled. 8. Upon entering some information into username and password fields login button must be enabled. 9. Upon entering some information into any of the fields clear button must be enabled. 10. Tabbing order must be username, password, connectto, login, clear and cancel buttons. Use-case template: 1. Name of the use-case. 2. Brief description of use-case. 3. Actors involved. 4. Special requirement. 5. Pre-conditions. 6. Post-conditions. 7. Flow of events. Use-case documents: 1. Name of the use-case: Login use-case. 2. Brief description of the use-case: This use-case document is used for describing the functionality of all the features present in the login screen. 3. Actors involved: Normal user and admin user. 4. Special requirements: There are 2 types of requirements; explicit requirements and implicit requirements. Explicit requirements: The special requirements given by the customer are known as explicit requirements. Implicit requirements: The requirements that are analyzed by the business analyst which will add some value to the application are known as implicit requirements. Explicit requirements for Login: 1. Upon invoking the application login and clear buttons must be disabled. 2. Cancel button must be enabled.

Page 15 of 21

VIKRAM

MANUAL TESTING

3. Upon entering some information into username and password fields login button must be enabled. 4. Upon entering some information into any of the fields clear button must be enabled. 5. Tabbing order must be username, password, connectto, login, clear and cancel buttons. Implicit requirements for Login: 1. Initially cursor must be positioned in the username field whenever login screen is invoked. 2. Upon entering invalid username, valid password and clicking on login button the following error message must be displayed Invalid username please try again. 3. Upon entering valid username, invalid password and clicking on login button the following error message must be displayed Invalid password please try again. 4. Upon entering invalid username & invalid password and clicking on login button the following error message must be displayed Invalid username & password please try again.

5. Pre-conditions: Login screen must be available. 6. Post-condition: Either homepage or admin page for valid users, error message for invalid users.

Flow of events:
Main flow: Action 1. Actors invoke the application. Response Application displays the login screen with the following fields like username, password, connectto, login, clear, cancel. Authenticates, application displays either homepage or admin page depending upon the actor entered. Authenticates, application displays either homepage or admin page depending upon the actor entered with the mentioned database connection. Go to alternative flow table1. Go to alternative flow table2. Go to alternative flow table3.

2. Actors enter valid username valid password and clicks on login button. 3. Actor enters valid username, valid password, selects a database option and clicks on login button. 4. Actor enters invalid username, valid password and clicks on login button. 5. Actor enters valid username, invalid password and clicks on login button. 6. Actor enters invalid username and invalid password and clicks on login button. 7. Actor enters some information into any of the field and clicks on clear button. 8. Actor clicks on cancel button.

Go to alternative flow table4.

Go to alternative flow table5.

Page 16 of 21

VIKRAM

MANUAL TESTING

Alternative flow table1 (Invalid Username) Action Actor enters invalid username, password and clicks on login button. valid Response Authenticates, application displays the following error message Invalid username please try again.

Alternative flow table2 (Invalid Password) Action Actor enters valid username, invalid password and clicks on login button. Response Authenticates, application displays the following error message Invalid password please try again.

Alternative flow table3 (Invalid Username & Password) Action Actor enters invalid username, invalid password and clicks on login button. Alternative flow table4 (Clear- Click) Action Actor enters some information into any of the fields and clicks on clear button. Alternative flow table5 (Cancel- Click) Action Actor clicks on cancel button. Use-case document: The guidelines to be followed by a test engineer soon after the use-case document is given for them. 1. 2. Identify the module to which the use-case belongs to. Security module. Identify the functionality of the use-case with respect to the total functionality. Authentication. Identify the actors involved in the use-case. Normal user and admin user. Identify the inputs required for performance testing. Valid & invalid usernames and passwords. Identify whether the use-case is linked with any other use-case. Home page & admin page. Identify the pre conditions. Login screen must be available. Identify the post conditions. Either homepage for valid users and error message for invalid users. Response Application closes the login screen. Response All the fields are cleared in the application and make the cursor positioned in the username field. Response Authenticates, application displays the following error message Invalid username & password please try again.

3. Identify the functional point and prepare the functional point document. 4. 5. 6. 7. 8.

9. Understand the main flow of the application. 10. Understand the alternative flow of the application. 11. Understand the special requirements. 12. Document the test cases for the main flow.

Page 17 of 21

VIKRAM

MANUAL TESTING

13. Document the test cases for the alternative flow. 14. Document the test cases for the special requirements. 15. Prepare the cross reference matrix (or) traceability matrix. Functional Point: The point where a user can perform some action is known as functional point. Testing process related documents: Use-case doc functional point test scenario test case doc project profile doc.

Traceability Matrix:
Its a document which contains a table of linking information used for tracing back for the reference in any kind of confusion or questionable situations. Example: Complete traceability matrix Use-case ID Functional point ID Test scenario ID Test case ID Test defect ID

Requirement traceability matrix Test case ID Requirement ID

Defect traceability matrix Defect ID Test case ID

Types of test cases:

Test cases can be broadly divided into 3 types: 1. GUI. 2. Functional test cases. 3. Non-functional test cases (performance, usability, compatibility etc) * Functional test cases are further divided into 2 types 1. Positive 2. Negative Guidelines for writing the GUI test cases: 1. Check for the availability of the objects. 2. Check for the consistency of all the objects. 3. Check for the alignments of all the objects. 4. Check for the spelling and grammar. Apart from the above example any other idea we got with which we can test something without doing any actions will fall under GUI test cases. Guidelines for writing +ve test cases: 1. A test engineer should have +ve mind setup. 2. He should consider +ve flow of the application.

Page 18 of 21

VIKRAM

MANUAL TESTING

3. He should use only the valid inputs from the point of the functionality. Guidelines for writing ve test cases: 1. A test engineer should have ve mind setup. 2. He should consider ve flow of the application. 3. He should use at least one invalid input for each set of data.

Test Execution:
In this phase the test engineer will do the following 1. He will perform the action as it is described in the description column. 2. He will observe the actual behavior of the application. 3. He will write the observed value under the actual result column. Result Analysis: In this phase the test engineer will compare the actual value with expected value, if both are matching then he will decide the result as PASS otherwise FAIL. In case if the test case is not executed due to some reasons then in the result column it will be specified as BLOCKED. Bug Tracking: It is a process in which the defects/bugs are identified, isolated and managed. Version: Whenever some modifications or new changes made to the application then version number is changed by the configuration manager depending upon the amount of change. Build: Whenever the developer fixes the defects releases the application to the testing department then the build is changed. * It will be changed every time the developer releases to the testing department.

Defect Profile
Defect Profile Document:
(Columns in the defect profile document) Defect ID: The sequence of defect numbers will be mentioned here in this column. Test case ID: The test case ID based on which the defect is found will be mentioned here in this column. Defect Description: What exactly the defect will be clearly mentioned here in this column. Reproducible steps: The list of all the steps that are followed by the test engineer for reproducing the defect will be mentioned in this column. Detected By: The alias name of a test engineer who found that defect will be mentioned in this column. (Unique names) Detected Date: The date on which the defect is found will be mentioned in this column. Detected Build: The build number in which the defect is found will be mentioned in this column.

Page 19 of 21

VIKRAM

MANUAL TESTING

Detected Version: The version number in which the defect is found will be mentioned in this column. Severity: It describes the seriousness of the defect. It is classified into 4 types 1. FATAL: If at all the problems related to navigation blocks or unavailability of main functionality then such type of defects is treated as fatal defects. 2. MAJOR: If at all the problems are related to functionality of the main features, then such type of defects is treated as major defects. 3. MINOR: If at all the problems are related to look and feel of the application then that type of problems can be treated as minor defects. 4. Suggestion: If at all the problems are related to value of the application then such type of defects is treated as suggestions. Priority: It describes the sequence in which the defects need to be rectified; it is classified into 4 types 1. CRITICAL 2. HIGH 3. MEDIUM 4. LOW Usually the fatal defects will be given critical priority, major will be given high, minor will be given medium and suggestion will be low priority. But depending upon the situations the priority will be changed by the development lead i.e. sometimes the highest severity will be given least priority and sometimes vice versa.

BUG LIFE CYCLE

Hold No Requirement Rejected Development Is it really a defect Y Open Deferred As per design

Application B#1 Testing

?
B#2

Rectification

Fixed

Y New If defe ct

No Stop the testing

No Reopen Is defect really rectifie d? Y Closed

New: Whenever the defect is newly found by the test engineers then they will set the status as New.

Page 20 of 21

VIKRAM

MANUAL TESTING

Open: Whenever the developers accept the defect then they will set the status as open. Deferred: Whenever the developers accept the defect and want some extra time to rectify the defect then they will set the status as deferred. Fixed: Also called as rectified, whenever the developers rectify the defect they will set the status as fixed. Reopen & Closed: Once the next build is released the test engineers will check whether the defect is really rectified? If it is really rectified then they will set the status as closed otherwise reopen. Hold: Whenever the developer is confused to accept or reject the defect then they will set the status as hold. Whenever the defect is in hold status there will be a meeting on that defect and if its decided as a defect then the developers set the status as open otherwise the testers will set the status as closed. Rejected: Whenever the developer feels its not at all a defect then they will set the status as rejected. Once the defect is in rejected state the test engineers will once again check and if they also feel its not a defect then they will set the status as closed otherwise reopen. As per design: Whenever the developer feels the test engineer has raised this defect without having the awareness of latest requirements then they will set the status as as per design. Whenever the defect is in as per design state, the test engineers will go through the latest requirements and if they also feel it is as per the design then they will set the status as closed otherwise reopen.

Bug Reporting:
1. Classical bug reporting process. 2. Common repository oriented bug reporting process. 3. Bug tracking tool oriented bug reporting process. Bug tracking tool: It is a software application which can be used only by the authorized people and provides all the facilities for bug tracking purpose. Ex: Bugzilla, PR-Tracker, Issue-Tracker

Test closure activity:

In this activity the test lead will prepare Test Summary Report which contains the information like number of cycles of execution, duration of each cycle, number of test cases executed in each cycle, number of defects found in each cycle and etc.

Page 21 of 21