Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Software Engineering - chp4- design patterns
Next
Download to read offline and view in fullscreen.

2

Share

Download to read offline

Software Engineering - chp7- tests

Download to read offline

Tests

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Software Engineering - chp7- tests

  1. 1. MedTech Chapter 7 – Tests Types of Tests, Verification, Methods… Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 1 MedTech – Mediterranean Institute of Technology CS321-Software Engineering MedTech
  2. 2. MedTech Why? Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 2 Software Testing
  3. 3. MedTech Why? • Because Software is Buggy! • Cost of bugs to the US economy 60 billion dollars per year • Software contain in average 1-5 bugs every 1000 lines of code • Having 100% correct mass-market software is impossible • We must verify the software as much as possible Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 3 Software Testing
  4. 4. MedTech Common Terms • Official IEEE terminology • Failure • Observable incorrect behaviour of the software • More related to the behavior of the program rather than its code • Fault • Also called a bug • Incorrect code • Necessarely but not sufficient condition of the occurrence of a failure • Error • Cause of a fault • Human error, conceptual… Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 4 Software Testing
  5. 5. MedTech Common Terms: Example • Let’s take this method: int doubleValue(int val){ int result; result = val * val; return result; } • Is the fact that this method is supposed to return the double of the input but doesn’t is considered a failure, fault or error? • Failure, because it is related to the behavior of the method • In this case, which line of code represents the fault? • result = val * val; • And what is the error that caused this bug? • Only God and the developer know… Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 5 Software Testing
  6. 6. MedTech VERIFICATION APPROACHES Software Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 6
  7. 7. MedTech Verification Approaches • How can we verify our software system? • Four main approaches: • Testing (dynamic verification) • Static verification • Inspections • Formal Proofs of Correctness • In our course, we will focus on testing, as it is the most common and used verification approach • We start first by summarizing the difference between these approaches Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 7 Verification Approaches
  8. 8. MedTech Testing • Testing: • Exercising the system to try to make it fail • Test Case: {𝑖 ∈ 𝐷, 𝑜 ∈ 𝑂} • A set of inputs in the domain D, and an expected output of the demain O • Test Suite: Set of test cases Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 8 Verification Approaches
  9. 9. MedTech Static Verification • Static Verification: • Tries to identify precise causes of problems in the program, such as null pointer • Instead of considering a precise input, it considers all possible inputs (executions) • Unlike testing, the verification is complete Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 9 Verification Approaches
  10. 10. MedTech Inspections • Inspections: • Also called Reviews or Walkthroughs • Manual and group activity, where several developers look at the code in order to identify defects • Quite effective in practice • Used widely in industry Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 10 Verification Approaches
  11. 11. MedTech Formal Proof • Formal Proof of Correctness: • Given a software specification, a formal specification is a document that formally defines the expected behaviour of the software • A formal proof of correctness prooves that the program being verified actually implements the program specification • Is done through a sofisticated mathematical analysis of the specification and of the code Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 11 Verification Approaches
  12. 12. MedTech Pros and Cons Approach Pros Cons Testing No False Positives Highly incomplete : testing considers a tiny fraction of the input domain Static Verification Considers all program behaviours Considers some impossible behaviours : can generate false positive Inspections Systematic Thorough Manual process Informal Subjective: depends on the people Formal Proofs Strong guarantees Need a formal specification, rarely available Complex and expensive Needs very a specialized personal Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 12 Verification Approaches
  13. 13. MedTech TESTING APPROACH Software Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 13
  14. 14. MedTech Definition of Testing • Today, Quality Assurance (Verification) is mostly about Testing • « 50% of my company employees are testers, and the rest spend 50% of their time testing » Bill Gates • Testing • Executing a program on a (tiny) sample of the input domain • Dynamic technique: the program has to be executed in order to test • Optimistic approximation: • Program under test being performed on a small subset of the input domain, it is therefore supposed that the behavior of any other input is consistant with that shown with the selected input data • Successful tests: • « A test is successful if the program fails » Goodenough and Gerhart • Testing cannot prove the absence of error, but can only prove their presence • If all tests are passed • Either the program is correct (unlikely) • Or the set of tests is bad (more likely) Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 14 Testing Approach
  15. 15. MedTech Testing Granularity Levels Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 15 Testing Granularity Levels
  16. 16. MedTech Testing Granularity Levels • Unit Testing • Testing single modules one by one • Integration Testing • Testing multiple modules • Testing their interactions • System Testing • Testing of the complete system • Both functional and non functional requirements • Acceptance Testing • Validation of the software against the customer requirements • Regression Testing • Done when the system changes • Verifies that the changes did not impact the behaviour of the system Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 16 Testing Granularity Levels
  17. 17. MedTech Alpha and Beta Testing • All previous testing levels are done at the level of the developing organization, by the developers themselves • Alpha Testing • A form of internal acceptance testing performed mainly by inhouse software QA and testing teams • Last testing done by test teams at the development site • After acceptance testing • Before releasing the software for beta tests • Beta Testing • Final testing phase • Testing carried out by real users in real environement • Generally more accurate because the customers are less tolerant for problems Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 17 Testing Types
  18. 18. MedTech TESTING TECHNIQUES Software Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 18
  19. 19. MedTech Black-Box and White-Box Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 19 Testing Techniques
  20. 20. MedTech Black-Box Testing • A kind of testing in which we consider the software as a closed box • Based on the description of the software (specification) • We don’t inspect the code of the software • Objective: • Cover as much specified behavior as possible • Limitations • Cannot reveal errors due to implementation details • Advantages • Focuses on the domain of the software, and is used to make sure that it is covering the important behaviors • No need for the code, can be used for legacy systems • It is possible to start test design early • Applicable at all granularity levels Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 20 Black-Box Testing
  21. 21. MedTech Black-Box Testing: Example • Specification: The function inputs an integer and prints it • Code void printNumBytes (int param){ if (param <1024) printf ("%d", param); else printf ("%d Kb",param/124); } • If we look only at the specification, we would perform at least 3 tests: with a positive, negative and null param • The result would be conform to the specification, if the tested integer is less than 1024 • Black box testing would not show the error at line 3 (124 instead of 1024) Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 21 Black-Box Testing 1 2 3
  22. 22. MedTech Systematic Functional Testing Approach Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 22 Black-Box Testing
  23. 23. MedTech Step1: Identify Independently Testable Features • Identifying all functionalities of the software that can be tested independently from the others • Example • For a simple function, there is only one testable feature • For a complex application, like a spreadsheet, we can have multiple features: • Merge cells • Statistical function • Chart creation • … Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 23 Black-Box Testing
  24. 24. MedTech Step2: Select Test Data • Identifying the relevant inputs for each function defined earlier • Consider the following case: • How can we select inputs to run our tests? • What are the relevant inputs, those that, once tested, can make us confident that the software is behaving correctly? Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 24 Black-Box Testing
  25. 25. MedTech Step2: Select Test Data: Selection Types • Exhaustive Testing: Test ALL possible inputs • Quite impossible in some cases, even with powerful software • For example, for the function printSun (int a, int b), if an integer’s size is 32 bits, if the system runs 1 test per nanosecond, it would take us 600 years to test all possible combinations! • Random Testing: Pick the inputs randomly in the domain • Has advantages • Inputs are picked uniformly: all inputs are considered equal • Avoids designer bias • Problem • Bugs are mostly scarse, so picking the inputs randomly will likely miss them Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 25 Black-Box Testing
  26. 26. MedTech Step2: Select Test Data: Selection Types • Partition Testing: Divide the input domain into partitions • Partitions : areas of the domain that are considered homogenuously by the software • Idea: Bugs tend to be dense in some partitions • Objective: • Identify partitions in the input domain • Select inputs from each partition • The parameters must be treated independenly to pick different partitions • Select Boundary Values in partitions Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 26 Black-Box Testing
  27. 27. MedTech Step3: Test Cases Specifications • Test Cases Specifications • Define how the values should be put together when actually testing the system • Combine the possible inputs, using a cartesian product, for example • Eliminate meaningless combinations Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 27 Black-Box Testing
  28. 28. MedTech Model-Based Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 28 Black-Box Testing
  29. 29. MedTech Model-Based Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 29 Black-Box Testing • To go from the specification to test cases, we have to construct a model • An abstract representation of the software under test • We can use many possible models • FSM: Finite State Machine • A possible model
  30. 30. MedTech Model-Based Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 30 Black-Box Testing • To go from the specification to test cases, we have to construct a model • An abstract representation of the software under test • We can use many possible models • FSM: Finite State Machine • A possible model
  31. 31. MedTech Model-Based Testing: Steps Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 31 Black-Box Testing
  32. 32. MedTech Model-Based Testing: Example 1. Start with an informal specification Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 32 Black-Box Testing
  33. 33. MedTech Model-Based Testing: Example 2. Build a model from the specification Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 33 Black-Box Testing
  34. 34. MedTech Model-Based Testing: Example 3. Extract Test Cases from the model by trying to • Cover all the states • Cover all the transitions Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 34 Black-Box Testing
  35. 35. MedTech White-Box Testing • Complementary to the black-box testing • Based on the code • Assumption: • Executing the faulty statement is a necessary condition for revealing a fault • Objective • Cover as much coded behavior as possible • Limitations • Cannot reveal errors due to missing paths: parts of the software specification that are not implemented • Because it is focused on the existing code, not on the specification • Advantages • The quality of the white-box testing can be measured objectively • The test can be measured automatically Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 35 White-Box Testing
  36. 36. MedTech White-Box Testing: Example • Specification: The function inputs an integer parameter and returns half of its value if even, its value otherwise • Code int fun (int param){ int result = param/2; return result; } • If we look only at the code, we guess that the function is supposed to return the half of any number given, which is correctly done. • With white box testing only, we wouldn’t know that we have to test even and odd numbers, and that each one gives a different output. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 36 White-Box Testing 1 2 3
  37. 37. MedTech Test Coverage • Assumption • Executing the faulty statement is a necessary condition for revealing a fault • So, in order for a test to have a chance to detect most of the bugs, it must « cover » a big percentage of the code. • Code coverage: • A measure (percentage) used to describe the degree to which the source code of a program is executed when a particular test suite runs • A program with high code coverage has more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low code coverage. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 37 White-Box Testing
  38. 38. MedTech Test Coverage Criteria • Function Coverage • Has each function (or subroutine) in the program been called? • Statement Coverage • Has each statement in the program been executed? • Branch Coverage • Has each branch (also called DD-path (Decision to Decision Path)) of each control structure (such as in if and case statements) been executed? • Condition Coverage • Has each Boolean sub-expression evaluated both to true and false? Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 38 White-Box Testing
  39. 39. MedTech Test Coverage Criteria • Coverage Criteria are defined in terms of : • Test Requirements • Elements, Entities in the code that we need to execute, in order to satisfy the criteria • Result: • Test Specifications • Descriptions of how the test should be in order to satisfy the requirements • Test Cases • Instanciations of test specifications Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 39 White-Box Testing
  40. 40. MedTech Test Coverage Criteria: Example printSum (int a, int b){ int result = a+b; if (result>0) printcol("red", result); else if (result<0) printcol("blue", result); } Test Specifications: conditions on a and b in order to cover all test requirements Test Spec #1: a+b > 0 Test Spec #2: a+b < b Examples of Test Cases: #1: ((a=[3], b=[9]), (output color=[red], output value=[12])) #2: ((a=[-5], b=[-8]), (output color=[blue], output value=[-13])) Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 40 White-Box Testing Test Requirement 1 Test Requirement 2
  41. 41. MedTech Statement Coverage • Basic and simplest coverage criteria • Test Requirements • All the statements in the program • Coverage measure • *+,-./ 01 .2.3+4.5 6474.,.*46 80479 *+,-./ 01 6474.,.*46 printSum (int a, int b){ int result = a+b; if (result>0) printcol("red", result); else if (result<0) printcol("blue", result); } With TC #1, almost 71% of the statements are covered (st #1,2,3,4,7) When adding TC #2, 100% are covered! Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 41 White-Box Testing TC #1 a=3 b=9 TC #2 a=-5 b=-8 1 2 3 4 5 6 7
  42. 42. MedTech Control-Flow Graph • Convenient representation of the code when you want to reason about its structure printSum (int a, int b){ int result = a+b; if (result>0) printcol("red", result); else if (result<0) printcol("blue", result); } Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 42 White-Box Testing 1 2 3 5 4 6 7 TF T F 1 2 3 4 5 6 7
  43. 43. MedTech Branch Coverage • Branch: Outgoing edges from a decision point (if, loop…) • Test Requirements • Branches in the program • Coverage Measure • *+,-./ 01 .2.3+4.5 -/7*3:.6 80479 *+,-./ 01 -/7*3:.6 printSum (int a, int b){ int result = a+b; if (result>0) printcol("red", result); else if (result<0) printcol("blue", result); } TC #1 covers branch #1 TC #2 covers branch #2 Branch #3 is never covered! => We add a new TC Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 43 White-Box Testing 1 2 3 5 4 6 7 TF T F TC #1 a=3 b=9 TC #2 a=-5 b=-8 TC #3 a = 0 b = 0 1 2 3 4 5 6 7
  44. 44. MedTech Condition Coverage • Test Requirements • Individual conditions in the program • Coverage Measure • *+,-./ 01 30*5;4;0*6 4:74 7/. -04: 8 7*5 < 80479 *+,-./ 01 30*5;4;0*6 void main(){ float x,y; read(x); read(y); if ((x==0)||(y>0)) y = y/x; else x = y+2; write(x); write(y); } Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 44 White-Box Testing 3 4 7 6 8 x==0 || y >01 2 3 4 5 6 7 8 9 10 9 ! (x==0 || y >0)
  45. 45. MedTech Condition Coverage void main(){ float x,y; read(x); read(y); if ((x==0)||(y>0)) y = y/x; else x = y+2; write(x); write(y); } Branch coverage = 100% But Condition coverage is not complete, because we don’t have a test case where x==0 is true Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 45 White-Box Testing 3 4 7 6 8 x==0 || y >0 1 2 3 4 5 6 7 8 9 10 9 ! (x==0 || y >0) TC #1 x=5 y=5 TC #2 x=5 y=-5
  46. 46. MedTech Condition Coverage void main(){ float x,y; read(x); read(y); if ((x==0)||(y>0)) y = y/x; else x = y+2; write(x); write(y); } Condition coverage = 100% because with both TC we covered all the possible values for both conditions But Branch coverage is not complete. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 46 White-Box Testing 3 4 7 6 8 x==0 || y >0 1 2 3 4 5 6 7 8 9 10 9 ! (x==0 || y >0) TC #1 x=5 y=5 TC #3 x= 0 y=-5
  47. 47. MedTech Test Criteria Subsumption • We say that Branch Coverage subsumes Statement Coverage • If a test suite satisfies branch coverage, it satisfies statement coverage too • But Branch Coverage doesn’t subsume Condition Coverage and Condition Coverage doesn’t subsume Branch Coverage Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 47 White-Box Testing Statement Coverage Branch Coverage Condition Coverage
  48. 48. MedTech Branch and Condition Coverage • Also called Decision and Condition Coverage • Considers both Branch Coverage and Condition Coverage • Test Requirements • Branches and individual conditions in the program • Coverage Measure • Both coverage measures Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 48 White-Box Testing Statement Coverage Branch Coverage Condition Coverage Branch and Condition Coverage
  49. 49. MedTech Branch and Condition Coverage void main(){ float x,y; read(x); read(y); if ((x==0)||(y>0)) y = y/x; else x = y+2; write(x); write(y); } Condition coverage = 100% Branch coverage = 100% Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 49 White-Box Testing 3 4 7 6 8 x==0 || y >0 1 2 3 4 5 6 7 8 9 10 9 ! (x==0 || y >0) TC #1 x=5 y=5 TC #3 x= 0 y=-5 TC #2 x=5 y=-5
  50. 50. MedTech Other Criteria • MC/DC: Modified Condition/Decision Coverage • Required for safety critical applications • Test important combinations of conditions instead of all of them • Extends branch and decision coverage with the requirement that each condition should affect the decision outcome independently • Path Coverage • Test requirements: all the paths in the program must be covered • Incredibly expensive, because we have virutally infinite number of TC • Data Flow Coverage • Coverage of statements where a memory location is modified and statements where this memory location is used • Mutation Coverage • Evaluation of the quality of the test suite by modifying slightly the statements in the code to see if the tests detect them Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 50 White-Box Testing
  51. 51. MedTech Test Criteria Subsumption Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 51 White-Box Testing Statement Coverage Branch Coverage Condition Coverage Branch and Condition Coverage MC/DC Multiple Condition Coverage Path CoverageMutation Coverage Data-Flow Coverage TheoriticalCriteria PracticalCriteria
  52. 52. MedTech NON FUNCTIONAL TESTING Software Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 52
  53. 53. MedTech Non Functional Testing • Testing an application from its non-functional attributes • Designed to figure out if your product will provide a good user experience • Types of non-functional testing: • Performance Testing • Load Testing • Stress Testing • Usability Testing • Security Testing • Portability Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 53 Non Functional Testing
  54. 54. MedTech Performance Testing • Mostly used to identify any bottlenecks or performance issues rather than finding bugs in a software • One of the most important and mandatory testing types • Determines how a system performs in terms of responsiveness and stability under a particular workload • Tests: • Speed (response time, data rendering and access..) • Capacity, stability, scalability • Performance testing • Can be either qualitative or quantitative • Can be divided into different sub-types such as Load testing and Stress testing. • Unless tests are conducted on the production hardware, from the same machines the users will be using, there will always be a degree of uncertainty in the results. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 54 Non Functional Testing
  55. 55. MedTech Load Testing • Verifies application behavior under normal and peak load conditions • Measures • Response times • Throughput rates • Resource-utilization levels • Identifies your application’s breaking point, assuming that the breaking point occurs below the peak load condition • Helps to determine • How many users the application can handle before performance is compromised. • How much load the hardware can handle before resource utilization limits are exceeded. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 55 Non Functional Testing
  56. 56. MedTech Stress Testing • When the load placed on the system is raised beyond normal usage patterns to test the system's response at unusually high or peak loads • Reveal application bugs that surface only under high load conditions • Synchronization issues • Race conditions • Memory leak • Provides an estimate of how far beyond the target load an application can go before causing failures and errors in addition to slowness. • Allows you to establish application-monitoring triggers to warn of impending failures. • Ensures that security vulnerabilities are not opened up by stressful conditions. Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 56 Non Functional Testing
  57. 57. MedTech Usability Testing • A black-box technique • Used to identify any error(s) and improvements in the software by observing the users through their usage and operation • Used in user-centered interaction design • Evaluates a product by testing it on users • Can be defined in terms of five factors • Efficiency of use • Learn-ability • Memory-ability • Errors/safety • Satisfaction • Usually involves systematic observation under controlled conditions to determine how well people can use the product • Focuses more on the UX (User Experience) than the UI (User Interface) Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 57 Non Functional Testing
  58. 58. MedTech Security Testing • Tests if the application is vulnerable to attacks • Main security requirements • Confidentiality • Integrity • Authentication • Availability • Authorization • Non-repudiation. • In order to define the main security issues and possible mechanisms for your system, you can consult the Open Web Application Security Project (OWASP: https://www.owasp.org) Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 58 Non Functional Testing
  59. 59. MedTech TESTING DOCUMENTATION Software Testing Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 59
  60. 60. MedTech Documentation • Documentation of artifacts that should be developed before or during the testing of Software • Documentation for software testing helps in estimating: • Required testing effort • Test coverage • Requirement tracking/tracing, etc. • Commonly used documented artifacts related to software testing : • Test Plan • Test Scenario • Test Case • Traceability Matrix Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 60 Documentation
  61. 61. MedTech Test Plan • Outlines: • The strategy that will be used to test an application • The resources that will be used • The test environment in which testing will be performed • The limitations of the testing and the schedule of testing activities • Responsible: Quality Assurance Team Lead • Includes: • Introduction to the Test Plan document • Assumptions while testing the application • List of test cases included in testing the application • List of features to be tested • What sort of approach to use while testing the software • List of deliverables that need to be tested • The resources allocated for testing the application • Any risks involved during the testing process • A schedule of tasks and milestones to be achieved • See the IEEE Test Plan Outline (given in the related documentation) Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 61 Documentation
  62. 62. MedTech Test Scenario & Test Case • Test Case • A set of input values, execution precondition, expected results and executed post condition, developed to cover a certain test condition. • Test Scenario • A detailed test procedure. • Has many test cases associated with it. • Tends to make sure that end to end functionality of application under test is working as expected • Checks if the all business flows are working as expected • The tester needs to put his/her foot in the end users shoes to check and perform the action as how they are using application under test • The tester needs to consult or take help from the client, stakeholder or developers Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 62 Documentation
  63. 63. MedTech Traceability Matrix • Table that is used to trace the requirements during the SDLC • Can be used for: • Forward tracing (i.e. from Requirements to Design or Coding) • Backward tracing (i.e. from Coding to Requirements) • Each requirement in the RTM document is linked with its associated test case • The Bug ID is also included and linked with its associated requirements and test case. • Goals: • Make sure that the software is developed as per the mentioned requirements. • Helps in finding the root cause of any bug. • Helps in tracing the developed documents during different phases of SDLC Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 63 Documentation
  64. 64. MedTech Traceability Matrix Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 64 Documentation
  65. 65. MedTech References Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 65 • Software Development Process (MOOC), https://classroom.udacity.com/courses/ud805/lessons/3608718991/ concepts/4404287840923# • Software Testing, Tutorials Point, https://www.tutorialspoint.com/software_testing/software_testing_q uick_guide.htm
  • OleksandrVinnytskyi

    May. 15, 2018
  • TusharPatil74

    Feb. 9, 2017

Tests

Views

Total views

2,660

On Slideshare

0

From embeds

0

Number of embeds

1,081

Actions

Downloads

164

Shares

0

Comments

0

Likes

2

×