Project: It is something that is developed based on the customers specification and used by that particular customer Product: It is something

that is developed by the manufacturers specifications and used by multiple customers and customized according to the specifications What is Quality? Justification of requirements either in a product or in a project; Quality: Classical definition Quality is not defined in the product or in the project but defined in the customers mind. Latest definition of Quality: Not only justification of requirements but presence of value (user friendliness) Defect: Deviating from the requirement Testing: It is process of identifying the defects, isolating the defects, subjecting the defects for rectification and ensures that the product is defect free in order to produce a

quality product at the end; And hence customer satisfaction. Bidding of the Project: It is defined as request for proposal, estimation and signing off. Kick off meeting: It is the initial meeting conducted in the SW company soon after the project is signed off in order to discuss the overview of the project, and to select a project manager. PIN: Project Initiation Note It is mail prepared by the project manager and sent to the CEO of the SW company in order to get the permission to start the project development. SDLC Phases: Phase 1: Initial or requirements phase Roles: Business Analyst and Engagement Manager Task of the Business Analyst: Takes an appointment from the customer, collects the template from the SW company, meets the customer on the appointment

date and time, interacts with the customer using the template and converts the template as document and submits the same to the SW company to make sure that they both are on the same page. Task of the Engagement Manager: Responsible for following: 1) Deals with the excess cost of the project 2) Responsible for the prototype demonstration: Prototype is a roughly and rapidly developed model. Output document or proof document from Initial Phase is called FRS or functional Requirement Specification. It is also called as BRS or Business Requirement Specification or URS user requirement specification or CRS client requirement specification or BDD Business Design Document or BD business document. Phase 2: Analysis phase: Input document for this phase is FRS Roles: 1) System Analyst, 2) Project Manager and 3) Team Manager Tasks: 1) Feasibility study:

A detailed study of the requirements in order to check if they are feasible or not; 2) Tentative planning: The resource as well as the time is temporarily planned here; 3) Technology selection: What are all the technologies that are required for accomplishing this project successfully are analyzed and listed off. 4) Requirement Analysis: What are all the requirements that are required to accomplish the project successfully are analyzed and listed out. Proof document or Output document from Analysis phase is SRS (Software requirement specification or System requirement specification) Phase 3: Designing phase Input document for this phase is SRS. Roles: Chief Architect and Technical Lead Tasks: High Level Designing (HLD): The process of dividing the project into modules is known as HLD usually performed by Chief Architect. Low Level Designing (LLD):

The process of dividing the modules into sub modules is known as LLD usually performed by the Technical Lead. Output document or Proof document from designing phase is TDD technical Design document. It contains of some diagrams and pseudo code Phase 4 Coding phase: Input document for this phase is TDD. Roles: Programmers or developers Tasks: Programming or Development Process: Developers using the pseudo code and following the coding standards like proper indentation, proper commenting and colour coding etc. develops the actual source code of the project. Output document or proof document from the coding Phase is SCD source code document. Phase 5: testing phase Input document is FRS functional Requirement specification

Roles: Test Engineers Task: Testing Process: FRS review. Prepares the review report; in doubt sends to the author of the document for clarification; after understanding all the requirements clearly, takes the test case template and develop the test cases. Once the build or module is released then executes the test cases. After the execution: Identifies the defects and isolate the defects. Subject the defects to the developers for rectification. Ensures that the product is defect free If any defects are identified, the same process continue till the product is defect free Output or proof of testing phase is Quality Product or the Product which is working as per the customers expectation.

Test CASE definition: This is a check list of all the deferent perceptions of a test Engineer in order to test a specific functionality. Phase 6: Release and maintenance Release: Roles: Deployment engineer or Senior Test Engineer Tasks: Deploying or installation Process: The deployment engineer will deploy the application into the client environment following the guidelines given in the Deployment document by the development team. Maintenance: After release if at all any problem is there with the SW then that problem will become a task depending upon that problem the corresponding role will be

appointed and he defines the process based of the issue and resolves the issue.
There are 2 sorts of testing. 1. Unconventional It is a sort of testing which is conducted on each and every out come document right from the initial stage onwards by the Quality Assurance people 2. Conventional It is also known as formal testing performed by the test engineers. Testing Methodology or Testing Techniques: White box Testing: If one performs testing on the structural part of the application then it is known as WBT usually developers perform it. Black Box Testing: If one performs testing on the functional part of the application with out having structural knowledge then that method of testing is known as BBT. Usually test engineers perform it. Gray Box Testing: If one performs testing on both functional as well as structural part of an application then that method of testing is known as GBT. Usually the test engineers with structural knowledge perform GBT.

Levels of Testing: Unit level: Smallest part of an application. One performs testing of a unit is called Unit level testing. It is performed by the developers as this is structural and called WBT. Module level: Collection of units is module. So a module will have some functionality and BBT is the method used due to it functionality feature. Integration Level: Once the modules are all ready, then the developers will try to integrate the modules and perform testing to make sure that the modules are integrated properly or not. This is a WBT. Integration of modules can be done 4 approaches; 1. Top Down Approach (TDA) In this approach the parent modules are integrated with the sub modules. STUB: While integrating the modules in TDA, if any mandatory module is missing that module is replaced with a temporary program know as STUB. 2. Bottom Up Approach (BUA)

In this approach the sub modules are integrated with the parent modules. Driver: While integrating the modules in BUA, if at all any mandatory module is missing that module is replaced with a temporary program known as Driver. 3. High breed or Sandwich approach This approach is the mixer of TDA and BUA. 4. Big Bang Approach (BBA) Once all the modules are ready integrating them at a time is known as BBA. System Level Testing: Once the application is ready, it is deployed into an environment and is prepared as a system. If one performs testing on the system then it is known as system level testing and it is a BBT User acceptance Testing: If one performs same system testing in the presence of the user, then it is known as user acceptance testing. It is also BBT. Environment: An environment is a combination of 3 layers 1) 2) Presentation Layer Business or application layer

3)

Database layer

Types of environments: There are 4 types of environments JayaQA\SDLC methods.ppt 1) stand alone environment or 1 tier architecture: If the 3 layers i.e. presentation, business or application and database layer resides in a single system, then it is known as stand alone environment. 2) Client server or 2 tier Architecture: If at all the presentation and business layers reside in the client system and database layer resides in the server system then it is known as 2 tier architecture or client server environment 3) Web Environment or 3 tier Architecture:

It contains 3 tiers where in the first tier contains Presentation or clients, the second or the middle contains the application server and the third tier contains the database server. 4) N tier architecture or distributed environment or multi tier architecture: Which is similar to the web environment but the business logic is distributed among a

number of application servers in order to distribute the load.

Software Development Life cycles Models: SW development Life cycle Models 1) Water fall or sequential model or Linear model 2) Prototyping model 3) Evolutionary model or the fickle minded 4) Spiral model 5) Fish model 6) V model

Software efficiency formula: DRE = A/ A+B DRE = Defect Removal Efficiency A = Defects found by the Test engineer B= defects found by the end user or the client. Types of Testing: 1) sanity testing or smoke testing or Build verification testing or initial testing (look and feel) 2) regression testing: In which already tested functionality is tested again mainly in 2 scenarios. A) When ever the defects are rectified by the developer and the next build is released to the testing department then the test Engineer will perform testing not only on the defects part but also on the related functionality once again. B) When ever the new changes are incorporated by the developer and released

to the testing department then the Test Engineer will perform testing on the old tested part once again in order to ensure that its old functionality is not affected due to the new changes. 3) Retesting In which already tested functionalities, tested once again with multiple sets of data in order to ensure whether the functionality is working fine or not. If any defect, whether it is reproducible or not? Alpha testing: It is a type of user Acceptance Testing UAT. A test engineer performs testing on an application in the presence of the user within the company. The advantage is if any defects are found then there is a chance for rectifying immediately. Beta Testing: It is a type of UAT conducted in the clients place either by the 3rd party testing units or by the end users. The disadvantage here is, if any defects are found then there is no chance for rectifying immediately. Usability Testing: It is a type of testing in which a test engineer will only focus on the user friendliness of the application. Static Testing:

One performs testing on the application or application related factors whenever it is not being executed. Ex: document testing and GUI testing. Dynamic Testing: If at all one performs testing on an application when ever it is being executed then that type of testing is known as Dynamic testing. Ex: functionality testing Installation Testing: A test engineer will deploy or installs the application into the environment following the guidelines given by the development team in the form of deployment document. If the installation is successful then he will come to a conclusion that the guidelines are correct. Compatibility Testing: A test Engineer may have to deploy the application into the environments prepared with different environmental components like browsers, application servers, web servers, Operating systems and databases and check whether the application is compatible with those environments. Port Testing: One will deploy the application into the client environment and check whether it is compatible with that environment or not.

Monkey Testing: It is type of stress testing in which one will perform abnormal actions on the application intentionally in order to check its stability. Exploratory Testing: Usually one will be exploring the functionality and simultaneously testing the functionality. Usually domain experts will perform it. Security Testing: Authentication Testing: In this type of testing, the test engineer will check if the application is accessed by the authorized person or not Direct URL Testing: Test Engineer will enter direct URL into the address bar of the browser and try to access those pages to make sure that they are not accessible with out proper authentication. Firewall leakage Testing: A test engineer will check weather the implemented firewalls are working properly or having any leakage. Soak Testing: It is also a type of stress testing. Test Engineer will perform testing on the application for longer period of times and checks weather the application is stable or not.

Mutation Testing: WBT It is a WBT performed by the developers where in he will do some complex changes and checks the performance of it. Since it is associated with different mutants (Logic) it is known as mutation testing. End to End Testing: In which performs testing on one complete transaction from one end to the other end of the application. ADHOC Testing: A test engineer will understand the requirements and performs testing on the application in his own style with out following any formal procedure or norms. SOFTWARE TESTING LIFE CYCLE: STLC 1. Test planning: This describes how to perform testing on an application in an effective, efficient and in an optimized way. Quality lead or test lead will prepare the test plan. INDEX or Contents of the TEST PLAN: 1.0 Introduction 1.1 1.2 Objective reference documents

2.0 2.1 2.2

Coverage of testing features to be tested Features not to be tested

3.0 Test strategies 3.1 Levels of testing 3.2 Types of testing 3.3 Test designed techniques (BVA) boundary Value partition (ECP) Equal class partition 3.4 Configuration management 3.5 Test metrics 3.6 Terminologies 3.7 Automation plan 3.8 List of automated tools 4.0 Base criteria 4.1 acceptance criteria 4.2 suspension criteria

5.0 Test Deliverables 6.0 Test environment 7.0 Resources planning

8.0 Scheduling 9.0 Staffing and training 10.0 11.0 12.0

2.

Risks and contingency plan Assumptions Approval information

TEST DEVELOPMENT: Use case: It describes the functionality of certain features of an application in terms of actor, action and response.

Input information required to prepare the USE CASE document a) Screen shot or snap shot b) FRS or functional requirements specification c) BRS or Business requirement specification or Special requirement specification d) Use case template a) Name b) Brief description of the Use Case c) Actors involved d) Special requirement, Explicit (FRS) and implicit requirements (business people) e) Precondition f)Post condition and

g) Flow of events. (Main flow) (Alternative flow)

MAIN FLOW: RESPONSE Log in screen is displayed with the following fields: User Name/password/connected to/Login/clear/cancel 2) Actor enters valid User Authenticates either home name, valid pw and click page or Admin page is on Login button displayed depending the Actor entered 3) Actor enters valid user Authenticates either home name and valid pw and page or Admin page is selects a database options displayed with the and clicks on login button mentioned database connection. 4) Actor enters invalid Go to Alternative flow Table username, Valid PW and 1 clicks on login button 5) Actor enters valid Go to Alternative flow Table username, in Valid PW 2 and clicks on login button 6) Actor enters some Go to Alternative flow Table information into any of 3 the fields and clicks on clear button 7) Actor clicks on cancel Go to Alternative flow Table button 4 ALTERNATIVE FLOW: ACTION 1) Actor invokes the application

Table 1 (invalid Username): ACTION RESPONSE Actor enters invalid An error message should username, Valid PW and be displayed invalid user clicks on login button name. Please try again Table 2 (Invalid PW) ACTION Actor enters invalid PW, Valid Username and clicks on login button Table 3 (Clear Click) ACTION Actor enters some information into any of the fields and clicks on clear button Table 4 (Cancel click) ACTION Actor clicks on cancel button RESPONSE An error message should be displayed invalid PW. Please try again RESPONSE All the fields should be cleared and the cursor should be placed inUser name field.

RESPONSE Login screen should be closed.

GUIDELINES TO PREPARE TEST CASES FROM A GIVEN USE CASE: Security: Identify the module to which the USECASE belongs to (Security module) Authentication: Identify the functionality of the UC with respect to the total functionality of the application. Identify the functional points and prepare the functional point documents.

Functional Point examples: 1) user name 2) passwords 3) connect to 4) login 5) clear 6) cancel Identify the inputs that are required to perform the UC (use case) EX: Valid and invalid inputs Identify the actors involved in the use case. Ex: Admin user and normal user Identify if the use case is linked with any other use case EX: home page or Admin page Identify the precondition: Ex: login screen or the initial screen should be available Identify the post condition: EX: for valid users valid page and error message for invalid users. Understand the Main Flow of the use case The Main Flow indicates the main purpose of the application and the remaining all comes under Alternative Flow. Document the Test Cases for the Main Flow Document the Test Cases for the Alternative Flow

Prepare the Cross reference matrix or traceability matrix This table is useful for tracing the exact location of the defect. And it also useful for to check for all the requirements of the customer are covered by the developers. CROSS REFERENCE MATRIX OR TRACEABILITY MATRIX TABLE USD (user FPD MTCD DTCD specification Functional Master Test Detailed Document) Point Case Test Case Document Document Document 3.5 13 12 8 This document explains the number of test cases that can be developed on a particular functionality.

DPD Defect Profile Document 1

Classification of the TEST CASES: Types of Test Cases: Test cases are broadly divided into 2 types User Interface Test Case: Guidelines:

Check for the application. Check for the Check for the Check for the

availability of all the objects in the alignment font, color and consistency spelling and grammar

Functional Test Case: Divided in to 2 types a) Positive: Test Engineer should have positive perception Considers only the positive flow of the application by using the valid inputs b) Negative: Test Engineer should have negative perception to consider only the negative flow of the application by using invalid inputs TEST CASE TEMPLATE: 1) Test case Objective 2) Test scenario 3) Test procedure 4) Test Data 5) Test Case

Test Case ID

Test Case Type

LOG_001 User

Description Expected Actual Value (expression Value must be (must use the commanding) word should) Check for the All the objects All the objects

Result

Remarks

Pass

None

Inter Face UI LOG_002 UI

availability of all the objects Check Spellings of all the objects Check consistency of all the Objects Check enabled property of LOG IN and CLEAE, CANCEL buttons Enter the User Name and PW as per the Valid Inputs Table and click on Login button Enter some information into any of the fields and click on Clear button

LOG_003 UI

should be available as per the objects table. All the objects should be spelled as per the Objects Table All the objects should be consistent LOG IN and CLEAR buttons should be disabled and CANCEL button must be always enabled. Correspondin g pages should be displayed as per the valid inputs table All the fields should be cleared and cursor should be placed in the user name field Login screen should be closed Correspondin g Error messages should be displayed as per the invalid inputs table.

are available as per the objects table All the objects are spelled as per the objects table All the objects are consistent Log in, clear, cancel buttons are enabled Pass None

Pass

None

LOG_004 UI

Failed

Log in and clear buttons are enabled

LOG_005 Positive Test Case

Correspondin g pages are displayed as per the Valid inputs table All the fields are clear but the cursor is not default into User name field

Pass

LOG_06

Positive

Failed

Tab action is not defaulting to the User Name field after clear.

LOG_07 LOG_08

Positive

Click Cancel Button

Log in screen is closed Correspondin g error messages are not displayed as per the invalid inputs table. Refer to Invalid

Pass Failed

Negative Enter USER NAME and Pass word as per the invalid inputs table and click on LOG IN

button

Inputs table for details

Objects Table: Serial Number 1 2 3 4 5 6 Valid Inputs Table: S.NO 1 2 3 User Name Sai Ram Alla Password Prema Love Akbar Expected Value Admin page should be displayed Home page displayed Sales Page Actual Value Admin Page is displayed Home page is displayed Sales page is displayed Result Pass Pass Pass Object Type Text Box Text Box Combo/drop down box Button Button Button Object Name User Name Pass Word Connect to Log in Clear Cancel

Invalid Inputs Table: S.NO User Password Expected Value Name 1 Kjkdjkj Prema Error message should be displayed. Invalid user name. Please try again 2 Sai Nidfje Error message should be displayed. Invalid PW. Please try again

Actual Value Home page is displayed

Result Fail

Error message is displayed invalid password please try again

Pass

3. Test Execution Phase:

In this phase, test engineer has to do the following things: 1) Perform the action that is described in the description column of the Test Case document. 2) Observes the actual behavior of the application 3) Documents the observed value under actual value column of the Test Case Document 4) Result Analysis Phase: In this Phase the test engineer will compare the actual values with the expected values. If both are matched then it is decided that the result is pass other wise the result is Fail. 5) Bug tracking Phase: In bug tracking phase, the defects are identified, isolated and documented and the documents must be maintained for next testing. Defect Profile Document:

Defe ct ID

Inde x num ber like a prim ary Key

Defect Steps Descrip for tion reprod ucibilit y Defect Instru scenari ctions o to reprod uce the defect

Sub mitt er

Date of Sub miss ion

Build Versi Assig num on ned ber num to ber

Seve rity

Prior Stat ity us

Severity: This describes how sever the defect is. It is classified in to 4 types. 1) Fatal: If the defects are related to navigational blocks, or unavailability of functionality then such types of defects are treated to be FATAL. 1) Major: If the defects are related with the major functionalities working then such types or defects are treated to be MAJOR. 2) Minor: If the defects are related to the look and feel of the application then such types of defects are treated to be MINOR. 3) Suggestion: This is not considered as defect. But if the test engineer wants to give a suggestion to a developer in order to increase the value of the application then such types are called SUGGESTIONS. Priority: This describes the sequence in which the defects have to be rectified. Usually it is given by the senior Test Engineer or Test Lead and can be changed by the

project lead according to his convenience depending on the situation. Priorities are classified in to 4 types: 1) Critical: Usually critical is given to FATAL. 2) High: This is given to MAJOR 3) Medium: This is given to MINOR 4) Low: This is given to SUGGESTION But depending upon the situation the priority may be changed. STATUS: There are 7 Status steps for a DEFECT 1) New or OPEN Initially when ever the defect is identified by the Test Engineer newly, then he will set the status as NEW or OPEN 2) RE OPEN: If the Test Engineer feels that the raised defect is not rectified properly by the developer then he will set the status as RE OPEN. 3) CLOSED: When the Test Engineer feels that the raised defect is rectified properly then the Test Engineer will set the Status as CLOSED. 4) FIXED FOR VERIFICATION: When ever the raised defect is accepted and rectified by the developer, then he will set the STATUS as FIXED FOR VERIFICATION. 5) HOLD: When ever the Developer is in a dilemma to accept or reject the defect then he will status to HOLD. Note: a triage meeting is conducted to resolve these HOLD status defects. Team lead, corresponding developer and Test Engineer are involved in the Triage meeting.

6) AS PER DESIGNE: When the new changes are incorporated by the developer into the build, and the test engineer is not aware of the updates, then he will raise them as defects. But the developer will set the status AS PER DESIGNE. 7) TESTERS ERROR: If the Developer feels that it is not at all a defect then he will set the status of the defect as TESTERS ERROR. Note: Testers errors are kind of warnings for the testers.
6) REPORTING PHASE:

CHECK THE DIAGRAM

WAYS OF TESTING:

There are 2 ways of testing: 1) Manual Testing: It is a process in which all the phases of the testing life Cycle (STLC) Like test planning, test development, test execution, Result Analysis, bug tracking and Reporting are accomplished manually with human efforts. Draw backs of Manual Testing: More number of people are required (Man power) Time consuming Human Errors Tediousness Repetitiveness Simultaneous actions not possible 2) Automation Testing: This is a process in which all the drawbacks of manual testing are addressed properly and provide speed and accuracy to the existing testing process. Advantages of Automation: Virtual users over come the man power issues As it is a SW component, Time, Tediousness, accuracy are overcome Record and Playback facility addresses the repetitiveness Rendezvous point feature over comes the simultaneous action problem Drawbacks of Automation: Cost efficiency

Expertise person not available to use the application Can not automate all the areas in a project EX: GUI
---The End-------