Contents

Philosophy of Quality What is Testing? Where Testing comes into picture? How we can perform Testing?

SDLC --- Initial --- Analysis --- Design ---- Coding --- Testing --- Test Case Testing Methodologies ----- 1. WBT Levels of Testing 1. Unit 2. Module 2. BBT 3. GBT

3. Integration Top Down Bottom Up

System level testing & User acceptance testing Environment --- 1. Stand alone 2. Client-server 3. Web 4. Distributed

Types of testing---smoke---sanity---regression---Re test--- --- ---static---dynamic---installation--compatibility---monkey---explorative---Usability---Mutation---Ad hoc Software Testing Life Cycle--- 1. Planning 2. Development 3. Execution 4. Result analysis 5. Reporting

Security Module, an example to go through STLC------severity-------priority-Bug Life Cycle--- StatusOpen/Newfixed for rectificationclosedreopenholdas per designtesters error Manual Testing Drawbacks Automated Testing advantages Quality Standards--Advantages

Terminology Defect Defective QA QC Audit Inspection Process violation NCR CAPA SCM MRM PPM

ISO 9000 Standards---Types---9000---9001---9002---9003---9004 SEI CMM levels----level1---level2---level3---level4---level5---CMMi---Benefits Six Sigma LevelsIntroprocessmath approachlife cyclegraphapplicabilityWhy 6sig

Testers Attitude & Characteristics Metrics Traceability Matrix Slippage Escalation Release Delivery SRN SDN Prototype Benchmark Judgment call review Review Report Peer Review Walk through Code Walk Through Code Optimization Version Build Work around Hard Coding Share Point Base Line Publish Deployment Document Change Request Impact Analysis Template Kick off Meeting Demonstrations QMS Priority Severity Change Control Version Control PPR

The operational overview of an automated tool ----- MS windows standards Overview on the tools tools table

Philosophy of Quality: Classical Def. of Quality: It is defined as conformance to the customers specifications. Or in other wards it is defined as the justification of all the requirements in the product. Defect: It is defined as a deviation from the requirement.

Latest Def. of Quality: It is defined as not only the presence of requirements or absence of the defects but also the presence of Value. To know what presence of Value is, take previous example again, in text box if u enter the value -5 then, message will appear as Invalid input. Now user enters his name, again he will get the same massage. So here TE must give an advice to developer that the message must be user friendly. This is the presence of value.
Contents

What is testing?
Testing: Testing is take place before the product is delivered to the customer. In order to know the actual def. of the testing we must know the following things. 1. Identification of defects: defects must be identified first in the product.

2. Isolating the defects: After identification defects must be listed. Isolation means
separation. Physical separation is done by the developer.

3. Subjected for rectification: This is the responsibility of the TE to send the list of
defects for rectification.

4. Ensure that the product is defect free: Ensure that the defects are really rectified
and the product is defect free. Actual def. of Testing: It is defined as the process in which the defects are Identified, isolated, subjected for rectification and ensure that the product is defect free in order to provide quality to it and hence customer satisfaction. Defect rectification this terminology is used by laymen where as Bug fixation is used by professionals. Error and Defect are different words. Error means mistakes that are associated with the program. Error is deviation from syntax of program where as Defect is deviation from requirements of the product.

In the process of developing project, where exactly testing comes in to picture?

In order to know the answer, we must know what SDLC (Software Development Life Cycle) is. Ok! Before going to learn about SDLC we must know some terminology. Project: Work with some objectives. Work has been created from need of customer. Client: Customer Package: Set of programs. Program: Set of sequence of instructions to get desired O/P. Now study the following example. Example: CEO of a bank want to automate (computerize) his bank. So he gave an advertisement in Newspaper. For response 4 software companies are reacted and come forward to handle the project. They gave their quotations as follows: Bank CEO

Project

A $100

B $80

C $60

D $45

Then CEO selects the best company and handover this project. Do u think this will be given to company D? No, it should be standard company (ISO). Once the project is signing off by the both CEOs, the first meeting takes place in the company among HLM (High Level Management), All members, Technical team, Quality team etc. This meeting is known as Kick off meeting. What will be discussed in this meeting? The overall views of project and customer expectations are discussed. PM (project manager), QL (Quality Lead), Team members etc are selected. There are two major leads, Development team and Quality team. Development team develops the product and quality team tests the quality of the product. Here Team Lead is known as PM. Once PM is selected, initiate the project and release Project Initiating Note. It is nothing but asking formal permission to start the project from CEO of the company.

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

In SDLC, the following phases have to study. 1. Initiation 2. Analysis 3. Design 4. Coding 5. Testing 6. Delivery & Maintenance In every phase of SDLC, four important things have to be discussed. For every phase there will be an out put in the form of Document. 1. Responsibilities or Objectives 2. Role 3. Process (Guide lines for the roles) 4. Documentation
Contents

1. Initial Phase:

1) Responsibility: Collecting all the specifications or requirements from the customer. i.e
requirement gathering.

2) Role: This job will be done by Business Analyst (BA) and Engagement Manager Assist BA.
BA deals with requirements and EM estimates excess cost for this project.

3) Process: BA must follow the guide lines, he should not follow his own style. These guide
lines are Quality standards like . a) Taking appointment before meeting with customer. b) What to talk what not to talk must be given. c) Work has to be done in consistent manner.

4) Documentation: While dealing with the CEO of Bank, BA must get the entire requirement
and note it down. And then this requirement must document. Once again BA must not follow his own style here, he must follow the pre format (Template) provided by the company. In this template all fields are pre defined, he must fill the requirements in that doc. Here the functionality of the requirement must be very clear. This document is known as BD/ BDD/ FRS/ BRS. * Always we must follow one document till Interview. Better follow BDD. Template: It is defined as a predefine format in which the fields are predefined for which the information can be given in preparing the document. BD: Business Document BDD: Business Design Document FRS: Functional Requirement Specification BRS: Business Requirement Specification

BDD

1 2 3 4 5 6

Initiation Analysis Design Coding Testing Delivery & Maintenance

Contents

In this Initial phase the out come is BDD. This BDD is analyzed in the next phase.

2. Analysis: In this phase the requirements in BDD are analyzed. a) Responsibility:

1. Analysis of requirements: Like implicit requirements and explicit

requirements. Explicit requirements mean req for which the testability is true. Implicit requirements mean req for which the testability is false. Ex: Take previous ex of Textbox. It take +ve integers, testing this box with 5, 56 ,128 .. is explicit req. Testing the box with -5, 5.555, A,B,C,@,#,% etc is implicit requirements. 2. Feasibility study: means the req is possible to implement or not. 3. Tentative planning: means rough planning of req to implement. 4. Technology selection: Which tech must be used for diff req like web PagesJAVA Tech, for documentation-MS Word etc. It analyzes what are system requirements.

b) Role: SA (System Analyst) c) Process: Guidelines will be given for analyst to follow. d) Documentation: In order to develop the product, the system requirements are
documented and send to design phase. This document is known as SRS (System Requirement Specifications). Technical requirements are incorporated here.

SRS

1 2 3 4 5 6

Initiation Analysis Design Coding Testing Delivery Maintenance

&
Contents

In this Analysis phase the out come is SRS. This SRS is designed in the next phase.

3. Design:
a) Responsibilities: Designing of the project. In this Design there are two levels HLD (High Level Design) and LLD (Low Level Design). HLD: It is the process in which, the total project is divided into several modules. This responsibility usually accomplished by Chief Architect (CA). LLD: It is the process in which the single module can be divided into sub modules and also the list of technical features that are associated with modules for design. This is usually done by Technical Leads (TL).

b) Role: HLD is done by CA and LLD is done by TL. c) Documentation: The document designed in this phase is called Technical
Design Document (TDD). This TDD contain: 1. Description of design 2. Sequence diagrams 3. Object diagrams 4. Action diagrams

10

5. Class diagrams 6. Component diagrams 7. Deploying diagrams etc.. There is another document called Functional Spec. This is functional specification document. It contains Pseudo Code. Pseudo code means code written in English statements for the different functions. For example, two test boxes aligned left one and right one. Put one add button at bottom. These two documents (TDD & Functional Spec) are coded in the next phase.

TDD & Functional Spec

1 2 3 4 5 6

Initiation Analysis Design Coding Testing Delivery Maintenance &

Contents

4. Coding:
a) Responsibility: In this phase programming is the responsibility. b) Role: Developer c) Process: Developer must follow some guide lines called Coding Standards Some of the Coding standards are: 1. Code space margin has to be left 2. Write comments at every program function so that readability enhanced. 3. Color coding etc

d) Documentation: All the coding files are documented in a document called

Program File or Source Code Document (SCD). 1 2 3 4 5 6 Initiation Analysis Design Coding Testing Delivery Maintenance

Program File or SCD

&
Contents

11

This program file or source code document is send to testing phase.

5. Testing:
a) Responsibility: Testing of the application b) Role: Test Engineer (TE) c) Process: How testing is done? To answer this question, understanding about application is very much important. And TE must follow the 5 important golden guidelines. 1. 2. 3. 4. Understand the functionality of the Application. To understand this application TE must review the BDD. Roughly the BDD contains 100 to 400 pages. Prepare review report. List out all the items for which clarifications are required. Send the review report to the author of the BDD (BA) and get the clarifications. Take the template for the test cases and prepare the Test Case Document. Ex: What do you mean by test cases? Take the previous Text Box example in which only +ve integers can be entered. This text Box is tested with following cases. 1. 5 2. -5 3. 5.555 4. A,B,C.. 5. @,#,$,& 6. empty

+ve Integer

Test cases

Contents

Test case: It is defined as the possibility, which provides an opportunity for us to check whether the applications feature works fine or not. In other words there are different cases, which are used for, different certain functionality hence they are known as test cases. Also these can be thought of various possible inputs in order to judge the application is behaving properly or not. 5. Execute the test cases in order to test the functionality of the Application. d) Documentation: Documentation in this phase is known as Defect Profile.

Defect Profile

1 2 3 4 5

Initiation Analysis Design Coding Testing

12

Delivery Maintenance

&

After testing the application is send to delivery phase. This is the review of the SDLC (Software Development Life Cycle). Now answer the previous question, where exactly testing comes? If this question arises in interview, in return you must ask that which type of testing do you expecting. Testing is of two types, Conventional testing and Unconventional testing. Conventional Testing: It is the testing after the coding. It is done by TE. Unconventional Testing: It is the testing right from initial phase through all the phases. It is done by QAL. Now we understand the difference between Project and Product. Project 1. Work in which requirements are coming from customer. 2. Project is delivered for specific person. 3. Ex: Web Pages, Home pages etc. How we can perform testing? To know how testing is performed, follow the example. Example: We all know about music competition. Who will be the judge in it? We know that he must have knowledge of music in order to judge whose performance is good. From this we can understand that expert is required to perform test. One should have exportation in that application. TE must be having proper understanding about application. What do you mean that understanding of application? In every application we can see two things, visible and invisible parts. Visible thing of application is functionality and invisible thing of application is program. So finally these two things can be written in a mathematical equation as follows, Application = Functional factor + Structural factor A=F+S both functional part and structural part. T(A) = T(F) + T(S) i.e test of application means test of functional factor and test of structural factor. TE must test
He will see first program and then functionality
Contents Contents

Product 1. Work in which requirements are coming from company. 2. Product is open to all. 3. Account Package etc.

What ever I can see that I can test. i.e GUI

TE

13

Functionality ( Functional part ) Structural ( Program part ) Programmer

From the above discussion we can understand that there are two testing methodologies.
Contents

Testing Methodologies:
Based on the different perceptions with which the testing is performed on the application, there are two basic testing methods involved. 1. Black Box Testing (BBT) 2. White Box Testing (WBT)

1. BBT: This is defined as the method of testing in which one can perform testing on an
application with much focus on functional part of it and ever without having an internal structural knowledge of application. Actually the Test Engineers are involved in the BBT.

2. WBT: This is defined as method of testing in which one can perform testing on an
application having internal structural knowledge of it. This is also known as Glass Box Testing.

This testing focuses on the structural part of an application and hence the Developers are involved in this type of testing.
Contents

Why Black & White box? Look at the glass box, now if this box is painted with Black then TE can see only the box but not boll. He can test it by shacking. If the black paint is removed then Programmer can see first boll, the structural part. That is why name Black box and White box. We know that the combination of black and white is grey. So we have another type of testing Grey Box Testing (GBT). GBT: It is another derived method of testing in which both the black box techniques and white box techniques are together used for testing an application usually a TE who has the knowledge of programming is involved in this type of testing. While this testing is done an application, the tester will be involve in BBT for some time and the WBT for some time. Black + White Grey

Those who involve in BBT will involve in GBT.

14

Contents

Levels of Testing:
There are some levels in testing the application. Level = sequence (systematic design) 1. Unit Testing 2. Module Testing 3. Integration Testing Unit Testing: It is first level of testing in which soon after the smallest unit is Developed. It will be tested for the desired output. Since testing is performed on this unit it is called unit testing. Unit testing is belongs to WBT and hence it is done by developer. Module Testing: Soon after the smallest units are build to form a module and we need to perform testing on this module to check for desired output for the given input. This testing is known as module testing. TE can perform module testing as the GUI is made available. Integration Testing: When the modules are developed individually and tested already, these modules are to be integrated with each other as per the designed document and testing has to be performed once they are integrated. This type of testing is known as integration testing. The purpose of integration testing: ensure the following, To check whether the individual output of the modules are not affected. To check the navigational flow as per designed document. To check the data flow among the modules as per the DFDs of TDDs.
Contents

It is performed on the application when the modules are integrated with each other to

Depending on the way the modules are getting integrated, there are basically two approaches in the integration. Top Down Approach and Bottom Up Approach.

1. Top Down Approach: In this approach as and when the child modules are developed

they keep getting integrated with the parent modules and also the direction of integration is from top to bottom (i.e. from parent module to child module) As these child modules are getting integrated with the parent module and if child module is missing, then integration process may get affected. In order to continue the integration process a temporary solution is employed in terms of stub to simulate the missing module. Once the child module is made ready the temporary solution is replaced with the actual module.

M1

M2 15

M3
TDA

M4

M5

Let us assume that Module-3 is not yet prepared, but we have to test rest all modules. In order to test M4 we required some input from M3. So we have to prepare temporary program to generate temporary input to M4. This is called STUB. STUB: It is defined as temporary program that replaces the missing module that is to be integrated with the other modules in order to simulate the desired output. Usually the stub comes into picture in Top Down Approach. Contents

2. Bottom Up Approach: In this approach the child modules are created first rather than
parent modules. Once these child modules are created and as these modules are to be integrated with parent modules, the integration flow will be from bottom to up words. Hence it is known as Bottom Up Approach. When child modules are integrated with parent module and if the parent module is missing, the integration is not possible and hence a temporary solution is employed in place of missing parent module in terms of driver.

M1

M2 M3

BUA

M4

M5

Let us assume that Module-3 is not yet prepared, but we have to test rest all modules. In order to test M2 we required some input from M3. So we have to prepare temporary program in M3 to generate temporary input to M2. This is called DRIVER. DRIVER: It is defined as a temporary program that replaces missing parent module in order to produce with integration successfully by producing the desired output on behalf of missing module. This temporary program is known as Driver.
Contents

System level Testing: This is the type of testing in which the application is deployed into certain client specific environment, it becomes a system altogether if one performs testing on the system considering all the simulated practical factors, it is known as system testing. (or)

16

System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of its individual components. Note: Before modules are being integrated, the programs are to be integrated first. Integration testing is white box testing and tested by developer. Developer develops an application and this application is deployed into the environment. After deployment the application is tested. It is done by test engineer. User Acceptance Testing: In this type of testing one can perform testing on an application when it is deployed into the environment in the presence of customer. Since this testing is performed for the acceptance of customer, it is known as User Acceptance Testing. Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria. Environment: There are 4 environments we can observe.
Contents

1. 2. 3. 4.

Stand alone environment: It is known as 1 tier Architecture. Client Server environment: It is known as 2 tiers Architecture. Web environment: It is known as 3 tiers Architecture. Distributed environment: It is known as n tiers Architecture.

Before going to discuss about types of environment, we must know what exactly mean by an application. Application is described as combination of the following factors.

1. 2. 3.

PL (Presentation Layer): The set of programs those are responsible for displaying the GUI part of an application, validating the user input and dynamic features of it. BL (Business Layer): These are vital programs, which are developed based on business tools and requirements of the customer and usually process the requirement of the client. DB (Data Base): Strictly speaking DB does not consider that the part of application and since it is being by the application during execution, the application has the DB has the big component. The business layer usually contacts DB for any vital information while process the requirement of client for giving the response. Application = PL + BL + DB

When User gives request through GUI, the process is done in server and if it require any vital information for process can be taken from Data Base Server.

DB Presentation GUI Server where process done

Contents

Let us now discuss about different environments.

17

1. Stand-alone environment: As it is known as 1 tier environment, it has one machine

where all PL, BL and DB are placed. EX: Our PC is best example for this type of environment.

PL + BL + DB Draw Back: We cannot share the data. Multiple users are not allowed. There may be possible for duplication. In order to over come this drawbacks we required another machine to keep data. That is exactly where we are going to 2 tiers architecture.
Contents

2. Client Server Environment: This is 2 tiers architecture where the PL, BL and DB PL + BL

divided between 2 machines. It facilitates multiple users and does not allow duplication. We can share the data. DB

PL + BL

Client-1

PL + BL

Client-2

Client-3
In this environment both presentation layer and business layer together placed in the same machine and DBS (data base server) is placed in another system. Draw back: In order to change BL, we have to go for all clients. So to overcome this we have to separate the BL from client.

3. Web Environment: This is also known as 3 tiers architecture where PL, BL and DB are
placed in three different machines BL

PL

Server (App. / web)

Client

DB

Draw back: As business logic grows, server gets loaded. So it must be shared with other machines.
Contents

18

4. Distributed environment: This is also known as n tier architecture where BL is

distributed among the machines. Generally RMI, EJB, J2EE stands in this environment. Application Server / Web server

PL

BL

BL

BL DB

Client
Client Types of Testing: Client Client
Contents

1. Smoke Testing 2. Sanity Testing 3. Regression Testing 4. Re Testing 5. Testing 6. Testing 7. Static Testing 8. Dynamic Testing 9. Installation Testing 10.Compatibility Testing 11.Monkey Testing 12.Explorative Testing 13.Usability Testing 14.Mutation Testing 15.Adhoc Testing

Contents

1. Smoke Testing: It is a type of testing in which initial overall testing is conducted on an

application in order to check whether all the functionalities are available. Note: No detailed testing is conducted. Quick overview testing must be conducted. For example all the web pages of an application are available or not tested in the smoke testing. Why name smoke testing? Generally PCBs (Printed Circuit Boards) are tested after manufacturing by connecting a pair of terminals to power supply and other pair of terminals to the CRO (Cathode Ray Oscilloscope). It is used to test the O/P signal. But manufacturers conduct an initial test before going to connect to the CRO. In this initial test a pair of terminals is connected to power supply left it for some time to test the smoke. Hence this testing is called Smoke Test. Then this term is used in all fields for initial testing. Power Supply PCB

2. Sanity Testing: It is a type of testing in which an initial overall testing is conducted on an

application just to check whether the applications behavior is proper or not. In other words is it usable or not from the point of end user. Sanity = proper (Sane: proper, insane : improper)

19

What is the difference between Smoke testing and Sanity testing? Practically both tests are same but perceptually they are different. For example there should be a add button in web page, TE testing the application; his thinking is that there may not be add button in that page. If the button is there he will disappoint. This is Smoke testing where as in Sanity testing he will think that the add button will be there. If it is there he will satisfy.
Contents

3. Regression Testing: It is a type of testing in which one can perform testing on certain
functionality of an application which is already tested before to make sure that the existing functionality remains un effected, when ever a change is added to it. Hence this testing focuses on existing functionality rather than the new addition. In regression testing, the existing functionality is rechecked and the newly added function is tested first time.

4. Re Testing: It is the type of testing in which a functionality which is already tested

before is once again tested just ensure that the defects are reproducible if at all any and to rule out the environmental issues. In this testing no newly added function.

5. testing: It is a type of user acceptance testing that is conducted on an application

with in the company just before it is released to the customer. Hence it is a final testing that is conducted on the application before the delivery.

6. Testing: It is also a type of user acceptance testing that is conducted on an

application when it is delivered to the customer, when it is deployed to the real time environment and when it is being used by real time users. Hence it is first test conducted on an application in the client place. The advantage of testing is if at all any defects encountered, those defects can be instantly rectified before the delivery on the other hand in testing there is no chance for these to rectify immediately and it takes time to follow. For conducting testing there will be a separate third party testers known as testers are available for working on the application on behalf of customer.
Contents

7. Static Testing: It is a type of testing in which one can perform testing on an application
when it is not being executed. Ex: GUI testing, Document testing (Unconventional testing)

8. Dynamic Testing: It is a type of testing in which one can perform testing on an

application when it is being executed. Ex: Functionality testing of an application.

9. Installation Testing: It is a type of testing in which the TE tries to deploy the module
into the test environment and check if the deployment is successful with the guidelines followed in the deployment Document. Deployment Document: It is basically a document with guidelines to the TE or the person who deploys in order to guide him to deploy the released module successfully into the specified environment. Either project manager or team leads prepare the deployment document. This document is sent to the testing team along with the module that is released for testing. TE can raise the defects in the deployment document.

20

Contents

10. Compatibility Testing: This is a type of testing in which usually the products are tested
on several environments that are created as test environments with various combinations of the environmental components like Browsers, Data bases, Application servers etc. to check whether the products are compatible with these environments.

11. Monkey Testing: It is a type of testing in which one can perform abnormal, more
volumes of data related, beyond capacity operations intentionally on an application just to check whether the application is stable in spite of the users abnormal behavior.

12. Exploratory Testing: It is a type of testing in which one can perform testing on an

application without knowing the functionality and without even any kind of document to make sure the application functions properly. In this testing the TE will come to know the functionality after he performs testing.
Contents

13. Usability Testing: It is a type of testing in which the TE chicks whether the product is

user-friendly at the time of usage. Every product should have the usability apart from the functionality. If the usability is missing, user-friendliness is obviously missing and consequently the quality is missing. As it is the key factor, we need the check the usability for the product.

14. Mutation Testing: It is a type of testing in which the program patterns are changed and
the corresponding outputs are checked. Depends on the O/P for the corresponding changes the program is tested and if required the program is corrected.

15. Adhoc Testing: It is a type of informal testing in which one can perform testing on an

application without using test case document. Unlike formal testing in order to cover the uncovered areas of test case document. One can assume that the testing can be completed once the formal testing and adhoc testing are completed on the product.
Contents

In formal testing TE may miss some functionality, which is not written in TCD. Adhoc = informal

Software Testing Life Cycle (STLC)

Important Phases in STLC: 1. 2. 3. 4. 5. 6. Test planning Test Development Test Execution Result Analysis Bug Tracking Reporting

Test Planning: It is defined as the strategic document, which explains the overall procedure of how to test an application in an effective, efficient and in an optimized way. In this a) b) c) d) test planning we have to learn 4 important things, What is the meaning of test planning? What are the contents of the Test planning? What is the input document for the Test planning? Who make this test planning?

21

a) Test Planning: Already we learned that the test planning is the strategic document,
which explains the overall procedure of how to test an application in an effective, efficient and in an optimized way.

b) The test planning contains the following information. 1. Test objective and the test scope: Test objective means the aim of the testing

of the different functionalities. We must know up to what extent we have test the application. For example a project may have to release in two phases and first we have to release Phase-1 in time. Here the scope of planning is up to Phase-1 and need not plan Phase-1 in this time.

2. What to test in the application? Here we must know the area of functionalities
that has to be tested.

3. What not to test? Here we must know that functionalities under not in the scope
need not to test.

4. Resource Planning: Assigning the functionalities of different modules to different

test engineers.

5. Scheduling: Allotment of timings to different TEs for different modules. 6. Areas of the functionalities to be automated: If an application need to test
again and again, then the automation is necessary for that application. Remember, Automation is not replacement for manual testing.

7. Evaluation of the automated tools: Basically what are the tests of an

application, based on this automated tools must be selected.

8. Test strategy: All the levels of testing must be done. To do this every company
has its own rules in test planning.

9. Testing terminology: Every Company has its own testing terminology. So TE

must follow that terminology. For example the designed document one company may call it as BDD and other company may call it as FRS, BRS and so on.

10. The defect metrics and the terms: Defects of testing must be measured. 11. Bug reporting process: Defects must be reported after testing. c) Input document for test planning: Project plane is the input document for Test
planning. Project plan is done by project manager.

d) Who makes this Test planning? Quality lead makes test planning.

Contents

Test Development: In test case development we have to prepare two things, test case document preparation and test procedure preparation.

1. Test Case Document Preparation: Take the template for the test cases and prepare the
test case document to test the application.

2. Test Procedure Preparation: The detailed description of the test case document is

known as Test Procedure. In other words it is a brief description that explains how the

22

feature of an application is tested in terms of GUI testing, positive testing and negative testing using the appropriate GUI test cases, positive test cases and negative test cases respectively. Test cases can be classified into two types; valid input test cases and Invalid input test cases. Test Execution: In the execution of test cases we have to observe three things.

1. Implementation of test cases: It is a phase in which the test cases which are prepared
in the previous phase will be implemented on the application.

2. Observe the behavior: As the test cases are implemented the response of the 3.
application is observed. Recording the behavior: Not only observing the behavior but also records the responses of the application as it is.

Result Analysis: Before going to define the result analysis we must learn about expected value and actual value.
Contents

Expected Value: It is defined as the expected behavior of an application. Executed values are always by the requirements. In other words expected values are extracted from the functional requirements. Actual Value: It is defined as the actual behavior of an application. In other words it defines the behavior actually exercised by the application depends on the corresponding program designed. Result analysis: It is a process of analysis in which the test result is concluded. The test results are expressed either in pass or fail. This process of analysis is associated with the comparison between the expected value and actual value. When they are compared, if they are matched the result will be pass else the result will be fail. Bug Tracking: It is a phase in which all the defects are listed in separate document known as Defect profile. All the failed test cases are considered to defects as they deviating from the expected values and in turn the requirements. Reporting: In this phase the defect profile document that is prepared in bug tracking phase will be reported to the counter part that is development team in order to rectify those defects. Also a separate reporting document is prepared in such way that the status and the stability of the functionality is described with a pictorial representation just to send to the high level management to let them know the status. This document can also be reported to the client if and only required.
Contents Contents

Security Module, an example to go through the STLC Authentication: Only valid user can allow to particular page when login. Security module: It is an example we have to test the following functionality of User Name, Password, and GUI etc. User Name Password

23

Login

Cancel

1. Test Planning: Let us assume that BDD has reviewed and test plan is prepared by QL. 2. Test Development: In the first part of this phase we have to prepare a Test case
document (TCD). Following TCD shows all the fields of document. T.C NO: 1 2 3 4 5 6 7 UN UN PW PW EV EV Description UN PW Expected value Actual value Result P P P P F F P Sever ity Priori ty Refere nce

= Enter valid user name into user name text box. = Enter invalid user name into user name text box. = Enter valid password into PW field and click on login button. = Enter invalid password into PW field and click on login button. = System allow the user to go to home page successfully. = System should not allow to go to home page.

In the second part of test development, we will see about test procedure. The above screen is planned to test in such way that the testing must be performed on the screen in terms of GUI testing, +ve testing and -ve testing with the help of GUI test cases, +ve test cases and ve test cases respectively.

3. Test Execution: In this phase, all the test cases from the above document will be

implemented observe the behavior of the application and record the observed behavior of the application. Here we will write the Actual Values of corresponding test cases.

AV AV

= System not allowed the user to go to home page successfully. = System should allowed to go to home page.

4. Result Analysis: In this phase, we will compare the Expected value with the Actual
value. If the EV is matched with AV, then the result is pass else the result is fail.

5. Bug Tracking: In this we will prepare a document called Defect profile with all defect
cases from the test case document. Following is the Defect profile containing different fields. Defec t Desc. A Sub -mitt er Raju Date of sub. 2/5/5 Mod nam e Secu rity mod ule Ver No: 1.0 Buil d No: 5.0 Sev erit y Fatal Prio rity High Assig n to Fill by PM St at us TC Ref No: 5

Defec t ID 1

24

A = For right user name and empty password system doesnt allow the user to the home page but actually it allowed. PM = project manager Version: It is defined as instance of the functionality. If the new functionality is added, then it becomes another version. Hence initially it is Ver #1.0 then it becomes another Ver #2.0 Build No: In the process of rectification and testing. As and went the module is refined, the module with the same version will be sent to testing departments in terms of several releases, each release is expressed in terms of build. Hence there could be several builds under one version. Assigned to: It is filled by PM with appropriate names of the developer who involved in developing these functionalities in which the defect is present. TC Reference No: It is the reference information, which helps to refer the corresponding test case, just to indicate the defect has been raised while that specific TC was been executed.
Contents

Severity: It is defined as the expression, which indicates how serious the defect is, if at all any defect that is present in the application. Severity is classified into 4 categories depends on seriousness 1. 2. 3. 4. FATAL MAJOR MINOR SUGESTION

1. FATAL defects: It is a degree of expression of severity whenever the defect is

encountered due to the navigational blockage. In other words if any functionality is missing or if any screen is blocked while navigation, this is considered to be very serious defect. Such types of defects are known as fatal defects. Ex: (1). 404 page is not found error. (2). 500 internal server error etc.

2. MAJOR: If at all the defects are related to mall functionalities i.e. if the functionality is not
as per the requirements, such types of defects are known as major defects. Ex: wrong calculations etc.

3. MINOR: If at all the defects that are related to look and feel i.e. GUI part of an
application, such defects are known as Minor defects. These are also known as cosmetic defects. Ex: Alignment Issues, Consistency issues, spell mistakes etc.

4. SUGGESTION: Strictly speaking its not a defect. It is a note to the developer by TE to

enhance the existing feature or to modify and also to incorporate certain features in order to add value to the application. As initially developers neglect these suggestions, it is responsibility of TE to see that the raised suggestion is incorporated in the application, if it is a valid suggestion.
Contents

Priority: It is a process in which the sequence is defined for the rectification procedure of various defects. In other words it tells us what defect has to take first, next and last for the process of rectification. Priority is classified in to 4 categories. 1. CRITICAL ----------- Fatal

25

2. HIGH ------------------ major 3. MEDIUM ------------- minor 4. LOW ------------------ suggestion Depending on the scope and deadlines, fatal may give low priority. Note: By default the priorities for fatal, major, minor, suggestion are critical, high, medium, and low respectively. But depends on situation like scope, deadlines and customer urgencies, the priorities can be customized. Ex: Fatal defects can be prioritized low if that defect belongs to the functionality, which is out of scope. And the suggestions are consider to be critical, if they are related to the functionalities which are in the scope of testing are, if it is more emphasized by the customer and wants them to be delivered immediately.

Bug Life Cycle (BLC)

Hold No As per design Testers Error

R Is it really Defect Yes

Dev. Team

M1

Ver# 1 B# 1 B# 2

Rectification

Testing

Fixed For Verification

Open/Ne w

Yes

If No Defect

STO P

Reope n

Is STOP 26

Yes

Defect really Rectified

No
Contents

STATUS: It is defined as an expression that conveys message to the reader that explains what state the defect is present right now. The advantage of status column in defect profile is to reduce explicit communication among the team members and let them know the status of the defect optimizing cost, ensuring productivity for the role involved. Status of Bugs: 1. 2. 3. 4. 5. 6. 7. open/new fixed for rectification closed reopen hold as per design testers error

Note: Tester is the responsible for birth and death of the bug. In BLC, when requirements(R) are set for module-1, developers write all the functionalities of the module-1(M1) and release for testing as version-1and since it is first time release for testing, releases as build-1. After testing TE raises all possible defects and writes status as open/new in defect profile. After seeing this status as open/new, any testing professional can easily understand that it is first time-encountered defect. These defects are sending to development team for rectification. After receiving defect profile, first developer validates whether they are really defects or not and rectifies the defects if any. After rectification develop changes the status of the defect as fixed for rectification and sends for testing as build-2. TE receives this module second time after reification for testing. TE must immediately verify whether the defects really rectified or not. If it is not rectified by any chance, TE raises the defects once again and writes the status now as reopen in the defect profile. This defect profile once again sends to the development team for rectification. If at all the defect is really rectified then the status is given as Closed
Contents

Once again after receiving this defect profile developer verifies whether they are really defects or not. By any chance, if there is no defect found then the developer can write the status as either Hold or As per design or Testers error. By chance in the BDD, if any functionality kept for <tbd>(to be discussed) like for calculation of commission per sales amount. At present the customer not yet decided whether the commission is 10% or 15%. But after reviewing the BDD test cases are written as assuming 10% by TE. In development programmer assumed it as 15%. So in testing normally defects arises and send for rectification. But in development it is not defect so keeps the status as Hold. Here another situation that the module-1 is ready for testing tomorrow and it is in the development chamber. Test case document also prepared. Suddenly by evening after leaving the testing team, a mail came for development team describing that addition of new functionalities immediately. So developers added new functionalities to the module-1 and set ready for testing.

27

By the next morning while testing the module-1 defects are raised and sent for rectification by TE. As usually the developers validates the defects whether they are really defects. As they know that module-1 is changed, write the status As per design. While reviewing the BDD, TE may misunderstand the functionality and may write the wrong test cases. In testing the module defects may arise and send for rectification. In development if they found that they are not really defects, write the status as Testers error. Manual & Automation Testing
Contents

Manual Testing: It is defined as the way of testing in which all the phase of STLC like, Test plane, Test document, Test execution, result analysis, Bug tracking and Reporting are accomplished with manual effort. Drawbacks of Manual Testing: 1. More people are required. 2. More tedious. (Tiresome, As repeating thing get tired) 3. More time is consumed. 4. Cant be repeated so easily. 5. Concurrency is missing. (i.e. all the users cannot give request at the same instant of time) Solution: Automation is the solution for the drawbacks of manual testing. Automation: computerized (speed & accuracy) Automation: It is another type of testing in which all the drawbacks of manual testing are affectively addresses and nullified and provides speed and accuracy for existing system. Note: Automation cant be replaced by manual testing. Advantages of Automation: 1. V-users can be used in automation in order to reduce the requirement of the people. 2. Software components are used in automation so that no tiredness in repeating works. 3. Speed reduces time consumption. 4. Recording machines are used in automation tools so that repeatability is so easy. 5. Rendezvous is provided in automation to get concurrence. Disadvantages of Automation: 1. Expertization is required in order to operate the tool to perform automation testing. 2. Automated tools are quite expensive (win runner costs nearly 30 lakhs) 3. If automation is not planned properly, it consumes multiples of Manual testing time. 4. Limitations of the features limit the automation of the application to be tested. What 1. 2. 3. are the areas to be tested with automation? When there is repeatability automation can be applied there. Ex: regression testing. Automation can be applied for GUI testing. Automation is used if at all the testing has to be repeated with various samples of documents. (Parameter, data driven testing) 4. In the case of load testing when all the users are supposed to send the queries simultaneously to the server. (Load testing, performance testing) Quality standards Quality standards are defined as the guidelines for an organization in order to accomplish each and every task i.e. happening in the organization in the most affective, efficient and in an optimized way so that the quality production is ensured in order to produce customer satisfaction. Adhoc Procedure:
Contents Contents

28

On the other hand some companies follow their own procedures to ensure the quality of the product. If the company fallows their own procedures, these procedures are known as adhoc procedures. Adhoc procedures may ensure quality or may not. It is always advisable to follow some quality standards or the other in order to ensure quality to the product as it is proven guidelines. There are 3 types of Quality standards: 1. ISO International Standards Organization 2. CMM Capability Maturity Model 3. Six Sigma International Standard Organization (ISO) Brief Description about ISO: Formally it is known as International Organization for Standards In ISO: 9001:2000, 9001 indicates quality number or serial number which speaks type of work takes place 2000 indicates the year of certification or indicates what type activity or services Originated from European standards As British people ruled all most all over the world, they wanted quality product, so they have given some standards Origination of ISO standards are due to following 1. European government established a healthy competition among the companies to produce quality products. Hence these companies were given initially some conditions to follow and get the quality products. These conditions eventually have become ISO standards. 2. The government started importing the quality products to the European market. Types of ISO standards: Depends on the different types of activities ISO standards are classified into 5 different types as given below. Hence each type speaks about the specific activity followed in the company. 1. ISO: 9000 2. ISO: 9001 3. ISO: 9002 4. ISO: 9003 Contents 5. ISO: 9004 ISO: 9000 -: These standards provide overall guidelines for an organization especially when they are in the stage of startup, to keep them in the systematic pace initially. These guidelines may not be detailed guidelines and these will be list of conditions which preciously given the guidance if not detailed. These are used to stabilize the company. ISO: 9001 -: It defines minimum quality system requirements for design/development, production, installation and servicing. It is the most complete standard. It applies to manufacturing and service businesses engaged in all these activities. It discusses how to meet customer needs effectively. This is the only implementation for which third-party auditors may grant certifications. The latest version is: 2000. ISO: 9002 -: It applies only to production and installation activities. ISO 9002 is nearly identical to 9001, except it does not incorporate design and development. ISO: 9003 -: It is intended for organizations whose processes are almost exclusive to inspection and testing of final products. ISO: 9004 -: It is a guideline for quality system elements. It is like a textbook, which describes, explains and recommends. It covers performance improvements. This gives you advice on what you should (or could) do to achieve ISO 9001 compliance and customer satisfaction.
Contents Contents

Capability Maturity Model (CMM)

29

Brief Description about CMM: Back in the early 1990s, the software industry's shortfalls began coming into view. Too many projects were being delivered extremely late, over budget, and with too many failures and flaws in the final products. The Software Engineering Institute (SEI) at Carnegie Mellon University stepped up to the plate and developed the Capability Maturity Model (CMM) as a way to capture the process elements, practices, and artifacts necessary during a product's software development lifecycle. CMM was not extremely detailed, and in some ways it seemed like common sensethe only problem was hardly anyone performed all the basic tasks CMM outlined. One of CMM's biggest criticisms is that it tends to push companies toward a process model similar to the waterfall software development model, which the majority of the software industry recognizes as too rigid for real success. CMM does not specify any particular process model. But it does dictate guidance on how to measure the maturity of your process, as well as outline certain Key Process Areas (KPAs) that it deems necessary for achieving different maturity levels. CMM grew and expanded from software process management to other technical arenas, including system engineering and workforce management. According to SEI, there are totally 1970 organizations in the world has assessed with CMM and more than 50 percent of these organizations are from USA and their off shore development centers.
Contents

CMM defines 5 maturity levels: 1. Level Initial 2. Level Repeatable 3. Level Defined 4. Level Managed 5. Level Optimized

For each level, CMM outlines certain KPAs along with the process artifacts required for that KPA to be certified at each level. The KPAs include areas such as requirements management, quality assurance, configuration management, training, and peer reviews. Level1 Initial: At the initial level, the software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics. Level2 Repeatable: Organizations at repeatable level (Level 2) have established management processes to track cost; schedule, and functionality, and earlier success on projects can be repeated with similar applications.
Contents

The key process areas at Level 2 focus on the software project's concerns related to establishing basic project management controls. These processes include Requirements

30

Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, and Software Configuration Management. Level3 Defined: When comes up to the defined level (Level 3), a standard software process for the organization is formed by documenting, standardizing, and integrating both management and engineering activities. Level 3 goes beyond project management by including both project and organizational issues, as the organization establishes an infrastructure that institutionalizes effective software engineering and management processes across all projects. They are Organization Process Focus, Organization Process Definition, Training Program, Integrated Software Management, Software Product Engineering, Intergroup Coordination, and Peer Reviews. Level4 Managed: Software development process at managed level (Level 4) collects detailed measures of the software process and product quality to quantitatively understand and control the process and procedure. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are Quantitative Process Management and Software Quality Management.
Contents

Level5 Optimized: The highest level, which is optimizing, contains continuous process improvement enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement. They are Defect Prevention, Technology Change Management, and Process Change Management. Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process. As an organization moves up on this five-level ladder, it incorporates the key processes at the corresponding level and becomes more mature in its information development process. CMM standards have the sequential role in terms of various levels. It is mostly used for software organizations. For evaluation it has the process of assessment and not certification. After these 5 levels, CMMi is the grade where i-stands for integration. Here hardware has integrated with software. CMMi machine is a high quality machine. WIPRO is a CMMi company.

31

Climb The Maturity Model

Contents

Benefits of CMM: There is now substantial evidence of the business benefits of CMM-based software and a growing understanding of the factors that contribute to a successful improvement effort. In the past years, SEI and others have conducted numerous empirical studies of organizations using CMM. The most broadly supported claim is that CMM-based SPI has substantial business benefits for those moving from the initial through the defined levels. Extensive studies have showed that organizations implementing CMM have achieved tremendous benefits in terms of productivity, calendar time, quality, and business value. Six Sigma: Introduction About six sigma process Mathematical approach Six sigma life cycle Graph analysis Applicability in software

Introduction: Six Sigma stands for Six Standard Deviations (Sigma is the Greek letter used to represent standard deviation in statistics) from mean. Six Sigma methodology provides the techniques and tools to improve the capability and reduce the defects in any process.

32

Contents

It was started in Motorola, in its manufacturing division, where millions of parts are made using the same process repeatedly. Eventually Six Sigma evolved and applied to other nonmanufacturing processes. Today you can apply Six Sigma to many fields such as Services, Medical and Insurance Procedures, Call Centers. Six Sigma methodologies improve any existing business process by constantly reviewing and re-tuning the process. To achieve this, Six Sigma uses a methodology known as DMAIC (Define opportunities, Measure performance, Analyze opportunity, Improve performance, Control performance). Six Sigma incorporates the basic principles and techniques used in Business, Statistics, and Engineering. These three form the core elements of Six Sigma. Six Sigma improves the process performance, decreases variation and maintains consistent quality of the process output. This leads to defect reduction and improvement in profits, product quality and customer satisfaction. Six Sigma methodologies are also used in many Business Process Management initiatives these days. These Business Process Management initiatives are not necessarily related to manufacturing. Many of the BPM's that uses Six Sigma in todays world include call centers, customer support, supply chain management and project management.
Contents

Six Sigma Process: This process is associated with, 1. Repetitive multiple cycles of production. 2. It is basically graph oriented process implementation A Six Sigma Engineer develops efficient and cost effective processes to improve the quality and reduce the number of defects per million parts in a Manufacturing/Production environment. Six Sigma Engineers determine and fine tune-manufacturing process. Once a process is improved, they go back and re-tune the process and reduce the defects. This cycle is continued till they reach 3.4 or less defects per million parts. Six Sigma is all about knowledge sharing. If a company has more than one manufacturing unit/plant, its more than likely that one of the plants produces better quality than others. The Six Sigma team should visit this higher quality plant and learn why its performing better than others and implement the techniques learned across all other units.
Contents

Mathematical Approach: For every cycle in the above process, mean and standard deviations are calculated based on production by using the following formulae.

Mean = (x + x + x + x + ..) / no. of x SD (sigma ) =

( xi x )2 N

33

Six sigma Life Cycle: It has the following 5 different phases. These phases are defined by an example. In this a company must be produce 100 pens with in the length range of 4 to 5

1. Define
2. 3. 4. 5. Measure Analyze Improve Verify

Contents

1. Define: In this phase the targets of the production are defined as per the requirements

and allow the system to produce the production. From the above example, the target of the pens is that the lengths must be in the range of 4 to 5.

2. Measure: This is the phase in which the product is measured whether the targets are
achieved by the product. Let us assume that some pens are produced and measured. Out of these pens some are with in the range and some are out of range that is deviating from the target requirement.

3. Analysis: This is the phase in which root cause analysis is done on the product, why it is
deviated from the target requirement. Here in this phase, why some pens are deviated from the requirement is analyzed. Wrong process is traced out and tries to eliminate in the next phase.

4. Improvements: In this phase wrong process is eliminated and ensures the process is
refined one with which better results are expected in future. Here the wrong process is eliminated and the process is refined until getting better results that is to meet the requirements.

5. Verify: In this process one has to look for that improvement in the latest production
whether it is really reflected in it as the previous process is refined. In this stage the product is verified whether it is really refined one or not. Like this refining and refining produce the pens.
Contents

34

Contents

Graphical analysis: So where to stop this process of refining? The answer probably requires graphical representation. Here in this case average and SD (standard deviation) in each phase is measured and tabulated. Now the average values are taken on x-axis and SD values are taken on y-axis as 1, 2, 3, .as shown below.

1 0.8 0.6 0.4 b

Average

0.2 0 1 2 3 4 5 6 7

6 units 8 9

SD

From the above graph it is clear that the process of refining must be stopped when the graph stretches up to 6 units. Hence it is Six Sigma.
Contents

35

Applicability in Software: Six Sigma methodologies can also be used to create a brand new business process from ground up using DFSS (Design For Six Sigma) principles. Six Sigma Strives for perfection. It allows for only 3.4 defects per million opportunities for each product or service transaction. Six Sigma relies heavily on statistical techniques to reduce defects and measure quality. Six Sigma experts (Green Belts and Black Belts) evaluate a business process and determine ways to improve upon the existing process. Six Sigma experts can also design a brand new business process using DFSS (Design For Six Sigma) principles. Typically its easier to define a new process with DFSS principles than refining an existing process to reduce the defects. Why it is six sigma?
Contents

In this process of six sigma implementation a graph is developed and that graph is drives the process and will intimate to stop the production when it is span over 6 units on sigma axis when the quality is nearly assisted as 99.73%. Since it is spanned over sigma axis it is known as Six Sigma. What 1. 2. 3. 4. 5. 6. are the advantages of Quality standards? Transparence is increased. Discipline is increased. Customer satisfaction is increased. Customer complaints are reduced. Reengineering is reduced. Every stage get optimized*

Optimization: It is a process in which the inputs are reduced in the system and there by maintaining either the same level of outputs or even more.

Test engineers characters

Following are the test engineers characters:

Contents

1. Quality oriented mind setup: involvement in work 2. Test-to-break attitude: 3. Tactful & Diplomatic behavior: tactful means to be wise, Diplomatic means something
related to your work.

4. Good communication & Drafting skills: Comm. Skills are important for convey your
ideas in systematic manner. Drafting means writing, what your writing it must be very clear.

5. If programming knowledge, it is plus but it is not mandatory. If we have knowledge

in programming, we can give a hint to the developer about defect.

6. Creativity is required: A writing test case is creative work. Contents 7. Judgment skills: (1) judgment call means be initiative (2) severity/priority judgment, he
must be able to judge how important that particular functionality.

Terminology: 1. Defect: Defect products usually have the non-conformance with the functionality, working
properly. Hence customer can use defect products.

36

2. Defective: The requirements are not justified in this product; hence there is non-

conformance while the functionality does not work. Hence these products cannot be used.

3. Quality Assurance (QA): It is the process in which a chick will be conducted on the

roles, responsibilities just to make sure that these responsibilities accomplished as per guidelines. In other words, it is a monetary system, which ensures proper accomplishment of the task to get the quality output in the end. QA engineer is involved in this process. QA engineer will be with the roles right from beginning to the end in almost all the phases of SDLC.

4. Quality Control (QC): It is the process in which inspections and audits are conducted on
the departments, roles and responsibilities just to segregate bad process from the good.

5. Inspections: It is the process of checking that is conducted on departments, roles and

responsibilities with out prior intimation. In this process QC professionals may be asking for several details, inspection of several documents regarding to work done by the role.

6. Audits: It is the process of checking conducted on the departments, roles and

responsibilities with the prior intimation well in advance. During the process of audits the roles are ready with the relevant documents and QC people verify these documents. Audits are basically of two types, internal audits and external audits.
Terminology

Once the audits are conducted, corresponding reports are generated and submitted to the high level management as audit reports for the review.

7. Process Violation: It is the act of not following the guidelines. This is given in terms of
the process for the roles.

8. Non-Conformance Raised (NCR): It is a kind of penalty for the role if at all he does not
follow the process. 9. Corrective Action & Preventive Action (CAPA): Corrective Action: It is a process in which if at all any damage happens to the process (Process violation) that will be rectified to ensure that the process is flow less. Preventive Action: If at all any mistake happens with respective to the process, they try to rectify this. In case it is not reparable the roles consider for the process oriented training to educate them not to repeat such mistakes in future. This activity is known as Preventive action.
Terminology

10. Software Configuration Management (SCM): SCM take care of change management.
It is of two types, (1) Change control and (2) Version control. Change Control: It is the process in which all the relevant documents are updated as per new updating happens to the actual product to make sure that there documents are in synch with the product at any point of time. Version Control: It is a system, which takes care of the nomenclature (naming convention) and version numbers in order to refer to the documents and identify them uniquely with appropriate name and version number.

37

11. Management Representative Meetings (MRM): These are intended to discuss the
status of the company precisely. They also had known as company updates. The following points are discussed in the meeting,
Terminology

The growth rate of the company Projects in the pipelines and projects just finished Customers appraisal about the project/product released Customers complaints about the project/product Internal issues like HR related and technical related Internal audit reports Individual achievements for the duration The present status of the all the projects currently being developed

12. Periodic Project Meeting (PPM): It is the meeting conducted periodically in order to
discuss the status of the project. In this meeting the team members that are associated with the project are participated. The following points are discussed in the meeting, The status of the project in terms of percentage covered and percentage not covered. In case of testing, the testing details like the total number of defects and the Defect metrics Slippages that are associated with defects (defect slippages) Technical related issues faced by the team HR related issues faced by the team Individual effort estimations with the task slippages if any Never-ever meeting conducted combine to developers and test engineers.
Terminology

13. Periodic Project Report (PPR): It is basically a document prepared by either QL or the
PM for their corresponding periodic meeting in which the status of the project is detailed.

14. Metrics: It is the system, which helps quantifying the information that is generated to
provide the clarity over the task. Hence it is defined as quantifying the objective criteria that keeps the information in statistical information.

15. Traceability Matrix: It is a process in which if at all any ambiguous or controversial

situation occurs with respect to any functionality. Always the role must depend himself by showing the proof in all the relevant documents for that the reference for that functionality must be present in all the relevant documents. Hence it is known as cross reference matrix.

16. Slippage: It is defined as the extra time that is consumed beyond the plan time. Usually
it is a positive integer. Mathematically Slippage = Actual time Plan time.

38

17. Escalation: It is the process in which the slippage information will be intimated in terms
of issue to the high-level management well in advance to let them know about it and interfere into the matter to solve that issue immediately.

18. Release: It is the process in which developers send the modules to the testing for them
to be tested.
Terminology

19. Delivery: It is the process in which the module is sent from the testing team to the
customer after it is been tested and certified.

20. Software Release Note (SRN): It is basically a document prepared by project

manager and he sent to the testing department along with the module that is released. It contains known issues and the useful information regarding the module that is released.

21. Software Delivery Note (SDN): It is also basically a document prepared by quality
lead and he sent from the testing department to the customer along with the module that is delivered. It contains known issues and useful information about the module that is delivered.

22. Prototype: It is defined as the rapidly developed model for a project in the beginning of
the project developed itself to demonstrate it to the customer to win the confidence of him so that he may feel that this how the project look like. Usually prototypes are even providing with complete functionality, as there is a risk of the customer to cancel certain functionalities.

23. Benchmark: It is model against which things are compared and conclude the results. 24. Judgment call:

Terminology

25. Review: It is the process in which either studies or the verification is done on the
documents usually.

26. Review Report: It is basically a document prepared by reviewer that contains either the
list of items for which clarifications are required or the review comments (Dos Donts suggestions) depends on the type of review conduct on the document.

27. Peer Review: It is the process of review in which the documents are exchanged by the
authors for review, in order to make sure that the documents are prepared perfectly.

28. Walk through: It is a process of a kind of review in which we can either know
something new or we can verify to conclude the perfection.

29. Code Walk Through: It is a process in which the source code document is verified for
the coding standards whether they have been prepared perfect.

39

30. Code Optimization (Fine tuning): It is a process in which the number of lines of code
and the complexity of the code are tremendously decreased in order to increase the performance. Since it is tuned for the best performance this process is also known as finetuning.
Terminology

31. Version: It is defined as instance of the functionality. If a new function is added to

previous function then it becomes another version. Hence initially it will be ver#1 later on it become ver#2. An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item.

32. Build: In the process of rectification and testing, as and went the module is refined, the
module with the same version will be sent to testing departments in terms of several releases, each release is expressed in terms of the build. Hence there could be several builds under one version.
Terminology

33. Work around: It is defined as an alternating solution that is temporarily employed to

see that the word is not struck and keep going without any difficulty.

34. Hard Coding: If at all the constant values present in the program, which are used
temporarily in the work around, are not removed, the dynamic nature of the application is affected. This is because of the constant nature of the program due to the constant values. TEs must consider these types of issues as fatal and take the responsibility to rectify the issue as soon as possible in the application.

35. Share Point: It is basically a server, which acts as a consumer repository that can
accommodate information that is shared by several roles with in an organization. This share point not only used as a storage place but also has the facility of version control system.

36. Base Line: It is the process in which the documents are finalized after the author
completes preparing the document. This process is also known as freezing of document.

37. Publish: This process is always is used in conjunction with baseline. in this process the
base line documents are made available to all the relevant roles for their further usage. Usually share point displays the list of documents among which the baseline documents are differentiated with the specific icon.

38. Deployment Document: This is basically a document in which guidelines are provided
to the test engineer at the time of deploying the module into environment.
Terminology

39. Change Request: It is the process in which customers send the proposed changes in
terms of requirements to the development team in order to incorporate them in the project in a formal procedure.

40

40. Impact Analysis: It is the process of analysis in which project manager evaluate the
impact that will be created on the already constructed parts of the project, in case the change is proposed by the customer at that stage.

41. Template: It is defined as a predefined format in which the fields are predefined for
which the information can be given in preparing the document.

42. Kick off meeting: It is the first meeting conducted in the company after signing off the
project. In this High-level management, all HOOs, technical team and quality lead will present to discuss about overall view of the project and customer expectations. Team lead (Project Manager) is also being selected in this meeting.

43. Demonstrations: Demos is the short form of the demonstrations and it is the process
in which the functionality will be displayed to the customer or representatives of the customer. Hence it is a process of display.
Terminology

44. Quality Management System (QMS): It is nothing but the source of guidelines for
almost all the activities takes place in an organization. These are basically made available to all the roles in terms of QPs (Quality Procedures) or QMs (Quality Manuals).

45. Priority: It is a process in which the sequence is defined for the rectification procedure
of various defects. In other words it tells us what defect has to be first next and last for the process of rectification.

46. Severity: It is defined as the expression, which indicates how serious the defect is if at
all any defect that, is present in the application.
Terminology

The operational over view of an automated tool Here training of a dog is compared with the tool as follows, Dog 1. Let the dog see the boll 2. Let the dog smell the boll and touch it. 3. Teach the dog how to do the work. Tool 1. The tool should focus the AUT 2. Learning The tool learns (captures) the properties of the object of AUT. 3. The tool records the operations of the user and generate the corresponding test script (programming statements) 4. Execute/run the test script in order to emulate the operations and testing task.
Contents

4. Run command is given to bring the boll

MS windows Standards: 1. All the objects in the window must be neatly aligned

41

2. No overlaps among the objects 3. Every window must have OK & Cancel button 4. Every label must start with a Capital letter 5. Every window must have minimum menus & options 6. Consistence must be maintained although the application
Contents

Tool Table:
S.No 1 Tool Name Win Runner Test Director Company Mercury interactive Inc (USA) -DoObjective 1. GUI testing 2. Client-server web application testing 3. DB testing 1. To manage the testing process. 2. To report the test results 1. To perform load testing 2. To perform a performance testing 3. To perform stress testing 1. GUI testing 2. Client-server web Application testing 3. DB testing 4. AS-400 & mainframes application testing 5. SAP-ERP testing 6. CRM application testing 7. .net application testing 1. Java application testing 2. web application testing 3. GUI testing 1. GUI testing 2. Functional testing Type of tool Functional tool Management (or) Reporting tool

Contents

Script language TSL (Test Script Language)

-NoGUI v-user script

Load Runner

-Do-

Performance tool

DB v-user script RTE v-user script

QTP

-Do-

Functional tool

VB script

Silk Test

Segue Inc (USA) SQA Inc + Rational Rose

Functional tool Functional tool

4 test key

SQA suit

SQA basic or VB script

Some of the important note from the above table: v-user: Virtual user RTE : Remote Terminal Emulators (non GUI application) QTP: Quick Test Professional AS-400: Degree of computer, here PC is low degree and super computers are high degree, AS-400 come after PC and mainframes comes after AS-400 ERP: Enterprise Resource Plane.

42

CRM: Customer Resource Management WR, Test Director, LR and QTP collectively called Mercury Interactive suit

TOP

43