Building a Quality Assurance, or QA, culture and starting QA processes from scratch is like going down the rabbit hole. It has taken great patience, effort, and planning to come to a point where we feel confident about our quality gate process.
Over time, I’ve seen that throwing more money, people, and effort at a quality problem without the right strategy doesn’t work. At Mixmax, QA had to be started from scratch. Here’s what we took into consideration when we began:
- Requirement assessment
- Planning
- Test case development
- Streamlining the deployment/testing/release process
- Cycle closure
- Ensuring QA has the right environment to test
- Documentation
- QA strategy and roadmap
- QA best practices, on a daily basis and on cross-functional teams
- QA automation
Quality is a team sport. For Mixmax, QA is a key element in product and service development. So, we began to follow the strategy of “shifting to the left,” and scheduling QA in our development processes from the very start.
To get the ball rolling on the shift-left testing, Mixmax and our engineering teams had to keep to some standards, such as:
- Getting everyone on the same page as to what procedures and coding bench-marks are implemented,
- Implementing early testing for each phase, especially in situations where Agile testing is barely an option, and
- Making use of automation tools, which helps to make the whole shift-left testing process less burdensome.
One of the main challenges we faced is that the QA process takes significant time, even with automated tests, and especially when we have to write test cases and scripts from scratch. To optimize our time spent in QA, we followed three rules.
First, we had to set clear expectations. Our QA process and automation must directly relate to the end objectives. This means, defining proper testing strategy for each and every scope of the testing (Unit testing, system testing, integration testing and non-functional testing). Ofcourse, this is carefully considered and planned in the early requirements phase. Second, we had to understand which QA tasks automation was best suited for, rather than applying it too broadly and missing out on the benefits of manual testing. Third, we decided to put QA in multiple stages of a product lifecycle to get the all-important feedback loop happening much faster. Doing so improved communication and collaboration within the team.
Today, we strive to make QA a priority in our company. We work as a team to enhance our “Quality culture” by using established best QA practices, employing quality management, experimenting with new ideas, and switching up testing practices and metrics used where necessary. Our QA practices now impact the entire workflow, not just the last few steps. Automation begins the QA process by reviewing basic and repetitive flows that don’t need a human eye cast over them. Then, we can focus on small, quick wins and functional testing. Tests are written to fail in the initial phase (before development starts), and developers are writing code to make our tests pass. Later, we will scale it further and expand basic test flows defined.
Our “shift left” strategy puts focus on problem prevention rather than problem fixing. For example, testers pair with developers and contribute to the coding process, or run tests before hitting the build. Testers also join refinement sessions, ask questions, and provide rapid feedback to influence development decisions.
With the development phase done and before moving to pre-production E2E testing, developers have to ensure "DEV QUALITY GATE", that includes:
- Write unit tests
- Test basic functionality
- Send to code review
- Do static code analysis
- Complete UI component testing (where applicable)
In regard of QA, the table below shows a summary of QA activities before, during, and after testing:
When pre-production testing is done, a closure report is provided. Closure report includes: Xray (test management tool) quality metrics and automated test results report. Product owner prioritizes resolving any issues before release. After release readiness is confirmed, final testing is done on production (when possible).
Our cycle then repeats, and if at any point we feel the need to rework something, this is done through the established QA Community of Practice, or QACoP.
QACoP is our space to help QAs grow professionally. In QACoP, we learn technical skills like testing principles/methodologies and how to understand different test approaches, as well as softer skills like how to develop leadership skills and empower a team. Organization-wide, QACoP helps the software testing unit improve by implementing best practices. Some examples of improvements include implementing better ways to do test planning, creating test cases and optimizing quality metrics, and even how to execute test automation. Based on every insight, we get from our iterations, setting quality goals and strategy around it makes a more efficient and productive environment. When the whole team shares the responsibility for the quality of the product, we work faster, smarter and more cost effectively.
Want to join us? Visit Mixmax QA Career.
