Understanding Requirements-Based Testing in Software Development
Dive into the world of requirements-based testing in software development, exploring main concepts, test levels, testing roles, and the importance of testing your solution and modeling case. Learn about test cases, different testing activities, and the significance of acceptance testing in identifying defects from requirements and specifications. Discover the distinctions between developers, end-users, and testers in the testing process.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
2 Main concepts behind testing Different terms are used, but the most important distinction is Software failure / Defect: the software does not behave as expected noticed by the end user/tester Cause is a "bug" error made by a programmer "Bugs" can go unnoticed if they never lead to software failure e.g. when a certain functionality of the software is not (yet) used LIRIS
Main Concepts behind testing Testers have a different view on requirements compared to other stakeholders Test activities Define set of test cases Test execution + comparing real against expected results Application real output Test Case Case Case Case Test Test Test test result model compare expected output specs (oracle)
Test levels Acceptance testing Requirements-based System, Integration, Component testing Code-based
Testing your modelling case solution Basically "Acceptance Testing" Motivation Reveal defects in the model created from the requirements Reveal defects in the specification that is used as reference for testing
Testing roles Developer Bad tester because being biased by knowledge on how the software works End-user Can be a good tester, but can also lack testing skills Tester Person trained at testing: Knows about test strategies Fluent in defining scenarios e.g. narrowing down to find the exact situation of the problem.
Testing your solution Assumption: prototype is correct implementation of model The source of the problem is the model, not the application ! Model Application real output test strategy Test Case Case Case Case Test Test Test test result Specs compare expected output specs (oracle)
What is a test case A test case is a "scenario" = a sequence of steps performed with the aim of achieving a goal Starts from a predefined situation Free format: when the system in state such & such do steps 1, 2, 3, ... observe that x...y...z Gherkin syntax (see e.g. https://en.wikipedia.org/wiki/Cucumber_(software)) Given ... (precondition) when .... (action) then ... (result)
Developing a testing strategy Defining test cases Testing only shows the presence or defects, not the absence ... Exhaustive testing is impossible (intractable) test all valid inputs test all invalid inputs test all edited inputs test all variations on input timing even the halting problem is undecidable Criteria/strategies for test case selection are necessary
Types of scenarios Instance versus type scenarios register that a professor teaches a course register that Prof. Snoeck teaches AMMIS Positive versus negative scenarios goal is satisfied or not satisfied Allowed versus not allowed scenarios Misuse: goal is satisfied, but scenario is not allowed e.g. withdraw money from a bank account using a stolen card.
11 Main concepts behind testing There are many different types of testing to perform Functional Testing Whether the software fulfills the functional requirements (= check for defects) Performance Testing Security Testing Usability Testing ... LIRIS
Main concepts behind testing Exhaustive testing is not possible Build confidence in the quality of software (i.e. low probability of software failure) Develop a test strategy: chose a limited set of tests that maximize the confidence in the absence of errors Some will-known strategies Coverage-based testing Boundary-value testing Mutation-based testing / Fault seeding
Main concepts behind functional testing Exploratory testing Does not really follow a specific strategy, but looks for the general experience (useful for UX evaluation) Coverage-based testing = when is the testing sufficiently complete? can be defined in terms of the requirements of system features of the the components of the code
Ensuring coverage Code based checking if all code has been visited Requirements-based Derivation from specifications Model-Based Test Case derivation e.g. covering class diagrams and transition coverage for FSMs
Test strategy Coverage Model-based coverage Do your test scenarios cover all classes in the class diagram ? Do your test scenarios cover all FSMs and their states ? Text-based coverage Has every requirement been covered ? Different types of scenario's to consider !
Types of scenarios to consider Positive (goal satisfied) Negative (goal not satisfied) Start from a goal Register work hours Registration of worked hours on a project I m assigned to fails due to the project being closed already and I m warned. I register worked hours on a project I m assigned to. Define the precondition/system state at start of scenario: Precondition: I'm assigned to project XYZ Scenario Allowed I (successfully) register worked hours on a project I m assigned to while project has already been closed. Scenario Not Allowed Registration of worked hours on an open project I m assigned to fails Define the actions defect ! defect ! Consider 4 types of scenarios for 1 goal !
