Types of Software Testing

Importance of Testing in SDLC & Various Kinds of Testing

Software Development Lifecycle All software development can be characterized as a problem solving loop in which four distinct stages are encounter: - Status quo : “represents the current state of affairs”; Problem definition: identifies the specific problem to be solved Technical development : solves the problem through the application of some technology. Solution integration: delivers the results (e.g., documents, programs, data, new business function, new product) to those who requested the solution in the first Place.

Waterfall Model Analysis Design Code Test System/information engineering

The Prototyping Model Listen to customer Build/revise mock-up Customer test-drives mock-up

The RAD Model Team #1 Team #2 Team #3 Business modeling Data modeling Process modeling Application modeling Test and turnover Business modeling Data modeling Process modeling Application modeling Test and turnover Business modeling Data modeling Process modeling Application modeling Test and turnover

V- Model SRS Unit test Tested modules Integration Test Integrated software System Integration Test Tested software System Test, AcceptanceTest Requirements Specification System Design Detailed Design Coding System Design SRS Module designs Code User Manual

Importance of Software testing in SDLC Its helps to verify that all the software requirements are implemented correctly or not. Identifying defects and ensuring they are addressed before software deployment. Because if any defect will found after deployment and force to fixed it, than the correction cost will much higher than the cost of it fixed it at earlier stage of development. Effective testing is demonstrates that software-testing function appear to be working according to specification, that behavioral and performance requirement appear to have been met. Whenever any system is developed in different components, its helps to verify the proper integration/interaction of each component to rest of the system. Data collection as testing is conducted provide a good indication of software reliability and some indication of software quality as a whole.

Different Types of Testing Dynamic v/s static testing. Development v/s independent testing. Black v/s white box testing. Behavioral v/s structural testing. Automated v/s manual testing. Sanity, acceptance and smoke testing . Regression testing. Exploratory and monkey testing. Debugging v/s be bugging.

Dynamic v/s static Static Testing: This testing refers to testing something that’s not running-Examining and reviewing it. Dynamic Testing: This you would normally think of as testing-running and using the software.

Development v/s independent testing Development testing denotes the aspects of test design and implementation most appropriate for the team of developers to undertake. This is in contrast to Independent Testing. In most cases, test execution initially occurs with the developer testing group who designed and implemented the test, but it is a good practice for the developers to create their tests in such a way so as to make them available to independent testing groups for execution. Independent testing denotes the test design and implementation most appropriately performed by someone who is independent from the team of developers. You can consider this distinction a superset, which includes Independent Verification & Validation. In most cases, test execution initially occurs with the independent testing group that designed and implemented the test, but the independent testers should create their tests to make them available to the developer testing groups for execution

Black v/s white box testing The purpose of a black-box test is to verify the unit's specified function and observable behavior without knowledge of how the unit implements the function and behavior. Black-box tests focus and rely upon the unit's input and output. A white-box test approach should be taken to verify a unit's internal structure. Theoretically, you should test every possible path through the code, but that is possible only in very simple units. At the very least you should exercise every decision-to-decision path (DD-path) at least once because you are then executing all statements at least once. A decision is typically an if-statement, and a DD-path is a path between two decisions.

Behavioral v/s structural testing Behavioral Testing: This is another name commonly given to Black Box Testing as you are testing the behavior of the software when it’s used without knowing the internal logics how they are implemented. Structural Testing: This is another name commonly used for white Box testing in which you can see and use the underlying structure of the code to design and run your tests.

Automated v/s manual Automated Testing: Software testing assisted with software tools that require no operator input, analysis, or evaluation. Manual Testing : That part of software testing that requires human input, analysis, or evaluation.

Sanity, Acceptance and Smoke testing Sanity Testing: Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc. Acceptance testing: Acceptance testing is the final test action before deploying the software. The goal of acceptance testing is to verify that the software is ready and can be used by your end users to perform those functions and tasks for which the software was built. Smoke Testing: Smoke testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details.

Regression testing The selective retesting of a software system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the modifications and that newly added features have not created problems with previous versions of the software. Regression testing is initiated after a programmer has attempted to fix a recognized problem or has added source code to a program that may have inadvertently introduced errors. It is a quality control measure to ensure that the newly modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity.

Exploratory and monkey testing Exploratory testing involves simultaneously learning, planning, running tests, and reporting / troubleshooting results. Monkey testing- This is another name for "Ad Hoc Testing"; it comes from the joke that if you put 100 monkeys in a room with 100 typewriters, randomly punching keys, sooner or later they will type out a Shakespearean sonnet. So every time one of your ad hoc testers finds a new bug, you can toss him a banana. The use of monkey testing is to simulate how your customers will use your software in real time.

Debugging v/s bebugging Debugging : The process of finding and removing the causes of failures in software. The role is performed by a programmer. Bebugging: The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program

Black Box & White Box Testing Techniques

Black-Box Testing Program viewed as a Black-box, which accepts some inputs and produces some outputs Test cases are derived solely from the specifications, without knowledge of the internal structure of the program.

Functional Test-Case Design Techniques Equivalence class partitioning Boundary value analysis Cause-effect graphing Error guessing

Equivalence Class Partitioning Partition the program input domain into equivalence classes (classes of data which according to the specifications are treated identically by the program) The basis of this technique is that test of a representative value of each class is equivalent to a test of any other value of the same class. Identify valid as well as invalid equivalence classes For each equivalence class, generate a test case to exercise an input representative of that class

Example Example: input condition 0 <= x <= max valid equivalence class : 0 <= x <= max invalid equivalence classes : x < 0, x > max 3 test cases

Guidelines for Identifying Equivalence Classes Input Condition Valid Eq Classes Invalid Eq Classes range of values one valid two inavlid (eg. 1 - 200) (value within range) (one outside each end of range) number N valid one valid two invalid values (none, more than N) Set of input values one valid eq class one each handled for each value (eg. any value not differently by the in valid input set ) program (eg. A, B, C)

Guidelines for Identifying Equivalence Classes Input Condition Valid Eq Classes Invalid Eq Classes must be condition one one (e.g. Id name must begin (e.g.. it is a letter) (e.g.. it is not a letter) with a letter ) If you know that elements in an equivalence class are not handled identically by the program, split the equivalence class into smaller equivalence classes.

Identifying Test Cases for Equivalence Classes Assign a unique number to each equivalence class Until all valid equivalence classes have been covered by test cases, write a new test case covering as many of the uncovered valid equivalence classes as possible. Each invalid equivalence class cover by a separate test case.

Boundary Value Analysis Design test cases that exercise values that lie at the boundaries of an equivalence class and for situations just beyond the ends. Example: input condition 0 <= x <= max Test for values : 0, max ( valid inputs) : -1, max+1 (invalid inputs)

Cause Effect Graphing A technique that aids in selecting test cases for combinations of input conditions in a systematic way.

Cause Effect Graphing Technique 1. Identify the causes (input conditions) and effects (output conditions) of the program under test. 2. For each effect, identify the causes that can produce that effect. Draw a Cause-Effect Graph. 3. Generate a test case for each combination of input conditions that make some effect to be true.

Example Consider a program with the following: Input conditions Output conditions c1: command is credit e1: print invalid command c2: command is debit e2: print invalid A/C c3: A/C is valid e3: print debit amount not valid c4: Transaction amount not e4: debit A/C valid e5: credit A/C

Example: Cause-Effect Graph C1 C2 C3 C4 E1 E2 E3 E5 E4 and and or and not and and not and and not not

Example: Cause-Effect Graph C1 C2 C 3 C4 E1 E2 E5 E4 not not not not and E3 and and or and and and and

Example Decision table showing the combinations of input conditions that make an effect true. (Summarized from Cause Effect Graph) Write test cases to exercise each Rule in decision Table. Example: C1 C2 C3 C4 0 0 - - 1 - 0 - - 1 1 0 - 1 1 1 1 - 1 1 E1 E2 E3 E4 E5 1 1 1 1 1

Error Guessing From intuition and experience, enumerate a list of possible errors or error prone situations and then write test cases to expose those errors.

White Box Testing White box testing is concerned with the degree to which test cases exercise or cover the logic (source code) of the program. White box Test case design techniques Statement coverage Basis Path Testing Decision coverage Loop testing Condition coverage Decision-condition coverage Multiple condition coverage Data flow testing

White Box Test-Case Design Statement coverage write enough test cases to execute every statement at least once TER (Test Effectiveness Ratio) TER1 = statements exercised / total statements

Example void function eval (int A, int B, int X ) { if ( A > 1) and ( B = 0 ) then X = X / A; if ( A = 2 ) or ( X > 1) then X = X + 1; } Statement coverage test cases: 1) A = 2, B = 0, X = 3 ( X can be assigned any value)

Decision coverage write test cases to exercise the true and false outcomes of every decision TER2 = branches exercised / total branches Condition coverage write test cases such that each condition in a decision takes on all possible outcomes atleast once may not always satisfy decision coverage White Box Test-Case Design

Example void function eval (int A, int B, int X ) { if ( A > 1) and ( B = 0 ) then X = X / A; if ( A = 2 ) or ( X > 1) then X = X + 1; } Decision coverage test cases: 2) A = 2, B = 1, X = 1 ( abe ) 1) A = 3, B = 0, X = 3 (acd) A > 1 and B = 0 A = 2 or X > 1 X = X+1 X = X/ A a c T F b e T F d

Example Condition coverage test cases must cover conditions A>1, A<=1, B=0, B !=0 A=2, A !=2, X >1, X<=1 Test cases: 1) A = 1, B = 0, X = 3 (abe) 2) A = 2, B = 1, X = 1 (abe) does not satisfy decision coverage X = X+1 a c T F b e T F d A > 1 and B = 0 A = 2 or X > 1 X = X/ A

White Box Test-Case Design Decision Condition coverage write test cases such that each condition in a decision takes on all possible outcomes at least once and each decision takes on all possible outcomes at least once Multiple Condition coverage write test cases to exercise all possible combinations of True and False outcomes of conditions within a decision

Example Decision Condition coverage test cases must cover conditions A>1, A<=1, B=0, B !=0 A=2, A !=2, X >1, X<=1 also ( A > 1 and B = 0) T, F ( A = 2 or X > 1) T, F Test cases: 1) A = 2, B = 0, X = 4 (ace) 2) A = 1, B = 1, X = 1 (abd) X = X+1 a c T F b e T F d A > 1 and B = 0 A = 2 or X > 1 X = X/ A

Example Multiple Condition coverage must cover conditions 1) A >1, B =0 5) A=2, X>1 2) A >1, B !=0 6) A=2, X <=1 3) A<=1, B=0 7) A!=2, X > 1 4) A <=1, B!=0 8) A !=2, X<=1 Test cases: 1) A = 2, B = 0, X = 4 (covers 1,5) 2) A = 2, B = 1, X = 1 (covers 2,6) 3) A = 1, B = 0, X = 2 (covers 3,7) 4) A = 1, B = 1, X = 1 (covers 4,8)

Basis Path Testing 1. Draw control flow graph of program from the program detailed design or code. 2. Compute the Cyclomatic complexity V(G) of the flow graph using any of the formulas: V(G) = #Edges - #Nodes + 2 or V(G) = #regions in flow graph or V(G) = #predicates + 1

Example 1 2 3 4 5 10 6 7 8 9 R4 R3 R2 11 12 13 R1 R6 R5 V(G) = 6 regions V(G) = #Edges - #Nodes + 2 = 17 - 13 + 2 = 6 V(G) = 5 predicate-nodes + 1 = 6 6 linearly independent paths

Basis Path Testing ( contd ) 3. Determine a basis set of linearly independent paths. 4. Prepare test cases that will force execution of each path in the Basis set. The value of Cyclomatic complexity provides an upper bound on the number of tests that must be designed to guarantee coverage of all program statements.

Loop Testing Aims to expose bugs in loops Fundamental Loop Test criteria 1) bypass the loop altogether 2) one pass through the loop 3) two passes through the loop before exiting 4) A typical number of passes through the loop, unless covered by some other test

Loop Testing Nested loops 1) Set all but one loop to a typical value and run through the single-loop cases for that loop. Repeat for all loops. 2) Do minimum values for all loops simultaneously. 3) Set all loops but one to the minimum value and repeat the test cases for that loop. Repeat for all loops. 4) Do maximum looping values for all loops simultaneously.

Data Flow Testing Select test paths of a program based on the Definition-Use (DU) chain of variables in the program. Write test cases to cover every DU chain is at least once.

Thank You… Any Questions ????

Types of Software Testing

More Related Content

What's hot

Viewers also liked

Similar to Types of Software Testing

Recently uploaded

Types of Software Testing

Editor's Notes