Finding bugs before implementation
It’s always been a passion of mine to find the real root causes of bugs, better understand them, and put in place controls that will help avoid similar unwanted side effects of development from happening in the future. Fortunately today Quality Engineers are expected to shift left and focus on prevention, which really helps me with following my passion.
In Spartez and Atlassian we shift to the very edge of left. Experiment and try techniques we hope can help us spot issues before implementation even begins.
During our workshop we would like to share with you few techniques we found valuable.
We’re going to walk you through an activity that usually takes place before coding a feature starts. We call it feature kickoff.
During feature kickoff people representing different roles and perspectives look at the problem they are going to tackle in upcoming months from different angles. They are trying to do everything in their power to fully understand true depth of a feature. Learn all known unknowns, assumptions, open questions, risks, and also by working together, identify all unknown unknowns.
Quality Engineers to drive the meeting efficiently came up with a framework, a physical deck of cards, so called Quality Cards. Those cards are divided into three categories. Each category represents a technique that one can use to increase their understanding of a problem.
First, we are going to interrogate feature. By designing, asking, and findings answers, we will help you find all assumptions needed confirmation – open questions, and also all invalid assumptions, that could have caused bugs. We very often find ourselves asking questions at late stage of feature delivery, when it’s being implemented, or already implemented. Interrogating feature helps find potential issues at early stage of the process, help avoid waste and bugs.
Second, we will look at a problem from various perspectives. Decompose the feature. At this stage, we will ask you to look at the feature by its technical architecture, ask you to analyse dependencies between blocks building the feature. We will also ask you to understand how the feature looks like from logical perspective, how does it model business domain, what kind of relations it assumes and builds. Finally, what kind of activities are involved in the feature, how they relate to each other, and how they may affect implementation.
Feature kickoff ends with heuristics. Categories of problems generating bugs. Do we expect security issues? What kind of issues? How we are going to mitigate the risk, at what stage?
We hope you will enjoy the journey and use presented techniques in your day job to find bugs not yet materialised but hidden in people’s understanding of a problem or rather it lack of.
Who is it for?