Hiccupps

I joined a new project this week. Me and a couple of engineers from my team are being asked to build a service to provide access to data sources, both in-house and external. As the lack of this data is being felt some distance from our team's main product, we haven't been involved in conversations up to this point. A kick-off meeting was the first opportunity for us to meet the various stakeholders and hear them say in their own words what they're looking for. This is usually an interesting phase in a project because there's lots of scope for ambiguity, conflicting vision, missing requirements and so on. But how to navigate it? No two projects are the same so I don't have a standard approach. The things I did around the meeting are reasonably typical and include: I looked for project documentation on Confluence, read it, and tagged the pages. I looked for other Confluence pages on the same topics, and tagged them too. I looked in Jira for recent tickets on the same

In recent times I've spoken and written about how much fun and how productive it's been to build random walkers to help me to test services I've been working on: Walking the Talk webinar , A Model Student , and Navigate, Survey, and Explore . The walkers are clients which use dice rolls to make decisions as they navigate paths through a service, asserting things about the state as they go. Traditional unit tests tend to be extremely specific. They imagine the system in a particular state with a hard-coded input and an expected output.  In my walkers, the assertions are relatively generic, for example: a service response payload conforms to a schema the value of a field representing progress will not decrease across a series of interactions some values in service responses must be in a particular relationship to others, or to the input. I doubt this is a technically-correct use of the term but I've been thinking of th

I've created a state model-based testing tool for the service I work on using Altwalker . I call the tool a walker because it walks the model, interacting with the service as it traverses edges and making assertions about the state in each node. The service itself is stateless so I've actually been building a model of the kinds of interactions that it allows. Initially I modelled the journeys our clients make and this was helpful to get a better understanding of our client needs and gripes and also some of the nuances of our API that I hadn't been aware of before. However, while building and exploring the model I've discovered some other permitted, functional, consistent, but unintended ways to interact with the service.  I decided to keep them in the model because they exist and can be exercised and if their behaviour changes it might tell us we've done something we weren't expecting. But I've been adding configuration options to allow them to be turned o

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "What is the best testing metric?" Now there's a question that has occupied many minds for many long hours. Don't worry, though, because this will be a short answer.  We've sp

Last week I attended a meetup on API testing with Mark Winteringham . In it, he talked through some HTTP and REST basics, introduced us to Postman by making requests against his Restful Booker bed and breakfast application, and encouraged us to enter the Test.bash() 2022 API Challenge which was about to close. The challenge is to make a 20-minute video for use at the Ministry of Testing's October Test.bash() showing the use of automation to check that it's possible to create a room using the Restful Booker API. I talk and write about exploring with automation a lot (next time is 14th October 2022, for an Association for Software Testing webinar ) and I thought it might be interesting to show that I am not a great developer and spend plenty of time Googling, copy-pasting, and introducing and removing typos. So I did and my video is now available in the Ministry of Testing Dojo . The script I hacked during the video is up in GitHub . My