Software Testing Trainning - Day4

Types of Testing. Testing Life cycle, Bug Life cycle

Day 4-Session 1 Lavanya.M

Software Testing Life cycle Test Plan Test Design Test Execution Test Log Defect Tracking Report Generation.

Testing Plan During this phase Test Strategy, Test Plan, Test Bed will be created. A test plan is a systematic approach in testing a system or software. The plan should identify: • Which aspects of the system should be tested? • Criteria for success. • The methods and techniques to be used. • Personnel responsible for the testing. • Different Test phase and Test Methodologies • Manual and Automation Testing • Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc • Evaluation & identification – Test, Defect tracking tools

Test Design During this phase • Test Scenarios will be identified. • Test Cases will be prepared. • Test data and Test scripts prepared. • Test case reviews will be conducted.

Test Execution

Testers execute the software based on the plans and test. Test cases will be executed. Test Scripts will be tested.

Test Log

A chronological record of all relevant details about the execution of a test. Test Results will be analyzed

Defect Tracking

Capture, review and analyze Test Results Raised the defects and tracking for its closure

Report Generation.

Test summary reports Test Metrics and process Improvements made Build release Receiving acceptance

Bug Life Cycle

Types of Testing List of the different types of testing that can be implemented are listed below which will be followed by explanations of the same















Black Box Testing White Box Testing Unit Testing Incremental Integration Testing Integration Testing Functional Testing System Testing End-to-End Testing Sanity Testing Regression Testing Acceptance Testing Load Testing Stress Testing Performance Testing

Usability Testing Install / Uninstall Testing Recovery Testing Security Testing Compatibility Testing Exploratory Testing Ad-hoc Testing Comparison Testing Alpha Testing Beta Testing Mutation Testing Conformance Testing Quality Assurance Testing

Black Box Testing It can also be termed as functional testing Tests that examine the observable behavior of software as evidenced by its outputs without referencing to internal functions is black box testing It is not based on any knowledge of internal design or code and tests are based on requirements and functionality In object oriented programming environment, automatic code generation and code re-use becomes more prevalent, analysis of source code itself becomes less important and functional tests become more important Test if a component conforms to specification

White Box Testing It can also be termed as Structural Testing Tests that verify the structure of the software and require complete access to the object’s source code is white box testing It is known as white box as all internal workings of the code can be seen White-box tests make sure that the software structure itself contributes to proper and efficient program execution It is based in of the internal logic of an applications’ code and tests are based on coverage of code statements, branches, paths, conditions In this type of testing code needs to be examined by highly skilled technicians Test if a component conforms to design

Functionality Testing It is black-box testing geared to functional requirements and should be done by testers Testing done to ensure that the product functions the way it is designed to according to the design specifications and documentation This testing can involve testing of product’s user interface, database management, security, installation, networking, etc.

Sanity Testing

Initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.

Regression Testing This is re-testing of the product/software to ensure that all reported bugs have been fixed and implementation of changes has not affected other functions It is always difficult to the amount of re-testing required, especially when the software is at the end of the development cycle These tests apply to all phases wherever changes are being made This testing also ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process

Load Testing

Testing an application under heavy loads For example, testing of a Web site under a range of loads to determine at what point the system’s response time degrades or fails Accurate pre-determination of performance can be determined through this testing

Stress Testing This term is more often used interchangeably with ‘load’ and ‘performance’ testing. It is system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system Always aimed at finding the limits at which the system will fail through abnormal quantity or frequency of inputs. Examples could be:
higher rates of inputs
data rates an order of magnitude above ‘normal’
test cases that require maximum memory or other resources
test cases that cause ‘thrashing’ in a virtual operating system
test cases that cause excessive ‘hunting’ for data on disk systems
This testing can also attempt to determine combinations of otherwise normal inputs can cause improper processing

Performance Testing This term is more often used interchangeably with ‘stress’ and ‘load’ testing To understand the applications’ scalability, or to benchmark the performance in a environment or to identify the bottlenecks in high hit-rate Web sites, this testing can be used This testing checks the run-time performance in the context of the integrated system This may require special software instrumentation Ideally, these types of testing are defined in requirements documentation or QA or Test Plans.

Usability Testing

This testing is testing for ‘user-friendliness’ The target will always be the end-user or customer Techniques such as interviews, surveys, video recording of user sessions can be used in this type of testing Programmers and Testers are not appropriate as usability testers

Install/Uninstall Testing

Testing of full, partial, or upgrade install/uninstall processes The target will always be the end-user or customer

Compatibility Testing

Testing whether the software is compatible in particular hardware / software / operating system / network / etc. environment

Alpha Testing This is testing of an application when development is nearing completion;mostly testing conducted at the developer’s site by a customer The customer uses the software with the developer ‘looking over the shoulder’ and recording errors and usage problems Testing is conducted in a controlled environment Minor design changes can be still made as a result of this testing Typically conducted by end-users or customers and not by programmers or testers

Beta Testing Testing conducted when development and testing are completed and bugs and problems need to be found before final release It is ‘live’ testing in an environment not controlled by the developer. Customer records the errors / problems reports difficulties at regular intervals Testing is conducted at one or more customer sites Typically conducted by end-users or customers and not by programmers or testers

Exercise 

Testing efforts should be started only after the coding is completed. True/False



Software testing efforts aim at preventing bugs. - True/False



During the Construction phase in the life cycle, both functional and structural Test data should be generated and applied. - True/False



The data that is generated for Statement testing, Branch Testing and path testing is known as ____________



Explain in your own words about Boundary value analysis Equivalence Partitioning