Testing everything and having absolute confidence is something testers know all too well is not going to happen. While we like to do our best to target maximum test coverage and think of all the different scenarios and permutations that could affect our software, the truth is that it’s incredibly difficult and often impossible to do given the complexity of the modern computing environment and need to get software out as fast as possible.
However, if there is one thing that testers can and should maintain absolute certainty about, it’s the critical path. In any given project or piece of software, there are requirements or pieces of functionality that remain an absolute necessity – and these are things that testers should always focus on when it comes to getting through the required testing. Teams can certainly pursue achieving more in their releases, but these should never be at the expense of the critical path and it’s the critical path that should drive the release of software and nothing else.
What exactly forms part of a team’s critical path? Well, the obviousness of must-have requirements or features is what most people focus on. It actually consists of more than just the critical parts of a project though and can also include critical tenants of your software design like security and performance (which really should never be compromised) and at times often a deadline, especially when it comes to regulatory updates. Essentially anything that cannot be compromised, for deadline or quality purposes, is the critical path. Must-have features where quality is less important, do not form part of this, because anything where quality can be compromised is essentially not all that important in the first place.
Plan According to the Critical Path
So, what should testers do to ensure they are on top of their critical paths and not ending up caught short in these areas? Well the solution is straightforward but you’ll be amazed at how seldom we actually get this right. All you need to do is prioritise and plan. However, I’m not referring to the whole project or sprint-work here, but merely on only the critical path. Too often teams lump all of their tasks together and plan their daily/weekly work accordingly with little focus on managing the critical path. Rather, critical items should be the only things prioritized at the start of any planning activity and the entire release and scheduling of work should then be done around this critical path before work begins.
In fact teams shouldn’t even set a deadline or planned release date for their work until they have fully counted for every aspect of their critical path and know how to achieve it. When a deadline becomes a part of that critical path, then it is your scope that is reduced and moved accordingly.
When planning, the following things are important to keep in mind when planning your critical path tasks:
- Complete Definition of Done: It should be clear exactly what it means for a piece of work to be completed. And this doesn’t mean code is done, but is actually related to quality. Code and Functional Test Coverage needs to be as close to 100% as possible and absolutely very few defects should be accepted. Included in your definition of done should be clear goals on security and performance testing expectations.
- Root Cause Analysis: If you’re working on a critical path, it shouldn’t just matter that all issues have been fixed. Work on a root cause to ensure that you fully understand why the issues occurred so that measures can be put in place to ensure they don’t creep into these critical path items again. Make provision for this added analysis in your planning
- Tests should be Automated: Many companies take short cuts on their automation work to rush getting things out. This doesn’t work and time should be provided to ensure that everything is automated properly and not left for repeated manual regression later.
- Plan contingency: Planning contingency is god practice for any form of development estimation, but on critical path items should be increased to ensure that work is not rushed. Rushing leads to bad code and shortcuts, which you don’t want on your critical path items.
Once you have successfully factored in your critical path items, only then work on the rest of your release tasks and plan dates accordingly. There is no point release a whole bunch of high quality features when the core things you need to be working on are going to fail. Get critical path items prioritised and work on these first.
Adapting To Change
However with all that said, if all it took were merely planning, most people would probably get this right. The problem is things seldom go according to plan and we end up having to make compromises to our original plans. And this is where the critical path becomes especially important, because it’s the thing that can’t be compromised. When things get difficult, everything should shift to that critical path and work should be done only around this. Outstanding defects? If it’s not part of the critical path, drop it from your release scope and move it later. A great new feature that is working well, but not on the critical path – release it later otherwise it will distract you from your critical path.
Think Beyond the Release
One of the crucial things though that people forget about in managing the critical path is focusing on more than just the release. Items on the critical path are important for a variety of reasons, which means it shouldn’t just be released in a high quality state, but should be maintained as such as well. What this means is that things like quality of the code, automation and root causes of defects should all be addressed before you release and time set aside to ensure these things are set in place. Many companies might leave these activities out in the hope of getting things into production on time, but the truth is that if you compromise here, you end up with technical debt and risk your future release. When it comes to the critical path, these things shouldn’t be taken for granted.
Comments