Professional Documents
Culture Documents
Scope of getting job is very high. No need to depend up on any technologies. Testing remains forever I want to be consistent through out my life
Why
Who
What
1. 2. 3. 4.
Project:
Project is some thing that is developed based on the particular customers requirements and used by that customer only ( E.g.: Marriage laddu)
Product: Quality:
It is some thing that is developed based on the companies specification and used by the multiple customers (e.g.: Thirupathi laddu)
Page 2
Defect: - Defect is defined as deviation from the requirements Latest definition for quality: - quality is defined as not only the justification of
requirements but also the presence of value (User friendliness) Testing: Testing is processes, in which the defects are identified, isolated, subjected for rectification & ensure that the product is defect free. In order to produce the quality product in the end and hence customer satisfaction.
Bidding the project is defined as request for proposal, estimation and signing off (Official agreement).
It is an initial meeting conducted in the soft ware company soon after the project is signed off. In order to discuss the overview of the project and to select a project manager for the project. Usually high level management, Project managers, team managers, quality managers, team leads and quality leads will be involved in this meeting.
It is a mail prepared by the project manager and sent to the CEO of the soft ware company in order to get the permission to start the project developments.
Software Development Life Cycle (SDLC):SDLC contains six phases they are 1. Initial phase or requirements phase. 2. Analysis phase 3. Design phase 4. Coding Phase 5. Testing Phase 6. Delivery & Maintenance Phase.
I. Initial Phase or Requirements Phase : (a) Tasks: Interaction with the customer and gathering the requirements. (b) Roles: Business Analyst (B.A), Engagement Manager (E.M)
Process: First of all the business analyst will take an appointment from the customer, collects the templates from the company, meets the customer on appointed day, gathers the requirements with the help of template and comes back to the company with the requirements documents. 2
Page 3 Once the requirement document has come to the company the engagement manager will check whether the customer gives any extra requirements or confused requirements. In case of extra requirements he deals the excess cost of the project. In case of confused requirements he is the responsible for prototype demonstration and gathering the clear requirements.
Templates: It is a pre defined format, which contains the predefined fields, and
used for preparing a document in an easy, comfort and perfect manner.
Prototype: -Defined as a roughly & Rapidly developed model which is used for
demonstrating to the client, In order to gather the clear requirements and to win the confidence of a customer.
II.
Analysis Phase:
(a) Tasks:
1. Feasibilty Study 2. Tentative planning 3. Technology Selection
(b) Roles:
Process
1. Feasibility Study: - It is detailed study of the requirements in order to check weather the requirements are possible or not. 2. Tentative Planning: In this section the resource planning and the time planning (scheduling) is done temporarily.
Page 4 3. Technology Selection: - The list of all the technologies that are required to accomplish this project. Successfully will be analyzed and listed out in this section. 4. Requirement Analysis: - The list of all the requirements that are required to accomplish this project. Successfully will be analyzed and listed out here in this section. SRC- System requirement specification
Proof: - The proof of this phase is system Requirement specification. III. Design Phase: Tasks: 1. High level designing 2. Low level designing
Roles: High-level designing is done by the chief Architect & Low level
designing is done by the Technical Lead
Process: The Chief architect will be drawing some diagrams using unified modeling
language in order to divide the whole project in to modules. The Technical lead will also draw some diagrams in order to divide the modules in to sub modules. The technical lead will also develop the PSEUDO code in order to make developers comfortable while de3veloping the actual code.
Proof: The proof document of this phase is Technical design document. IV. Coding phase: (a) Task: Developing or Programming (b) Roles: Developers or Programmers Process: Developers will develop the actual code by using the technical design
document as well as following the coding standards like Proper indentation, color coding, proper commenting and etc..,
Page 5
V.
Testing Phase: (a) Task: Testing (b) Roles: Test engineers Process:
1. First of all the test engineers will collect the requirements document and try to understand all the requirements 2. While understanding it at all they get any doubts they will list out all of them in a review report. 3. They will send the review report to the author of the requirements document for clarifications. 4. Once the clarifications are given and after understanding all the requirements clearly, they will take the test case template and writes the test cases. 5. Once the first build is released then they will execute the test cases 6. If at all any defects are found. They will list out all of them in a defect profile template then 7. They will sent the defect profile document to the development department and then will be waiting for the next build to be released. 8. Once the next build is released then they re-execute the test cases. 9. If at all any defects are found they will update the profile document and sent it to the development department and will be waiting fro the next build to be released. 10. This process continuous till the product is defect free.
Test Case: (def) Test case is an idea of a test engineer based on the customers
requirements in order to test a particular feature or a function.
Page 6
Delivery:
(a) Task: - Installing the application in the clients environment (b) Rolls: -Deployment engineer or Senior test engineers.
Process: - The senior test engineer or deployment engineer will be going to the clients place and install the application in their environment with the help of the guidelines provide in the deployment document.
Maintenance:
After delivering the soft wate while using if at all any problem occurs then that problem becomes a task, based on that problem corresponding rolws will be appointed, the roles will defined the process and solve that problem. Some clients may request for the continuous maintenance in such situations a group of people from the software company will be continuously working on the clients place and taking care of the soft ware.
************************^^^^^^^^^^^^^^^^^^^************************ Where exactly the testing comes in to picture? Which sort of testing you are expecting? How many sorts of testing are there? There are two sorts of testing.
Page 7 Testing
(a) Black-Box Testing: If one performs testing only on the functional part of an application with out having any structural knowledge then tat method of testing is known as Black-Box testing, usually the test engineers perform it. (b) White-Box Testing: If one performs testing on the structural part of an application then that method of testing is known as white box testing, usually the developers or white box testers perform it. (c) Grey-Box Testing: If one performs testing on both the functional part as well as the structural part of an application then that method of testing as known as gray box testing using the test engineers who have structural knowledge will perform gray- box testing.
Levels of Testing:
There are five levels of testing 1. Unit Level Testing 2. Module Level Testing 3. Integration Level Testing 4. System Level Testing 5. User Acceptance Testing (U.A.B)
1.Unit Level Testing: It is a level of testing in which one will perform testing on the units. It is a white box testing and usually developers or white box testers will perform.
2.Module Level Testing: Module: Module is defined as a group of related functionalities to perform a major
task It is a level of tasting in which one will perform testing on the modules. It is a black box testing and usually test engineers perform it. 7
Page 8
3.Integration Level Testing: It is a level of testing in which the developers will develop some interfaces to integrate the modules and test whether the interfaces are working fine or not. It is a white box testing usually developers or white box tasters perform. The developers may follow one of the following approaches while integrating the modules. 1.Top-down approach 2.Bottom up approach 3.Hybrid or Sandwich approach 4.Bigbang approach 1.Top-down approach: - In this approach one will develop the parent modules first and then integrate them with the related child modules 2.Bottom-up approach: - In this approach one will develop the child modules first and integrate them to the parent modules 3.Hybrid approach Or Sandwich approach:- This is a mixed approach of both the top down and bottom up approaches
4.Big bang approach:-In this approach one will wait till all the modules are ready
and finally they will integrate all the modules at a time STUB: - While integrating the modules in top down approach if at all any mandatory module is missing then that module is replace with a temporary program known as STUB
mandatory module is missing then that module is replaced with a temporary program known as DRIVER
4.System integration Testing: It is a type of testing in which once the complete application is developed one will perform an action at one module and checks for the reflections at the corresponding modules. It is a black box testing and usually test engineers perform.
Page 9
5.User- Acceptance Testing: It is the level of testing in which one will perform the same system testing in the presence of the user in order to make him accept the application. It is a black box testing and usually Test engineer performs it. Environment: - Environment is a combination of three layers (e.g.: Yahoo)
a. Presentation layer b. Business layer c. Data base Layer System: The application installed in to an environment combinable called as system. a. Presentation Logic: The logic that is used for viewing application is known as presentation logic b. Business Logic: - The logic that is used for performing the operations on the application is known as business logic. c. Data Base Logic: - The logic that is used for sharing and retrieving the data is known as database logic. Types of Environment: - There are Four types of environments a. Stand alone environment or One-tier environment b. Client server environment or Two-tier Architecture c. Web environment or Three-tier Architecture d. Distributed environment or N-tier Architecture a.
Stand Alone environment: In this type of environment all the three layers that is presentation layer, Business layer& Database layer will be present in al single tier. This type of environment is suitable for single user application.
One-Tier Architecture
PL BL DBL One tier Architecture
Page 10 b. Client
server environment:
In this type of environments there will be two tiers, one tier is for clients and other tier is for database servers. The presentation layer and the business layer will be present in each and every client . The database layer will be present in the database server. This type of environment is suitable for multi user application in a single or a limited area.
PL+BL
Clients
Server
c. Web environment: - In his type of environment three tiers will be there. One is for clients the middle one is for application server and the other one is for database servers. Presentation layer will be present at clients, Business layer will be present in the application server, and database layer will be present at the database servers. This type of environment is suitable for the applications that are used all over the world by limited number users
Three-tier Architecture:
PL DBL BL PL DBL PL
Clients
Appl Server
Database server
Page 11 E.g.: - Internet Information service (IIS). Example for Application servers: Tom pact, Web logic, web sphere etc.., d. Distributed environment: It is similar to the web environment but the number of application servers are increased and represented in individual tiers in order to distribute the business logic so that the logic will be distributed. N-tier Architecture: Ws PL BL PL PL PL BL BL DBL
Clients
Apl server1
Apl server2
Apl server2
Database server
******************^^^^^^^^^^^^^^^^^^^^^^^********************************
Page 12
PHASE INITIAL
ACTIVIT Req.gathering
ANALYSIS
Sys.design
DESIGN
S/w design
TDD, GUI
UTR
CODING
Implementation
TESTING
DEL&MAINT
Delivery to client
Advantages: It is a simple model Project monitoring & maintenance is very easy Drawbacks: Con not accept the new requirements in the middle of the project (b) Prototype Model: Unclear Req SRS Doc Base lined H/Wprototype S/WPrototepe Client environment confirmation H/Wprototype H/Wprototype
Prototype
Advantages: -
REQ.are BRS DOC Base Refined Lined Whenever the customer is not clear with the requirements this is the best
12
Page 13
Drawbacks: It is not a complete model Prototype has to be built on companies cost User may limit his requirements by sticking to the prototype. (B)
Evolutionary Model:
Application
User validation
User
accept
Advantages: Whenever the customer is evolving the requirements this is the best Suitable model.
Drawbacks: Cannot define the dead lines Project monitoring & maintenance is very difficult No Transparency (No clear)
Advantages: -
Implementation
This is the best suitable for developing the highly risk based project (scientific projects) 13
Page 14
Drawbacks: Risk analysis and estimation is not an easy task It is a costly model It is a time consuming model
Analysis SRS
Coding
Sys testing
SCD
BRS Review
Black
SRS Review
White box
Box testing
testing
Advantages: This is the best suitable for developing the highly risk based project(scientific projects)
Verification: It is a process of checking conducted on each and every role of the organization in order to check whether they are working according to the guidelines or not right from the starting of the process till the ending of the process Validation: It is a process of checking conducted on the developed product in order to check whether it is working according to the requirements or not.
(D) V-Model: Verification Initial& design Phase BRS Validation Preparing proj plan 14
Page 15 SRS Preparing Test plan Req.Phase testing Design Phase testing Program phase testing
Testing
System testing Test management Process User acceptance testing Port Testing S/W efficiency
DRE=A/A+B
Advantages; AS verification and validation as well as test management process is done the out come will be a quality product.
15
Page 16
1.Build Acceptance Testing Or Build Verification Testing Or Sanity Testing: It is a types of testing in which one will conduct over all testing on the released build in order to check whether it is proper for further detailed testing or not. Even some companies call it as smoke testing, but some companies says that just before releasing the build the developers will conduct the overall testing on the build that is known as smoke testing and once the build is released what ever the test engineers do in order to accept the build is known as B.A.T or B.V.T or Sanity Testing.
2.Regression Testing: It is a type of testing in which one will perform testing on the already tested functionalities again and again. It is usually done in two scenarios. 1. Whenever the testers has raised the defects, rectified by the developers and next build is released to the testing department then the test engineers will test the defect functionality as well as the related functionality once again. 2. When ever some new features are incorporated by the developers, next build is released to the testing department then the test engineers will once again test the related functionalities of the new features in order to confirm that they are working same as previous.
Note: - Testing the new functionalities for the first time is known as new testing but not
Regression Testing.
3.Re-Testing: It is a type of testing in which one will test the same functionality again and again with different sets of values in order to come to a conclusion whether it is working or not.
4.- Testing (Alpha Testing): It is a type of user acceptance testing in which the test engineers will test the application in our company, in the presence of the customer.
Advantage: - If at all any defects are found then there is a chance of rectifying them
immediately.
5. -Testing (Beta): It is a type of user acceptance testing done in the clients place either by the end-users or by the third party testing experts before actual implementation.
16
Page 17 Drawback: If at all any defects are found then there is no chance of rectifying them immediately.
6. Static Testing: It is a type of testing in which one will perform testing on the application or application related factors with out performing any action. Eg:- Documentary testing, GUI testing, Code reviews and etc.,
7. Dynamic Testing: It is a type of testing in which one will perform in the application or its related factors by doing some actions Eg: - Functionality testing.
8.Installation Testing: It is a type of testing in which one will install the application in to the environment by following the guide lines provided in the installation document and if the installation is successful then he will come a conclusion that the given guide lines are correct other wise he will come to a conclusion that the given guidelines are not correct.
9.Compatibility Testing: It is a type of testing in which one may have to deploy the application in to the multiple number of environments prepared with different combinations of environmental components in order to check whether the application is compatible with all that environments. This type of testing is usually done to products.
10. Monkey Testing: It is a type of testing in which one will perform abnormal action on the application intentionally in order to check the stability of the application.
11.Usability Testing: It is a type of testing in which one will check whether the application is user friendly or not and it can be comfortably used by the end user or not.
12. Exploratory Testing: It is a type of testing in which one will (Domain Experts) will perform testing on the application with out having the knowledge of requirements but by exploring the functionality.
13.End-To- End Testing: It is a type of testing in which one will perform testing on all the end- to-end scenarios of the application. 17
Page 18
14.Port Testing:It is a type of testing in which one will deploy the application in to the clients environment and check whether it is compatible with that environment or not.
15.Reliability Testing: It is a type of testing I which one will perform testing on the application continuously for long period of time in order to check the stability of the application
16.Security Testing: Its is a type of testing in which one will concentrate on the following areas of the application a. Authentication Testing b. Direct URL Testing (Uniform Resource Location) c. Fire Wall Leakage Testing.
(a) Authentication Testing: It is a type of testing in which one will enter different combinations of usernames and passwords and try to access the home page in order to check whether only the authorized persons are accessing the application or not.
(b) Direct URL Testing: It is a type of testing in which one will enter the URL of an unauthorized page directly in the browser and try to access that page in order to check whether it is been accessed or not.it is a unique kind of testing which is usedwidely.
It is a type of testing in which one will enter as one level of user and try to access the other level of unauthorized pages in order to check whether the firewalls are working properly or not.
17. Mutation Testing: It is a type of testing in which one will perform testing on some thing by doing some changes to it.
18. ADHOC Testing: It is a type of testing in which one will perform testing on the application in his own style after understanding the requirements clearly.
18
Page 19
The Soft Ware Testing Life Cycle Contains Six Phases They are
Test Planning Test Development Test Execution Result Analysis Bug Tracking Reporting
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, efficient and optimized way.
Optimization: Optimization is a process of utilizing the available input resources to their max and getting maximum possible out put.
19
Page 20 1.0
Introduction Objective Reference Document Coverage Of Testing Features To Be Testing Features Not To Be Testing 3.0 Test Strategy Levels Of Testing 3.2 Types of testing 3.3 Test metrics 3.4 Automation Plan 3.5 List of automated tools
4.0
Base criteria 4.1 Acceptance criteria 4.2 Suspension criteria Test Deliverable Test Environment Resource Planning Scheduling Staffing& Training
1.0 Introduction: 20
Page 21 1.1 Objective: The Purpose of the document is clearly described here in this section 1.2 Reference Document: The list of all the documents that are refereed to prepare the test plan will be listed out her in the section.
2.0 Coverage Of Testing: 2.1 Features to be tested: The list of all the features that are to be tested in this phase will be clearly mentioned here in this section. 2.2 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 section a. Out of scope features b. Low risk features c. The functionalities that are planned to be incorporated in future d. The features that are to be skipped based on the time constraints.
3.0 Test Strategy: Test strategy is defined as an organizational 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 used for testing a particular project in the organization.
Note: - Test strategy is common for all the projects but the test plan is
specific for a particular project 3.1 Levels of Testing: The list of all the levels of testing that are followed by 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 in that company will be listed out here in this section.
3.3 Test Metrics: The list of all the metrics that are maintained in that company will be listed out here in this section 21
Page 22
3.4 Automation Plan: The list of all the areas that are plan for automation in that company will be listed out here in this section.
3.5 List Of Automated Tools: The list of all the automated tools that are used in that company will be listed out here in this section.
4.0 Base Criteria: 4.1 Acceptance Criteria: When to stop testing feeling that enough testing has been done on the application is clearly described here in this section.
4.1 Suspension Criteria: When to suspend testing suddenly (abruptly) will be clearly mentioned here in this section.
5.0 Test Deliverable: The list of all the documents that are to be prepared during the testing phase will be listed out here in this section. Eg: Test case, defects profile document.
6.0 Test Environment: The customer specified environment would be clearly described here in this section. The same environment will be simulated in the company and will be used for testing purpose.
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 data of the each and every tasks is clearly planned here in this section.
9.0 Staffing& Training: How much staff is to be recruited and what kind of training is to be provided is clearly described here in this section.
22
Page 23 The list of all the potential risks and the corresponding solution plans will be listed out here in this section.
Example:
Risks:
i. Unable to deliver the soft ware with in dead lines. ii. Employees may leave the organization in the middle of the project iii. Customer may impose the dead lines. iv. Unable to test all the features with in the time. v. Lack of expertisation
11.0 Assumptions: The list of all the assumptions that are to be assumed by the test engineer will be listed out here in this section.
12.0 Approval Information: Who has to approve what is clearly described here in this section.
USE CASES
Use Cases:
23
Page 24 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. ii. iii. iv. Screen shot Functional requirements Special requirement/Business rules/Validation Template
i.
Login
Clear
Cancel
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.
Page 25 Actors Involved Special Requirements Pre Condition Post-Conditions Flow of Events
: : : : :
Actors Involved:
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
25
Page 26
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 Flow 2.Alternative Flow 3.Exceptional Flow
1. Main
1.Main Flow:
Action
1.Actor invokes the application.
Response
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 actor entered by authenticating. 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
2.Actor enters valid user name, Valid password and clicks on login button. 3.Actor enters valid user name, valid password, selects a database option and clicks on login button. 4.Actor enters invalid user name Valid
26
Page 27
password and clicks on login button. 5.Actor enters valid user name, Invalid password and clicks on login button. 6.Actor enters both username and password invalid and clicks on login button. 7.Actor enters some information in to any of the fields and clicks on clear button. 8.Actor clicks on the cancel button. 8. Login screen is close 5.Go to Alternative flow table 2 6.Go to Alternative flow table 3
Response
Authenticates an error message is displayed Invalid User name Please Try again.
Response
Authenticates an error message is displayed Invalid User Password Please Try again.
Page 28
1 2 3 4 5 6 7 8
1 1 1 2 2 2 2 2
Page 29
Test Case Template: (a) Test Objective (b) Test scenario (c) Test procedure (d) Test Data (e) Test Cases
(a)Test Objective: The main purpose of the document is described here in this section
(b)
Test Scenarios: The list of all the scenarios that are to be tested will be listed out here in this section.
(c)Test Procedure: DEF: It is a functional level term, which describes how to perform testing on the functionalities of the application. The plan for testing the functionalities is briefly described here in this section
(d)
Test Data: The date that is required for testing is made available here in this section
DESCRIPTION
EV
AV
Result
TYPE
Description
Expected Value
Actual Value
GUI
Check for the availability of All the objects must be All the objects are all the objects as per the available as per the available as per Login Obj Tab login obj tab the login obj tab Pass All the objects must be consistent with each Check for the constancy of other all the objects Check for the spellings of all the objects as per the All the objects must be spelled properly as per Login obj TabLogin Obj the login obj tab All the objects are consistent with Pass each other
GUI
GUI
Tab.xls
GUI
Initially login, clear must Check for the enable be disabled and cancel Login, clear and property of login, clear and button must be enabled cancel buttons Fail cancel buttons are enabled Initially the cursor must Initially the cursor be positioned in the is present in the user name field username field Pass
Check for the initial position of the cursor Enter some information in to user name and Login button must be password field and check enabled for the enabled property of Positive login button GUI Enter some info in to any of the fields and check for Clear button must be enabled the enabled property of Positive clear button
Pass
Pass
30
Page 31
Corresponding pages are displayed as per valid in puts table Pass Corresponding Corresponding page pages are must be displayed as Enter username, Password displayed as per per the VIT With the as per the VIT and select a the VIT with the mentioned data base data base option and click mentioned data connection Positive on login base connection Pass All the fields are All the fields must be cleared but the cleared and the Cursor Enter some information in cursor is not should be placed in the to any of the fields and placed in the user user name fields Fail Positive clear button name field. Enter user name, Password as per the VIT Positive and click on login button Corresponding page must be displayed as per the VIT Login screen should be closed Login screens Pass Positive Click on the cancel button closed Tabbing order is Tabbing order must be as follows as follows User name, Username, Password, Connect to, Password, Check for the tabbing orderLogin, Clear, Cancel Connect to Login, Pass Positive of all the objects clear, Cancel Corresponding Enter username, Password messages should be as per the IVIT and click ondisplayed as per IVIT Negative login button Enter some information only in to the user name Login button must be field and check for the disabled enabled property of login Negative button Enter some information only in to the password Login button must be field and check for the disabled enabled property of login Negative button Corresponding error messages are not displayed Fail as per IVIT
10
11
12
13
14
Fail
15
Fail
31
Page 32
Invalid password Plz try DADA Invalid password Plz try again again Invalid password Plz try TOPI Invalid password Plz try again again Invalid user name & Invalid user name & illu4 password Plz try again password Plz try again Invalid user name & Invalid user name & Admin6 password Plz try again password Plz try again
32
Page 33
A test Engineer will do the following during the test execution 1. He will perform the action that is described in the description column 2. He will observe the actual behavior under the actual value column. 3. He will document the observed value under the actual value column.
In this phase the test engineer will compare the expected values with the actual values and if both are matched they will document the result as pass other wise they will document the result as fail.
Bug Tracking is a process in which the defects are identified, Isolated and managed
Defect ID: -
The lists of defect numbers are mentioned here in this section. Defect Description: What exactly the defect is clearly described here in this section. Steps for reproducibility: The list of all the steps that are followed by the test engineer to identify the defect will be listed out here in this section. Submitter: The name of the test engineer who has submitted the defect will be mentioned here in this section. Date Submission: The date on which the defect is submitted is mentioned here in this section. Version No: 33
Page 34 Corresponding Version number is mentioned here in this section. Build No: Corresponding build number is mentioned here in this section. Assigned To: The development lead will fill the developers name for whom the defect is assigned.
34
Page 35
Defect Id
Defect Description
Initially Login, cear buttons are enabled instead of being disabled
1.0.0 1
1.Enter some information in to any Upon Clicking on of the fields clear button all the 2.Click on clear fields are cleared button but the cursor is not 3.Observe that the placed in the user cursor is not placed name field in the username fields after clearing all the fields 2 1.Enter Suresh1 in to the user name Upon entering field 2.Enter Suresh1 as qtp in to the username and qtp password field as password and 3.Click on login clicking on login button button admin page 4.Observe admin is displayed instead page is displayed of error message instead of error message. 1.Enter some information in to username field 2.Check for the enabled property of login button. 3.Observe that login button is enabled instead of being disabled. Sri Balaji
11-Feb-08
1.0.0 1
Sri Balaji
11-Feb-08
1.0.0 1
Up on entering the information only in to the user name field login button is enabled instead of being disabled 4
Sri Balaji
14-Feb-08
1.0.0 1
1.Enter some information in tho Upon entering the password field information only in 2.Check for the to the password enabled property of field login button is login button enabled instead 3.Observe that login being disabled button to enable instead of being disabled
Sri Balaji
11-Feb-08
1.0.0 1
35
Page 36
Defect- Id: The list of defect numbers are mentioned here in this section Defect Description: What exactly the defect is clearly described here in this section Steps for reproducibility: The list of all the steps that are followed by the test engineer to identify the defect will be listed out here in this section Submitter: The name of the test engineer who has submitted the defect will be mentioned here in this section. Date Of Submission: The date on which the defect is submitted is mentioned here in this section. Version No: Corresponding Version number is mentioned here in this section. Build No: Corresponding build number is mentioned here in this section. Assigned To: The development lead will fill the developers name for whomthe defect is assigned. Severity: How serious the defect is defined in terms of severity, Severity is classified in to four types: 1.Fatal 2.Major 3.Minor 4.Suggestion (Sev1) or S1 or 1 (Sev2) or S2 or 2 (Sev3) or S3 or 3 (Sev4) or S4 or 4
1.Fatal:
If at all the problems are related to the navigational blocks or unavailability of functionality then such type of defects are treated to be fatal defect. Val1 Val2 Result ADD Next Next UN AVAILABL E
Main Menu
Next
36
Page 37
2.Major: If at all the problems are related to the working of major functionalities then such types of defects are treated to be major defects. 10 20 -10 ADD
3.Minor: If at all the problems are related to the Look & Feel of the application then such type of defects are treated to be minor defects
4.Suggestions: If at all the problems are related to the value of the application then such type defects are treated to be suggestions. +Ve integer Box Some alphabets Invalid Entry Plz Try again
37
Page 38
38
Page 39
As per design
DEV
OP EN
Rectific ation
M1 Build #1 Build #2
TESTING
Ne w
No
If Defect
RE
ope n
No
Yes
Clos ed
39
Page 40
Status: New: - When ever the defect is found for the first time the test engineer will set the status as New. Open: -When ever the developer accepts the raised defect then he will set the status as open. Fixed for verification Or Fixed for rectified: - When ever the developer rectifies the raised defect then he will change the status to fixed. Re open and Closed: -When ever the defects are rectified, next build is released to the testing dept then the test engineers will check whether the defects are rectified properly or not. If the defect is rectified properly then the test engineer will set the status as Closed. If the defect is not rectified properly then the test engineer will set the status as Re open. Hold: - When ever the developer is confused to accept or reject the defect then he will set the status of the defect as hold. Testers Error or Testers Mistake Or Rejected: - When ever the developer is confirmed it is not at all a defect hen he will set the status of the defect as Rejected.
As Per Design: - When ever the test engineer is not aware of new requirements and if he raises defects related to the new features then the developer will set the status As Per Design. Note: This is a rare case not usually Occurs
40