MANUAL TESTING

Evolution of the Software testing discipline

The effective functioning of modern systems depends on our ability to produce software in a cost-effective way. The term software engineering was first used at a 1968 NATO workshop in West Germany. It focused on the growing software crisis! Thus we see that the software crisis on quality, reliability, high costs etc. started way back when most of todays software testers were not even born! The attitude towards Software Testing underwent a major positive change in the recent years. In the 1950s when Machine languages were used, testing is nothing but debugging. When in the 1960s, compilers were developed, testing started to be considered a separate activity from debugging. In the 1970s when the software engineering concepts were introduced, software testing began to evolve as a technical discipline. Over the last two decades there has been an increased focus on better, faster and cost-effective software. Also there has been a growing interest in software safety, protection and security and hence an increased acceptance of testing as a technical discipline and also a career choice!. Now to answer, What is Testing? we can go by the famous definition of Myers, which says, Testing is the process of executing a program with the intent of finding errors

SDLC Software Development Life Cycle

It is defined as, different activities which it undergo from starting of requirements gathering to ending of Maintenance. Phases which it undergo 1) Requirements Gathering and Analysis 2) Design i. High Level ii. Low Level 3) Actual Coding 4) Testing 5) Implementation 6) Maintenance

Requirements Gathering and Analysis

Variy from project based and product based companies Project based Client End user Product based Customer End user Project Based Gathering Development Domain Experts In case of project based companies client will give all the needs, which are called requirements. This information will be analyzed by Domain Experts by checking feasibility of implementing the requirements, completeness of the information provided and clarity in the given information. If information is missed, list of questioner will be prepared and send to the client .Based on the response requirements will be modified. After completion of the requirements analysis requirements will be freeze and transfer to the design. Product Based Sources of Product based company 1. Market Survey 2.Customer 2. Enhancement Request 4.Competer Moves Client Analysis 1. Feasibility 2. Completeness 3. Clarity

In case of product based companies Market Survey will be used to get initial requirements from various group of people, the common needs will be consolated and will be used as requirements for these requirements feasibility, Completeness and Clarity will be check as part of analysis 1) 2) 3) The other sources of getting requirements in case of product based company is Customer new business needs Current limitations and Enhancement request (either internal and external) Competitor Application Functionality

Design
High Level Design A block of application which can be executed for a particular functionality. .Module Design .Integration of Modules .Front end and Back end technologies These are performed by Architects, who are having real experience (Developers) Modularity design of the application is called High Level design. It will be performed by the expert team called Architect team ,as part of these requirements which are ment for similar purpose will be group and called as a module .The following activities will be as part of High Level design. Low Level Design As part of these, for every transaction the different screens and corresponding fields in the screen and validations for every file will be documented .These is the key document for both development and testing activities.

Coding
Development phase where programs will be written by the developers to implement the functionality specified in Low Level design.

Testing
Checking the application behavior as per the Low Level design.

Implementation
Installing the application at the client or customer location and making it ready to conduct the Business.

Maintainance
Addressing all the customer problems which are occurred in production. It can be either free or paid Maintenance.

STLC Software Testing Life Cycle

It is defined as, different activies which it undergo from starting of Test plan to ending of Delivery of the project Phases which it undergo i. Test Planning 1. Initial test plan/Wrough estimation 2. Master test plan ii. Test cases design iii. Test case execution iv. Bug Reporting v. Analysis and Preparation of reports

Test Plan
Doing an activity in a systematic way , which happens in two stages. Initial Test Plan It is a wrough estimation of different activities which needs to be perform to achieve testing goals, it contains the information related to types of testing , resources and schedules etc. Master Test Plan It is also same as Initial test plan ,except that it contain accurate information.

Test Case Design

After completion of test plan preparation work will be assigned to individual test engineers by the leads after completion of Kick Off meeting. As per this test engineers will study functional specifications to understand the behavior of the application ,for any doubts mail will be sent either to author of FS document or Domain Experts , Based on functional understanding of the applications, test cases will be prepared by using test case writing techniques like i. Equivalence Class Partition ii. Boundary Value Analysis iii. Error Guesssing These test cases will be review and finalized.

TEST CASE WRITING

.Boundary Value Analysis

Process of selecting the values on the boundary, inside the boundary and outside the boundary Example: For a given range n-m the values selected will be n,n-1,n+1 m,m-1,m+1

.Error Guessing
Identified the more bugy areas based on previous experience and writing a more no. of test cases for these areas while testing a new application.

.Equivalence Class Partition

Dividing the given input domain into valid and invalid domain which may be equal and unequal sizes Valid 0-100 Invalid >100, &&, $

Marks =0-100
Failed +1 0 -1 Pass Pass 35-100 +35 34 -33 1st Class 60 100

2nd Class +50 +60 50 59 -49 -58

3rd Class +36 35 -33 +50 49 -48

Non Distinction +61 60 -59 +70 69 -68

Distinction +71 70 -69 +101 100 -99

Test Case Execution

By the time of completing test cases writing, application build will be ready for testing. Test cases will be executed to check the behavior of the application.

Bug Reporting
During test case execution process if there is any mismatch between expected behavior of the application and actual behavior of current application a bug will be reported using Bug tracking tools and process.

Analysis and Preparation of Reports

After conducting different types of testing the results will be analyzed to identify the mistakes existing in the different process of the system. Reports will be prepared root cases will be analyzed to eliminate the mistake from the system permanently.

SDLC Models
Arrangement of SDLC and STLC phases in an specific manner. There are 7 SDLC models

Water Fall Model

RG & A Test Case Execution Bug reporting

HLD

LLD Analysis and Preparation of reports

Coding

Test Plan

Test Case Design In case of Water fall model different activities of development and testing happens in sequential format these phases will be completed from top to the bottom like water fall. Once after completion of particular stage it will be freezed and further modification will not be allowed, output of this phase will be given as input to the next phase. These

model suits to the environment where both development and testing activities are performed be development teams. Advantages 1) Clarity of work & responsibility 2) Process maintenance cost is less 3) Can be used for a small application & Organization. Disadvantages 1) Change Management cant be in-corporate 2) Maintenance cost is very high 3) No optimization of time 4) No Risk Management concept

Change Management Process

To make any changes to the existing requirements client will raise the request which is called Change Request(CR). CR will be pass to domain expert team to analyze functional feasilbilty of implementation in the existing or current system, if it is feasibility to implement,CR is passed to the Architect teams to study technical feasibility. If the design change are high or huge then CR is postponed to next version of the application, if changes needs to perform are less, rework effort estimation is pass to client information will be pass to both development and testing teams.

V-V Model
Both development and testing team will work parallel. This is one way to optimize the time

Verification: Checking the correctness of every stage of application development process till coding.

Validation: Checking the correctness of developed application RG & A Test Plan, Test Cases, templates etc Acceptance Testing

Verification

HLD

Test Plan, Test Cases, templates etc

System testing

LLD

Test Plan, Test Cases, Templates etc

Integration Testing

Coding After completion of requirements gathering analysis and verification this document will be pass to development people to prepare HLD of the application, same requirements document will be used by the testing team to prepare relevant documents of Acceptance testing like Acceptance Test Plan ,Test cases Templates and any other document. Similar activities will be repeated at HLD and LLD Once after the completion of the Coding, testing will be conducting in the sequence of Integration testing, System testing and Acceptance testing by making use of different testing related documents which are prepared earlier. Advantages 1) Optimization of time(This can be achieved as development and testing are working parallel) 2) Less number of bugs(Output of every phase is going to verified by using static testing techniques which results identifying the bugs at early stage) 3) Low maintenance cost (As more number of bugs are identified either in Verification or in Validation, final system or application will contain less number of defects. Disadvantages 1) 2) 3) No Risk Management concept More maintenance cost as multiple number of teams and processes are involved Cant be used for application which are taking longer durations.

Incremental/Progressive Model
This model is used to develop the applications which takes more amount of time or in case of dynamic business like Banking where requirements will be changed contionusly based on Market changes design new versions of the applications based on existing versions.

Requirements will be gathered and analysis for the complete system at initial stage from these requirements critical requirements which are required to start business automation will be identified by architects with these requirements ,applications will developed and tested. If quality is good application will be released, same process will be repeated for portion of the application.

Iterative Model
Release Goal is Met Yes NO Testing Change Requirements HLD Goal

Requirement

I Coding

LLD

In this model to achieve a specific goal requirements will be gathered based on assumptions of expertise people based on these requirements entire application development process will be completed. This application will be tested to check the desired goal is met or not. f the goal is met application will be released to the market or else requirements will be changed based on results entire development process will re-iterated till the goal is met This is mainly used in case of research based application and in product based companies. Their will not be any restriction in duration and budget of the project.

RAD Model
This model is used to develop the application at a quick rate for specific domain generic requirements will be gathered and application will developed as independent blocks. After getting requirements from a specific client, generic requirements will be separated from customer requirements, for this new requirements applications will be developed and integrated with in dependent blocks of the program which is developed based on generic requirements. Advantages of this model is designing the application with low price and less amount of time but risk involved in this model is very high.

TEST PLANING

Test plan is a document which contain the information of Testing Approach Scope and Schedules Initially when the requirements are available Initial test plzn will be prepared with rough estimation, after completion of High Level design intial test plan will be modified to prepare master test plan with accurate estimations. If scope of the project is very high, test plans will be prepared in two stages.

.Project Level
This contains all the testing required for whole projects.

.Team Level
It contains testing approach for a specific testing team The document contains 1. Header or First Page of the Document In this Administration will maintain the data like Title of the project, Author, Status, Creation & Modified Dates and Document Control Number etc. 2. Change History S.No 1. 2. Modified By Xyz Abc Designation PM TL Modified On 12/04/08 14/04/08 Reasons/Comments Change requested by Client

In the Change History the details of the Requirements changes , When the changes occur , who made the changes and reasons of the changes will be formatted in the table. 3. Index What is the purpose of preparation of this documentation? What are the things which exist in this project? This section contains why this document is prepared and a brief overview of the project will be mentioned 4. *Scope We will mention that what types of testing we are going to perform. This section contains information related to types required for the project. If it is project level, Master Test Plan, all the testing of the project will be mentioned. If it is related to type of testing or team Level Test plan only the testing conducting by a specific team will be mentioned.

5. Functionalities to be tested This gives the information of functionalities of the application which need to be tested as part of a specific testing.

Content of this section will be vary for each type of testing. 6. Functionalities Not to be tested This section contains modules or functionalities , which are not included in the current scope of the testing. 7. Entry and Exist Criteria S.No Activity Entry Criteria Date Start Exit Criteria DateReasons/Comments End

When a particular activity has to be started is called Entry Criteria and when the activity has to be stopped is called Exit Criteria. Entry and Exit Criteria will be mentioned for every activity of testing. In case of chain of activities, Exit and Criteria of previous activity will be Entry Criteria for the further activity with few additions. 8. Pass or Fail Criteria This section contains information of guide lines to make a test case or a build or a module either Pass or Fail. 9. Schedules Type Of Testing Start Date End Date

In project level , Master Test Paln contains type of testing, Start Date and End Date of every testing will be mentioned 10. Resources .Human .Software .Hardware 11. Training .Internal .External 12. Risk Management If any unknown error occurs , how to over come that. 13. Deliverables Nothing but the outputs of our testing like Test Plan, Test Cases, Test Execution Reports, Test Summary Reports, Test Execution Logs, Test Incident Reports, Status Reports and Feed Back Reports etc.

14. Approvals

TOOL EVALUTION
Process of selecting the automation tool or Tool Evaluation is a process of studying different automation tools available in the market. Factors to be taken care on selecting of a tool Applicability Current Future Easy to Use/Usability Cost/Budget Training Requied Availability Brand Name Efficiency or Effectiveness To start this process a request will be raised to a vendor to give and explain demo on major functionality of the tool, after completion of the demo , vendor resources will give a trailed version of the tool .The same thing will be repeated for all the tools which are selected for Tool Evaluation based on applicability

Example of Tool Evaluation

Factors Applicability Java .NET Usability Cost Support Training Availability Brand Name Efficiency Win Runner QTP .NET application Both can be tested cant be tested Moderate 2-Lac Very Good Minimal Very High Most Popular Medium Very High 3-Lac Very Good Minimal Medium Most Popular Very High Slik Test NET application cant be tested Moderate 2.5-Lac Moderate Moderate Less Average Very High