:quality(90))
People make mistakes. No matter how accurate we are, no matter how much we try, when working on modern, complex applications misunderstandings and misconceptions are embedded into our daily work. The key to success is to make sure that we have skills and processes in place to detect and eliminate those as soon as possible. This is where the QA team comes in. Not only does the team care about catching and describing bugs, but also about making sure that all new features and stories are described in an understandable and meaningful way. This helps the project move forward smoothly, keeping both team and the customer happy and confident.
This article will help you understand and sort out basic Quality Assurance rules in an Agile development team.
Good and bad stories of a project
What could go wrong?
To put it briefly: everything. One of the most significant problems that one could mention is the chaos in the backlog. A lack of regular maintenance could not only slow down project development, but could also result in doubling the tasks and thus doubling the workload of developers.
As the project grows, it becomes a real nuisance for every team member to know what is actually going on, what was done before and what is yet to come. Trying to find a particular ticket written a year ago might be harder than finding a needle in a hay stack! Another good practice is ticket prioritisation - keep the most important tickets on top of the backlog for everyone to see and access easily, and as the list goes on, let the less urgent issues wait for their time to come.
Another issue that deserves additional care is the ticket description itself — without proper content provided, there comes a need to dig elsewhere for further knowledge on the subject. This means lots of time needlessly lost and a great risk of providing improper results, which means even more lost time.
So what’s the happy story?
Let’s take for example a new feature we want to add to the project. What we have given is the whole idea what should be done, so - for example - we could create an epic to store all the ideas in one place for further reference. Then we can divide it into a list of tasks for each feature, which could then be described, prioritised and estimated. Every team member working on a particular task has almost instant access to all the necessary knowledge and as the project grows and the team expands, each new team member can easily catch up on the project. Furthermore, other members don’t have to spend time explaining the same things all over again. Needless to say, documentation maintenance is a challenging task in a short term, but it pays greatly on the long run.
How to describe features
1. Give it a title
What we need here is a short nice title containing keywords about the feature it regards. Keywords are especially useful when it comes to finding the feature in the ocean of other ones. Also, it helps to point out instantly what part of the application we are talking about. It could be anything - „top bar navigation”, „hamburger menu dropdown”, „search field on the home page”.
2. Meaningful description
The next most important thing is the description. We want to make sure that basically anyone will understand it. We want to be very specific, not skipping any details that might seem obvious at the given time. Believe me or not, but they won’t be that clear after a couple of weeks. After reading the description we want to know clearly what the feature is supposed to do and where it’s located in the app. There's no harm in adding a link to the specification as well.
3. Show it!
Now, at that point, we know exactly what the feature does and where it is but we have no idea how it should look. The answer are links to designs! Anything could be helpful - screenshots, Invision mockups, psd files - they sometimes say more than hundreds of words. Great to have them in the task.
4. Additional information
Last but not least, comments! Over time, some of the requirements might change. Maybe the feature interacts with other ones but it’s not obvious right away, maybe the designs have changed, maybe a client has new insights? Comments are a great way to inform about any extra cases and changes.
Keep in mind though that what exactly the feature should contain and at what point it should be described is rather project/company-specific. The whole idea is to answer all the obvious questions in the task itself and save a lot of time.
How to describe a bug?
The main reason we report a bug is to get that bug fixed. When there isn't all the necessary information, the bug won’t be fixed. Simple as that. I divided the topic “how to report a bug” into two parts: first, more technical connected to our issue tracking tool (Jira) and second, good practices.
What should a good bug report have?
1. Proper description!
Firstly, a good bug report should have a meaningful title, and I think this is and should be pretty self-explanatory. You need to give information about your environment, not only the OS and browser. It's very important to flag a bug that appears in Staging, Preprod or maybe on a Production server. Does the application that you test have a lot of modules? Please specify which one you found a bug in. Seems logical, right? Of course, a good bug description must also have: the steps to reproduce the bug, the actual result and the expected result. Another very, very important thing is to add pictures and videos - one picture can save dozens of minutes trying to figure out what the author of the report had in mind.
2. Severity
Actually, severity in my opinion, is more accurate because when I report a bug it’s easier and more natural to me to say how big an impact on the application that bug will have and whether it is important or not. These are “must haves” in a proper bug report.
3. Good practices
Report a bug just after discovery. Don’t postpone it! You can say “we all know that” but to be honest - who does it? As Jeff Sutherland wrote in his book about Agile: when a developer has to fix bug on a project (branch, etc.), working right now it will take maybe 2 hours but when you tell him after a week it will take maybe 12 times more (branch switching, rebasing, getting into context again). Be sure it hasn’t been reported yet (there is no point in making duplicates and messing up the issue tracking tool). Crucial: try to reproduce it before posting (at least once!). When a developer can’t reproduce a bug, he won’t fix it. Simple as that. Read the report at least once before you post it. It seems weird but I caught myself a few times with a lot of mistakes (mostly grammar). Very important: don’t use abusive language! There is no point in making enemies in the developer team ;) Each issue should be reported separately - there is no need to create a subtask for fixing one thing and another subtask for the second. It’s just going to be completely messy. The last and also very important thing: the bug report is not an essay - less is more unless it's less. Keep it simple, stupid. ;)
Tools which may help us
You already know, what should be included in a descriptive bug or task. But when a reporter starts her issue, she may notice that not all necessary information is fast and easy to reach.
The most important information to explain the state of your system are of course screenshots and video captures. We prepared a small list of free but useful tools.
We are recommending:
- Video capture
- QuickCast (only for MAC) - easy and useful tool. Lets you to choose the capturing area. Uses cloud storage to keep your captures.
- OBS - free software, available for Windows/MacOS/Linux.
- Screenshot capture
- Lightshot (MAC and Windows) - useful tool for screenshot capture, uses cloud storage.
Capture for Jira
Apart from those, we would like to tell you about Capture for Jira. If you are a lucky-child and your company uses Atlassian tools, we have great news for you: the report process is easier than ever! It’s a powerful tool which is implemented as a browser extension. It lets you to take screenshots of the page you’re on with one click. It provides you an interface to fulfill necessary information for the new issue or to add something new to an existing one. And the most important thing: it saves the environment information so you don’t need to check the browser or OS version, and your colleagues won’t be mad if you forgot about that. :) And of course this saves your and their time.
:quality(90))