CAinc Introduction_to_Testing.ppt

8/10/2019 CAinc Introduction_to_Testing.ppt

1/52

Welcome to ConsultAdd Inc

TestingTraining


2/52

Goal

To learn about...Software Development Life Cycle Software Testing

Software Testing Terminology Roles and Responsibilities of a QA Tester Test PlanTest Cases

Defect Reporting and TrackingOther Test Documents


3/52

Software Development Life Cycle

Initiate the ProjectDefine the SystemDesign the SystemBuild the SystemTest the SystemDeploy the System

Support the System


4/52


Initiate the ProjectThe users identify their BusinessRequirements.

Define the SystemThe marketing people of the Softwaredevelopment team, take requirements fromthe users. During the requirements phase theproblem to be solved is clearly defined. Thebusiness requirements are translated intosystem specifications and put together intoSystem Specification Document.


5/52


The following list suggests the informationthat should be recorded in therequirements.

Program functions (what the programmust do)The form, format, data types and unitsfor inputThe form, format, data types and unitsfor outputHow exceptions, errors and deviationsmust be handled


6/52


Design the SystemThe System Architecture Team design thesystem and write Functional Design Document.

During design phase general solutions arehypothesized and data and process structuresare organized.

Build the SystemThe system specification and designdocuments are given to the development andtest teams. The development team code themodules by following the Requirements andDesign document.


7/52


Test the SystemThe Test Team develops the test plan followingthe requirements. The software is build and

installed on the test platform after developershave completed development and Unit Testing.The testers test the software by following theTest Plan.

Deploy the SystemAfter User Acceptance Testing and certificationof the software, it is installed on the productionplatform. Demos and training are given to theusers.


8/52


Support the SystemAfter the software is in production, themaintenance phase of the life begins. At this

point, the two teams (Development and Test)resume their individual roles: the DevelopmentTeam works with the development documentstaff to modify and enhance the application;the Test Team works with the test

documentation staff to verify and validate thechanges and enhancement to the applicationsoftware.


9/52

Introduction to Software Testing

Software TestingTesting a software is just like testinganything else. The idea is to find outwhether the software does what is issupposed to do. Once the testers knowwhat the software is supposed to do,they would do anything and everything

to see if there is any error or any partof the software that doesnt work asstated in the Requirement Document.


10/52

Why to Test the Software

Software development companies usually developsoftware for others. The clients spend millions ofdollars for developing a software. If a softwaredevelopment company produces a software thatgives the end user a lot of trouble then that clientcompany would think twice to ask the samecompany to develop any more software for them.When someone forms a software developmentcompany, the company tries to do everything sothat clients come back for more quality software.Since the companies want to stay in the business,they would do everything to make sure that thesoftware is error free.


11/52


The only way of getting more business is toproduce quality software which is dependable anderror free. The only way to produce error freesoftware is to test the software spending as much

time as possible.All software products contain defects/bugs,despite the best efforts of their developmentteams. It is important for an outside party (onewho is not developer) to test the product from aviewpoint that is more objective andrepresentative of the product user.


12/52


Programmers are too close the their product, andhave certain assumptions about them. Inparticular, the programmers may havemisinterpreted the specifications for the product,and some of those specifications will not berealized unless the product is tested by anindependent party.The testers test the software from therequirements point of view or what is required bythe user. Testers job is to examine a programand see if it does what it is supposed to do andalso see what it does not what it is not supposedto do.


13/52

QC Vs QA

QC is anabbreviation forQuality Control.

Quality ControlTeam makes surethat theapplication meets

the requirementsas per thedocuments.Finds out the

problems and

QA is anabbreviation forQuality Assurance.

Quality Assurancegroup focuses onthe overall processfor achieving the

better quality ofthe product.Works oneliminating the

reasons behind the


14/52

Phases of Testing

There are several phases of testing forsoftware products:

Unit Testing

Integration TestingSystem TestingUser Acceptance Testing


15/52

Phases of Testing

Unit TestingUnit Testing is performed by the developers.Unit Testing is also called as Module Testing.

During Unit Testing, a developer tests a singlemodule.

Integration TestingIntegration Testing is performed by thedevelopers or testers. During IntegrationTesting the modules are integrated togetherand end-to-end testing is performed. Also theinterface between the modules is tested.


16/52

Phases of Testing

System TestingAfter the completion of the Integration Testing,product is handled over to the System Testing

Team. In System Testing the features andrequirements of the product as described inthe Requirement Document are tested. Onlyafter the System Test Team determines thatthe product meets a predetermined quality

level, should the product be signed off andsend for System Integration Testing.


17/52

Phases of Testing

System Integration TestingAfter the completion of System Testing,product is handled over to the System

Integration testing team. In systemintegration testing the compatibility of theproduct with other applications is tested. Onlyafter the System Integration Test Teamdetermines that the product meets a

predetermined quality level and has nocompatibility issues, should the product bereleased.


18/52

Phases of Testing

User Acceptance TestingIt is also called as Beta Testing. Once SystemTesting is done and the system seems stable

to the developers and testers, systemengineers usually invite the end users of thesoftware to see if they like the software. If theusers like the software the way it is thensoftware will be delivered to the user after

passing through the System IntegrationTesting. Otherwise necessary changes will bemade to the software and software will passthrough all phases of testing again.


19/52

System Testing

System Testing encompasses a wide variety ofareas that should be tested.

FEATURES

Functional TestingThe product should be tested against theRequirement Document to ensure that theproduct conforms with what was specified.Testing should also be performed against thedocumentation for the product.


20/52

System Testing

Limit (Boundary) TestingSystem limits should be tested at and aroundtheir boundaries, both for input and output.

This should be done not only for data valueranges, but also for size of input/output.

Storage TestingStorage specification should be tested todetermine whether the storage system cansuccessfully accommodate required amounts ofdata .


21/52

System Testing

INDUSTRIAL STRENGTH Performance Testing

Timings for both read and update transactionsshould be gathered to determine whethersystem functions are being performed in anacceptable timeframe. This should be donestand-alone and then in a multi-userenvironment to determine the transaction

throughput.


22/52

System Testing

Volume TestingLarge volumes of data should be fed to thesystem to determine if it can correctly process

such amounts. Systems can often respondunpredictably when large volume causes filesto overflow and need extensions.

Stress TestingLoads that result from large number ofsimultaneous users, transactions and/ordevices, are needed to test the system todetermine whether it can handle peak usageperiods. Throughput and system stabilityshould be monitored.


23/52

System Testing

Recovery TestingA system should be tested to see how itresponds to errors and abnormal conditions,

such as system crash, loss of device,communications, or power.

Reliability/Availability TestingThis testing is concerned with issues such asmean-time-to failure, and usually requiresextensive testing over long periods of time.

Security TestingThe system should be secure fromunauthorized use and unauthorized data

access.


24/52

System Testing

ENVIRONMENT Installation Testing

The tester should install the system to

determine whether the installation process isviable. The installation document must befollowed in order to determine its accuracy.

Configuration Testing

The system should be tested to determinewhether it works correctly with the appropriatehardware and software configurations.


25/52

System Testing

Compatibility TestingThe system should be tested to determinewhether it is compatible with other systems

that it needs to interface with.USABILITY Error Testing

The system should exit gracefully upon an

error and leave its environment in apredictable and reasonable state. Appropriateand understandable messages should begenerated.


26/52


27/52

Regression Testing

Imagine finding an error, fixing it andthen re-testing it.Regression Testing refers to executing astandard series of tests to make sure thatthe change did not disturb anything else.Sometime fixing a problem causes a newproblem in some part of the application,which had no problems before.Automation Tools are useful for theRegression Testing.


28/52

Positive Vs Negative Testing

Positive Testingmeans testing theapplication to

validate thatapplication isdoing what it issupposed to do.

Negative Testingmeans testing theapplication to

validate thatapplication is notdoing somethingwhat it is not

supposed to do.


29/52

Required Product Knowledge forTesting

For Unit and Integration testing, detailedknowledge of modules internals is required.Developers must consider their algorithms, datastructures and how these are actuallyimplemented in code. Such testing is generallyreferred to as White Box Testing (or Glass -BoxTesting or Logic Driven Testing). Since SystemTesting is performed by personnel outside thedevelopment team, such intimate knowledge ofthe product will not exist. In fact, during SystemTesting, the focus is generally on the productspecifications. System Testing generally referredto as Black - Box Testing (or Data Driven Testing)approach, where program internals are notconsidered.


30/52

QA Tester

Roles and ResponsibilitiesUnderstanding the Business and SystemRequirements

Documenting Test PlanDocumenting Test CasesSetting up the Test EnvironmentExecution of Test Cases

Defect Reporting and TrackingWriting Summary ReportsParticipating in Meetings, Walkthroughs, andDemos


31/52

Test Plan

Test Plan is a detailed document thatdescribes the entire testing process. MostTest Plans contain lists, tables, outlines

and metrics. Test plan can be one bigdocument or small separate documents.There are industry defined standards forwriting Test Plans.

Making a detailed Test Plan is veryimportant because it helps to performtesting more effectively and efficiently.


32/52

Test Plan

Following information usually goes in aTest Plan:

Unique Test Plan Name

Contact ListApprovalsGeneral IntroductionFeature that will be tested for the presentreleaseFeature that wont be tested for the presentreleaseApproachPass/Fail Criteria


33/52

Test Plan

Suspension Criteria and ResumptionRequirementsTest Deliverables

Environment NeedsResponsibilitiesStaffing and Training NeedsScheduleRisk and ContingenciesExit Criteria


34/52

Test Plan

Unique Test Plan NameEvery Test Plan has a unique name by whichpeople can refer to it for future use.

Contact ListThis section contains information about thedevelopers and System Engineers. It containsdevelopers and system engineers name andphone number etc., So that the testers wouldknow who to contact if there is a problem withthe program or the requirements.


35/52

Test Plan

ApprovalsThis section contains the information aboutwho has to approve the Test Plan also the

space for the signatures.General IntroductionGeneral Introduction contains high leveldescription of the testing process. It alsocontains references to all testing standardsthat company follows.


36/52

Test Plan

Features that will be tested for thepresent release

This section usually contains the list of features

or items that will be tested for the presentrelease of the software. This section alsocontains list of all the documents that will bereferred to in the test plan document.

Features that wont be tested for thepresent release

This section contains the list of all the featuresthat wont be tested and reason why theywont be tested for this release.


37/52

Test Plan

ApproachThis section contains overall approach oftesting: who does it, main activities,techniques and tools used for group offeatures. How will you decide that a group offeatures is adequately tested?

Pass/Fail CriteriaThis section contains information about howdoes a tester decide whether the programpassed or failed a given test.


38/52

Test Plan

Suspension Criteria & ResumptionRequirements

This section contains anything that would

cause to stop testing until it is fixed. Whatwould have to be done to get you to restarttesting? What tests should be redone at thispoint?

Test DeliverablesThis section lists all of the testing documentsthat will be written for this product.


39/52

Test Plan

Environment NeedsThis section describe the necessary hardware,software, testing tools, lab facilities, etc..

ResponsibilitiesThis section contains the people responsible formanaging, designing, preparing, executing,checking, fixing, resolving, getting you theequipment, etc...


40/52

Test Plan

Staffing and Training NeedsThis section contains people you need at eachskill level, and what training they need.

ScheduleThis section lists all milestones with dates, andwhen all resources (people, machine, tools andfacilities) will be needed.


41/52

Test Plan

Risk and ContingenciesThis section contains the risk assumptions inthe test plan. What can go sufficiently wrongto delay the schedule and what can you doabout it?

Exit CriteriaThis section contains the information abouthow you will finish your testing. How you willdecide that application is ready for production?


42/52

Test Case

A Test Case is a step by step description of howto test for a specific scenario. A Test Case needsto contain such level of details so that a personwho never used that software can follow the testcase to test the software. Usually Test Cases arewritten by following certain templates.A template is nothing but a format that a testerwould use for uniformity.Test Cases are written based on the base-linedSystem Requirements Document. If requirementsare not clear testers contact the System Engineerfor clarification.


43/52

Test Case

Test Case ExecutionOnce the Test Cases are base-lined and theproper environment for testing is set up, thetesters would follow the test cases to test thesoftware. Lot of times the testers would usetheir instincts to find errors instead of justblindly following the test cases.The Test Cases usually state what the

expected result is. The tester actually works onthe application following the test case stepsand makes sure that the Actual Result andExpected Result are matching.


44/52

Defect Reporting and Tracking

Defect Reporting is also known by the term MR -Modification Request.MR - Modification Request is nothing but arequest to modify the program so that it doeswhat it is supposed to do. Tester writes aModification Request for reportingproblems/errors in the software.During Test Case execution, if a tester finds outthat the Actual Result is not matching with theExpected Result, after analyzing and making surethat the Test Step is correct, a tester must createa MR or Modification Request.


45/52

MR - Modification Request

Following information is contained in a MR- Modification Request:

Test Case NumberDate CreatedStatus of MR

OpenOn holdRe-test

Re-openedClosedDeferred


46/52


Severity of MRCriticalHighMediumLow

Detected during what phaseRequirements that were testedDescription of how the testing was done sothat the programmer can reproduce the testingscenario and see how the tester found thatproblem.


47/52


What exactly happened after certain input wasgiven (actual result)What was supposed to happen (expectedresult)Any suggestions or recommendations for fixingthe problem.Attachments like screen print of errors oroutput etc. For more clarity about the problem.


48/52


MR Life CycleOnce a MR is created, the developer is notifiedand he/she will fix the code. Once the code isfixed the tester will be notified and he/she willrun the same exact test to test that part,(Regression Testing) will be performed. If itworks this time then test case passes andstatus of MR is changed to closed, but if itgives the same error then the tester wouldchange the status of MR to re-opened. Afterthe problem is fixed by the programmer,regression testing will be performed by thetesters again.


49/52

Other Test Documents

Following are the other important TestDocuments:

Test Log

Test Incident ReportTest Summary Report


50/52

Test Log

This is a chronological record of the Testexecutions and events that happenedduring testing. It includes the following

sections:Test Log IdentifierDescription: Whats being tested, includingVersion ID, where testing is being done, whathardware and all other configurationinformation.Activity and Event Entries: What happenedincludingExecution Description: The procedure used.

Procedure Result: What happened. What did


51/52

Test Log

Environment Information: Any changes(hardware substitution) made specifically forthis test.Unexpected Events: What happened before

and after problem/bug occurred.Incident/Bug Report Identifiers: Problem

Report number.


52/52

Test Summary Report

This is a summary of series of tests, ofthe type that you might issue aftercompleting a cycle of testing. It briefly

describes the testing done and evaluatesthe results. It includes the followingsections:

Summary

Comprehensive AssessmentSummary of ResultsEvaluationSummary of ActivitiesApprovals

Date post:	02-Jun-2018
Category:	Documents
Upload:	anil
View:	220 times
Download:	0 times