Each month at Veterans United we provide a forum for lunch and learn activities. These can be instructional, similar to TED talks or sharing new information related to software development and process. Recently the software testing team presented at this venue what it means to be a tester. My main motivation for this event was to expose our developers to the role and the work of a software tester and to better understand what testers look for. I had watched a portion of Kate Falanga's talk Teaching Testing to Non-Testers in which she suggests using a stapler as a basis for exposing testing to non-testers. In the talk she discusses this idea originated from another blog with 100+ test cases for the stapler.
One area I sought to improve after Veterans United hosted its most recent internal conference "Agile Days" was providing a talk that focused more on workshopping an idea. While I love discussing code I felt that our audience would gain the most appreciation of the role if we had them working in groups to test something together. Originally I came up with a quite complicated idea and luckily meeting with our very talented amazing set of QA Engineers we refined the idea to its simplest form.
We gave a short presentation about where QA has been and where it is going then at the end we provided a vague set of acceptance criteria for a "Paper Grouping Device". We wanted 20 papers to be grouped, they should be readble, and the paper should not be damaged as well as detachable from the device.
The group of 30+ people were split into around 6 groups and given writing materials/posters to expose their creativity and they certainly suprised our QA Engineers. To the point that next time we might include some more strict restrictions such as reinventing PDFs. Incidentally during this event no one reinvented staplers.
We gave the teams 5 minutes to come up with an implementation. Optionally it might go smoother to decide for groups what their item would be but there would be less creativity in test cases in some ways. The next time period became what questions you would ask your product owner about clarifying whether the product meets the criteria. Finally test cases you would design for this product to ensure it is meeting its operational characteristics.
Our QA Engineers walked around the room and answered questions about how they would approach testing the particular devices. Once everyone lost steam with their test cases, product owner questions, and drawing their products we had them present to the room what they had come up with. Then our highly incisive QA Engineers narrowed in on some tough questions about these products that revealed gaps or created more interesting conversation.
It was a fun activity and I look forward to helping our teams better understand the role as they create new products.
Top comments (0)