1 / 20

From textual requirements to test models - Coping with natural language ambiguities for testing

Fraunhofer Institute for Open Communication Systems | Kaiserin-Augusta-Allee 31 | 10589 Berlin, Germany. From textual requirements to test models - Coping with natural language ambiguities for testing. Marc-Florian Wendland | RCIS 2013 Industrial Day | 31 st May, 2013 | Paris, France.

kobe
Download Presentation

From textual requirements to test models - Coping with natural language ambiguities for testing

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. Fraunhofer Institute for Open Communication Systems | Kaiserin-Augusta-Allee 31 | 10589 Berlin, Germany

  2. From textual requirements to test models - Coping with natural language ambiguities for testing Marc-Florian Wendland | RCIS 2013 Industrial Day | 31st May, 2013 | Paris, France

  3. Agenda • Motivation • Requirementsand model-basedtesting • Conclusion

  4. Agenda • Motivation • Requirementsand model-basedtesting • Conclusion

  5. From textual requirements to test modelsSomefactsaboutrequirements Costsoffixingsoftwaredefects: • logicalarchitecture1.000 € • technicalarchitecture4.000 € • realisation12.000 € • acceptance / rollout48.000 € • in field90.000 € • [2] [1] Costs per bugfound As much as 60% of all defects in a systems lifetime originate from deficient requirements [3] - bugsintroduced 45% 40% 55% - bugsfound 30% 15% 10% 5% in field req. spec. impl. design [4]

  6. From textual requirements to test modelsImpact network of requirements Req. Engineering Test Analysis System/SoftwareRequirementsSpecification (SRS) Test Requirements Requirements <<organizes>> <<verifies>> <<realizes>> <<interprets>> System Dev. Test Design <<realizes>> <<covers>> System/Software Specification System/SoftwareTestSpecification 1..* <<satisfies>> <<satisfies>> Test Exec. Implementation <<executesagainst>> Test Case

  7. From textual requirements to test modelsRequirements specification techniques Visual Notation Restricted NL Formal language Unrestricted NL Formalismandprecision Grantedfreedomtoengineers Suitableforautomatedtransformation Acceptance in industry We need an approach that copes with natural language ambiguity and imprecision.

  8. From textual requirements to test models Satisfaction with requirements engineering tasks Requirementselicitation Requirementsanalysis Requirementsspecification Requirementsvalidation Requirementsmanagement [5] high 50% of all respondentsseesunsufficientlyspecifiedrequirementsasbiggestchallengefortesting medium low

  9. Agenda • Motivation • Requirementsand model-basedtesting • Conclusion

  10. From textual requirements to test modelsState of the art in automated test design – Model-Based Testing Test Plan Requirements TC TC TC SUT SUT SUT Formalisation Test Model Implicit knowledge • Implicit/imperfectknowledgeismade explicitand (semi-)perfect • Test design isdone on themodel • Repeatable, comprehensibleandsystematic • Preventslossofknowledge • Model isself-documented • Quality oftestmodeldepends on experiencesandingenuityofthetester Intellectualtask Automated clericaltask

  11. From textual requirements to test models Requirements models as starting point • Introduce a dedicated requirements model • Formalize the externally observable behavior of the system based on its requirements • Requirements model can be exploited to partially facilitate activities both system and testing side • Shared source of information for further development We need a methodology, which ensures the requirements model is complete, unambiguous, consistent, correct and testable (IEEE 830)

  12. From textual requirements to test modelsWhatisBehavior Engineering? Model-centric Document-centric Phases of BE Validation (IBT) Formalisation (RBT) Integration (pIBT)

  13. From textual requirements to test modelsRequirementsFormalisation – Translation Requirement 1 There is a single control button available for the use of the oven. If the oven dooris closed and the user pushthe button, the oven will start cooking (that is, energizethe power-tube) for one minute. RBT Translateeachsinglerequirementindependently CT User

  14. From textual requirements to test modelsRequirements Integration Precondition Axiom Every constructive, implementable, individual functional requirement of a system, expressed as a behavior tree, has associated with it a precondition that needs to be satisfied in order for the behavior encapsulated in the functional requirement to be applicable." Interaction Axiom For each individual functional requirement of a system, expressed as a behavior tree, the precondition it needs to have satisfied in order to exhibit its encapsulated behavior, must be established by the behavior tree of at least one other functional requirement that belongs to the set of functional requirements of the system."

  15. From textual requirements to test modelsRequirements Integration Precondition Axiom Every constructive, implementable, individual functional requirement of a system, expressed as a behavior tree, has associated with it a precondition that needs to be satisfied in order for the behavior encapsulated in the functional requirement to be applicable." Interaction Axiom For each individual functional requirement of a system, expressed as a behavior tree, the precondition it needs to have satisfied in order to exhibit its encapsulated behavior, must be established by the behavior tree of at least one other functional requirement that belongs to the set of functional requirements of the system."

  16. From textual requirements to test models(Test) Analysis model as result of BE IBT CT Fokus!BE BE with UML

  17. Agenda • Motivation • Requirementsand model-basedtesting • Conclusion

  18. From textual requirements to test models Conclusion • Requirementsare still mostlyspecifiedtextuallywithunrestrictednaturallanguage • Requirementsvalidationtechniquesneedtocopewithunrestrictednaturallanguage • BE is a methodologythatisaimingatvalidatingtherequirementsbyintegration • BE alleviatesthetransitionfrom a requirementsmodeltofurthermodels • Testingishighlydepending on thequalityoftherequirements • MBT ishighlydepending on thequalityofthemodelthatmodeltherequirements • BE ispredestinedtotacklecurrent model-basedtestingchallenges • BE with UML seemswisesincesystem/testmodelsareoftenrepresented in UML/UTP

  19. Thanks for your attention.Questions?

  20. References [1] Boehm, Berry: Software Engineering Economics, Englewood Cliffs, NJ : Prentice-Hall, 1981. ISBN 0-13-822122-7 [2]Spillner, A: SQS Empirische Daten aus 3000 IT-Projekten. 1st Testing Day Franken, Nürnberg, 10-March-2009 [3] Berry, D. M.: Formal methods: the very idea - some thoughts about why they work when they work. Sci. Comput. Program., 42(1):11–27, 2002 [4] Standish Group: ChAOS Reports. URL: http://www.standishgroup.com. Last visit: January 05, 2012 [5] SwissQ, Trends und Benchmark Report Schweiz, Wostehenwir, wogehteshin? Testing 2013, http://de.slideshare.net/swissq/testing-trends-und- benchmarks-2013-web

More Related