We embark on all of our projects primarily from an agile perspective. This means that we know that we can’t predict the entire course of a project from the very beginning — the route will inevitably change along the way. Therefore, we have to keep things open and flexible as possible.
But we also have a commitment to the highest quality from beginning to end.
This is where Quality Assurance comes in. But on first look, having an intensive Quality Assurance policy from the very beginning can seem to go against agile practice. But there is a way to monitor quality throughout a project while being open to change, keeping sights set on the best possible end result.
In this blog we’ve highlighted three key ways that we assure the highest possible quality for all our projects in an agile environment.
The very beginning of a project is critical for Quality Assurance. It’s the time when a framework can be developed alongside the Plan phase, in cooperation with the client. We start by looking at all business goals and functional requirements, documenting initial aspects of the project, and developing relevant guidelines.
One of the best strategies to ensure a flexible plan from the start is to establish which factors are likely to change and which are more reliable. We find it useful to spit factors into two main groups:
a. Business requirements highlight what the team will be building, and defines the scope of the project at a very high level. They’re quite objective and are very unlikely to change in a big way.
b. Functional requirements however, dictate how the team will build the product and provides a much more detailed look at flows and functionality. These requirements are very vulnerable to change along the timeline of a project, and this should be considered at all times.
By creating quality assurance guidelines that relate to both the the high-level business needs and the specific project requirements, we’ve achieved a quality assurance process that thrives in an agile environment. It’s detailed enough to be relevant and structured, but keeps things high-level just in case things change. Starting this process right from the beginning means that we’re always on top, adjusting as we go.
Having the QA Analyst present early in meetings allows the tester to utilize their expertise and bring up potential red flags early. It also means that they have access to the conceptual rendering from the UX team, including design documents, wireframes, and technical architecture.
Like with most things, poor communication leads to poor results. We know that communication in all stages of quality assurance is critical, so we do this by writing detailed test plan that offers step-by-step guides on how to locate defects.
Another key communication strategy is making it known to all team members that bugs will exist — it’s unavoidable. When that happens — no one is to blame, and that the overall goal for everyone involved is a successful end product. It’s about working together to eradicate defects as and when they appear, rather than constraining the development process by trying to prevent them happening in the first place. This is a key point in agile — we need our teams to feel free and to keep their focus on producing the best end product.
A positive, upbeat atmosphere can go a long way in avoiding a potentially stressful environment. Being a successful QA does not just mean finding bugs, but also working together as a team to help eradicate defects with as little friction as possible.
Analysis is critical in understanding the extent of damage that a defect can cause. Utilizing metrics (e.g. burn down charts, daily test execution progress, executions by test cycle, number of executions per day, defect severity and status) can give us a much more in depth look at our testing process and allow us to consistently improve our Quality Assurance.
When we understand and can predict the effect of actions we take, it gives us more space to work in an agile environment. It results in faster tests and more time for developers to discover solutions to defects. Additionally, metrics can help us identify specific bugs slowing down our process and draft reports that allow us alter future test plans for further levels of success.
Ironically, analysis gives us the freedom make more mistakes — which is vital as they’re inevitable in a creative and innovative environment. Embracing this with the knowledge that we can fix them quickly using minimal resources (instead of fearing them) means that we can create the best environment for creating exceptional end products.
When considering the philosophy of agile and the traditional outlook of Quality Assurance, the two do not seem the perfect match. However, QA is, in reality, an enabler of agile practices — it is the reason why we can afford to be creative and fearless in the way that we go about the development of our projects.
Nansen Creative Directive, Justin Dauer, also argues that keeping the process agile with a strong focus on quality assurance has big pay-offs for the overall experience as an end user.
QA is our safety net of knowledge, achieving great results by combining process with creativity. Through this, we can prepare to be spontanious in an agile environment.
