April 28, 2020 | 6min read
Shifting-Left the Right Way: Quality Kickoff Process
Nowadays, we hear a lot about shifting left and quality assurance in testing. It’s an approach that encourages starting testing as early as possible in the development process. Thanks to that, defects are found earlier, even before the implementation of a feature begins.
We always want to provide products of the best quality, but we’ve encountered some problems on our way. Quality practices in our projects differed with the experience of our team members.
That’s why we’ve started and implemented our process that helps us assure the quality in our projects—and we named it Quality Kickoff.
At Polidea, we value workshops and love to participate in them. Therefore we had several brainstorming sessions, which resulted in the conclusion that quality assurance (as a part of our DNA) must be consistent with one of the other values—agility.
The main goal of the Quality Kickoff is to use the best quality practices in every project, smartly and reasonably. How? By creating and maintaining a knowledge base of these practices and mistakes to avoid and providing a process that helps the team implement them. The other value is constant discussion about the quality that the process inspires.
We’ve designed the Quality Kickoff process as a simple and straightforward framework—we treat quality practices as an integral part of a project since the beginning. Quality Kickoff is triggered by the first meeting, in which the team plans future quality processes and tools based on experience gathered from previous projects.
If you’re eager to get to know the whole Quality Kickoff Process, we will shed some light on how we do it and what it does in this section.
The Quality Kickoff meeting itself is the first step. It opens and accelerates the whole process. During this meeting, the team goes through the various project aspects as:
- Types of automated tests to implement—unit, integration, end to end, performance, security.
- A need for security audit and required security level of it.
- Necessity and value of periodical pair and crowd testing sessions.
- Defining process for creating Acceptance Criteria, Definition of Ready, Definition of Done for user stories.
- Needs and requirements for CI Infrastructure.
- Processes and requirements for managing a release.
As a basis for this meeting, we use a special document that describes best practices, but also typical issues and problems that might occur, as well as areas that should be taken care of before the development starts. It’s based on our experiences from many projects that we’ve participated in at Polidea. Thanks to that collected experience, we have a knowledge base that every one of us can use.
During Quality Kickoff, we go through the above list and decide which items are relevant for the current project. This is highly dependent on the project’s context and scope. For non-applicable items, we add a clear explanation of why it’s not needed.
What could be an example of such non-required items?
- Skipping deep level security audit for an offline application that does not store any sensitive user data.
- Ignoring visual regression testing for libraries and their demo apps.
- Documenting very conceptual projects.
This is a first added advantage—even before the project starts, we already plan how to provide the best value. Thanks to that, when we plan the infrastructure, processes—we take quality requirements into consideration too.
All improvements we agreed on create an extensive list of action points. It’s hard to implement all of them when the project starts or even when it’s ongoing (we have to have time for awesome features too!). Prioritizing tasks and putting them into a backlog along with other development items is a way to go here. Thanks to this solution, we have a clear backlog of quality improvements, rituals, and processes we want to implement. Some of them should be implemented since the beginning of the project—and these are prioritized. Some might wait till later stages and can be taken from the backlog one at a time.
When we were designing the Quality Kickoff Process, we wanted to make sure that it’s not yet another meeting that you attend, and then forget about it. It was crucial for us to implement a way of assessing progress, but also checking and resolving problems that occur during implementation. That’s why just after the first Quality Kickoff meeting, we set up a date of the Quality Check meeting—that’s our initial deadline to deliver the effects of our first arrangements.
This is the core part—we implement what we have planned!
All agreed on items at this point are added to the backlog with priorities—to assure full transparency (and to help with our weak memory, of course). Now the ball is in the team’s court—it’s their responsibility to assure that tasks are implemented before the Quality Check meeting.
This kind of agility and flexibility encourages closer cooperation between team peers.
A good practice that helps to achieve this goal is adding these things as regular tasks into the backlog and treating them as any other type of activity in a sprint. It might counterintuitively seem like a development slowdown (shouldn’t), but don’t be fooled! The benefits are great—the whole team constantly thinks about quality and makes it an everyday task.
Now’s the time for the next important ritual—Quality Check meeting. Its purpose is to check the progress of improvements we made and what still should be done. It adds a reflection moment—we shouldn’t only tick off some items from our to-do lists. It’s also a great time to analyze why some items weren’t completed.
- Did we forget about them? If that’s the case, maybe it’s time for backlog cleanup or better prioritization?
- Are they still relevant? Sometimes after development starts, the team realizes that some of the initial assumptions are not valid anymore, and they should be adjusted or canceled. And that’s ok, we’re agile after all!
- Do we have enough time in our sprint to introduce the improvements? If the answer is no, that might be a topic to discuss with the Product Owner. It’s important not to focus only on features added to the product—fixing bugs, paying technical debt, and improving quality are also very important items.
That’s also a perfect time to address risks that are awaiting us shortly—do we plan a store release or an expansion to a new market? Maybe the new feature we’re working on created some technical debt that should be addressed? Such items should definitely be discussed–newly generated ideas should be documented as previously, by adding them to the product backlog.
Just after the meeting, we set a date for the next check, so the process is ongoing seamlessly.
Quality Kickoff Process is a tool for making quality assurance our everyday routine. It’s not a thing we remind ourselves about from time to time—it’s a constant part of our development process.
As an additional value—it helps to involve all team members in a discussion about quality. We all want to deliver the best product, and we take it into account from the early stages of development.
With good planning, we can devote more time to extensive and more elaborate manual testing instead of performing endless, repeatable regression test suites. What is important, making solid quality assurance principles helps us assure similar standards in all our projects—regardless (well, maybe not entirely) of team members’ experience. Sharing best practices and “lessons learned” between our teams raises the quality of our products and helps to avoid our previous mistakes.
Okay, so we did our part of presenting our idea and implementation of quality assurance. You’re already familiar with the basic concept of the Quality Kickoff Process. If you have any further questions—don’t hesitate to contact us, we’re always happy to answer questions!
Senior Test Engineer
Senior Test Engineer