This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: The JIRA QA Process
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
This is the first in a series of blogs on Atlassian QA. We will cover how the QA strategy has been implemented in different teams, the tools and techniques we use, and the personal experiences from members of the team. The JIRA engineering team is large, consisting of 78 developers and team leads, 10 product managers, six UI designers, and three technical writers. To assist this vast crowd with quality, we have a team of only six QA engineers. In Introducing Atlassian QA, we described the overall approach that the Atlassian QA team takes to ship software high-quality software quickly. However, different product teams implement this same strategy in different ways. This allows us to flex to the different needs of the teams, and to easily experiment with new ideas. This blog describes how the JIRA QA team currently implements the QA strategy. The overall vision of the process is for every feature to be coded and tested only once, by the developer responsible for implementing it. No bugs, no bouncing back and forth between tester and dev, and no extra testing stages. JIRA development Process The development of an average story looks roughly like this: If a story follows the most efficient development process, it follows the solid black line from Planning to Done. However, occasionally there are issues along the way, and the story may follow one of the alternative paths marked with black dotted lines. During this process, a QA engineer has multiple points at which he or she provides input into the way the story is developed and tested – providing every form of quality improvement except actually testing the story themselves. The opportunities for a QA engineer to influence the development of a story are as follows: Planning feedback Occasionally, a story will seem simple, but the QA engineer knows in advance that it will actually be very difficult. To get this feedback in as early as possible, the QA engineer attends the iteration planning meeting. For example, a story might say, “As an administrator, I want to create a JIRA sample project at any time.” The QA planning feedback for this story might be, ”The sample project data makes assumptions about the available issue types, resolutions, and other configuration of the system. We can’t rely on the system being configured in this way when the instance isn’t brand new. So this story will also need to cover rewriting the way that the sample data is injected.” Based on this feedback, the team might choose to increase their estimates, change the scope, or move the story further down the backlog in favor of lower-hanging fruit. Pre-development testing notes As QA, we can often make accurate predictions about what bugs we’d find in a completed story. If so, why not warn the developer in advance and save everyone the bother of dealing with the bug? In order to achieve this, we introduced pre-development testing notes. They are a set of hints, written before development starts, about the type of bugs we might have expected to […]
Previous Topic
