O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
A live webinar presented by Curiosity Software on October 21st 2020, featuring Jim Hazen.
Watch the on demand webinar recording - https://us02web.zoom.us/rec/play/6AvhjXKlWxyv-bpXIbfNMBP545etsnKqVDg6EBspto0ttfc8mnx5Njnxf2-jWIl9FknKjxMlIJo86ioV.u1bewtXzzwMAcs5i?startTime=1603295712000
Visual modelling is nothing new in software development, from the diagrams today drawn in sprint meetings, to defined methodologies like systems modelling, visual task analysis and UCML. Applied to perennial challenges in testing, modelling can accelerate test creation, reduce test maintenance time, and help define upfront the complex data needed in testing. In their fullest application, models bring stakeholders across the delivery lifecycle into close collaboration: System designers can formulate requirements in visual models, with engineers rapidly developing and testing in parallel from the accurate specifications.
Jim Hazen is a 25-year veteran of automation in testing, who in recent years has developed a keen interest in modelling for testing and development. Jim will discuss the practical value of different modelling approaches live on this webinar, illustrated through real-world experiences and stories. Posing the question of whether any one approach can realise the full potential of modelling, Jim will hand over to Curiosity Director of Technology James Walker. James will provide a practical demonstration of cutting-edge techniques in model-based test and requirements design, discussing how they are helping organisations design, develop and build quality software in short iterations.
Traditional modeling techniques tend to be done as part of the overall process and not really collaborative. Input/Feedback loop is slower and prone to miscommunication.
Modern modeling techniques can be done as part of the front-end work and be more collaborative. Input/Feedback loop is faster and lead to clearer communication. Can be part of a “Shift-Left” effort to push testing and testers to earlier in the process. Can push BA’s, PM’s, Devs and Testers to work more collaboratively.
FFD useful for determining different scenarios/paths through system. Helps with E2E scenarios and determining what could be tested in isolation. This can also be created using UML (Unified Modeling Language) techniques.
Determine negative conditions to inject and if the system will react correctly for error handling.
DFD’s are very useful for data design and creating validations for data state and transformation process.
Helps to determine the data types to be utilized in testing and automation. Can be used to determine valid and invalid data sets.
Defines Actions, States, and transitions that are useful for scenario development and test data design/determination.
These are also known as Finite State Machine (FSM) diagrams. And this is the basis of Model Based Test automation frameworks.
A way to categorize, group and prioritize all at the same time is to use the method created by Jeff Patton now called Story Mapping. This is a visualization technique for representing the system under test in a graphical manner. It allows for a high-level abstraction of the possible usage scenarios to perform for testing overall. As part of this work you can also start to determine the data and data conditions to be created and utilized during test execution. In turn, this helps to determine what has to be handled by the automation code.
Good for functional decomposition of system and determining what type of data may be needed for test to work. Mind Maps. Are another way to visually organize information in a hierarchical format that shows the relationship of pieces to the whole. The central idea, or concept, is at the center of the diagram and all of its parts are placed around it and spider webbed into it. You can think of it as being a graphical representation of a written hierarchical outline.
Scott Barber, used for Performance Testing. Design usage scenarios and workload models. Useful for functional automation in design of test scenarios and functional components to map/build.
Scott Barber's User Community Modeling Language (UCML) methodology supports the 80/20 rule. It is used for Performance Test work but is applicable for automation as well. As part of mapping the functionality, you also calculate the usage percentage of the functionality. It is a way of seeing the frequency of use and can help to prioritize what tests to automate first. It is useful for individual functional testing as well as End-to-End testing.
Richard Bradshaw & Mark Winteringham model, used to determine what to automate and at what layer in technology stack. Also helpful in determining data needs. Visual Task Analysis starts by modeling visually the application stack. Breaks down the different layers of the stack and places them on the left side of the diagram. Between each draw a line to represent the layer, or seam. Next represent the different processes at each layer of the logic flow by drawing a circle and labeling it. Connect the processes with lines that represent the action being performed. From this diagram we see 10 possible points in the flow for a check (test) to occur. Most of these occur below the UI layer. This view below the surface provides a better understanding of what is really going on, and the types of automated tests we need to build.
Tim Harrison – useful for designing generic scenarios for BDD tests and their data requirements. Keeps from getting too deep into the weeds in the GWT syntax. BBT is a visual approach to mapping requirements to test cases. Instead of hard-coding tests for each individual requirement, you map out context, events and outcomes, and then translate these to Gherkin-style test cases. Approach is similar to Behavior Driven Development (BDD), but is visual and can provide a higher level of coverage. The BBT approach is based on automating the individual steps needed to complete multiple test cases. Each context, event and outcome is automated in easy-to-maintain code snippets. The automation then pulls in whichever context, event and outcome it needs to create the test. This leads to a natural Data-Driven approach.
Business Process Model and Notation (BPMN). It is a standard way for modeling business processes using a graphical notation and is based on a flowcharting technique very similar to Activity diagrams in UML. This type of model is used by tools that support Robotic Process Automation (RPA). There are even some tools in the Software Test realm that use this type of modeling for test scenario, test case, and test data generation. Some of them even allow for code generation for use by various automation tools.
BPMN models are a higher level abstraction of process and include Events (something that happens), Activities (describes the kind of work being done, or work that a company performs), Gateway’s (a decision point), and Connections (flow to next item).
In the beginning there wasa model: Using requirements models to drive rigorous test automation