        

  

What is Software? Types of Software Testing Entrance Testing Concepts & Tools in Market What is Software Testing? Why Testing in Organizations? What is Quality? How to get Quality Software? Quality Standards  ISO  CMM  SIX SIGMA Quality Assurance System (QAS) Software Development LifeCycle (SDLC) SDLC Models  Fish Model  Waterfall Model  Prototyping Model  RAD model  Component Assembly Model  Spiral Model  V-Model Testing Methodologies  White Box Testing  Black Box Testing System Testing  Usability Testing  Functional Testing  BVA & ECP  Ad-Hoc Testing  Performance Testing  Security Testing  Maintenance Testing  UAT

         

 

What is Manual Testing? Error, Defect, Bug Defect Lifecycle or Bug Lifecycle Why does Software have Bugs? Testing Documents (R&R) Good Testing Engineer (or) Quality Assurance Engineers General STLC HP STLC IBM STLC Test Initiation  Test Policy  Test Strategy  Testing Factors (or) Issues  Test Methodology (TRM) Test Plan Test Design


   

 Test Cases  Examples on Test Cases Preparation  Use Cases  Traceability Matrix (RTM) Test Execution  Build Version Control  Test Harness  Sanity Testing & Smoke Testing  Comprehensive Testing  Regression testing  Final Regression Testing Test Reporting (or) Defect Reporting  Resolution Type  Types of Bugs Test Closing Sign Off Testing Metrics Certifications for Testing

    

What is Automation Testing? Differ Manual Vs Automation Automation Advantages/Dis-Advantages Why Automation? Automation Testing Tools Automated Testing Process

      

       

Introduction QTP Testing Process QTP Installation QTP Starting Process Add-In Manager Using Sample Applications QTP Window  Test Pane  Keyword View  Expert View  Working with Actions  Active Screen  Data Table  Debug Viewer Pane Using Quick Test Commands Designing Tests & Components Planning Tests & Components Recording Tests & Components Choosing Recording Modes Changing the Active Screen Creating, Opening, Saving Tests or Components with Locked Resources Checkpoints  Standard Checkpoint


                  Image Checkpoint  Table Checkpoint  Database Checkpoint  Text Checkpoint  Text Area Checkpoint  Bitmap Checkpoint  XML Checkpoint  Adding Checkpoints to a Test or Component  Modifying Checkpoints Parameterzing Values Data Driver Wizard Outputting Values Configuring Values Learning Virtual Objects Working with Data Tables Recovery Scenarios Configuring Quick Test Testing WEB Objects Testing VB Applications Testing Active X Controls Object Repository Object Spy Object Identification User Defined Functions Quality Center Connection QTP Interview Questions                       Introduction QC Testing Process Starting Quality Center Quality Center Window Sample Web Sites Specifying Requirements Planning Tests Designing Test Steps Running Tests Running Tests Manually Running Tests Automatically How to Track Defects Adding New Defects Matching Defects Updating Defects Mailing Defects Crating Favorite Views Triggering a Traceability Alert Creating Follow up Alerts Generating Reports Generating Graphs QC Interview Questions 4 .

5 .

develops the proposed system. The development team adopts one of the software development methodologies that is given below. Meet customer requirements 2. 4. Once the conceptual system is developed and tested in a hypothetical environment. Life Cycle Development: SDLC 1. 3. Meet customer expectations 3. Time to market 4. In some cases. and gives it to the customer. people and other resources. it has to satisfy four factors 1.Software Quality: To say software is a quality one. Cost to purchase Technical Factors Non-Technical Factors Software Quality Assurance: (SQA) Maintaining and measuring the strength of the development process. System is the basic and very critical requirement for the existence of software in any entity. the system should be engineered and put in place. So if the system is not in place. System/Information Engineering and Modeling As software is always of a large system (or business). 6. 5. Eg: Life Cycle Testing. Stages in S/W Development Life Cycle Information Gathering Analysis Design Coding Testing Maintenance & Implementation Research and Development Once the Market Research is carried out. to extract the maximum output. 2. This system view is essential when the software must interface with other elements such as hardware. Once 6 . the system should be re-engineered and spruced up. the customer's need is given to the Research & Development division (R&D) to conceptualize a cost-effective system that could potentially solve the customer's needs in a manner that is better than the one adopted by the competitors at present. the development team takes control of it. work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software.

Java are used for coding. Programming tools like compilers. Different testing tools and methodologies are already available. the development team visits the customer and studies their system.. Different high level programming languages like C. the software program testing begins. the data structure design etc. The code generation step performs this task. the software's overall structure and its nuances are defined. Pascal. are all defined in this phase. With respect to the type of application. Testing Once the code is generated. costs. project schedule. Much care is taken during this phase. as well as required function. They investigate the need for possible software automation in the given system. C++. the number of tiers needed for the package architecture. There 7 .... are used to generate the code.the ideal system is engineered or tuned. the team furnishes a document that holds the different specific recommendations for the candidate system. the right programming language is chosen.. the development team studies the software requirement for the system. To understand the nature of the program(s) to be built. If the design is performed in a detailed manner. the database design. the software development process. Some companies build their own testing tools that are tailor made for their own development operations. The logical system of the product is developed in this phase. In this phase. It also includes the personnel assignments. Different testing methodologies are available to unravel the bugs that were committed during the previous phases.. interpreters. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. the system engineer or "Analyst" must understand the information domain for the software. target dates etc. performance and interfacing. The requirement gathering process is intensified and focused specially on software. behavior. The essential purpose of this phase is to find the need and to define the problem that needs to be solved. code generation can be accomplished without much complication. Software Requirement Analysis This process is also known as feasibility study. debuggers etc. By the end of the feasibility study. Maintenance The software will definitely undergo change once it is delivered to the customer. In terms of the client/server technology. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Code Generation The design must be translated into a machine-readable form. System Analysis and Design In this phase..

can be many reasons for this change to occur. Analysis. This HLD is also known as External Design. Coding phases are called Verification. The software should be developed to accommodate changes that could happen during the post implementation period. BRS : (Business Requirement Specification) This document defines customer requirements to be developed as software. In addition. LLD’s : (Low Level Design) This document defines the internal logic of every sub modules in terms of structural logic (DFD’s) and backend logic (E-R diagrams). Design. Change could happen because of some unexpected input values into the system. Review : It is a static testing technique to estimate the completeness and correctness of a document. Life Cycle Testing: [Upper Line: Life Cycle Development] Analysis Design Coding Maintenance System Testing SRS Functioinal & System Infor Gathering (BRS) HLD LLD Programs BlackBox Testing Review Review Prototype White Box Testing Test s/w Changes [Lower Line: Life Cycle Testing] Fig: Fish Model Software Development BRS: Business Requirement Software In this Fish model. HLD : (High Level Design) This document defines overall hierarchy of the system from root module to leaf modules. This document is also known as Customer Requirement Specification (CRS) and User Requirement Specification (URS). SRS : (Software Requirement Specification) This document defines functional and system requirements to be used. System Testing and Maintenance are called Validation. 8 . the changes in the system could directly affect the software operations.

Test Efficiency Build Maintenance . Eg: Power Point Slides. Assessment of Development Plan 2. This model is derived from Fish Model. V-Model : V.Stands for Verification and Validation. Note : The above discussed model is almost implemented by all companies to produce the quality software. White Box Testing : It is called a coding level testing technique to estimate the completeness and correctness of a program in terms of Internal Logic. Functional Testing (WB) 2.This LLD is also known as Internal Logic. User Acceptance Testing 3. Eg: DFD’s. Software Testing Testing. Prepare Test Plan 3. Test Documents Management 9 1. Testing Development Information Gathering & Analysis 1.e. Requirements Phase Testing 1. : The verification and validation of a software is called software Verification : Whether the system is right or wrong? Validation : Whether the system is right system or not? (with respect to customer requirements). test engineers validate completeness and correctness of every functionality in terms of customer requirements. During this test. only screens) is called prototype. Design Phase Testing 2. E-R diagrams.e. Coding 1.e is called V-Model. Black Box Testing : It is a build level testing technique (i.exe form of the software program). The above model is refined in depth i. Port Testing 2. class diagrams and object diagrams etc. . Test Software Changes 3. Prototype : A sample model of an application without functionality (i. This model defines mapping between software development stages and testing stages. Design 2. Program Phase Testing 1.

Business Analyst Category people develop BRS and S/wR. responsible Business Analysts are conducting reviews. they can follow below factors BRS 1. 2. 3. Are they testable? II. Are they reasonable? (With respect to Time). In this phase. S/wRS Are they right requirements? Are they complete? Are they achievable? (With respect to Technology). Black Box Testing). the software development process starts with information gathering and analysis. Reviews During Analysis: In general. small scale and medium scale organizations are maintaining separate testing team for System Level Testing only (i.e. To estimate the completeness and correctness of these documents. design category people concentrate on external design and internal design development. BRS/CRS/URS Review User Acceptance Testing S/wRS HLD Review * System Testing (BB) Integration Testing (WB) LLD’s Unit Testing Coding I. To estimate completeness and correctness of documents. Due to this reason. In this review.Refinement Form of V-Model : V-Model is expensive process for small scale and medium scale organizations. 5. Reviews During Design: After completion of analysis and their reviews. they can follow below factors 10 . 4.

1. 2. 3. 4. 5. Are they understandable? Are they met right requirements? Are they complete? Are they follow able? Does they handle errors?


III. Unit Testing: After completion of design and their reviews, programmers
concentrate on coding to physically construct software. In this phase, programmers are conducting Unit Level Testing on those programs through White Box Testing technique. White Box Testing technique classified into three parts 1. Execution Testing Basis Paths Coverage Loops Coverage Program Technique Coverage Basis Paths Coverage: Means that every statement in the program is correctly participating in execution. For Eg: In If – else statement, every such statement has to check two times for If separately and else part separately. Loops Coverage: Means that to check whether the loop is correctly terminating or not, without going to infinite loop. Program Technique Coverage: A programmer is said to a good programmer, if the execution performs less number of memory cycles and CPU cycles. 2. Operations Testing: To check whether the program is running on customer expected platform or not? Platforms means that operating system, compilers, browsers etc. 3. Mutation Testing: Mutation means that a complex changes in program logic. Programmers are following this technique to estimate completeness and correctness of a program testing. _____ Tests _____ _____ _____ _____ Tests _____ _____ Change _____ _____ Tests _____ _____ Change _____ _____

Passed During Testing time all tests are passed

Passed (Incomplete) 11 After changes also all tests are passed.

Passed Failed After changes some tests passed & some tests failed

Fig: Showing the different tests after a complex change.

IV. Integration Testing: After completion of dependent modules development
and testing, development in composing them to form a build and conducts integration testing to verify completeness and correctness of that modules composition. There are three approaches in Integration testing such as a) Top-down Approach: In this approach, conducts testing on main module without coming to some of the sub modules is called Top-down approach. Developers are using temporary programs instead of under constructive sub modules, which are called as ‘stubs’. Stubs are those which deactivate the flow to under constructive module and return the flow to main module. Stub calls the main module. Main Stubs Sub Sub 111 2 b) Bottom-up Approach: In this approach, conducts testing on sub modules without coming from main module is called Bottom-up approach. Developer used a temporary program instead of under constructive main module called ‘driver’. Driver is that which activates the flow to sub modules. Drivers are called by the sub module. Main Driver Sub 1 Sub 2 c) Hybrid Approach: This approach is a combination of Top-down and Bottom-up approaches. This approach is also known as SandWitch Approach.


Main Driver Sub 1 Stubs Sub 2 Sub 3

Build: A finally integrated all module set in ‘.exe’ form is called build or system.

V. Functional & System Testing: After completion of all possible modules
integration as a system. The separate testing team in an organization validates that build through a set of Black Box testing techniques. These techniques are classified into four divisions such as

1. 2. 3. 4.

Usability Testing Functional Testing Performance Testing Security Testing

Usability Testing: In general, a System Level Testing starts with usability. This is
done in early days of the job. In this level, testing team follows two testing techniques. a) User Interface Testing: Under this testing technique, we have three categories Ease of use (i.e. understandable screens to the user) Look & Feel (Attractiveness of screens) Speed in Interface (Sharp navigations to complete a task) b) Manual Support Testing: In this technique, context sensitiveness (with respect to work or task) of the user manuals. This is done end days of the job. Eg: Help documents of user manuals. Receive build from developers User Interface Testing


a) Sanity Testing: Testing the Over Functionalities in the Initial Build released to know that whether a development team released build is stable for complete testing or not? For example Specifying that it is not good without reason like. such as ‘Boundary Value BVA(Size/Range) Analysis’ (BVA) and ‘Equivalence Class Partitions’ (ECP). just watch is not working. testing team concentrate on “meet customer requirements”.e. but test engineers are giving special treatment to input domains of object. b) Smoke Testing: Testing the Functionalities in Higher Level from End-to-End when a stable Build is released. i. Forgot Password. there is one wrong placement.e. testing team reject a build with reason when that build is not working to be applied complete testing. If you forgot password how can you login to the window. Functional testing is classified into below sub tests There are some functionalities listed below Mail Chat Forgot Password Change Password Exit Here in this. For example to say that watch is not working due to key rod i. Receive build from developers Sanity/Smoke Test Functional & System Test User Acceptance Test (UAT) c) Input Domain Testing: It is a part of functionality testing.Remaining Functional & System Tests Manual Support Testing Functional Testing: A mandatory part in black box testing is functional testing. During this tests. In this level. with reason. ECP(Type) The BVA and ECP are as follows: Min = pass Min-1 = fail Min+1 = pass Max = pass Max-1 = pass Valid Invalid 14 Pass Fail .

ECP defines what type of characters it accepts is valid and remaining is invalid. ‘*’ is mandatory and ‘-‘ is optional. Example 1: A login process allows user-id and password to authorize users. In this number. here the range is taken into consideration. Give the BVA and ECP for this textbox. From designed documents. A-Z 0-9 without * Special Chars except *. Prepare BVA and ECP for user-id and password. Textbox: Valid BVA (Size) Min = Max = 12 digits = pass Min-1 = Max-1 = 11 digits = fail Min+1 = Max+1 = 13 digits = fail 15 ECP (Type) Invalid a-z. Blank Space 0-9 with * 0-9 with *. by these we can know the size or range of the object. user-id allows alpha-numeric from 4-16 characters long and password allows in lower case from 4-8 characters long. - . the range is 1860.BVA defines the range and size of the object. User-id: BVA (Size) Min = 4 characters Min-1 = 3 characters Min+1 = 5 characters Max = 16 characters Max-1 = 15 characters Password: Max+1= 17 characters BVA (Size) Min = 4 characters Min-1 = 3 characters Min+1 = 5 characters Max = 8 characters Max-1 = 7 characters Max+1= 9 characters ECP(Type) Valid a-z A-Z 0-9 Valid Invalid Special Characters Blank Space ECP (Type) Invalid A-Z 0-9 Special Chars Blank Space a-z These are the BVA and ECP values. For example take age. Example 2: A textbox allows 12-digits numbers. not the size.

and means that there is some defect in our application. 16 . that application should not hang the system it should give end user and then system should enter from abnormal state to normal state by the backup and recovery procedures. test engineers validates that whether our application build change from abnormal state to normal state or not? Suppose that if an application is terminated or power is off in middle of the process. During this test. and means that our software is correct. test engineers validate that whether our application build run on customer expected platforms or not. but the operating system is having some defects. During this test. This case does not occur because.d) Recovery Testing: It is also known as Reliability Testing. Example for backward compatibility is that Oracle-95 working on Windows-98. Normal State Abnormal State Backup & Recovery Procedures Normal State e) Compatibility Testing: It is also known as portability testing. but it is working on Windows-98 also. test engineers are facing two types of compatibility problems such as forward compatibility and backward compatibility. It means that Oracle-95 is developed for Windows-95. mostly the operating system will not have such defects. Forward Compatibility Backward Compatibility Build Operating System Build Operating System VB UNIX Orcle-95 WIN-98 Example for forward compatibility. During this test. is that VB program not working on UNIX platform.

g) Installation Testing: Application + Supported Software Install Customer site like configuratio n Setup Program Execution Easy Interface Occupied Disk Space Easy interface is during installation and occupied disk space is checked after installation. During this test. Max Min j) Retesting: The re-execution of a test with multiple test data on same application Max Max build is called Retesting. Based on the past experience tester tests the Min Max build of the project. test engineers try to find competitiveness of our application product through comparison with other competitive product. This test is done only for the software product. different LAN topologies. Input1 Input2 i) Ad-hoc Testing: A tester conducts a test on application build. different technology LAN cards. Value 0 Value 0 Multiply Input 1: Input 2: OK Result: Expected Result = Input 1 * Input 2 k) Regression Testing: The re-execution of tests on modified build to ensure “bug Tests fix work” and possibilities of side effects occurrence is called Regression Testing. During this test. These all should work to our application build.f) Configuration Testing: It is also known as ‘Hardware Compatibility Testing’. depends on Min Min predetermined ideas. Impacted passed Tests Build Failed Tests Passed Failed 17 Developers Modified Build Remaining Tests Defects . not for Test Data application software. h) Parallel Testing: It is also known as comparative testing. called Ad-hoc Testing. test engineers validates that whether our application build run on different technology hardware devices or not? Ex: Different technology printers.

This team consists of few developers. User Acceptance Testing (UAT): After completion of all possible functional and system tests. our project management concentrates on User Acceptance Testing to collect feedback from customer site people. few testers and few hardware engineers. release team concentrate on training sessions to be conducted for end users. During utilization of that software. For software applications . In customer site like environment VII. There are two ways to conduct UAT Alpha-Test . project management concentrate on release team formation. For software product . By customer site like people . customer site people are sending “change requests” to our organization. Enhancement Missed Defect Impact Analysis Impact Analysis Perform Change 18 Perform Change Test Software Change * Improve testing process capability .“Testing on Modified Application Build” VI.  Compact installation  Over all functionality  Input devices handling  Output devices handling  Secondary storage devices  Operating system error-handling Change Requests  Co-existence with other software’s to share common resources After completion of port testing. By real customers . Testing during Maintenance: After completion of User Acceptance Testing and their modifications. In development site itself Beta-Test . This release team conducts port testing in customer site to estimate completeness and correctness of software installation in customer site.

4. test engineers are following this style of testing. Big Bang Testing: A single stage of testing process after completion of entire system development is called Big Bang Testing. Manual Vs Automation: A test engineer conducts any test on application build without using any software tool help is called Manual Testing. A test engineer conduct a test on application build with the help of a software tool is called Test Automation. 3. Because. Eg: LCT (Life Cycle Testing). Incremental Testing: A multiple stages of testing process from program level to system level are called Incremental Testing or Formal Testing.Defect Removal Efficiency (DRE): DRE = A/A+B Here ‘A’ is bugs found by testing team during testing. due to lack of knowledge on that entire module. Due to lack of knowledge on that application. Exploratory Testing: The coverage of all activities in level by level during testing is called exploratory testing. Testing Terminology: 1. Mail reply and Mail forward is similar to Mail compose due to lack of time. Eg: A carpenter fitting screw without screw driver (manually) is manual testing and fitting screw with screw Build Build driver is called test automation. Mail forward are there we conduct only Mail open and Mail compose. 5. Mail compose. 2. testing team follows this type of testing. Mail reply. For example Mail open. Tool 19 Manual Testing Test engineer Test Engineer Test Automation . ‘B’ bugs found by customer site people during certain period of maintenance. It is also known as “Informal Testing”. Due to lack of time. It is done module by module. Monkey Testing or Chimpanzee Testing: The coverage of “main activities” in our application build during testing is called money testing.

Note: From the definitions of Retesting and Regression testing. 20 . Criticality means that complexity to be applied a test manually. Due to impact and criticality of test. Due to this reason. test repetition is a mandatory task in test engineer’s job.Test Automation is done in two approaches they are as follows Impact of test Criticality of test Automation Manual Impact means that test repetition. test engineers are going to Test Automation. test engineers concentrate on test automation.

Number of screens. input’s.Test Policy Quality Control(QC) Test Strategy Quality Analysts(QA) Company Level Test Methodology Test Plan Test Cases Test Procedures Test Scripts Project Level Test Lead Test Engineers Test Log Defect Report I) Test Policy:. queries. forms. The below abbreviations are follows: LOC  Lines of code FP  Functional Points (i. reports) QAM  Quality Assessment Measurement TMM  Test Management Measurement PCM  Process Capability Measurement.e.It is a company level document and developed by Quality Control people (QC  almost management). output’s. 21 .

O) Above Test Policy can defines. Components in Test Strategy:1) 2) Scope and Objective:. in matrix form.Proper planning before starts testing :.Verification + Validation Address of Company :.Budget control for testing. Quality Analyst people can define. That matrix is called as Test Responsibility Matrix (TRM)/Test Matrix (TM). E. Eg: 100% Project Cost 64% 36% S/W Development Testing & Quality & Maintenance Assurance Testing Approach:. five stages. To meet that objective. This testing approach is done in the following way i. In Development Stages we have. Business Issues:. and in testing factors side we have.e. Testing Approach through a Test Strategy document. This test strategy defines a common testing approach to be followed. TMM. II) Test Strategy:. fifteen factors. It is mainly based on he Development stages and Test factors.It is a company level document and developed by Quality Analyst (QA) people.xxxxxxxxxxxxxxx xxxxxx Testing Definition Testing Process Testing Standard :.Mapping between testing issues and development stages (V-Model). Purpose of testing and testing objective. “Testing Objective”. PCM xxxxxxxxx (C.1 Defect per 250 LOC/1 defect per 10 FP Testing Measurements:. These are shown in the following figure: 3) 22 .About Organization.QAM.

Names of jobs in testing team and their responsibilities during testing.Development Stages Test Factors 1) Ease of Use 2) Authorization Information Gathering & Design Analysis Coding System Testing Maintenance X X Depends Change Request on 4) Roles and Responsibilities:. 23 .

Test Automation & Tools:.Required negotiation between testing team and development team to track defects. Uninstallation.Required training sessions to testing team to understand business requirements.Installation.5) 6) 7) 8) 9) 10) 11) 12) Test Deliverables:.Whether a valid user have permissions to use specific services or not? 3) Audit Trail:.User friendliness of screens. 24 .Whether our application maintains Metadata about user operations or not? 4) Continuity of processing:. uploading.To define a quality software.List of expected failures and possible solutions to over come during testing. 8) Ease of operate:. downloading. Training Plan:. Defect Reporting & Tracking:. Risks & Mitigations:.Whether a user is valid or not valid to connect to application? 2) Access Control:. dumping (on computer to other computer).Required testing documents to be prepared during testing.The integration of internal modules for control and data transmission (Integration Testing). Quality Analyst people are using fifteen test factors.Co-existence with other existing software (Inter System Testing) to share common resources. TMM.QAM. 1) Authorization:. 6) Coupling:.Required possibilities to go to automation.Meet customer requirements in terms of functionality. Testing Measurements & Metrics:. PCM. Change & Configuration Management:.How to handle change requests of customer during testing and maintenance. 5) Correctness:.Required negotiation between every two consecutive jobs in testing team. Communication and Status Reporting:. Test Factors:. 7) Ease of use:.

12) Performance:.  User Interface Testing  Manual Support Testing  Installation Testing  Functionality/Requirements Testing  Recovery Testing  Recovery Testing (One-user level)  Stress Testing (Peak load level)  Compatibility Testing  Configuration Testing (H/W) 25 2) Access Control 3) Audit Trail 4) Continuity of Processing 5) Correctness 6) Coupling 7) Ease of use 8) Ease of Operate 9) File Integrity 10) Reliability 11) Portability .Creation of back up during execution of our application (For recovery).  Functionality/Requirements Testing (Error-Handling Coverage)  Integration Testing (White Box Testing). 11) Portability:.Run on different platforms. 10) Reliability:.Speed in processing.Recover from abnormal states. Test Factors Vs Black Box Testing Techniques 1) Authorization  Security Testing  Functionality/Requirements Testing.Order of functionalities.  Functionality/Requirements Testing  Inter Systems Testing. 13) Service levels:.Whether test engineers are following standards or not during testing.  Security Testing  Functionality/Requirements Testing.9) File Integrity:. 14) Maintainable:.Whether our application build is long time serviceable in customer site or not? 15) Methodology:.

It is a project level document and developed by Quality Analyst or corresponding Project Manager(PM). The test methodology is a refinement form of the test strategy with respect to corresponding project. Step 1: Acquire test strategy Step 2: Identify Project Type Project Type Analysis Design Coding System Testing Maintenance 1) Traditional Project 2) Off_the_shelf Project (Out Sourcing) 3) Maintenance Project (OnSite Project) 26 . QA/PM follows below approach. To develop a test methodology from corresponding test strategy.12) Performance  Load Testing  Stress Testing  Data Volume Testing  Storage Testing  Functionality/Requirements Testing  Stress Testing (Peak load)  Compliance Testing 13) Service Level 14) Maintainable 15) Methodology  Compliance Testing (Whether our testing teams follow testing standards or not during testing?) Quality  By Quality Control people (QC) Test Factors  By Quality Analyst Testing Techniques  By Test Lead Test Cases  By Test Engineers III) Test Methodology:.

Step 5: Identify tactical risks Note: Depends on analyzed risks. Testing Process:Test Initiatio n Test Close r Test Plan Test Design Test Execution Test Reporting 27 . Quality Analyst(QA) or Project Manager(PM) can add some of the previously removed test factors into TRM.e. Quality Analyst(QA) or Project Manager(PM) decrease number of columns in TRM (Test Responsibility Matrix) means i. means that is done in Test Factors. Quality Analyst(QA) or Project Manager(PM) decrease some of selected rows in TRM. Note: Depends on expected future enhancements. depending on above analysis. Step 3: Determine Project Requirements Note: Depends on current project version requirements. in development stages. Quality Analyst(QA) or Project Manager(PM) decrease number of rows in TRM. Step 8: Prepare modules test plans if required.Depends on project type. Step 7: Prepare system test plan.Note:. Step 6: Finalize TRM for current project. Step 4: Determine the scope of project requirements.

After completion of test methodology creation and finalization of required testing process. 10) Test Environment:. 16) Approvals:. 3. Test plan Format:. Development plan. 7. 4.About project Test Items:. test lead category people concentrate on test planning to define “What to test?”. 12) Staff & Training needs:.Modules or functions or services or features Features to be tested:. Customer Requirement) 13) Responsibilities:.Dates and time 15) Risks & Mitigations:. 8.What are the technological problems.When a feature is pass and when a feature is fail.The names of selected test engineers and required training sessions to them to understand business logic. 11  Defines How to test? 12.Necessary tasks to do before starts every feature testing. raised during execution of above features testing. 9) Feature pass or fail criteria:. (i.Selected testing techniques to be applied on above modules. 9.Signatures of Project Manager or Quality Analyst & Test Lead.Non-technical problems raised during testing and their solutions to over come.Work allocation to above selected testers. 8) Suspension Criteria:.Required testing documents to be prepared during above modules testing by test engineers. “Who to test?”.(IEEE) 1) 2) 3) 4) 5) 6) Test Plan_ID:.e.Required hardwares and softwares to conduct testing on above modules. S/wRS. Design Documents Inputs 1) Testing team Formation 2) Identify Tactical Risks 3) Prepare Test Plan Test Plan 4) Review Test Plan Outputs 28 Finalized TRM . 11) Test Deliverables:. 10.IV) Test Planning:. “How to test?”.Unique number or name Introduction:. Features not to be tested:. test lead follows below work bench (approach). 13  Defines Who to test? 14  Defines When to test? To develop above like test plan document. in terms of modules. 5  Defines What to test? 6.Which ones & why not? Approach:. “When to test?”.Responsible modules for test designing. (Finalized TRM by Project Manager) 7) Testing Tasks:. 14) Schedule:.

Team Size:.) Risk 2: Lack of budget (i. and mitigation is Ad-Hoc testing.After completion of test planning and required training sessions to testing team.e. Hard ware related projects)  7-9 months of System Testing. (Rigor means seriousness) Risk 6: Lack of communication 3) Prepare Test Plan:. based on past experience). test lead prepare test plan document in IEE format.After completion of test plan document preparation. the test plan process starts with testing team formation. compilers. test design will come in to state. (Bad Testing environment. depends on below factors  Availability of test engineers  Possible test duration  Availability of test environment resources.e. mitigation is working for over time). In this review. Case Study: Test Duration:Client/Server. test lead applies coverage analysis. Time) Risk 3: Lack of resources. a) Business logic based test case design b) Input domain based test case design 29 .In general.  Requirements based coverage (What to test?)  Risks based coverage (Who & When to test?)  TRM based coverage (How to test?) V) Test Design:. Web Applications. test lead conducts reviews on that document for completeness and correctness.Team size is based on the developers and expressed in terms of ratio’s i. through three test case design methods.e. i. Risk 5: Delays in delivery (in terms of job completion. in terms of facilities) Risk 4: Lack of test data (Improper documents.1) Testing Team Formation:. test lead concentrate on risks analysis or cause-root analysis. Examples:Risk 1: Lack of knowledge on that domain of test engineers (Training sessions required to test engineers. System Software (Net working.After completion of testing team formation and risks analysis. Developers : Testers = 3 : 1 2) Identify Tactical Risks:-After completion of testing team formation. Risk 6: Lack of development process rigor. In this state. ERP (like SAP)  3-5 months of System Testing. Machine Critical (Like Satellite projects)  12-15 months of System Testing. test engineers are preparing test cases for responsible modules. 4) Review Test Plan:.

To prepare test cases depending on use cases. Step 1: Collect all required use cases of responsible module Step 2: Select a use case and their dependencies from that collected list. test engineers are following below approach. Business Requirement Use Cases/ Functional Specs HLD LLD’s Coding . test engineers are preparing test cases depending on use cases in S/wRS. describes that how to use a functionality? These use cases are also known as functional specifications (FS).In general.in login) 30 . Every use case in S/wRS.exe Test Cases From the above model.c) User interface based test case design a) Business logic based test case design:. Use case Determinant Use case Use case Dependent Login  Mail  Log out Module 2.1: Identify entry condition (Base State) (First operation user-Id. every test case describes that a test condition to be applied.

Sol: Test Approach: Manual Testing Test Condition: Login Process Test Techniques: BVA/ECP Test Documents: Use cases. Password allows alphabets in lower case from 4 to 8 characters long.4: Identify outputs & outcome Eg: xx Input 1: Input 2: OK Result: xx xx User_Id: Password: OK xx xx Inbox Window Output(means value) Outcome(means process change state) 2. 0-9 A-Z Special chars Blank space 31 .. S/WRS. User-Id allows alphanumerics in lower case from 4-16 characters long. Use Case 1: A login process user_id and password to authorize users.3: Identify Exit condition (End state) User-Id is last operation in login 2.5: Study normal flow (Navigation or procedure) 2.2. Step 4: Review that test cases for completeness and correctness. and Test Log Test Case ID: Login_TC_01 Test Case 1: Successful entry of User_id BVA (Size) Min =4 chars  Pass Max =16 chars  Pass Min-1=3 chars  Fail Min+1=5 chars  Pass Max-1=15 chars  Pass Max+1=17 chars  Fail ECP (Type) Valid Invalid a-z.6: Study alternative flows and exceptions? Step 3: Prepare test cases depending on above collected information from use case. Step 5: Go to Step 2 until all completion of all use cases study. Test Procedure.2: Identify input required (Test Data) 2. Design Docs.

A-Z. users can apply for different types of items purchase orders.BVA (Size) Test =4 Case 2: Successful Min chars  Pass entry of password Max =8 chars  Pass Min-1=3 chars  Fail Min+1=5 chars  Pass Max-1=7 chars  Pass Max+1=9 chars  Fail Test Case 3: Successful login operation. User_Id Valid Valid Invalid Value Blank Password valid invalid valid Blank Value Criteria Pass Fail Fail Fail Fail ECP (Type) Valid Invalid a-z 0-9. Test case 1: Successful selection of policy type B insurance Test case 2: Successful focus to age. system returns one item price and total amount with respect to quantity. 0-9 Special Chars Blank Space Use Case 3:. user selects item number and enters quantity up to 10. From a purchase order Use case. when a user select type B insurance. system asks age of the customer. A-Z Special chars Blank space Use Case 2:. After input’s filling.In a shopping application. Test case 1: Successful selection of item number Test case 2: Successful entry of quantity BVA (Range) Min= 1  Pass Max= 10  Pass Min-1= 0 Fail Min+1= 2  Pass Max-1= 9  Pass Max+1= 11  Fail ECP (Type) Valid Invalid A-Z. when you selected type B insurance Test case 3: Successful entry of age BVA (Range) Min= 19 years  Pass Max= 59 years  Pass Min-1= 17 yrs  Fail Min+1= 20 yrs  Pass Max-1= 58 yrs  Pass Max+1= 60 yrs  Fail ECP (Type) Valid Invalid a-z. a-z. The age value should be greater than 18 years and should be less than 60 years. From a use case. 0-9 Special chars Blank Space 32 .An insurance application allows users to select different types of policies.

EG: Time expired or other bank card 33 . Person Inside Outside Outside Inside Criteria Pass Fail Pass Fail Test case 4: Unsuccessful door closing due to person standing at middle of the Use Case 6:.A door opened when a person comes in front of door and that door closed when person came inside the door. when a person is in front of door.Prepare test cases for money with drawl from ATM. with all rules and regulations. Test case 1: Successful open of door. Use Case 5:.Prepare test cases for a computer shutdown Test case 1: Successful selection of shut down operation using start menu Test case 2: Successful selection of shutdown option using alt+F4 Test case 3: Successful shutdown operation Test case 4: Unsuccessful shutdown operation due to a process in running Test case 5: Successful shutdown operation through power off. Door Closed Closed Opened Opened door.Test case 3: Successful calculation with Total = Price * Quantity Use Case 4:. Test case 1: Successful insertion of card Test case 2: Unsuccessful card insertion due to wrong angle Test case 3: Unsuccessful card insertion due to invalid account. Person Present Absent Door Opened Opened Criteria Pass Fail Test case 2: Successful door closing due to absence of the person. Door Opened Closed Closed Person Present Present Absent Criteria Pass Pass Fail Test case 3: Successful door closed when a person cone to inside.

Selection of account type. Test case 5: Unsuccessful operation due to wrong PIN number enter 3 times Test case 6: Successful selection of language Test case 7: Successful selection of account type Test case 8: Unsuccessful selection due to wrong accounts type selection with respect to that corresponding card.Test case 4: Successful entry of PIN number. Selection of account type. (Test box Oriented) Test case 12: Successful with-drawl operation (Correct amount. Test case 9: Successful selection of with-drawl operation Test case 10: Successful entry of amount Test case 11: Unsuccessful operation due to wrong denominations. after insert card Test case 18: Unsuccessful operation due to click cancel after insert card. enter PIN number. enter PIN number. enter PIN number. selection of language. selection of language. selection of language. Selection of account type Test case 21: Unsuccessful operation due to click cancel after insert card. selection of with-drawl. after entering amount Test case 23: Number of transactions per day. Use Case 7:. selection of with-drawl Test case 22: Unsuccessful operation due to click cancel after insert card. enter PIN number Test case 19: Unsuccessful operation due to click cancel after insert card. Test case 14: Unsuccessful with-drawl operation due to lack of amount in ATM Test case 15: Unsuccessful with-drawl operation due to server down Test case 16: Unsuccessful operation due to amount greater than day limit (Including multiple transactions also) Test case 17: Unsuccessful operation due to click cancel. right receipt & possibility of card come back) Test case 13: Unsuccessful with-drawl operation due to amount greater than possible balance. enter PIN number. selection of language Test case 20: Unsuccessful operation due to click cancel after insert card.Prepare test cases for washing machine operation Test case 1: Successful power supply Test case 2: Successful door open Test case 3: Successful water supply Test case 4: Successful dropping of detergent Test case 5: Successful clothes filling Test case 6: Successful door closing Test case 7: Unsuccessful door close due to clothes over flow Test case 8: Successful washing setting selection Test case 9: Successful washing operation Test case 10: Unsuccessful washing operation due to lack of water Test case 11: Unsuccessful washing operation due to clothes over load Test case 12: Unsuccessful washing operation due to improper power supply Test case 13: Unsuccessful washing due to wrong settings 34 .

Special Chars Blank Space Test Case 2: successful entry of area code ``````````````````````````````````````````````````````````````````````````````````````````````````````` BVA (Size) ECP (Type) Min = Max = 3  Pass Valid Invalid Min-1 = Max-1 = 2  Fail 0-9 A-Z. money transfer.An E-Banking application allows users through internet connection. a-z. a-z. Min+1 = Max+1 = 4  Fail Blank Space Special Chars Test case 3: Successful entry of prefix BVA (Range) Min = 200  Pass Max = 999  Pass Min-1 =199  Fail Min+1 = 201  Pass Max-1 = 998  Pass Max+1 = 4: 1000  Fail entry of suffix Test case Successful BVA (Size) Min = Max = 6  Pass Min-1 = Max-1 = 5  Fail Min+1 = Max+1 = 7  Fail ECP (Type) Valid Invalid 0-9 A-Z.digits number Area code: 3-digits number/ blank Prefix: 3-digits number but does not start with “0” & “1” Suffix: 6-digit alphanumeric Commands: Cheque deposit. mini statement Test case 1: Successful entry of password BVA (Size) Min = Max = 6  Pass Min-1 = Max-1 = 5  Fail Min+1 = Max+1 = 7  Fail Valid 0-9 ECP (Type) Invalid A-Z.Test case 14: Unsuccessful washing due to machine problems Test case 15: Successful dry clothes Test case 16: Unsuccessful washing operation due to water leakage from door Test case 17: Unsuccessful washing operation due to door opened in the middle of the process Use Case 8:. a-z. Password: 6. bills pay. To connect to bank server our application allows values for below fields. Special Chars Blank Space Valid 0-9 a-z A-Z 35 ECP (Type) Invalid Special Chars Blank Space .

money transfer. 10) Test Procedure: A step by step process to execute this test case 36 . Remaining Fields With Valid Any one blank Area Code Blank Blank Criteria Pass Fail Test case Format (IEEE):1) Test case-Id: Unique number or name 2) Test case name: The name of test condition 3) Feature to be tested: Module or function name (To be tested) 4) Test Suit-Id: The name of test batch.Test case 5: Successful selection of commands such as cheque deposit. 9) Test Setup: Necessary tasks to do before starts this test case execution. Remaining Fields All Valid Any one invalid Area Code Blank Blank Criteria Pass Fail Test case 8: Unsuccessful connect to bank server with out filling all fields except area code. Installation…) P2  Cosmetic Functionality (Eg: User Interface Testing) 6) Test Environment: Required hardwares & softwares to execute this case 7) Test Effort (Person per hour): Time to execute this test case (Eg: Average time to execute a test case is 20 minutes) 8) Test Duration: Date and time to execute this test case after receiving build from developers. Configuration. bills pay and mini statement. Error handling. in which this case is a member 5) Priority: Importance of test cases in terms of functionality P0  Basic functionality P1  General Functionality (I/P domain. Inter Systems. Compatibility. Fields All valid Any one invalid Criteria Pass Fail Test case 7: Successful connection to bank server with out filling area code. Test case 6: Successful connection to bank server with all valid inputs.

1) Test case-Id: Tc_Mail_Reply_1 2) Test case name: Successful Mail Reply 37 . Note: In general.Company Name Project Name Step.Prepare test case document for “Successful Mail Reply”. Case Study 1:.Version NO. no Company Logo Feature Data Input (Action) My Organization TESTCASE FORMAT Use Case ID Actual Result Run1 Run2 Run3 UseCase Name Test Case ID <Project ID.Prepare test case document for “Successful file save” in notepad.> Project circle ID These are filled during test design These are filled during test execution 11) Test case Pass/Fail Criteria: When this case is pass & when this case is fail. test engineers are creating test case document with the step by step procedure only. They can try to remember remaining fields for the further test execution. 1) Test case-Id: Tc_save_1 2) Test case Name: Successful file save 3) Test Procedure: Step No 1) 2) 3) 4) Description I/P Required ------Expected Empty editor opened and save option disable Open notepad Fill with text Click save Enter file name & click save Valid text Save option enabled -------Save window appears with default file name Unique Saved file name appears in title bar of notepad filename Case Study 2:.

---------Compose window appears with To: Received Mail_ID Sub: Re:[Received Mail Sub] CC: Off BCC: Off Message: Received mail message with Comments Acknowledgement from server 2) 3) Click Inbox link Select received Mail subject 4) Click Reply Enter new Valid text message and click send b) Input domain based test case design:. EG: E-R diagrams During the study of data model. Due to above reason. test engineers are studying data models in low level design documents to collect complete information about size and type of every input object. test engineers follows below approach Step 1: Collect data models of responsible modules Step 2: Study every input attribute in terms of size. which are participating in internal manipulations Step 4: Identify non-critical attributes.Sometimes test engineers are preparing some of the test cases depends on designed test cases. which are just input/output type A/c No A/c Name Balance Address Critical Attributes 5) Non-Critical Attributes 38 . type & constraints Step 3: Identify critical attributes.Step Description No 3) Test Procedure: 1) Login to site I/P Required Expected Valid User_Id & Empty editor opened and save option Pwd ------------------disable Mail box page appears Mail message window appears (Mail Opened). EG: Input domain test cases. because use cases are responsible for functionality description and not responsible to size and type of inputs.

0-9. Depositor name: Alphabets in lower case with initcap Amount : 1500 to 100000 Tenure(Time to deposit) : Up to 12 months Interest : Numeric with decimal point From the fixed deposit operation use case. Test case 1:1) Test case_Id: Tc_Fd_1 2) Test case name: Successful entry of depositor name 3) Data matrix I/P Attribute Depositor Name ECP (Type) Valid Invalid a-z. If a test case is covering an object. special Chars. test engineers are preparing data matrix like table. Blank BVA (Size) Min Max 1 char 256 chars Test case 2: 1) Test case_Id: Tc_Fd_2 39 . test engineers are preparing a step by step procedure for that test case. Prepare test case document for above scenario. For example: Login is a operation. if tenure greater than 10 months. init a-z.Step 5: Prepare data matrices for every input attribute I/P Attribute ECP (Type) Valid Invalid BVA (Size/Range) Min Max Data Matrix Note: If a test case is covering an operation. and entering Uer_Id and Password are object. Case Study: A bank automation application allows fixed deposit operation from bank employees. then interest also greater than 10%. init cap A-Z. This fixed deposit form allows below fields as inputs.

a-z. Blank BVA (Range) Min Max 1500 100000 Test case 3: 1) Test case_Id: Tc_Fd_3 2) Test case Name: Successful entry of tenure 3) Data Matrix I/P Attribute Tenure 0-9 ECP (Type) Valid Invalid A-Z. Blank BVA (Size/Range) Min Max 1 month 12 months Test case 4: 1) Test case_Id: Tc_Fd_4 2) Test case Name: Successful entry of interest 3) Data Matrix I/P Attribute Interest Name ECP (Type) Valid Invalid 0-9 A-Z. a-z.2) Test case Name: Successful entry of amount 3) Data Matrix I/P Attribute Amount 0-9 ECP (Type) Valid Invalid A-Z. a-z. Special Chars.1 100 Test case 5: 1) Test case_Id: Tc_Fd_5 2) Test case Name: Successful fixed deposit operations 40 . With decimal Special Chars. Special chars. Blank BVA (Size/Range) Min Max 0.

Step Description No 3) Test Procedure: 1) I/P Required Expected Login to bank server Valid User_Id & Menu appears Pwd ---------- 2) 3) Click FD option Fill fields and Click “OK” FD form appears all valid fields  Acknowledgement from server any one field is  Error form server. Invalid Test case 6: 1) Test case_Id: Tc_Fd_6 2) Test case Name: Successful fixed deposit operation when tenure is greater than 10months & interest also greater than 10% Step 3) Test Description Procedure: I/P No Required Expected 1) Login to bank server Valid User_Id & Menu appears Pwd ---------- 2) 3) Click FD option Fill fields and Click “OK” FD form appears Valid name. Deposit with Tenure>10 @interest >10  Acknowledgement from server @interest<=10  Error form server. Test case 7: Step Description I/P No 1) Test case_Id: Tc_Fd_7Required Expected 2) Unsuccessful fixed deposit operation with out filling all fields 3) Test procedure 1) Login to bank server Valid User_Id & Menu appears Pwd ---------Some as Blank 41 2) 3) Click FD option Fill fields and Click “OK” FD form appears  ERROR message from application .

test lead follows coverage analysis  Business Requirement based coverage  Use Case based coverage  Data Model based coverage  User Interface based coverage 42 . Font. (Eg: MicroSoft 6 rules) and interest of customer site people. test engineers are depending on User Interface conventions (rules) in our organizations. test case 7 indicates Manual Support Testing.c) User Interface based Test Case Design: To prepare test cases for usability testing. Style.77 Report 10.768 Table 10.77 Test case 6: Accuracy of data in the data base as a result of external factors.After completion of test cases design for responsible modules to test lead. EG: Imported files. Example Test cases:Test case 1: Spelling check Test case 2: Graphics check (Alignment. Global user interface rules. Test case7: Meaningful help messages. Note: Test case 1 to test case 6 indicates User Interface Testing. other Micro Soft 6 rules Test case 3: Meaning error messages Test case 4: Accuracy of data displayed (Reality is there or not). In this review. for completeness and correctness checking. Test cases Selection Review:. Example: 1) Amount: xxxx 2) Date of Birth: Amount: $ xxxx Date of Birth: Date of Birth: --/--/---/--/-(dd/mm/yy) Test case 5: Accuracy of data in the data base as a result of user input Form 10. color.

Business Sources Test Cases Requirements (Use Case. 1) Levels of test execution:Development Testing Initial Build Level-0 (Sanity/TAT/BVT) Stable Build Bug Fixing Level-1 (Comprehensive Testing) Bug Resolving Level-2 (Regression Testing) Level-3 (Final Regression/ Postmortem) 2) Test Execution Levels Vs Test Cases:Level-0  all P0 Test cases Level-1  all P0. P1 & P2 test cases with respect to high bug density modules. P1 & P2 test cases as batches Level-2  Selected P0. testing team concentrate on build release from development team. 43 . test lead prepare Requirement Traceability Matrix (RTM) and it is also known as Requirements Validation Matrix (RVM) and this matrix defines mapping between test cases and customer requirements. Data models…) xxxxxxxxx xxxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx xxxxxx xxxxxx V!) Test Execution:. TRM based coverage At the end of this review.After completion of test design and their reviews. P1 & P2 test cases with respect to modifications Level-3  Selected P0.

e. 4) Build Version Control:. test engineers are receiving build from developers in below model (In general).During test execution. testing team concentrate on below factors to verify. To distinguish builds.(Sanity Testing) In general. (i. test execution starts with sanity testing to decide whether development team released build is stable for complete testing to be applied or not? During this sanity testing. 5) Level-0:. This numbering system is understandable to testing team to distinguish old build and modified build.  Understandable  Operatable  Observable  Controllable  Simplicity  Maintainable Testability Factors 44 . (Eg: FTP  File Transfer Protocol). Test Harness = Test Environment + Test Bed (Test Environment is hardwares and softwares required for testing. Microsoft Visual Source Safe to maintain old code and modified code). development people are using version control tools also. Build Server FTP SoftBase (Saved in one folder) Test Environment From the above model. where as Test Bed means that “testing documents”.3) Test Harness:. test engineers are downloading application from softbase in the server system. development people are using unique version numbering system for that builds. through networking protocols.(Test Frame Work) It means that “ready to start testing”. For this build version controlling.

testing team concentrate on test automation if possible. Every test batch consists of a set of dependent tests (i. 7) Level-1 (Comprehensive Testing):. other wise test engineers reject that build to developers. Developers Resolved Bug Severity 45 . because they are not repeatable and easy to apply. This document consists of three types of entries. In this test automation.  Passed.During Level-1 test execution. During this test batches execution. test engineers are not automating some of P1 test cases and all P2 test cases. After receiving modified build from them. test engineers prepare Test Log document.  Failed. Consistency  Automatable When an application build allows above factors successfully. post-pone due to parent functionality is wrong Skip In Queue Blocked In Progress Passed Failed Partial Pass/Fail Closed Complete Automation Level-1 (Comprehensive Test Cycle) 8) Level-2 (Regression Testing):. test engineers concentrate on real test execution as batches. This type of Level-0 testing is also known as Tester Acceptance Testing/ Build Verification Testing/ Testability Testing/ Octangle Testing. Test Automation * Selective Automation (All P0 Test cases & carefully selected P1 Test cases) From the above model.After receiving stable build and completion of possible automation.e. end state of every test is base state to other test). all expected values are not equal to actual. test engineers conducts complete testing on that build.After receiving stable build from developers. testing team concentrate on Regression Testing to ensure completeness and correctness of that modification. any one expected variates with actual  Blocked. 6) Test Automation:. Test batches are also known as Test Suites or Test Sets. test engineers are reporting mismatches to developers. test engineers conducts recording and check points insertion to create automated test script.

Some of P1 test cases. Low  may or may not to solve 10) Priority: The importance of defect to solve with respect to customer (high. Attach Test Procedure: 8) If No. P1 and P2 test cases. 12) Reported by: Name of test engineer. appears rarely) during test execution. then test engineers are receiving all P0.During test execution.e. then test engineers are re-executing some of P0. Low Some of P0 test cases. but able to continue remaining testing before solving that defect. Some of P2 test cases. 7) If yes. Medium  Mandatory to solve. medium. all P1 Test cases. 5) Test case Name: Corresponding failed test condition. you found that defect. Case 3: If development team resolved bug severity is low. and some of P2 test cases. VII) Test Reporting:. Modified Build Case 1: If development team resolved bug severity is high. IEEE Format:1) Defect_Id: Unique number or name 2) Description: Summary of that defect. all P1 and carefully selected P2 test cases with respect to sudden changes in requirements. in which above defect raised. test engineers are reporting mismatches to developers through an IEEE defect report. all P1 and carefully selected P2 test cases on that modified build. then test engineers are re-executing all P0. which returns above defect. carefully selected P1. Reopen  Re-reporting the defect again second time. Medium All P0 test cases. carefully Selected P2 test cases. 6) Reproducible: Yes/No Yes  If defect appears every time during test repetition No  If defect does not appears every time (i. Attach snap shot and strong reasons: 9) Severity: Seriousness of defect with respect to functionality High  not able to continue remaining testing before solving that defect.High All P0 Test cases. * Case 4: If testing team received modified build from developers due to sudden changes in customer requirements. 13) Reported on: Date of submission 46 . carefully selected P1 test cases. low) 11) Status: New/ reopen New  For the first time test engineers are reporting defect to the developers. then test engineers are re-executing all P0. 3) Build version_Id: Current build version. Case 2: If development team resolved bug severity is medium. Some of P2 test cases. 4) Feature: In which module of that build.

14) Assigned to: The name of responsible person at development side to receive that defect. _______________________________________________________________________ _ (By developers) 16) Fixed bug: (Acceptance or rejected) Project Manager or Project Lead 17) Resolved bug: Developer 18) Resolved on: Date of solving 19) Resolution type: Type of solution 20) Approved by: The signature of Project Manager Defect Age: The time gap between “resolved on” and “reported on”. Defect Submission: (i.e. Defect Statuses: If h de i g h. fect b s de ut re ever ve je ity lo c t p ers ed b is y Quality Analyst Test Manager Test Lead Test Engineers * Project Manager Team Lead Developers Transmittal Reports Large Scale Organization Project Manager (PM)* Test Lead New Test engineer Developers (Open/Accepted) / (Closed/Rejected) / Differed Transmittal Reports Small & Medium Scale Organization Closed/Solved 47 (If Possible) Reopen (After performing regression testing) Team Lead . 15) Suggested fix: Possible reasons to accept and resolve that defect. Process) Defect submission process is different for large scale organization and small scale organization.

2) Enhancement. used by developers to intimate to test engineers. rejected due to improper meaning of the defect. 3) Software Limitation.Bug Life Cycle: Detect Defect (Occurred due to error in coding) Reproducible defect (If the defect appears more than once) Report Defect Bug Fixing (Acceptable or not by the developers) Bug Resolving Bug Closing Resolution Type: (Receiving by developers to testers) Test engineer Defect Report Resolution Type There are twelve resolution types. 4) Hardware Limitation. 5) Not applicable. rejected due to this defect like as previously reported defect. rejected due to this defect raised with respect to limitations of software technologies. 1) Duplicate. Developers Fixing/ Review 48 . rejected due to this defect related to future requirements of customer. rejected due to this defect raised with respect to limitations of hardware.

logo missing. accepted and ready to resolve. 11) Fixed indirectly. 9) No plan to fix it. not accepted and not rejected but developers required extra time to fix. copy right window missing. * Types of defects (bugs):1) User Interface bugs (Low Priority) Ex1: Spelling mistake (High priority based on customer requirements) Ex2: Improper right alignment (Low priority) 2) Input domain bugs (Medium Severity) Ex1: Does not allows valid type (High priority) Ex2: Allows invalid type also (Low priority) 3) Error handling bugs (Medium Severity) Ex1: Does not return error message (High Priority) Ex2: Incomplete meaning of error message (Low Priority) 4) Calculations bugs (High Severity) Ex1: Dependent outputs are wrong (High priority) Ex2: Final output is wrong (Low priority) 5) Race Condition bugs (High Severity) Ex1: Dead lock (High Priority  Shoe Stopper) Ex2: Does not run on expected platforms (Low priority) 6) Hardware bugs (High Severity) Ex1: Device is not responding (High priority) Ex2: Wrong output device (Low Priority) 7) Load condition bugs (High Severity) Ex1: Does not allows multiple users (High Priority) Ex2: Does not allows customer expected load (Low priority) 8) ID_Control bugs (Medium Severity) Ex: Wrong logo. 7) Need more information. 8) Not reproducible.6) Functions as designed. rejected due to coding is correct with respect to design documents. wrong version number. tester name missing etc. version number missing. extra negotiation between developers and test engineers. differed) 12) User misunderstandings. accepted but postponed to future version (i. not accepted and not rejected but developers required correct procedure to reproduce that defect. 10) Fixed. not accepted and not rejected but developer’s required extra information to fix.e. 9) Version controlled bugs (Medium Severity) 49 .

Ex: Mismatches between two consecutive build versions. test lead follows below factors: 1) Coverage Analysis  Business requirement based coverage (BRS)  Use cases based coverage (S/wRS)  Data Model based coverage (Design Documents based)  User Interface based coverage  TRM based coverage (PM) 2) Bug Density Example: %of bugs found 20% 20% 40% 20% ------------100% ------------In the above example.e. In this review. So there is need for Regression testing. Modules Name A B C D 3) Analysis of differed bugs: Whether the corresponding differed bugs are postponable or not? At the end of this test closure review meeting. more number of bugs found in “Module-C”. test lead concentrate on Level-3 testing (i. Post Mortem Testing / Final Regression Testing/ Pre-Acceptance / Release Testing) The below figure brief idea: Test Reporting Gather Regression Requirements depends on Bug density Effect Estimation Regression Testing 50 Plan Regression Person/ Hour .After completion of all possible test cases execution and bug solving. 10) Source bugs (Medium Severity) Ex: Mistakes in help documents. VIII) Test Closer:. test lead conduct test closer review meeting to estimate completeness and correctness of test execution process.

This report is a part in Software Release Note (S/wRN). Final Bugs summary report is of below format: Bug Found Description By Features Severity Status Comments (Closed/Differed) Case Study 1: (Schedule for five months of Testing Process) Deliverable 1) Test cases Selection 2) Test cases Selection Review 3) Requirements 4) Level-0 Test automation 5) Level-1 & Level-2 6) Communication & Status Reporting 7) Defect Reporting & Tracking 8) Test Closure & Final Responsibility Test Engineers Test Lead & Test Engineers Test Lead Test Engineers Test Engineers Test Lead & Test Engineers Test Lead & Test Engineers Test Lead & Test 51 Completion Time 20-30 days 4-5 days 1-2 days 10-20 days 40-60 days Weekly twice On Going 4-5 days . This Final Test Summary Report consists of below documents as members.IX) User Acceptance Testing:. X) Sign Off:. Project management concentrate on User Acceptance Testing to collect feed back from customer site people.After completion of final regression. There are two approaches to conduct this testing. 1) Alpha Testing 2) Beta Testing These are explained in previous topic.After completion of User Acceptance Testing and their modifications. test lead prepare Final Test Summary Report (FTSR).

when your reported defect rejected by developers? 17) What is the difference between defect age and build interval period? 18) What you do to conduct testing on unknown project? 19) What you do to conduct testing on unknown project with out documents? 20) What are the differences between V-Model and Life Cycle/ Water Fall/ SDLC? Engineers Customer site people with involvement of testing team Test Lead 4-5 days 52 .Regression 9) User Acceptance Testing 10) Sign Off 1-2 days Case Study 2:1) What type of testing you are doing? 2) What type of testing process is going on at your company? 3) What type of documents will you prepare for testing? 4) What is your involvement in that document? 5) How will you select reasonable test to be applied on a project? 6) When will you go to automation? 7) What methods will you follow to prepare test cases? 8) What are the key components in your company test plan document? 9) What is your company test case format? 10) What is the meaning of Regression Testing and when will you do this? 11) What is the difference between error. defect and bug? 12) How will you report defects in your company? 13) What are the characteristics of the defect to define? 14) Explain bug life cycle? 15) How will you know whether your reported defect accepted / rejected? 16) What you do.

b) Stress Testing: The execution of our application build under customer expected configuration and un-interval loads to estimate performance is called Stress Testing. but here we express in terms of records. we express the storage space in terms of GB. but test engineers test for customer expected configuration and some intervals i.Performance Testing It is an expensive testing division in black box testing. 1 user and no users but it should give the same performance. In previous Data Volume Testing. Example: When we take VB as front-end and MS-Access as back-end database. Performance Testing classified into below testing techniques a) Load Testing: The execution of our application build under customer expected configuration and customer expected load to estimate performance is called Load Testing or Scalability Testing.e. testing team concentrate on “speed of the processing” in our application build. here MS-Access supports only 2 GB of storage. 200 users. d) Data Volume Testing: The execution of application build under huge amounts of resources to estimate volume (size) of data in terms of records is called Data Volume Testing. ‘Scale’ means number of concurrent users. During this test. Threshold Point Pe rfo rm an ce Resources 53 . for 2000 users. For example take web browsing application. c) Storage Testing: The execution of our application build under huge amount of resources to estimate storage limits is called Storage Testing. is a limitation. here customer expected configuration is 1000 users at a time.

COBOL…) for Load Testing  Create Virtual Environment to decrease Testing Cost. SQALoadTest and JMeter. EG: Websites and Networking applications. C++. SilkPerformer. Performance Testing is mandatory for multi user applications.LOADRUNNER Test Initiation Test Planning Test Design Test Execution Test Reporting Performance Testing Test Closer From the above testing process. Web.0: Developed by Mercury Interactive  Load Testing Tool to estimate performance  Support Client/Server. test engineers are planning to be applied Load Test Automation. Due to this reason. But manual Load Testing is expensive to find performance of an application under load. EG: LoadRunner. LoadRunner 6. ERP and Legacy Technologies (C. Virtual Environment:- 54 .

RCL:. This time is also known as Turn Around Time (or) Swing Time. during execution of server process to respond to multiple virtual user requests. Client Server Application Layer Transport Layer NetWork Layer Control Scenario (CS) Portmapper Remote Command Launcher (RCL) VUGEN (Virtual User Generator) NetWork Interface Card Customer Expected Configuration + 1. process in server and s response transmission. CS:.Remote Command Launcher.5 KB RAM per one Virtual User Time Parameters:.It submit all virtual user requests to single server process port. Clien Server Proces t time to get first response 2) Response Time: The s from server process.Virtual User Generator creates multiple virtual requests depending on a real remote request.To measure the performance of software applications. Portmapper:. 55 .Controller Scenario returns performance results. converts a local request into a remote request. we can use below time parameters: 1) Elapsed Time: Request Clien Server Response Proces This means that the ttotal time for request transmission. VUGEN:.

(KB/Sec).Request Ack Response + Response Time 3) Hits per second: The number of web requests received by web server in one second of time. I) Client/Server Load Testing:.LoadRunner allows you to conduct load testing on multiuser two-tier applications. Hits/sec Buffer/ Queue Structure of application & Configuration Throughput Leaky Bucket Algorithm Note: We can use last two time parameters to estimate performance of web applications. In this load testing. 4) Throughput: The speed of web server to respond to that web request in one second of time. If the project is in VB-Oracle or JAVA-Oracle. test engineers are using below components:  Customer expected configured server computer  Client/Server master build (Usability and Functionality testing is completed on that build)  Remote Command Launcher  Virtual User Generator  Portmapper  Controller Scenario  Database Server 56 .

Test cases for Client/Server Load Testing:Client DSN Insert Update Delete Select Commit Rollback Server Data Manipulation Language (DML) Transaction Control Language (TCL) Navigation: Load Test cases Assume customer expected configuration  “Start” menu Programs  LoadRunner  Remote Command Launcher Start  Programs  Corresponding database server (SQL Server. actions. Sybase. Oracle.exe) Specify working directory (C:\WINDOWS\TEMP) Specify record into action (VUser_init. VUser_end) Click “OK”  Record our business operations per one user Click “Stop Recording”  “Tools” Menu Create “Controller Scenario”  Save “VUser Script” Enter number of VUsers  Click “OK” 57 . Quadbase) Start  Programs  LoadRunner  VUGEN  “File” Menu Click “NEW”  Select Virtual User Type as Client/Server Select database technology name (By default ODBC)  Click “OK” Browse Master build path (C:\PF\MI\Samples\bin\flights.

when no transaction found in VUser script.It is an interrupt point in VUsers script execution. test engineers are inserting transaction points to enclose required operations as actions part.Transaction Point: LoadRunner is not able to return performance results. This point stop current process execution until remaining programs also executed up to that point. Navigation: Select position on top of required operation  “Insert” menu  start transaction Enter transaction name  Click “OK”  Select position at end of the operation “Insert” menu  End transaction  Click “OK” Rendezvous Point:. Navigation: Select position on top of transaction  “Insert” menu  Rendezvous Enter name  Click “OK” Analyze result: LoadRunner returns performance results through a percentile graph. Controller Scenario  “Group” Menu  Add VUser Select quantity to58 add  Click “OK” . Response Time 0 Formula:Average Response = Time Percentage 100% 100% Work Completion Load 0% Transaction Starting Time Increase Load:. Due to this reason.(Stress Testing) LoadRunner allows you to increase load for existing transactions.

Select operation with load 10 and Update operation with load 10. EG:. Scenario (Select. In this benchmarking.9 25 13. project manager compare current performance values depending on below factors. delete.3 Up to Peak load Benchmark Testing:.Performance Results Submission:. then development team is concentrating on changes in structure of application or improve configuration of the environment. project manager can go to decide whether the corresponding values are specifying good or bad performance.LoadRunner allows you to conduct testing on variant operations under variant loads. test engineers are maintaining same name for Rendezvous point.After receiving performance results from testing team. Mixed Operations:. 59 . *Note4: In general. testing team submit performance results to project management in below format. rollback) Time(milisec) Select Select Select Load Average Response 10 6 15 7. update.During load and stress testing. insert. test engineers are maintaining 25 VUsers for one group to get perfect performance results. Note3: LoadRunner maintains 30 seconds as maximum time gap between two consecutive groups. Navigation: Controller Scenario  “Group” menu  add Group  Enter group name Specify VUser Quantity  Browse Script name  Click “OK” Note1: In this multiple groups execution.  Performance results of old version  Interest of customer site people  Performance results of competitive products in market  Interest of product managers If the current performance is not good. commit. Note2: One group users are waiting at Rendezvous point until remaining group VUsers come to same point.

“Target frame= “.II) Web Load Testing:-LoadRunner allows you to conduct testing on three-tier applications also. 60 .  Customer expected configured Server computer  Web master build (Project)  Remote Command Launcher  Portmapper  Virtual User Generator  Controller Scenario  Browser (IE/Net Scape)  Web Server  Database Server Test cases for Web Load Testing: Browser TCP/IP  URL open  Text Link  Image Link  Form Submission  Data Submission Web Server DSN Database Server Web Load Test Cases 1) URL Open:. “Fields values”. 3) Image Link:. “URL=path of next page”.It emulates you to open a web site home page under load Function: web_url(“Step name”. ITEMDATA. ENDITEM. “URL= path of next page”. 4) Form Submission:. 2) Text Link:. “Target Frame= “. Function: web_submit_form(“Form name”.It emulates you to submit a form data to web server under load. “hidden fields”. “URL= path of home page”. LAST). Function: web_image(“Image File name”. LAST). LAST). LAST). In this web load testing. “Target Frame= “.It emulates you to open a middle page through text link under load Function: web_link(“Link text”. test engineers are using below components to create test environment.It emulates you to open a middle page through an image link under load. “attributes”.

ENDITEM. ITEMDATA. LAST) 5) Data Submission:. “Field Values”. Select position in action  “Insert” Menu  “New Step” Select required operation (URL. “action=http:\\localhost\dir\login. “Graphs” Menu in result window  Web Server resource graphs Hits Per Second & Through Put a) Hits Per Second:- 10 Hits/sec 5 1 2 3 4 5 6  Elapsed Time 61 . Submit Data) Click “OK”  Fill arguments  Click “OK” Analyze Results:. LoadRunner returns two extra time parameters to analyze results. ENDITEM. “User_ID=xxxx”. Note 1:. Note 2:. “method=GET”.asp”. ITEMDATA. To record above VUser script statements. LAST).It emulates you to submit a formless (No form on desktop) or context less data to web server under load. “sysdate”.web_server_data(“Step name”. Form Submission. LoadRunner treat one action as one transaction. Text Link. test engineers are selecting E_Business  web(Http/HTML) as VUser type. Function:. “Pwd=xxx”.web_submit_form(“Login”. “Sysdate=xxx”. “attributes”.In web load testing.In web load testing. by default. Image.During web load testing. we can follow below navigation.

Select the drive where QTP 9. QTP Installation Process           Insert QTP CD. Load Time KB/sec Data submit) In Sec URL 10 2 118 URL 15 2 140 URL 25 2 187 URL 30 3 187 Peak Load  Functionality Testing Tool.  Supports . data related operations are taking 12 seconds under normal load.2’ zip file. Double click on my disk. Oracle Apps. 62 .  QTP records our manual test procedure into ‘VB Script’. QTP 9.2’ setup to a selected drive.net. Extract the ‘QTP 9.2 is unzipped. Multimedia like technologies.2 (Quick Test Professional) Introduction  Developed by Mercury Interactive.  Advanced keyword driven testing. test engineers are reporting performance results to project manager in below format: Benchmarking:.b) ThroughPut:Performance Results Submission:. Scenario(URL. Double click on ‘QTP 9.  Fast and reliable in testing process. SAP.2 key zen’ folder. Extract to same drive. Transaction Through put Image.Submit form. Double click on crack for QTP folder. Link operations are taking 3 seconds.Form World Wide Web consortium standards. Double click on ‘Mercury QTP 9. Double click on my computer. Double click on my computer.Link.During web load testing.

                Double click on QTP 9. Click ‘Finish’ button. Enter user name. Double click on setup. Double click on QTP CD – FCS folder.B). Double click on Legend folder.2 installation started. Select “I accept the terms in the license agreement”. Double click on Mercury – QTP – V9. QTP setup box displayed. Review settings displayed. Click ‘Finish’ button. 63 . QTP 9. Setup status displayed. Click ‘Next’ button. Note: Right click in the maintenance no. Select set the required options automatically. (Required space to install QTP – 235652 K. Double click on QTP CD – FCS folder. and paste the maintenance no.2 – LND folder.2 folder.2 successfully installed. Unselect the register now. Click ‘Yes’ (registration conformation). Click ‘Next’ button. Select and click copy and close the notepad. Click ‘Next’ button. Choose destination location dialogue box displayed.2 license agreement dialogue box displayed.exe. Select Quick Test Professional setup. Set internet explorer advanced options dialogue box displayed. Press ‘Yes’ button. QTP 9. Customer registration displayed. Quick Test Professional menu displayed. company name and maintenance number.txt notepad.2 registration information displayed. QTP 9. Double click on Install. QTP 8. Select updates displayed. Unselect ‘view readme file’.                    Click ‘Next’ button. Select “do nothings with the found updates”.

2) Start recording: It is an advanced option in QTP to record our manual test procedure into VB Script directly from the welcome page. Select and click ‘Options’ in Tools menu. Select ‘display welcome screen on startup’ in general tab. 6) Show this screen on startup: If you want to display the welcome page select this option or else unselect this option. Click OK. 5) Tip of the day: This displays the help on a short menu day to day by giving the tips during our QTP testing process. Click Blank Test. 1) Tutorial: This displays the entire QTP testing process as a help document. if we want to display the welcome screen again follow the below process. Select Quick Test professional. QTP Window QTP Window consists of different types of tool bars. QTP – add in manager dialogue box displayed. 4) Blank test: Select this option when the QTP starts. Note: When we unselect the welcome screen. Select programs. Select and click Quick test Professional.      Select Tools menu in QTP window. 1) Title bar 2) Menu bar 3) File tool bar 64 . 3) Open existing: This is used to open the existing test created. Quick Test Professional welcome page displayed with the following options. Clicks apply and click OK.QTP Starting Process        Select start menu on the desktop.

This testing tool bar consists of below icons. File tool bar: This tool bar consists of buttons of commands from the file to start and stop the testing process using QTP. maximize and close buttons in blue colour. Menu bar: This tool bar displays the buttons of commands for testing process in QTP with dropdown menus. Record Recording Stop action split start transaction recording 65 . This menu bar consists of different types of menus.4) Testing tool bar 5) Debug tool bar 6) Action tool bar 7) Test pane 8) Data table 9) Active screen 10) Status bar 11) Debug viewer Title bar: This tool bar displays the name of the testing tool (QTP) and name of the test created (by default untitled test) with minimize. New Active debug test quality object save screen viewer settings center spy connection Open print data results table objects object repository Testing tool bar: This tool bar consists of buttons of commands to create the test during testing process in QTP.

Global 2. This data table consists of 2 tabs. Data table: This is an excel sheet provided by the QTP to parameterize the values into variables. Action list Display selected action Back Test pane: Test pane displays the ‘Keyword view’ and ‘Expert view’.Start Run New insert stop action checkpoint transaction Debug tool bar: This tool bar is used to run the test created smoothly without any errors. Action Active screen: This option displays the snapshot of the application. 1. Step Into step out clear all break points Pause step insert/remove Over break point Action tool bar: This tool bar displays the individual actions we performed on our application during creation of one test. 66 . this active screen displays the snapshot for the actions performed on our application.

If we load the technologies based on the seat license. The QTP provides 3 built in technologies like as active X controls. Note 2: To display the file toolbar. The licenses are of different types like as a. Permanent: This type of licenses are given for the technologies loaded with out any time limit and the technologies loaded remains permanent. Not – licensed: If a technology is loaded and if it is not licensed as permanent. visual basic and web by default. testing. Add – In: This displays the name of the technology loaded with one check box. License: This option displays the type of the license used for the technologies loaded. QTP Add – In Manager This option is provided by the QTP to load the supporting technologies. c.  Select file. We can select or unselect this check box. testing toolbar and debug toolbar follow the below navigation. Built – In: This license is provided by the Mercury Interactive for the technologies provided by the Mercury Interactive. Note 1: When we start the QTP active screen and debug viewer are not displayed in QTP window. This Built – In license is a permanent license for the technology provided by Mercury Interactive. To conduct testing on the selected technology based application. Debug viewer: This debug viewer displays the errors raised while debugging one test. The Add – In Manager displayed when we start the QTP.  Select view menu in menu bar. b.  Select view menu.  Select toolbars. The Add – In manager dialogue box consists of I. d. the license column displays the “Not – Licensed”. debug. 67 . Limited license (Seat license): This license supports the technology loaded upto some extent as a trail versions by providing how many days remaining for this license to be outdated (minimum 14 days etc).Status bar: status bar displays the current status for the current test created. II. the time remaining column in Add – in manager displays the remaining time.  Select and click Active screen and Debug viewer. to display this 2 options follow the below navigations.

If you are not interested to display the Add – In manager unselect this option. Show on startup: This option is provided by the QTP as a check box.In license: If a technology is not licensed. When we click license QTP license summary dialogue box is displayed. we can update the technology using the modify Add – In license. Select display Add – In manager on startup check box in general tab. Outdated licensed: if we load one technology and if it is not working even the license is updated. There are 3 types of recording modes to record our business operations into VB Script. then the license column displays the outdated. Modify Add -. IV. Click Ok. 1) General Recording 2) Analog Recording 3) Low – level Recording General Recording: This is context sensitive recording mode in winrunner. Note3: If this license is not loaded for this technologies and if we want to display the licenses created for the technologies loaded. we can select or unselect this check box to display the Add – In manager during the QTP starting process. 68 . Clicks apply. Note1: If we are interested to display the Add – In manger during QTP Starting process follow the below navigation. select license button. III. Note4: We can modify the license here by using modify license. if we want to know that technologies loaded into the Add – In manager follow the below navigation.e.  About Quick Test Professional dialogue box displayed. This displays the loaded Add – Ins. Add – In description: This option displays the summary of the loaded technology. test engineers record our manual test procedure into VB Script.     Tools menu select options. Recording Modes During QTP testing process. This recording mode is used to record the mouse and keyboard operations on our application. Note2: After the QTP window is started.  Help menu → about Quick Test Professional. V.

General Recording navigation:  Click record button in testing tool bar (or) select ‘Test’ menu and select and click record (or) press F3 in keyboard. 1) Type of the internet explorer (Ex: Microsoft internet explorer). digital signatures etc. To record the business operations of a particular web application fill in the following browser details. Open the following browser when a record (or) run session begins.  Record and run setting dialogue box displayed Note: The record and run settings dialogue box consists of 2 tabs.  Click apply. second option is selected to record the business operations of a particular web application. This recording mode is used to record the satellite applications and medical applications etc.t time operations. This recording mode is used to record the images. Note3: After specifying the above 2 details. 69 .r. select the below options Do not record and run on browsers that are already open. 2) Address of the application (URL).r. electronic signals. Record and run test on any open window.  Web  Windows applications Web: This option is provided in QTP record and run settings dialogue box to record the business operations based on web applications.t desktop co – ordinates. Note2: In the above 2 options.Analog Recording: This recording mode is used to record the mouse moments w.  Click OK. test engineers should maintain constant resolution of the application. Close the browser when the test closes. This web tab consists of 2 options. Low – Level Recording: This recording mode is used to record the mouse moments w. the first option is selected to record the business operations on any web applications. During this Analog recording. Note1: In the above 2 options.

Click Apply.Windows Applications: This option is provided in QTP record and run settings dialogue box. but in web application we can give one details only. second option is selected to record the business operations of a particular window application. Note1: In the above 2 options. Application details dialogue box displayed. 70 . Browser the working folder. Analog Recording navigation  Start General recording. record and run settings dialogue box dose not displayed up to a new test is started. To record the business operations of a particular windows application fill in the following window application details. the first option is selected to record the business operations on any windows applications. Note2: In the above 2 options. Select the program arguments (optional). Note2: More than one window applications can be added to the application details. Record and run test on any open windows based application (default). Note1: Use edit and delete buttons to modify and delete the application selected. Click OK.         Click Add. o Record and run on these applications (Open and session start). Browser the application path. To record the business operations based on windows applications (C/S applications). Note3: Once the general recording is started and stopped. In this windows applications tab there are 2 options to record the business operations.  Select and click Analog recording (or) ctrl + shift + F4. Click OK.  General recording started with red color intimation in status bar.  Select Test menu.

71 . Analog recording settings dialogue box displayed. Analog recording dialogue box consists of the below options. Navigation for windows based application  Select start menu on desktop.  Select programs. Note: Select whether to record mouse operations related to a specified window or related to the screen. Note4: To know that whether the Analog record is started or not QTP displays the ‘Analog’ in status bar. Select and click low level recording. Note2: In the above 2 options. Low – Level recording navigation     Start General recording. Record relative to the screen (default).  Select Analog record (click). Note3: Window title is captured from the application. Record relative to the following window. When we select this option specify the window title using hand icon button. Sample Application starting process Mercury Interactive is providing sample application for testing using QTP. select record relative to the following window. Hand icon displayed. Mercury Interactive provides 2 types of sample applications. select the window title in your application (double click). 1) Windows based application (Flight reservation).  Analog recording started. select record relative to the screen to record the business operations performed on any web application. Select Test menu. 2) Web application (Mercury tours site ). Low level recording started displaying Low – Level in the status bar. Note1: In the above 2 options.

adjust the application to the right side corner of the application using mouse. 1) Item 2) Operation 72 . The tests created in keyword view are displayed in English. view and modify the tests. Select Programs. Enter agent name (any name). Flight reservation windows based application is displayed. Enter password (mercury). Note1: After the application is displayed on the desktop. The options displayed in keyword view are as below. Login displayed. Working with Keyword view: The Keyword view is used to create. Navigation for web application      Start Menu. Select and click Flight. The keyword view displays the steps created in expert view as a row. 1) Keyword view 2) Expert view Keyword view The keyword view is used to create the tests and to view the tests in a modular format. Test Pane The Test Pane consists of 2 tabs. Select sample applications. Note2: Drag the QTP window to the left side corner of the desktop. Select sample applications. The keyword view is displays the tests in a tree view. This helps us to understand the tests created in expert view (VB Script) into a easy process.        Select Quick Test professional. Select Quick Test Professional. Click OK. The keyword view consists of different columns in a table format or modular format. Select and click Mercury tools website.

 Select one column name in visible column tab. this option is not displayed in tools menu. 73 .  Select and click keyword view. 1) Available columns 2) Visible columns Available columns: This tab consists of required columns to be added into the keyword view. view. Note: If we want to remove one column from keyword view follow the below navigation. Visible columns: This tab displays the existing columns in keyword view and also newly added columns from available columns tab.  Select Tools menu.  Click ‘>’ button to add new column into keyword view. Note: To add the more columns to the keyword view follow the below process. To add one column follow the below navigation. Adding Keyword view options: We can add. Keyword view options dialogue box: This dialogue box consists of 2 tabs.  Select the existing available column in available column tab. If we are creating the tasks in expert view. modify and delete the columns displayed in the keyword view by using the below navigation.  Click ‘>>’ (Add+) button. Note1: If we want to add all the columns which are displayed in the available columns tab follow the below navigation.  Click ‘<’ button to remove one column from keyword view. Note: In tools menu ‘Keyword view options’ option is displayed only when we are into keyword view. Note: When you follow the above procedure a new column is added to the keyword view.3) Value 4) Documentation The above columns are displayed in a keyword view by default.  Keyword view options dialogue box displayed.

The tests are created by recording the business operations performed on our application into steps. This item column is displayed with ‘Action’ as the parent step for all the items displayed in a tree view. 4) Documentation: This column displays the operation are performed on our application. 6) Assignment: This column displays the no. Edit box / Text x Web Edit 74 .Note2: If we want to remove all the columns which are displayed in the visible column click ‘<<’ (remove --) button. of variables used in VB Scripts. Press etc. The arguments displays the whether the operation we performed on our application is passed or failed and also displays the expected values in terms of 0 and 1. Expert view The expert view in the test pane is used to create the test in VB Script. The keyword view consists of the following columns. 3) Value: This column displays the arguments (true or false). While recording the business operations the following objects and windows are recorded. Select. We can expand and collapse the items displayed by using ‘+’ and ‘—‘ icons. Click OK. 5) Comments: This column displays the name of the window in red color. where we performed our business operations. We can expand and collapse the tree view to display on which items we performed our operations. Ex: Click. Note: If we want to display the columns in the keyword in an order as you like use the up and down arrows available in keyword view dialogue box. 1) Item: This is name of the object of the following columns where we are performing our business operations in the application. 2) Operation: This column displays the type of operation we performed on the item.

The check points are of 8 types in QTP. 1) Standard checkpoint 2) Bitmap checkpoint 3) Text checkpoint 4) Text Area checkpoint 5) Accessibility checkpoint 75 .List box Web List Web Button Push Button Check box Web Check box Radio button Web Radio Group Win Edit Edit box / Text x List box Win List Push Button Win Button WinCheckbox Check box Radio button Win Radio Button Check Points: During recording the business operations the steps are created in the expert view in VB Script. To test the current behavior of one application with its earlier behavior check points are used.

count. focused. focused. disabled. X. List box ………. Navigation for Flight reservation application:  Click record in QTP window 76 . Check box --------- enabled. X. regular expression.6) Database checkpoint 7) XML checkpoint (file) 8) XML checkpoint (web) Standard Checkpoint This checkpoint is used to check the object properties. focused ………. focused. width. value Push Button Y……… --------- enabled. disabled. width. -------enabled. height.. Radio button -------- enabled. disabled. disabled.. disabled. Ex: Flight Reservation (Windows application) Requirements: Focus to window → “Update order” button disabled Open order → “Update order” button disabled Perform change → “Update order” button enabled Objects & Properties: Edit box / Text x height. focused ………. Value. In general a standard checkpoint is used for starting the every checkpoint. -------enabled.. Y……….

         

General recording started Select ‘file’ menu in application. Select and click open order Select order no. Enter order no (1 to 10) Click Ok. Perform change in opened order. Click update order button. Stop recording. Keep application in blank mode. (Click new in application).

Navigation for Checkpoints Insertion: Follow the requirements and insert checkpoints. Note: In QTP, to insert one checkpoint general recording is to be started. If not, checkpoints are not displayed in ‘insert’ menu.        Start recording. Select insert menu. Select checkpoint. Select and click Standard checkpoint (F12). Hand icon displayed. Click on the testable object in application using this hand icon. Object selection – Checkpoint properties box displayed.

Note: This box displays the location of the object you selected associated with several objects and windows.  Click OK.  Checkpoint properties dialogue box displayed. Checkpoints properties dialogue box: This dialogue box displays the objects properties. We can select one property to test as given in the customer requirements. This dialogue box consists of the below options. 1) 2) 3) 4) 5) Name of the object Class of the object Type, Property, Value table Configure value Checkpoint timeout

Type, Property, Value: 77

In checkpoint properties dialogue box in QTP (Type, Property, Value) table is displayed. In this table we can select the properties based on customer requirements. Note: If the customer requirements is enabled or disabled, select6 the checkbox given for enabled property in this table. Value: This value option is provided based on the requirement for particular property. We can change this value in ‘configure value’. Configure value: The configure value consists of 2 options. 1) Constant 2) Parameter Note1: In the above table, we can change the property values using ‘constant’ option in configure value. Note2: As per customer requirements, change the value of the property in constant. We can change the value in constant by using the list box for the constant option. (True / False).  Click Ok.  Checkpoint inserted. Note: Insert the order checkpoints by following the above process and by using the customer requirements.  Click “Run’  ‘Run dialogue box’ displayed  Click ‘OK’ Note: This “Run” dialogue box displays the results location of the current test created.  ‘Test results’ window displayed Example: Flight Reservation VB Script for update order button. Requirements: Focus to window → “Update order” button disabled Open order → “update order” button disabled Perform change → “Update order” button enabled VB Script: 78

 Window (“Flight Reservation”). WinMenu (“Menu”). Select “File; Open Order---“  Window (“Flight Reservation”). WinButton (“Update Order”). Check CheckPoint (“Update Order”)  Window (“Flight Reservation”). Dialog (“Open Order”). WinCheckBox (“Order No.”). Set “ON”  Window (“Flight Reservation”). Dialog (“Open Order”). WinEdit (“Edit”). Set “1”  Window (“Flight Reservation”). Dialog (“Open Order”). WinButton (“Ok”). Click  Window (“Flight Reservation”). WinButton (“Update Order”). Check CheckPoint (“Update Order_2”)  Window (“Flight Reservation”). WinRadioButton (“First”). Set  Window (“Flight Reservation”). WinButton (“Update Order”). Check CheckPoint (“Update Order_3”)  Window (“Flight Reservation”). WinButton (“Update Order”). Click Test Results Window This results window displays the status for the current test created in pass / fail criteria. This test results window consists of two tabs. 1) Test untitled test summary (in tree view) 2) Untitled test results summary To know whether the current test created is passed or failed, (i.e.) whether the expected is equal to actual or not, we can know through the checkpoints created as a result of pass (or) fail. To know whether the current test is passed (or) failed expand the tree displayed in the left side corner in the test result window. Untitled Test Result Summary: This tab displays the test name, results name, time zone, run started and run ended, status (pass, failed, warnings) and the no of times the test is passed or failed. Note: This tab is also displays the name of the iteration failed.


4) Comments: A comment describes the operations performed on the application during the creation of tests.Understanding the VB Script syntax In QTP. 6) Variables: QTP VB Script allows the parameterization of the values into variables. WinEdit (“Edit”). To call them during the running session of the test created. This comment describes the script created in a simple language like English. 1) Case – Sensitive: VB Script used in the QTP is not case – sensitive. Understanding the variables You can specify the variables to the test objects are simple values. Set “XXX” │ │ │ │ Test String Test String 3) Parenthesis: VB Script in QTP allows the text string must be inserted in Parenthesis. Parameterization means string the values into variables. To use the VB Script in QTP the following tasks are to be followed. Ex: comment: ‘In “sample” window “ok” button is clicked’ Script: Window (“Sample”). A variable describes the test objects or simple values by following the object hierarchy. WinButton (“Ok”). Whenever a text string is inserted in VB Script. In VB Script variables are started with ‘set’ statement. Winbutton (“update order”). Test String Test String 80 . WinButton (“Open Order”). WinButton (“Update Order”) (right) Window (“flight reservation”). Click 5) Spaces: In QTP VB Script allows blank spaces between the test created. Ex: Window (“Flight Reservation”). Ex: Window (“Flight Reservation”). it must consist of double quotes. to create one test VB Script is used to for easy purpose. (Wrong) 2) Test String: QTP VB Script allows test based strings within the double quotes.

The For – Next statement in VB Script is followed by below syntax. Syntax: While {condition} Statement End 81 . Set “UserEditbox Next Do – Loop Statement Do – Loop statements enable the Quick test to execute a statement or a series of statement. Set “XXX” For – Next Statement In VB Script the For ---.Set objvar = obj hierarchy Ex: Set UserEditbox = Window (“Flight Reservation”) WinEdit (“username”) UserEditbox. Syntax: Do [{while} {until} condition] Statement End While Statement While statement is used to execute a statement or a series of statements while a condition is true. step2} Statement Next Ex: For User Edit box = 1 to 8 {‘1’} Window (“Flight Reservation”). while condition is true or until the condition is true. Syntax: For counter = Start to End {step1.Next loop is used to execute the sequential statement. WinEdit (“Username”).

If – then – else Statement This statement is used to execute a statement or a series of statement. test engineers concentrate on creating the Object Repository (GUI Map). The object Repository is created ‘to recognize the objects. Object Repository Before starting the QTP testing process. ---------------} End EX: With Window (“sample”) WinEdit (“Username”) WinButton (“Ok”) End.  Click Object Repository 82 . Syntax: With {statement 1. Navigation:  Select ‘Tools’ menu. The creation of objects and windows using OR helps the QTP testing process in a simple way. If you want to continue another statement to execute else is used Syntax: If {condition} then Statement Else if {condition2} Statement Else {condition3} Statement End With Statement To execute a group of statements into a single statement. statement2. windows and browsers into QTP’.

 Select one object.     Click Add objects button.  Expand the tree view in ‘Action’ tab.  Click OK. Selected object and all its descendants. Object Repository dialogue box displayed. Object Spy 83 . The Object Repository dialogue box consists of the following tabs. windows and browsers recognized from application in a tree view. Note: This dialogue box is used to select which objects to add to OR by using the below options. 1) Action 2) Properties 3) Configure Value 1) Action: The ‘Action’ tab is to display the objects. Only the selected object Selected object and all its direct children. Double click on the application window or browser title bar. Note1: All the objects and windows are added to the ‘Action’ tab in a tree view. if we want to view the particular object and window which are recognized from our application follow the below navigation. To add (recognize the objects and windows into this action tab follow the below navigation. In the above 3 options select the objects and all its descendants. “Object selection – Add to repository” box displayed Note: This box displays the location you clicked which is associated with several objects.  Click OK.  Click highlight button. Note2: After completion of reorganization of objects and windows. Hand icon displayed. which point outs the selected object or window in our application.  Add object to object repository dialogue box displayed.

2) Properties: This option is provided in OR to display the properties of objects and windows recognized into QTP.  Object spy dialogue box displayed.QTP provides an option to spy the objects and windows properties in our application by using Object Spy (GUI Spy). In the above 2 options. Run – time object properties. Note: When we select the objects or windows in our application using this hand icon. In QTP.  Select and click Object Spy. the properties and methods of the particular object are displayed in the Object Spy. Bitmap Checkpoint: This checkpoint is used to test the static and dynamic images. select the second option to test the recognized objects or windows into Object Repository. 3) Configure Value: This option is provided in OR to change the property value for the objects recognized. This properties option displays the name of the property. Test objects properties. a bitmap checkpoint is also used to test digital signatures like application in analog recording mode.  Hand icon displayed. Note1: The Object spy consists of a pointing hand button to select the object or window whose properties you want to view. Navigation:  Click ‘record’ in QTP window. Note: To open the Object Spy follow the below navigation. These values are called constants (true/false).  Click on hand icon button.  Click on hand icon button. Note2: The Object spy consists of 2 options.  Select the object or window you want to spy the properties in your application. 84 .  ‘Record and Run settings’ dialogue box displayed. type of the property and expected value for that property.  Click ‘Object Spy’ button in Object Repository (OR)  Select ‘Tools’ menu.

Select ‘open the following browser when a record or run session begins’. Note3: If u wants to test the text exactly to meet the requirement select exact match. We can test the object’s text in one application using text checkpoint.        Click OK. Note1: This text checkpoint properties dialogue box consists of checkpoint summary. Stop recording. Text checkpoint inserted. 85 . Note2: There is an option to ignore the spaces in between the text displayed. Click OK. Hand icon displayed.     Select Web tab. (Select ignore spaces checkbox). Click ‘Run’. Select the text we want to test of one object. Select insert menu. Text Checkpoint Text checkpoint is used to test the calculations and text base tests. Navigation:  Start recording. Navigation:        Start recording. configure (constant and parameter). Select checkpoint. Clicks apply. Enter the browser details (type. Expand the untitled test iteration. Test results window displayed. Select and click text checkpoint.  Select insert menu. Text checkpoint properties dialogue box displayed. address). Text Area Checkpoint This checkpoint is used to check the screen area of the text. Click on checkpoint.

Select the area of the text we want to test of one object. 86 . In the above two options. Click database checkpoint. Specify SQL statement manually. Create connecting string (by using the create button). Note: To connect to the database using ODBC (Object Database Connectivity). Expand the untitled test iteration. select the second one to get the data from database. Select machine data source tab. Database Checkpoint This checkpoint is used to correctness of the backend tables. Click OK. Click insert menu. Click Create.        Click next. Select the DSN (data source name) Note1: The DSN is provided by the development team to test the database (Ex: Flight 32). Click on checkpoint. Specify SQL statements displayed. Select one of the below option.            Select che4ckpoint. Select data source dialogue box displayed. Create query using Microsoft query. Test results window displayed. Database query wizard dialogue box displayed. Click checkpoint. Click Run. Text area checkpoint inserted. This checkpoint is created either by using MS query or by specifying the SQL statements. Select and click text area checkpoint. Stop recording. Navigation:      Start recording. Test area checkpoint properties dialogue box displayed. Cross hairs icon displayed.

Note4: For the constant. 1) Database 2) Queries     Select database tab.     Click OK. Note3: This dialogue box consists of expected data. Note: What columns of data do you want to include in query select those columns. Note: All the columns in the table are added to a separate tab (columns in your query tab). constant value options browse button is displayed. Click next. Select DSN given by the development team. Database checkpoint properties dialogue box displayed. Navigation to test the database using MS query:          Start recording. Database query wizard dialogue box displayed. Select database checkpoint.Note2: Flight 32 is the DSN for the Flight Reservation application. When we click this browse button constant value options dialogue box displayed. Enter the expected value or use regular expression to display all the orders in an order. Specify SQL statement (select * from orders) Click finish. In expected data test engineers are specifying the constant values as expected values. Query wizard – choose columns dialogue box displayed. Click OK. Microsoft query window displayed and choose data Source dialogue box also displayed. Select insert menu. Note: This dialogue box consists of 2 tabs.  Click add ‘>’ button. Select and click checkpoint. settings and cell identification. 87 . Select “Create query using Microsoft query”.

Select “View data or edit query in Microsoft query”. Library: there are different types of functions available in QTP like as library functions. Arguments: The arguments are used to assign the expected value of particular property selected. The step generator consists of the following options. Select object (Click the browse button displayed for this object). utility objects and functions. Use the pointing hand icon to select the object and to generate the step for that object. Sort order dialogue box displayed.  Query wizard – filter data dialogue box displayed. Step Generator This option is provided in QTP to know the unknown functions for each and every object and window.  Click ok. Note: Select the columns you want to retrieve from the displayed list. Select object for step dialogue box displayed.     88 . Click finish. Click next. Navigation: Select category (Test objects).  Object selection dialogue box displayed. Operation: Operation displays the different types of operations we performed on the application. Query wizard – finish dialogue box displayed. 1) 2) 3) 4) 5) 6) 7) Category Library Operation Arguments Generated steps Return value Insert another step Category: This is a list box provided by the step generator in QTP. This shows us different categories of functions like as test objects. Click next.       Click next. built – in functions and local script functions.

testing team concentrate on “Privacy to user operations “in our application build. visual basic and web. This testing technique is classified into below sub tests a) Authorization: Whether a user is authorized or not to connect to an application? b) Access Control: Whether a valid user has permission to use specific service or not? c) Encryption/Decryption: Encryption Client Decryption Server Response Cipher Text 89 Converted to Original Text Request Original Text Converted to Cipher Text . Select step. Navigation for step generator:     Select insert menu. This environment consists of different types of objects like as active X controls.  The step is generated in the generated step box. Select and click step generator (or) F7.  Select the operation (click. Object identification dialogue box displayed. Object Identification This option is available in QTP to know the properties of different objects and to identify the hiding properties. set) required for the object selected. standard windows. Select object identification.Note: The object selected is displayed in the object list box. Navigation: Select Tools menu. Step generator dialogue box displayed. During this test. The Object Identification displays the properties of an object by selecting the environment.  Click OK. **********************************THE END***************************** Security Testing: This testing technique is complex to be applied.

e.e. server performs decryption.Here sender i. Test Lab. Note: In small scale organizations. Test Plan. authorization and access control are covered by the test engineers. and analyzing the results of these runs. Introduction Test Management Process Define Test Requirements Develop Test Plan Execute Tests Track Defects The four modules of Quality Center — Requirements. client performs encryption and receiver i. •Execute tests: This phase involves organizing test sets. Developers perform the encryption/decryption procedures. performing test runs. •Develop test plan: This phase involves planning and confirming which tests need to be performed and how these tests must be executed. scheduling their executions. and Defects — map directly to the following stages of the testing process: •Define test requirements: This phase involves identifying and validating the functional and performance requirements that need to be tested. 90 .

Quality Center provides reports and graphs for performing test data analysis and gathering status updates across all stages of the testing process. •Create requirements.This chapter covers the first stage of the test management process. Defining Test Requirements Defining Test Requirements Purpose . You need to avoid this kind of a moving target. and modify test requirements using four different views. You can then use that goal as a reference to focus on individual efforts. you will be able to: •Identify the characteristics of a useful test requirement. •Build a requirements tree. •Define the testing requirements of an application. create. •Helps prevent scope creep: Documented requirements are the best defense against Scope creep. •Track the status of requirements.Not For Duplication What are Test Requirements? Test requirements describe in detail the components that need to be tested in an application and provide the test team with the foundation on which the entire testing process is based. Test requirements also provide guidelines to the testing team to identify their testing priorities. •Sets clear expectations between teams: Defining requirements and getting them signed off by relevant stakeholders is the best way to ensure that expectations have 91 . impeding the software development and testing efforts. where requirement documents are continually amended and appended.. The chapter describes the steps to define.•Track defects: This phase involves reporting defects that were detected in the application and tracking the repairs. and instead clearly define the goal at the start of the project. Define test requirements clearly and correctly at the beginning of a project has the following advantages: •Aids development and testing: Clearly defined test requirements help developers set a target for themselves. Mercury Education . Objectives After completing this chapter.

take out time at the beginning to invest in your requirements. Quality Center provides this functionality through the REQUIREMENTS module. but it applies to requirement development as well. Make sure that all necessary parties are represented in the creation of the requirements. but if you do not do it right. Building this tree makes it easy for you to define and manage hierarchical relationships between requirements. Confirm and validate the expectations of everyone involved in the project. The test requirements are arranged hierarchically. If you do not want to waste your time and money later in your project. you may have to scrap what you are doing and start over. IT. •Saves time and money: "Measure twice. Characteristics of a Useful Test Requirement A useful test requirement is always: •Unique: Is this the only requirement that defines this particular objective? •Precise: Are there any vague words that are difficult to interpret? •Bounded: Are there concrete boundaries in the objectives? •Testable: Can you build one or more test cases that will completely verify all aspects of this requirement? What is a Requirements Tree? Requirements Tree Quality Center helps you define requirements for the testing process. 92 . These four views are: •REQUIREMENTS TREE view this view enables you to view requirements in a tree.been agreed upon by all parties involved -.product marketing. Measuring a piece of wood to prepare for a cut does not take much time. The REQUIREMENTS module enables you to build a requirements tree to outline and organize the test requirements of a project. customer service. and documentation. cut once" is a phrase used in carpentry.

non-hierarchical view. •COVERAGE ANALYSIS view this view enables you to analyze the breakdown of child requirements according to their test coverage status.Not For Duplication Using the Coverage Analysis View 93 . The REQUIREMENTS COVERAGE view has the following four tabs: •TEST COVERAGE: This tab displays the tests to which a requirement is linked and the execution status of these tests. the TEST COVERAGE tab is clicked by default. •LINKED DEFECTS: This tab displays the defects that were logged for a requirement.•REQUIREMENTS GRID view this view enables you to display requirements in a flat. two new tabs appear towards the right Side of the screen.When you switch to the REQUIREMENTS COVERAGE view. When you click the TEST COVERAGE tab. •ATTACHMENTS: This tab displays the files that have been attached to a requirement. TYPE. This helps in analyzing test requirements with respect to their position in the requirements hierarchy. such as its PRIORITY.. and CREATION DATE. Mercury Education . –TEST SET TREE: This tab displays the hierarchy of tests within a test set. These tabs are: –TEST PLAN TREE: This tab displays the hierarchy of tests within the test plan. such as tests and defects. •DETAILS: This tab displays the details of the requirement. The REQUIREMENTS TREE view displays the parent-child relationship between test Requirements. •REQUIREMENTS COVERAGE view this view enables you to view requirements based on their association with tests and defects. REQUIREMENTS TREE view provides a tabulated list of the requirements data. AUTHOR. You can use this view to add requirements within the hierarchy. . Using the Requirements Coverage View The REQUIREMENTS COVERAGE view enables you to define and track relationships between requirements and other entities.

•ATTACHMENTS tab: Enables you to add attachments to subject folders or specific tests. The efficiency of the test runs depends on how well you plan and decide the tests that need to be performed and how these tests should be executed. To add a folder: 94 .The COVERAGE ANALYSIS view provides a chart that shows the requirements that are directly associated with tests and the execution statuses of these tests.. Elements of the Test Plan Module The test planning tools in Quality Center are organized into the following elements of the TEST PLAN module: •DETAILS tab: Enables you to enter descriptions for the subject folders and tests. •REQ COVERAGE tab: Enables you to link tests to requirements. you create main subject folders and add subject sub-folders within each main folder. the testing team designs tests that validate whether the application meets these requirements. Test Planning Test Planning Test Planning the second stage of the testing process is test planning. From the SUBJECT folder. Test Planning Creating a Subject Folder The TEST PLAN tree starts with the SUBJECT folder. . •LINKED DEFECTS tab: Enables you to link tests to defects. •DESIGN STEPS tab: Enables you to specify the steps for each test. The COVERAGE ANALYSIS view is a graphical representation of the REQUIREMENTS COVERAGE view. After test requirements are approved.All the tabs listed above are displayed when a test is selected from the TEST PLAN tree. •TEST SCRIPT tab: Enables you to design scripts for automated tests.

Mercury Education . The CREATE NEW TEST dialog box appears. Select a TEST TYPE and type a name for your test in the TEST NAME field.Not For Duplication Adding Test Steps Add Test StepsWhen all of the individual tests are laid out. 2. and the expected output. |. or *. Click NEW FOLDER. Click OK to add the test to the selected subject in the TEST PLAN tree. On the Quality Center toolbar. select the subject folder in which you want to add the new test. 2. 3. Select a test and click its DESIGN STEPS tab. 4. Adding a Test To add a test to the TEST PLAN tree. the input to enter. 3. From the TEST PLAN tree. Folders can contain sub-folders. ?. Note: A folder name cannot include any of the following characters: \. Click NEW STEP. In the FOLDER NAME field. Adding a test step involves specifying the actions to perform on the application. 95 . Note: You can select an existing main folder to create a sub-folder. The REQUIRED FIELDS dialog box appears. >.1. From the TEST PLAN tree. ^. *. 5. 2. select the SUBJECT folder to create a main subject folder. To add and define a test step: 1. type a name for the new test subject. Click OK to add the folder to the TEST PLAN tree. To add a test: 1. Open the TEST PLAN module. 4. Click OK.:. The DESIGN STEP EDITOR dialog box appears. %. click NEW TEST. Note: A test name cannot include any of the following characters: \. Each folder or sub-folder can contain a maximum of 676 sub-folders. 6. 3. Enter the appropriate values for the required fields. “. or ‘. The NEW FOLDER dialog box appears. <. and each sub-folder can have sub-folders. you need to define the basic information about the test. the next task is to specify the detailed steps to execute each test. /.

A footprint Icon appears next to the test name in the TEST PLAN tree. You can subsequently report these problems into a defect tracking system for further investigation. This icon indicates that Steps are defined for the test. type the instructions that need to be carried out in this Step.. Parameters provide flexibility by enabling each calling test to dynamically change its values. then the PARAMETERS OF TEST dialog box appear. After running the tests.This chapter covers the tasks performed from the TEST LAB module -. 7. This adds a step in the current test And labels it as CALL <TEST_NAME>. correction. Test Execution . type a description of what should be expected after this step is completed. and recording test results.creating test sets. To call another test as a step within a test: 1. Click the CALL TO TEST button. 2. 5. The third stage of the test management process involves organizing tests into test sets and running the tests. 3. The test steps appear in the DESIGN STEPS tab. If you call a test that has unassigned Parameters. you have a complete documentation that lists the inconsistencies. In the EXPECTED RESULT field. Calling a Test Call Another TestYou can build the steps of a test to include calls to other tests. In the DESCRIPTION field. Click the DESIGN STEPS tab of the calling test.4. Type a name for your step in the STEP NAME field. This enables you to modularize and reuse a standard sequence of steps across multiple tests. Select the test that you want to call and click OK. and defects in your application. scheduling and running test executions. For example. You now assign the Parameters values. and retesting. 96 . Click OK when done. Using Parameters A parameter is a variable that can be assigned a value from outside the test in which it is defined. The SELECT A TEST dialog box appears. issues. 6.

Creating a Test Set 97 . or select an existing folder to create a subfolder. click the TEST LAB icon from the Quality Center sidebar. In the FOLDER NAME field. The NEW FOLDER dialog box appears. The folders can contain subfolders that further classify the test sets in each hierarchy. On the toolbar. You use the TEST LAB module to create test sets and perform test runs in Quality Center.Using the Test Lab Module You perform all test execution tasks from the TEST LAB module. ^. you can create your main folders. Creating a Test Set Folder The TEST SETS tree always starts with the ROOT folder. What is a Test Set? A test set is a group of tests designed to achieve specific testing goals. you can build a test set to include tests that validate a specific functionality. The test sets tree organizes and displays your test sets hierarchically. Developing a test sets tree helps you organize your testing process by grouping test sets into folders and organizing the folders in different hierarchical levels. so that you can reuse routines. Click OK to add the folder to the TEST SETS tree. type a name for the new folder. From the TEST SETS tree. Note: Folders can contain subfolders. In this folder. You can also build a test set to include tests that verify that an application works in a particular environment. For example. 2. or *. click NEW FOLDER. To add a folder: 1.A test set can contain a combination of manual and automated tests. Each folder or subfolder can contain a maximum of only 676 subfolders. The test sets tree can contain folders at the root level to indicate the general classifications of test sets. and add subfolders. select the ROOT folder to create a main folder. 3. You can add a test multiple times to the same test set and across different test sets. 4. Note: A folder name cannot contain any of the following characters: \. and each subfolder can contain further subfolders. To navigate to this module.

Providing Additional Information for a Test Set To add additional information to a test set: 1. •TEST SET PROPERTIES tab: Enables you to define additional test execution parameters and requirements. Note: A test set name cannot include any of the following characters: \. Click the DETAILS link. or *. Click NEW TEST SET. When you update a test in a folder. 4. 2. You can also add new defects to a test. From the TEST SETS tree. sequencing. •EXECUTION FLOW tab: Displays the test data in a diagram and provides drag-anddrop functionality for adding. 3. The NEW TEST SET dialog box appears. 2. Click the TEST SET PROPERTIES tab. Type a name for the test set in the TEST SET NAME field and its description in the DESCRIPTION field. Note: Use the ATTACHMENTS button to add attachments to a test set. the data change is reflected in the graph without manually regenerating the graph. Click OK to add the new test set to the TEST SETS tree.To create a test set: 1. run tests. which you use to provide information about test sets: •EXECUTION GRID tab: Enables you to declare the tests that make up each test set. •LINKED DEFECTS tab: Enables you to view the defects that are associated with a test. ^. select a test set. Elements of the Test Lab Module The TEST LAB module in Quality Center consists of the following test execution elements. 4. select the folder to where you want to add the new test set. 3. and scheduling tests. type the additional information that you need to specify. Displays test data in a grid. This provides the same procedures and options for adding attachments as in the REQUIREMENTS module. In the TEST SET INFORMATION section. From the TEST SETS tree. and review the results of these executions. 98 . •LIVE ANALYSIS tab: Enables you to generate a graphical representation of the different fields associated with a test.

The MANUAL TEST RUN dialog box appears. select a test set. click a test folder to add an entire group of tests or click a test name to add a specific test. 3. The MANUAL RUNNER dialog box appears. Under the TEST PLAN TREE tab. you will be prompted to assign values to the unassigned parameters in the PARAMETERS VALUES FOR RUN dialog box.. Type the parameter values and click OK. you are prompted to enter their required values.. 5. you select and add the tests to each test set.You need to hold down the SHIFT key to select multiple tests. 4. click BEGIN RUN. To start the test run. From the TEST SETS tree. Running Tests Manually To manually run and record the results of a test: 1. 4.Adding Tests to a Test Set After building your TEST SETS tree. You can also drag and drop tests from the TEST PLAN tree to the EXECUTION GRID tab. Additionally. Note: Use the RUN DETAILS section to record information about the current run and the TEST DETAILS section to make changes to the tests before running them. Select MANUAL RUNNER and click OK. Click the EXECUTION GRID tab and click SELECT TESTS. select a test set. 2. The TEST PLAN TREE tab appears on the right side of the screen. 3. Click ADD TESTS TO TEST SET. The MANUAL RUNNER dialog box appears. Note: If you select a folder containing tests that are already included in the test set. if the tests that you add have unassigned parameters. 99 . click the RUN arrow and select RUN MANUALLY. This number indicates the sequence when an instance of this step is added to the same test set. Note: If the tests contain unassigned parameters. Click the EXECUTION GRID or EXECUTION FLOW tab and select multiple manual tests. To add tests to a test set: 1. The MANUAL RUNNER dialog box appears. you are prompted to choose the tests in the folder that you still want to add. 2. From the TEST SETS tree. This adds the test to the test set and prefixes a number to its name. On the Quality Center toolbar.

system information. •STATUS column to record the execution status of a test. Perform the test step as outlined in the DESCRIPTION field of MANUAL RUNNER dialog box. This additional effort may impact the testing lifecycle. you use the: •COMPACT VIEW button to individually view and update the DESCRIPTION. tracking.6. 8. •ATTACHMENTS tab: Enables you to attach files. additional effort is required by the testing team to track these issues at a later stage. Using the Defects Module The DEFECTS module in Quality Center provides a complete system for logging. The DEFECTS module screen is displayed. 100 . snapshots. on the Quality Center toolbar. managing. click the DEFECTS icon from the Quality Center sidebar. If application issues are not tracked correctly. •DESCRIPTION tab: Provides a text box for entering and reviewing annotations for each defect. 7. •Grid filter: Provides filter fields from where you can define a criterion for filtering the data listed in the DEFECTS grid. click the RUN arrow and select CONTINUE MANUAL RUN. EXPECTED RESULT and ACTUAL RESULT fields of each test step. Record the status and actual result of each step using the provided fields. •ACTUAL field to record additional details about the completion of a test step execution. URLs. Quality Center provides a central defect tracking system that both the testing and development teams can use to collaboratively resolve defects. which lists the various defects and their attributes. To end the test run. To navigate to this module. click END RUN. Defect Tracking Managing and tracking application issues is a critical step in the testing process because it involves a lot of time and money. Note: To run a test whose status is NOT COMPLETED. Recording Results of Manual Tests While recording the results of a manual test run. Module Quality Center’s defect tracking tools are organized into the following elements of the DEFECTS module: •DEFECTS grid: Provides a tabular list of the defects submitted for a project. and clipboard images for providing a better explanation for a defect. and analyzing application defects.

such as a test instance. Click SUBMIT to save the defect to the DEFECTS module. is associated with Test_01. Therefore. Logging a Defect New Defect Quality Center enables you to log defects at any stage of the testing process. building a test plan. each Quality Center module you work with provides a common tool for logging defects. Type the appropriate information to describe the defect. The NEW DEFECT dialog box appears. Defect-Test Relationship To ensure traceability throughout the testing process. Defect_01. 2. use the refreshed NEW DEFECT dialog box to type new information.•HISTORY tab: Provides an audit trail of changes made to each defect. To log another defect. which we created in the topic Defect-Requirement relationship. When a defect is associated with a test. you can also add attachments to a defect to provide further information about the defect. click CLOSE. the requirements covered by these tests are also automatically associated with their corresponding defects. defects can be associated with tests. it can be easily traced in all instances of the test. This is a direct link between a defect and a test. These test instances may be in the same test set or in different test sets. The NEW DEFECT dialog box may contain data fields and multiple tabbed pages that your Quality Center administrator may have custom-defined for your project. let us consider a test with the name Test_01. but is pending for 101 . which we had linked to R_01. or executing test runs. In the DEFECTS module. a test run. whenever an instance of this test is executed in any of the three test sets. For example. or a test step. Otherwise. For example. will now be associated with Test_01. To log a defect: 1. This means that the defect has been fixed by the development team. Additionally. Whether you are defining test requirements. click NEW DEFECT. Now there are three instances of Test_01 in three different test sets. Besides filling in the data fields in the NEW DEFECT dialog box. Let us assume that requirement R_01. Defect_01 will be indirectly linked to that particular test instance. A defect may be indirectly linked to a test through other entities. This association allows you to use the status of the defects as the basis for determining if and when the tests should be run. 3. you may decide to run a test only if the defect status is CLOSED. Therefore. The defect-test association has the following features: •Tests from the TEST PLAN module can be associated with defects that have been logged in the DEFECTS module.

A new menu appears that lists the types of reports available in the current module. 2. Select a test from the TEST PLAN tree. thus minimizing time required for re-work.your review. The REQUIREMENTS. TEST LAB. Navigate to the TEST PLAN module to view the TEST PLAN tree that opens on the left side of the screen. Generating a Report To generate a report: 1. 3. These graphs also 102 . You use these report and graph templates to retrieve the information you want to analyze. Type the appropriate information in the required fields and click SUBMIT to add the defect. click LINK EXISTING DEFECT. •Defects logged during a manual test run are automatically associated with that specific test run. 3. REPORTS. To add an existing defect to a test instance. This will ensure that a protocol is defined for communication between the development and testing teams. Quality Center Graph Types Quality Center graphs help you analyze the progress of your work. Adding Defects with a Test To associate a defect with a test: 1. Note: The MANUAL RUNNER TEST SET dialog box is used to log defects during a test run. You can type a Defect ID or click SELECT to select a defect from the DEFECTS grid. TEST PLAN. and DEFECTS modules of Quality Center provide predefined report and graph templates. •A test can be associated with multiple defects. Reporting and Analysis You can generate reports and graphs within each Quality Center module to track and assess the progress of your project at any stage in the testing process. The NEW DEFECT dialog box appears. From the menu bar. Navigate to the Quality Center module that has the data that you want to use for the report. After the report generation task is complete. Click the LINKED DEFECTS tab and click ADD AND LINK DEFECT. 4. the report output is displayed in the current window. 2. Click the report type you want to run. select ANALYSIS.

This graph type shows the history of changes to specific fields over a specific period. grouped by test coverage status. It summarizes the lifetime of all reported defects. It shows the total count of requirements. •DEFECTS AGE graphs: This graph type is specific to the DEFECTS module. •REQUIREMENTS COVERAGE graphs: This graph type is specific to the REQUIREMENTS module. TEST PLAN. and ends when it is closed. The following graph types are available in Quality Center: •SUMMARY graphs: Each Quality Center module provides summary graphs specific to the tasks that it supports. This graph type shows the accumulation of requirements. and DEFECTS modules provide trend graphs specific to the tasks they support. •PROGRESS graphs: Each Quality Center module provides progress graphs specific to the tasks that the module supports. •TREND graphs: The REQUIREMENTS. or defects that were defined throughout the testing process.help you analyze the relationships between the data that your project has accumulated throughout the testing process. The lifetime of a defect begins when it is reported. tests in TEST SETS. This graph type shows the total count of requirements. tests in TEST SETS. tests. or defects over a specific period. tests. 103 .

Sign up to vote on this title
UsefulNot useful