Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Test Design and Management in context of IFDK reference product PowerPoint Presentation
Download Presentation
Test Design and Management in context of IFDK reference product

Test Design and Management in context of IFDK reference product

101 Views Download Presentation
Download Presentation

Test Design and Management in context of IFDK reference product

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Test Design and Management in context of IFDK referenceproduct

  2. About this course material • This material if for general training for Test Design and management • Material is more supportive in class room • Material will be updated during courses • FreeNest Portable Project Platform is used to demonstrate things only in practice. This is not limiting usage for material for other training environments (I hope ) Aboutmaterial

  3. Example of IFDK productconcept IFDK = Internal Flame Drum Kit Requirement Management

  4. Differentaspects to product QA Tester Customer Seller Developer Yläotsikko

  5. Different requirement levels Customer/Business/Stake Holder Requirements System Requirements Scalability Stability Performance Design Requirements Security Performance Stress Component Requirements Usabilty Implementation

  6. V-Model in testing Verification and Validation Customer Requirements Acceptance Testing System Requirements System Testing Integration Testing Sub System Requirements Component Requirements Component/Unit Testing Verification = Are we building the product right? Validation = Are we building the right product? Yläotsikko

  7. Why we need requirements from testing point of view? ”Traditional Testing Levels” „Test Engineers Area“ Customer/Business/Stake Holder Requirements Acceptance Testing System Testing System Requirements Design Requirements Integration Testing „Developer's Area“ Component Requirements Unit Testing Implementation

  8. IFDK System Verification and Validation IFDK Product Ideas Product VALIDATION Features Customer/Business Requirements Acceptance Testing Validation = Are we building the right product? Verification = Are we building the product right? Use Cases System Requirements System Testing Architecture& Design& Implementation Sub System Requirements Integration Testing User Storys Component Requirements Component / Unit Testing VERIFICATION Requirements VALIDATION vs VERIFICATION? Yläotsikko

  9. You have vision of productWhat means testing in brief? Ready to test Product Design & Implementation Testing & Quality Assurance Features Test Case Ready to Deliver Test Case Use Cases Not ready to deliver Can we deliver Product User Storys Test Case ? Customer Test Case Requirements Yläotsikko

  10. Verification vs Validation? Validation = Are we building the right product? Verification= Are we building the product right? Verification Validation Product Design & Implementation Testing & Quality Assurance Ready to test Features Test Case Ready to Deliver Test Case Use Cases Can we deliver Product Not ready to deliver User Storys Test Case ? Customer Test Case Requirements

  11. SW Development Process (Waterfall) Requirement Gathering/Evaluation Design Implementation Verification & Validation Error Managment Process Maintenance Mile Stone 1 Mile Stone 2 Mile Stone 3 Task1 Task1 Task1 Task1 Task1 Task1

  12. Testing Orientation http://en.wikipedia.org/wiki/Software_testing Black Box Testing “SYSTEM TESTING” Perspective Grey Box Testing White Box Testing “CODE LEVEL TESTING” Perspective

  13. Black Box vs White Box Testing ? ? Black Box Testing for selected component Unit Testing is White Box testing Yläotsikko

  14. TESTING LEVELS

  15. Unit/Module/Component Testing Product VALIDATION Customer/Business Requirements Acceptance Testing System Requirements Architecture& Design& Implementation System Testing Sub System Requirements Integration Testing Component Requirements Component / Unit Testing VERIFICATION Yläotsikko

  16. How to Test? What should be tested? How ?

  17. How to test? What should be tested? How ?

  18. How to verify component implementation -Unit Testing -Code Coverage -Branch Coverage -Complexity Analyse Yläotsikko

  19. Component /Unit Testing Developer Implemented Class Unit Test Frame Work TestClass Class Class Class Class Test Method Call Attributes Attributes Attributes TestMethodCall Method Result Methods Methods A=1 B=2 C=Class.TestMethodCountValues(A+B) C<>3 FAIL C=3 PASS MethodCountValues( int x, int y) z=x+y+1 Return z

  20. Code Coverage An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage. http://en.wikipedia.org/wiki/Code_coverage http://www.atlassian.com/software/clover/ Yläotsikko

  21. Branch coverage The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage. Yläotsikko

  22. Code Complexity Example tool CCCC https://wiki.jenkins-ci.org/display/JENKINS/CCCC+Plugin http://sourceforge.net/projects/codeanalyze-gpl/?source=recommended Yläotsikko

  23. Integration Testing Product VALIDATION Customer/Business Requirements Acceptance Testing System Requirements Architecture& Design& Implementation System Testing Sub System Requirements Integration Testing Component Requirements Component / Unit Testing VERIFICATION Yläotsikko

  24. Integration Testing

  25. How To Test ? What should be tested? How ? http://prosentti.vero.fi/veropros_tietojen_syotto2011.asp

  26. Why Integrate first? Avoid Big Bang! Web Service HW Component Data Base Component/Application 10% tested Tested Component/Application Yläotsikko

  27. System Testing Product VALIDATION Customer/Business Requirements Acceptance Testing System Requirements Architecture& Design& Implementation System Testing Sub System Requirements Integration Testing Component Requirements Component / Unit Testing VERIFICATION Yläotsikko

  28. How to test? What should be tested? How ?

  29. System Testing in Large DB ? Sales DB Application & Gateways Application & Gateways What should be tested? How ? Application CRM DB Room Reservation DB

  30. System Acceptance Testing Product VALIDATION Customer/Business Requirements Acceptance Testing System Requirements Architecture& Design& Implementation System Testing Sub System Requirements Integration Testing Component Requirements Component / Unit Testing VERIFICATION Yläotsikko

  31. What to test? http://www.123rf.com http://www.123rf.com What should be tested before so customer could be so happy ? How ?

  32. IFDK Verification/Validation (Testing Organization) Product Release Acceptance Test Engineer IFDK System Acceptance Testing System Test Engineer Test Manager IFDK System Testing Project Manager Acceptance Testing Designer/Coder System Testing Integration Test Engineer Test Automation System Testing Error Manager Feature Unit/Integration Testing Regression Testing Feature Pack Validation Verification Unit Testing Report Staus Error Database Test Management Database Regression Testing IntegrationTesting

  33. What should be tested? Input ? Output?

  34. What is Test Design? REQ-X REQ REQ-O What I should check ? REQ-Z REQ-Y Implementation IDEAL Yläotsikko

  35. Why we need test design? • Discuss about reasons for test design? • Why we need to do design? • Stupid work  ! I wan’t to progress!??

  36. Test Case Design

  37. UNDERSTAND YOUR TEST LEVEL Product Release Acceptance Test Engineer IFDK System Acceptance Testing System Test Engineer Test Manager IFDK System Testing Project Manager Acceptance Testing Designer/Coder System Testing Integration Test Engineer Test Automation System Testing Error Manager Feature Unit/Integration Testing Regression Testing Feature Pack Validation Verification Unit Testing Report Staus Error Database Test Management Database Regression Testing IntegrationTesting

  38. What Information Test Case should contain? Add Information about case • Test Case Id • Test Case owner/writer • Date • comments Verify what? Using configuration? With tools? • Verify drum track player pause mode functionality. • Do this with IFDK software release X and playing song ”Show must go on by Freddy Mercury” • Test should be done using android emulator environment and using your hands, ears and eyes” • Pre State: • Android emulator is running • Release X is installed on emulator • Test Case Steps: • 1. Open drum kit player application • 2. Select song ”Show must go on” • 3. Start to play • 4. Press Pause and check song is paused • 5. Check memory usage from system application • 6. Press Play • 7. jump to 4 several time (<10) • 8. Listen song to the end • 9. Exit player using ”exit button” • End State: • IFDK Kit in main screen mode Define pre-state Define Steps Define end-state What is verdict? • If Pause is working result is PASS. If Pause mode failed result is FAIL

  39. Why we need test design again! • Stupid work! This takes ages! This Test Case documentation is old as soon I have changed some implementation? Why you need to do so hard documentation? Give me a one good reason!

  40. Checklist? Check UI is working Working? Check color change Working? Check Counter value after 50 logins Working? Check disable mode for counter Working? Checklist can be working great in small team!  What happens if team is disbanded to other projects? And you are new maintainer for this project?

  41. Agile Thinking? • We have to automate all tests!! No sense to create documentation ? • Who does automation without a design?

  42. Where I find sources for test design? Mixed Specification based Testing design Negative Testing Test Case Step Step Step Design based test desing Write Test Engineer’s Daily Job? Requirement based test design Defect based test design Test Design Method Functional test design • Customer's Idea • Brainstorm • Intitution • Exploratory NonFunctional test design

  43. How to create Test Case??? Acceptance Test Case Functional Test Case Choose Case Type Non-Functional Test Cases Check different sources & strategy for Test Case design WRITE A Test Case! What is Testing level Field Test Case Interoperability Test Case Conformance Test Case Regression Test Case

  44. Test Case Design in agile framework User Story: Implementation Done As a user I would like to use my google account for login Definition for Acceptance Criteria Definition for test cases Check list Verify Test Verify Test Verify Test Verify Test Tested using test automation?

  45. Test Driven Development TDD in all levels! Design draft Tests Case Define Architecture & Design? Design Tests Implement Code

  46. Unit Testing

  47. Test Driven Development and Unit Testing DEFINE TEST CASES FIRST!!! Developer IMPLEMENT CODE AGAINST TESTS Implemented Class Unit Test Frame Work TestClass Class Class Class Class Attributes Attributes Attributes Test Method Call Methods Methods TestMethodCall Method Result A=1 B=2 C=Class.TestMethodCountValues(A+B) C<>3 FAIL C=3 PASS MethodCountValues( int x, int y) z=x+y+1 Return z

  48. Ideal project team and unit testing Software Product Integration Integration test engineer #1 Integration test engineer #2 Test Sand Box Test Sand Box Test Sand Box Test Sand Box Developer 1 Developer 2 Developer 3 Developer 4 TESTS TESTS TESTS TESTS Implemented Software Component #3 Implemented Software Component #4 Implemented Software Component #2 Implemented Software Component #1

  49. Integration Test with stubs/mocs STUB/MOCK Component STUB/MOCK Component Simulated Interface Log Tested Component/Application Control Interface Messages/Events Control Configure Scripted STUB Interface