These terms I came up with as a joke over the last couple of years in regards to adherence to code lock down and code freeze. We have all been there and will be there again where something (or many) slip into the release post-lock down.
Back in the day I used to lament and complain and use this as a crutch to state I could not be job successfully. Now I have to come to see it differently and plan for it and adjust our approaches to accommodate late changes as well as educating others what testing can/cannot do for them. I will to get to more on that later, but first the origins of the names.
This I feel is a more appropriate name for what we think of “Code Lock down” in our daily lives. This idea came out during many conversations/venting sessions with a developer friend of mine.
The term Lochness is in reference to the mythical Loch Ness Monster. Like Code Lock Down, the Loch Ness Monster is claimed to exist by many yet has never been seen. They are both mythical creatures.
This is a more recent addition to my vernacular. The term “Code Freeze” is misleading and is more of a Frost. Code is not frozen, but generally (hopefully) the stream of new code/features coming in to a release under test slows down to a trickle after Code “Frost” hits.
Lessons Learned in Software Testing – Lesson #162 “There are always late changes”
I recently re-read this lesson and jumped out now as have been thinking about this a lot.
This lesson talks about how often times new software is being built and there hasn’t been something like this built and/or used before. There are many reasons listed that drive late changes.
- All requirements not known when project kicked off and planning was done.
- Requirements change through design sessions, UAT, etc. and as the team gains more info/insight into the target and intended use.
- Differing needs of the various stakeholders.
- Sometimes the work involved takes much longer than expected it will take.
I have seen this time and time again as well as other needs that drive late changes:
- A customer escalation that is found in production and needs to be fixed right away. The risk of impacting that customer relationship by doing nothing is often times higher than that of coding the fix and deploying to release for testing.
- A customer commitment with a high $$$ value and/or good publicity can weigh in and be willing to accept a certain level of risk to meet a deadline and satisfy the customer.
- Similar to first bullet point, the risk of NOT making the fix/enhancement is far greater than that of getting the code in place, tested and out the door to production.
How to Respond:
- Expect and plan for late changes. Understand why these changes are coming in late and develop a context driven approach on how you will test these changes in the limited time frame and what tools/techniques you can use to aid in your testing. If you have an hour or two, figure out what are the best tests and approaches to explore and provide the most information possible on the state of the fix and its impact on the feature/release.
- Educate development and leadership on what they can actually expect testing to be able to cover given time & resource availability. Make sure they understand the risks associated with implementing a late change post lock down/near release.
- Don’t use it as a crutch to NOT do your very best work & effort.
My job is to explore and provide relevant information to all relative stakeholders and continue to educate them on software testing’s role in the overall quality of a product and clarify what folks can/cannot expect from the testing group. We can assure quality, we cannot guarantee issue releases. It does not mean we stop trying for that goal and in that hopefully our understanding of the issue is accurate, our strategy to attack this issue is sound and that we give nothing less than 100% to the task at hand.
The long story short is we will most likely see the The Loch Ness Monster before we ever see a true, full code lock down. And you know what? I am okay with that (now).