Five reasons to model during QA
•Download as PPTX, PDF•
0 likes•76 views
Model-based testing offers several advantages over traditional documentation-based approaches to quality assurance. It allows testers to create executable models that can automatically generate test cases and scripts, focusing testing on high-risk areas. When the software changes, the model can automatically update dependent tests. Using the same models across teams provides a central point of reference that brings business and development groups into alignment. Modeling catches design flaws earlier in the development process compared to traditional testing approaches.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Five reasons to model during QA
Similar to Five reasons to model during QA (20)
More from Curiosity Software Ireland
More from Curiosity Software Ireland (12)
Recently uploaded
Recently uploaded (20)
Five reasons to model during QA
- 1. © Curiosity Software Ireland Ltd. 2019 Five Reasons to Model During QA September 5th 2019 Tomas Rosenqvist, Consultant, Lemontree Tomas.Rosenqvist@Lemontree.se @LemontreeNordic James Walker, PhD Director, Curiosity Software Ireland James.Walker@Curiosity.Software @CuriositySoft
- 2. © Curiosity Software Ireland Ltd. 2019 Five Reasons to Model During QA 1. You’re already modelling all the time 2. Reasons to Model during Testing and QA 3. Model-Based Testing Demonstration 4. Q&A and discussion
- 3. © Curiosity Software Ireland Ltd. 2019 Lemontree offers Testing as a service DevOps Robotic Process Automation Test automation Test Data ManagementProducts for automation Project, requirements and test management RPA Consulting services Project and product deliveries
- 4. © Curiosity Software Ireland Ltd. 2019 Implicit modelling in testing You’re already modelling all the time
- 5. © Curiosity Software Ireland Ltd. 2019 How many of these make up a system? Could we possible add/change/ remove…?
- 6. © Curiosity Software Ireland Ltd. 2019 How many of these make up a system? Testers and Developers Human Processing Power The system
- 7. © Curiosity Software Ireland Ltd. 2019 Test the Code Testing = cognitive = creative Behaviour-Driven Scenarios ChatOps and Oral Agreements “Flat” diagrams Requirements Documents Email Requests Spoken Agreements BAs/users Continually feed in new requests and stories Developers Create a representation of the requirements as code Test and QA Teams Connect the dots and create their own representation, that they compare to the code: -Test Data -Test Scripts -Test Cases -Environments
- 8. © Curiosity Software Ireland Ltd. 2019 Testers and developers are building models all the time What happens if the user does not do that? How does this relate to those other stories? Where have I seen this context/constraint before? “Implicit” modelling
- 9. Demo © Curiosity Software Ireland Ltd. 2019
- 10. © Curiosity Software Ireland Ltd. 2019 Reasons to Model Explicitly during testing and QA
- 11. © Curiosity Software Ireland Ltd. 2019 • Must have 4 wheels • Must be comfortable • Must be able to transport large and heavy loads • Must be able to turn rapidly • Must have radio receiver • Must run on gasoline How long does it take to process and understand? vs
- 12. © Curiosity Software Ireland Ltd. 2019 Formal documentation: Write-only, write- once, throw away Model-Based Testing: Iterative, executable, evolving. A central point for team discussion.
- 13. © Curiosity Software Ireland Ltd. 2019 You are wrong! This model looks wrong! Can you show me what you mean? Constructive criticism? vs
- 14. © Curiosity Software Ireland Ltd. 2019 1. Modelling overcomes ambiguity and incompleteness • 56% of defects are traceable to the design phase (Bender RBT, 2009) • Some say as many as 59% (IT University, Denmark, 2001) • Or even 63! (Hyderabad Business School, 2012) The best way to ‘test’ against design faults is to catch them as they arise Behaviour-Driven Scenarios ChatOps and Oral Agreements “Flat” diagrams Requirements Documents Email Requests Spoken Agreements Modelling otherwise disparate, unconnected formats spots missing logic and forces us to resolve ambiguities
- 15. © Curiosity Software Ireland Ltd. 2019 2. Automate test asset creation Avoid slow and repetitious test case design, unnecessary scripting, and the bottlenecks associated with test data. • Mathematically precise models allow automated test generation • Test data is generated dynamically for every test • Subflows maximise re-usability • Automated script generation automates tests for a range of frameworks
- 16. © Curiosity Software Ireland Ltd. 2019 3. Coverage Focuses QA • Automated test case design reliably generates the smallest set of tests needed to “cover” the model • Complex systems contain thousands or millions of possible test cases – too many for humans to hold in their heads, but no match for computer processing • You can test exhaustively or focus test creation based on time and risk
- 17. © Curiosity Software Ireland Ltd. 2019 4. Reliably react to change: 1. Parse the code automatically to build a map of its dependencies 2. A Git commit is made 3. Automated impact analysis identifies every component of dependent code that has been impacted. 5. Test assets are (auto-)updated and kept aligned as they are all linked to the same central models. 4. It flags up test cases and user stories that are linked to the code.
- 18. © Curiosity Software Ireland Ltd. 2019 5. A central point of reference for technologies and teams • Models are often already used by BAs and those who gather requirements (VISIO, BPMN) • Using models that deliver value directly “right” in testing and development brings IT and business teams into alignment • Everyone can work from the same central models • “Single pane of glass” automation and Robotic Process Automation connects technologies to models – all metadata updates with them
- 19. © Curiosity Software Ireland Ltd. 2019 A central point of reference Recorded tests activity Test Cases BPMN diagrams Mainframe and databases System under Test Mobile and web Thick client Back-end, APIs, Messages Test Reports and results Auto-update JIRA and HP ALM.Auto-update Trello boards, Git, etc. Slack and email alerts Test Modeller BDD Scenarios Business Requirements Test Data Optimised Test Cases Automated Tests Development Clear Specifications New Iteration Change Request Import New RequirementsDependency AnalysisAutomated Maintenance Application Scans
- 20. Demo © Curiosity Software Ireland Ltd. 2019
- 21. © Curiosity Software Ireland Ltd. 2019 10 (!) Reasons to Model During QA 1. Models are more accessible, easier to understand, and take less time to process 2. Models evolve iteratively 3. Models are “executable” – they deliver value directly in testing and are not thrown away 4. “Shift left” QA uproots design defects earlier 5. Automated test case design 6. Test data tied to test cases 7. Automated test scripting 8. Coverage-focused QA 9. Faster QA Reaction Times 10. A “single Pane of Glass” for technologies and teams
- 22. © Curiosity Software Ireland Ltd. 2019 A full set of learning resources to get you started with Model-Based Testing. Free Model-Based Testing certification is available upon request – get in touch! Visit Testmodeller.io to start your free trial today! © Curiosity Software Ireland Ltd. 2019 Automation experts: DevOps, RPA, and testing. Based in Stockholm with coverage of Scandinavia. A trusted Curiosity partner and modelling experts! Contact Tomas.Rosenqvist@Lemontree.se to carry on the Model-Based Testing conversation!
- 23. © Curiosity Software Ireland Ltd. 2019 Questions and Discussion
- 24. © Curiosity Software Ireland Ltd. 2019 Thank you for listening. James.Walker@Curiosity.Software , Tomas.Rosenqvist@Lemontree.se Email us if you have any questions or feedback, or would like a demo of any of the technology shown
Editor's Notes
- Lösningar, koncept och verktyg för * RPA, * Testautomatisering och relaterade tekniker * Krav- och testdatahantering, * Testing as a service - TAC Konsulttjänster inom * Projekt-, krav och testledning * Teknisk testning och testautomatisering * RPA, digitalisering och robotisering * Testdatahantering * DevOps * Samt tillhörande tjänster
- While text-based documentation can be very precise, it takes our brains time to read and process it. A visual model on the other hand, is more accessible and can quickly give a high-level understanding of the system. When introducing a new team member, we typically want to at least show them the UI and do some whiteboard drawings to help them get a basic understanding before digging into the technical documentation
- Formal documentation, such as requirements specifications, often turn out to be ”write-only” and/or ”write-once” documents. Maybe there’s a brief period of initial uncertainty, contract negotiations etc. where the documentation is thoroughly worked at, but as the development effort moves along, there’s a good chance that the documentation gets left behind. Model-based testing provides you with a model that can be automatically executed and verified against the current state of the system, so that it will always be kept up to date as the system evolves. The model becomes a natural and central point for team discussions.
- Even members of the same team will sometimes disagree with one another, for example when discussing new requirements. It can be hard to vocalize a differing opinion in a constructive manner though. Sometimes heated arguments flare up and sometimes a dissident might refrain from speaking up out of fear of confronting someone else. By shifting the discussion to a visual model, we can challenge the model rather than our colleague and thereby have a more productive collaboration. Ideally such models should be so easy to grok that even someone external to the team should be able to follow and participate in the discussion.