1 / 25

Gastcollege 21-03-2012

Gastcollege 21-03-2012. Testing in practice Bart Knaack Logica Bart.Knaack@logica.com. Who am I?. Bart Knaack, Senior Test Advisor , Logica, The Netherlands 15 years experience in IT , of which 12 in testing.

armina
Download Presentation

Gastcollege 21-03-2012

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Gastcollege 21-03-2012 Testing in practice Bart Knaack Logica Bart.Knaack@logica.com

  2. Whoam I? Bart Knaack, Senior Test Advisor, Logica, The Netherlands 15 yearsexperience in IT, of which 12 in testing. Developer, DevelopmentLead, Tester, Testautomator, Testcoordinator, Testmanager, Testadvisor. Trainer in Testmanagement

  3. Paper clippings

  4. Testpyramide Testgrip RRBT Test Frame

  5. The goal of testing is to finderrors Footer appears here

  6. Testing is trying to buildconvidence in system, bytrying to diminishthatconfidence (and hopefullynotsucceeding) D. Graham Footer appears here

  7. Why testing? Prevent defects duringoperation of the system. Verifyintendedfunctionality ValidationvsVerification €€€ €€€ €€€ €€€ Definition Design Development Production

  8. Black box White box terms according to: Test levels in the V-model User needs, Requirements, Business processes Acceptance Test Test specification Test execution System Integration Test System Specification System Test D y n a m i c T e s t i n g S t a t i c T e s t i n g Component Integration Test Technical Design & Code Component Test

  9. Also called ‘white-box’ or ‘structural’ testing Testers have access to the system design They can Examine the design documents View the code Observe at run time the steps taken by algorithms and their internal data Individual programmers often informally employ glass-box testing to verify their own code Glass-box testing

  10. Testers provide the system with inputs and observe the outputs They can see none of: The source code The internal data Any of the design documentation describing the system’s internals Black-box testing

  11. BoundaryValueAnalysis Equivalencepartitioning BranchCoveragetesting Test Techniques

  12. Equivalence Partitioning Requirementsdivide data in ranges of equivalent behavior. All peoplebetween 25 and 65 have to pay premium fortheirretirement. All peopleolderthan 65 get a pension. All peopleearninglessthen €5000 do not have to pay premium. These classes need to betested

  13. Equivalence Partitioning Requirementsdivide data in ranges of equivalent behavior. All peoplebetween 25 and 65 have to pay premium fortheirretirement. All peopleolderthan 65 get a pension. All peopleearninglessthen €5000 do not have to pay premium. These classes need to betested

  14. Boundary Value Analysis Requirementscontainvalues All peoplebetween 25 and 65 have to pay premium fortheirretirement. All peopleolderthan 65 get a pension. All peopleearninglessthen €5000 do not have to pay premium. These valuesform the basis for setting up testcases

  15. Boundary Value Analysis Requirementscontainvalues All peoplebetween25 and 65 have to pay premium fortheirretirement. All peopleolderthan65get a pension. All peopleearninglessthen€5000 do not have to pay premium. These valuesform the basis for setting up testcases

  16. You are donetestingwhen all possible tests have been executed Footer appears here

  17. No Risk, No Test Footer appears here

  18. RRBT: risks versus requirements Matching risks with requirements • Risk, no requirement: • Add requirement (earlier error detection) • Delete risk (No useless testing) • Requirement, no risico: • Adapt Risicolijst(better coverage) • Delete Requirements (no useless development, no “frails”) Requirements Product Risks Matching requirements with risks

  19. Must have Should have Could have Won’t have Must test Should test Could test Won’t test Prioritze requirements Assess Impact risks Definetestcases Combine productrisks en requirements Analyse requirements Analyse risico’s

  20. Kwaliteitsattributen ISO9126 Kwaliteitsattributen Kwaliteitsattributen ISO 9126 ISO9126 Functionaliteit Functionaliteit Betrouwbaarheid Betrouwbaarheid Bruikbaarheid Bruikbaarheid Onderhoudbaarheid Onderhoudbaarheid Portabiliteit Portabiliteit Efficiëntie Geschiktheid Geschiktheid Volwassenheid Volwassenheid Begrijpelijkheid Begrijpelijkheid Tijdsbeslag Tijdsbeslag Analyseerbaarheid Analyseerbaarheid Aanpasbaarheid Aanpasbaarheid Nauwkeurigheid Nauwkeurigheid Fout tolerantie Fout tolerantie Leerbaarheid Leerbaarheid Middelenbeslag Middelenbeslag Wijzigbaarheid Wijzigbaarheid Installerbaarheid Installerbaarheid Connectiviteit Connectiviteit Herstelbaarheid Herstelbaarheid Opereerbaarheid Opereerbaarheid Stabiliteit Stabiliteit Inschikkelijkheid Inschikkelijkheid Veiligheid Veiligheid Aantrekkelijkheid Aantrekkelijkheid Testbaarheid Testbaarheid Uitwisselbaarheid Uitwisselbaarheid Functionaliteits Functionaliteits Betrouwbaarheids Betrouwbaarheids Bruikbaarheids Bruikbaarheids Efficiency Efficiëntie Onderhoudbaarheids Onderhoudbaarheids Portabiliteits Portabiliteits naleving naleving naleving naleving naleving naleving naleving naleving naleving naleving naleving naleving

  21. Types of testing Functionaltesting Usabilitytesting Performance testing Stress testing Penetrationtesting Footer appears here

  22. Heuristicevaluation (Nielson) Visibility of system status Match between system and the real world User control and freedom Consistency and standards Error prevention Recognition rather than recall Flexibility and efficiency of use Aesthetic and minimalist design . Help users recognize, diagnose, and recover from errors Help and documentation Footer appears here

  23. Most of the time spend in testing is wastedeffort. Footer appears here

  24. Quality is always under pressure Planning and Specification Development Testing

  25. Tasks of a tester RequirementsAnalysis Risk Analysis Testcase Preparation StakeholderInvolvement Test Execution Bug Reporting Bugfix meetings Retesting Reporting

More Related