It’s definitely that time of the year when we need to smartly balance the effort for the last production deployment of the year with arriving on time to those famous company Holiday dinners. Nevertheless I think we should take some time away to reflect on how us, as QA, we approach our day-to-day jobs and how we can change that for the best in the New Year.
There are few key things that I have seen in the projects that actually were making the QA process an ease, that I think we all should be sleeping on during the holidays:
Shifting Left
- QAs participate from the very beginning. In all the stages of SDLC. With the exposure one can get from each phase can help you notice how the quantity of issues raised in that stage is dramatically reduced.
- Test Cases are written early, from requirements gathering phase. This helps you notice missing requirements even before development starts.
- Test early and often. Whenever a testable version is ready, run the tests to get early feedback. This helps avoiding delays in the project.
Preparing
- Build a solid QA Vision. Start with WHY. Understand business, project, organizational and infrastructural needs and involve everyone into shaping up this. Without one, we’re not talking about QA, just about some pure ad-hoc validation.
- Structure your test. Decide what needs to be tested in each layer and stick to that. The test pyramid is not just a myth, it stands for lightweight: easier to maintain, reliable and faster in execution.
- Find your “good enough” point. Involve stakeholders in creating a Test Plan to cover the identified risks, scope and objectives of testing and fit them into budget and deadlines. In an ideal world we would like to test everything, but that’s not the case in most of the projects.
Our Role as QA inside the Organization
- QA is a software developer, but with a twist. Living with this assumption inside teams brings us closer to a DevOps reality. We are not just bugbusters, our role is to deliver better software faster to production.
- QA is a Joker. The “QA is everyone’s responsibility” mentality should also apply the other way around, and QA should be ready to chip in to help others in different situations: Is it a basic code change your grandma can be doing and devs are busy with something else? Is it fixing the broken CI pipeline? Is the Scrum Master sick and someone needs to facilitate the daily ceremonies? I believe that we will be getting the same amount of support with QA activities if we promote an attitude like that. Again, QA as a facilitator of delivery, not a road blocker.