Software Testing

INTRODUCTION It is the process used to identify the correctness, completeness and quality of developed computer software. It is the process of executing a program/application under positive and negative conditions by manual or automated means. It checks for the :- Specification Functionality Performance

SDLC(Software Development Life Cycle) Standard model used word wide to develop a software. A framework that describes the activities performed at each stage of a software development project. Necessary to ensure the quality of the software. Logical steps taken to develop a software product.

Classical Waterfall Model Feasibility Study Requirements Analysis & Specification Design Coding & Unit Testing Integration & System Testing Maintenance It is the oldest and most widely used model in the field of software development.

Testing Life Cycle Project Initiation Summary Reports System Study Analysis Test Plan Regression Test Design Test Cases Report Defects Execute Test Cases ( manual /automated )

Test Plan It is a systematic approach to test a system i.e. software. The plan typically contains a detailed understanding of what the eventual testing workflow will be.

Test Case It is a specific procedure of testing a particular requirement. It will include: Identification of specific requirement tested Test case success/failure criteria Specific steps to execute test Test data

Verification vs Validation Verification: The software should confirm to its specification (Are we building the product right?) Validation: The software should do what the user really requires (Are we building the right product?)

Testing Methodologies Black box testing White box testing

Black box testing (Behavioral or Functional) No knowledge of internal program design or code required. Tests are based on requirements and functionality. Errors found by black – box testing Incorrect or missing functions. Interface errors. Errors in data structures or external data base access. Behavior or performance errors. Initialization and termination errors.

Various Black – box testing methods Equivalence partitioning (Divide the input domain of a program into classes of data from which test cases can be derived) Boundary value analysis (Ex: Check the Array boundary and loop boundary) Comparison testing (These independent versions form the basis of a black box testing technique called comparison testing and back – to- back testing) Orthogonal array testing (faulty logic within a software component) Syntax – driven testing (This type of testing is suitable for the specifications which are described by a certain grammar). Decision table – based testing The testing is implemented when the original software requirements have been formulated in the format of “if – then” statements. Form of a Rule – if (cond1 and cond2 and cond3 ) then action i Cause – effect graphics in functional testing

Black box testing requirements output input events

White box testing White box testing (Clear or Glass or Transparent or Structural) Knowledge of the internal program design and code required. Tests are based on coverage of code statements, branches, paths, conditions.

Benefits of White – Box Testing Focused testing (Test the program in pieces) Testing coverage (All lines must be testes) Control flow (Program is supported to do next, as a function of its current state) Data integrity (The programmer knows which parts of the program modify any item of data) Internal boundaries (The programmer can see internal boundaries) Algorithm specific (The programmer apply standard numerical analysis techniques to predict the results.

Various White – Box Testing techniques Basis path testing Control Flow Graph (CFG) Sequential Statement Control Structure if statements While Statement Until Statement Case Statement Condition testing (Branch testing, Domain testing, Branch and relational operator testing) Data flow testing The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program. For a statement with S as its statement number, DEF(S) = {X | statement S contains a definition of X} USE(S) = {X | statement S contains a use of X}

Loop Testing 1. Simple loops 2. Nested loops 3. Concatenated loops 4. Unstructured loops

Testing Levels Unit testing Integration testing System testing

UNIT TESTING Tests each module individually. Follows a white box testing (Logic of the program). Done by developers. The more common errors in computation are: Misunderstood or in correct arithmetic procedure Mixed mode operation Incorrect initialization Precision inaccuracy Incorrect symbolic representation of an Expression Test cases should uncover errors such as: Comparison of different data types Incorrect logical operator or precedence Improper loop termination

INTEGRATION TESTING Once all the modules have been unit tested, integration testing is performed. It is systematic testing. Produce tests to identify errors associated with interfacing. Types: Big Bang Integration testing Top Down Integration testing Bottom Up Integration testing Mixed Integration testing

Bottom Up Integration testing Top Down Integration testing Big Bang Integration testing Mixed Integration testing

SYSTEM TESTING The system as a whole is tested to uncover requirement errors. Verifies that all system elements work properly and that overall system function and performance has been achieved. Types: Alpha Testing Beta Testing Acceptance Testing Performance Testing

Alpha Testing It is carried out by the test team within the developing organization . Beta Testing It is performed by a selected group of friendly customers. Acceptance Testing It is performed by the customer to determine whether to accept or reject the delivery of the system. Performance Testing It is carried out to check whether the system meets the nonfunctional requirements identified in the SRS document.

Types of Performance Testing: Stress Testing Volume Testing Configuration Testing Compatibility Testing Regression Testing Recovery Testing Maintenance Testing Documentation Testing Usability Testing

Software Implementation Techniques Coding process The coding activity starts when some form of design has been done and the specifications of the modules to be developed are available. The programming team must have a designated leader, a well define organization structure and a through understanding of the duties and responsibilities of each team member. The implementation team must be provided with a well defined set of software requirements, an architectural design , specification, and a detailed design description. Also, each team member must understand the objectives of implementation. Incremental Coding Process A coding is written for implementing only part of the functionality of the module.

Other Methods Test Driven Development The programmer first writes the test scripts then writes the code to pass the tests. The whole process is done incrementally. Pair Programming More than one programmer implements the code and thus algorithm are checked in a better way. Advantages: Common ownership of programs Informal review by both Supports refectoring

Refactoring It is a technique to improve existing code and prevent this design decay with time, caused by changes. Refactoring through done on source code, has the objective of improving the design that the code implements. The main risk of refactoring is that existing code may break due to changes, Therefore rules: Refactor is small parts Have tests scripts available to test existing functionality. Need for factoring arises when Duplicate code exists in code Methods become long Classes are large Parameter lists are long Too many switch statements To much communication between objects

Common code Refactoring Improving methods Extracting functionality cohesive code from a large method. Add / Remove parameters as per requirements Improving classes Moving methods to appropriate classes where they are actually required Move field Extract classes from a large class Replace data value with object if the data is used frequently for operations. Improve hierarchies Replace conditional with polymorphism Pull up field / method

THANK YOU