Software Testing Notes, Study notes of Software Project Management

Download Software Testing Notes and more Study notes Software Project Management in PDF only on Docsity! Reviews. Walkthroughs Technical Reviews rere Inspection Statement / Decision Condition ondition } Multiple oni informal et | Structure-based / Static Analysis / | Data Flow ~~ Control me Error Guessing Exploratory Testing a / / | Specification Based testing • Also known as black box or input/output testing technique. • No Knowledge about how system works. • Tester is concentrating on what the software does, not how it does it. • They are based on model of some aspect of specification. Equivalence Partitioning • Divide a set of test conditions into groups or sets that can be considered the same. • It is also called as equivalence classes. • We test one condition from each partition. • If one condition works then assume that all condition work. • If one condition does not work, then we assume that none of them work. Equivalence Partitioning • In this method the input domain data is divided into different equivalence data classes. • This method is typically used to reduce the total number of test cases Equivalence Partitioning • If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid data. • A saving account in a bank earns different interest rates depending upon the balance. • E.g. If balance range 0$ to 100$ -> 3% interest rate • Balance over 100% to 1000% - 5% • Over 1000% - 7% interest rate • Invalid Partition- -0.01$ • Valid (3% interest) – 0.00$ to 100.00$ • Valid(5% interest) – 100.01$ to 999.99$ • Valid(7% interest) – 1000$ Boundary Value Analysis • It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. • More application errors occur at the boundaries of input domain. • ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain. Boundary Value Analysis • To apply boundary value analysis, we will take minimum and maximum values from the valid partition together. Boundary Value Analysis Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis: 1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case. 2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999. Decision Table Testing • Decision Table Testing is a good way to deal with a combination of inputs, which produce different results. • It helps reduce test effort in verifying each and every combinations of test data, at the same time ensuring complete coverage. Decision Table Testing Example @ FIIgHRS Conditions itty 8 Uta iti toaed FLY FROM eS Cat) rn TOR Ae the ovtcome wil be False OUTCOME (flight button disadoled) FLIGHTS BUTTON Decision Table Testing Example • Rule 2: When Fly From destination is set but Fly to is not set, Flight button is disabled. Correspondingly, you register True for Fly from destination in the decision table, and the rest of the entries are false. • Rule 3: When Fly from destination is not set but Fly to destination is set, Flight button is disabled and you make entries in the decision table. Decision Table Testing Example • Rule 4: only when Fly to and Fly from destinations are set, Flights button is enabled and you make the corresponding entry in the decision table. State Transition Testing • Any system where you get a different output for the same input, depending on what has happened before, is a finite state system. State Transition Testing A state transition model has four basic parts: • The states that the software may occupy (open/closed or funded/insufficient funds); • The transitions from one state to another (not all transitions are allowed); • The events that cause a transition (closing a file or withdrawing money); • The actions that result from a transition (an error message or being given your cash). State Transition Testing card inserted enter PIN PIN not OK PIN not OK PIN not OK access to account FIGURE 4.2 | State diagram for PIN entry Use Case Testing • Actors are generally people but they may also be other systems. • Use cases are a sequence of steps that describe the interactions between the actor and the system. • Use cases are defined in terms of the actor, not the system. They often use the language and terms of the business rather than technical terms, especially when the actor is a business user. Use Case Testing • Use cases can uncover integration defects, that is, defects caused by the incorrect interaction between different components. • Use cases describe the process flows through a system based on its most likely use. • Each use case must specify any preconditions that need to be met for the use case to work. • Use cases must also specify post conditions that are observable results and a description of the final state of the system after the use case has been executed successfully. Step | Description 1 A: Inserts card Main Success Scenario 2 S: Validates card and asks for PIN A: Actor S: System L 3 A: adi PIN 4 Is; Validates PIN T 5 S: Allows access to account a Card not valid S: Display message and reject card + Extensi 4 PIN not valid ene S: Display message and ask for re-try (twice) 4b PIN invalid 3 times S: Eat card and exit Advantage of Statement Coverage • It verifies what the written code is expected to do and not to do • It measures the quality of code written • It checks the flow of different paths in the program and it also ensure that whether those path are tested or not. Disadvantage of Statement Coverage • It cannot test the false conditions. • It does not report that whether the loop reaches its termination condition. • It does not understand the logical operators. Statement Coverage and Statement Testing • Statement Coverage= No. of statement exercised/Total no. of statement X 100 • Black box testing achieve 60% to 75% statement coverage. • Adhoc testing cover around 30%. Statement Coverage 1. Read A 2. Read B 3. C=A+2*B 4. If C>50 THEN 5. Print ‘Large C’ 6. END IF Statement Coverage • Test 1_1: A=2, B=3 • Test 1_2: A=0, B=25 • Test 1_3: A=47, B=1 • Test 1_4: A=20, B=25 Statement Coverage • Test 1_4 on its own is more effective which helps in achieving 100% statement coverage, than the first three tests together. • we measured coverage first, and then designed a test to cover the statement that we had not yet covered. Disadvantages of decision coverage: • This metric ignores branches within Boolean expressions which occur due to short-circuit operators. Formula Number of decision outcomes exercised Decision COVerage = --------------------------- 22a nnn nnn nnn nnn nnn n nnn en nee e- x 100% Total number of decision outcomes Decision Coverage • Decision coverage requires each decision to have had both a True and False outcome. • to achieve 100% decision coverage, a second test case is necessary where A is less than or equal to B which ensures that the decision statement ‘IF A > B’ has a False outcome. • 100% decision coverage guarantees 100% statement coverage, but not the other way around. Decision Coverage • The dotted line shows where Test 2_1 has gone and clearly shows that we haven’t yet had a test that takes the False exit from the IF statement. • TEST SET 2 Test 2_1: A = 20, B = 15 Test 2_2: A = 10, B = 2 • This now covers both of the decision outcomes, True (with Test 2_1) and False (with Test 2_2). Experience- based testing • people’s knowledge, skills and background are of prime importance to the test conditions and test cases. • The experience of both technical and business people is required, as they bring different perspectives. • Experience-based techniques go together with specification-based and structure-based techniques. • This technique used for low-risk systems Error Guessing in Software Testing • It is a technique where the experienced and good testers are encouraged to think of situations in which the software may not be able to cope. • Some people seem to be naturally good at testing and others are good testers because they have a lot of experience. • The success of error guessing is very much dependent on the skill of the tester. Exploratory testing • It is hands-on approach in which testers are involved in minimum planning and maximum test execution. • The planning involves the creation of a test charter, a short declaration of the scope of a short (1 to 2 hour) time-boxed test effort, the objectives and possible approaches to be used. • Test logging is undertaken as test execution is performed, documenting the key aspects of what is tested, any defects found and any thoughts about possible further testing. Regression Testing • Regression testing is a technique that is carried out by implementing units of code repeatedly so as to ensure that the constant code modifications are not impacting the system’s functionality. Benefits of Regression Testing • Increase chances of detecting bugs caused due to new changes introduced in the software • Helps in identifying undesirable side effects that might have been caused due to a new operating environment • Highly beneficial in situations when continuous changes are introduced in the product Retest-all Regression Testing • This type of testing is very tedious and tends to waste a lot of time. • The strategy involves the testing of all aspects of a particular product as well as reusing all test cases even where the changes/modifications have not been made. Selective Regression Testing • It is done to analyze the impact of new code added to the already existing code of the software. • When this type of regression testing is conducted, a subset from the existing test cases is used, to reduce the effort required for retesting and the cost involved. Progressive Regression Testing • This type of regression testing works effectively when there are certain changes done in the program specifications as well as new test cases are designed.