Summary
In this episode, we discuss the importance of a code freeze during the implementation phase. A code freeze ensures that the testing group has a stable target to test, and it helps prevent frustration in QA efforts and implementation groups. We also touch on the importance of version control and rebuilding the situation being tested to confirm the fix was correct.
Detailed Notes
The step where we hand off code, our actual deliverables at the end of implementation, can be a line in the sand, preferably a very strong line in the sand, where we go through all of our implementation, we somehow package up that code or have a code freeze where no further changes will be made, and then we turn it over to the testing group. That is more often than not not the case though, because in a lot of cases, a lot of situations, a lot of methodologies, there is more of a, it's a more fluid approach from implementation to testing. So you're actually still implementing while you are testing. That being said, you still want to have some sort of a code freeze. If you don't, if you don't stop coding on what is being tested, the testers are going to end up with a moving target. They don't know what they're actually testing for, or actually what they're testing, because it is changing underneath them. So if you're using a situ- in a situation where it's like Agile or one of those specifically like sprints and even RAD and some of these other methodologies and approaches, where you are implementing and testing sort of in a looped cycle, so those both go on at the same time, what you want to do is ensure that you have a well-defined module or code segment or something along those lines that can be tested. If you get into the idea of continuous integration and continuous deployment, then there should be some sort of a version, whether it's like a build date or build number release version, something like that. So the code that's being tested is that specific version. The testing group, the QA people, whoever they are, can test it. And when they have a response, when they get a result back, they will say that version ABC or build number 12345, this is what the results were. This is where we found the problem. Now this does go into some of the things we'll talk about in a future course when we're talking about implementation and version control, is that you do want to be able to rebuild essentially that situation that's being tested so that you can confirm that it's broken, so that you can fix it, and you can confirm that the fix was correct, that it actually fixed the problem. If you have a shifting sand of code coming in, then it's very hard to do that. You may very easily get in a situation where you can't actually reproduce that bug the same way again. That doesn't mean that it's fixed. It just means that you changed something. So now that bug shows up in a different way or in a different place. So the key to your implementation handoff is to do it in a way that is essentially nice and can be placed into equivalent of a box to say this code is being is ready for testing, and when you test it, your results will apply to this chunk of code, this state. If you do anything else, then you're going to really frustrate your QA efforts, and you're going to really frustrate the implementers because when QA responds with a bug or an error, some sort of correction, then the implementation group is going to struggle to figure it out because they won't be able to reproduce it. So whether you use code freeze, whether you're using some sort of version control, whether you're using a build process, whatever it is, make sure before you get into the handoff that you have defined that, that the parties involved understand what's going on and understand what signifies or labels code as being frozen and or, and actually I guess it would be and, ready to be tested. If you do, your process will go a lot smoother. If you don't, you're going to have a lot of headaches.
Highlights
- A code freeze can be a strong line in the sand to ensure the testing group has a stable target to test.
- In Agile and other methodologies, implementation and testing are done in a looped cycle, so a well-defined module or code segment is crucial for testing.
- Continuous integration and continuous deployment require a version control system to ensure the code being tested is a specific version.
- Rebuilding the situation being tested is essential to confirm the fix was correct.
- A code freeze helps prevent frustration in QA efforts and implementation groups.
Key Takeaways
- A code freeze ensures the testing group has a stable target to test.
- Version control and rebuilding the situation being tested are essential for a smooth implementation handoff.
- A shifting sand of code can lead to frustration in QA efforts and implementation groups.
- Continuous integration and continuous deployment require a version control system.
- A well-defined module or code segment is crucial for testing in Agile and other methodologies.
Practical Lessons
- Implement a code freeze to ensure the testing group has a stable target to test.
- Use version control to ensure the code being tested is a specific version.
- Rebuild the situation being tested to confirm the fix was correct.
Strong Lines
- A code freeze can be a strong line in the sand to ensure the testing group has a stable target to test.
- A shifting sand of code can lead to frustration in QA efforts and implementation groups.
- Continuous integration and continuous deployment require a version control system.
Blog Post Angles
- The importance of a code freeze in implementation handoffs
- Version control and rebuilding the situation being tested for a smooth implementation handoff
- The challenges of a shifting sand of code in QA efforts and implementation groups
- Continuous integration and continuous deployment require a version control system
- The key to a successful implementation handoff
Keywords
- code freeze
- version control
- continuous integration
- continuous deployment
- implementation handoff
Transcript Text
The step where we hand off code, our actual deliverables at the end of implementation, can be a line in the sand, preferably you know a very strong line in the sand, where we go through all of our implementation, we somehow package up that code or have a code freeze where no further changes will be made, and then we turn it over to the the testing group. That is more often than not not the case though, because in a lot of cases, a lot of situations, a lot of methodologies, there is more of a, it's a more fluid approach from implementation to testing. So you're actually still implementing while you are testing. That being said, you still want to have some sort of a code freeze. If you don't, if you don't stop coding on what is being tested, the testers are going to end up with a moving target. They don't know what they're actually testing for, or actually what they're testing, because it is changing underneath them. So if you're using a situ- in a situation where it's like Agile or one of those specifically like sprints and even RAD and some of these other methodologies and approaches, where you are implementing and testing sort of in a looped cycle, so those both go on at the same time, what you want to do is ensure that you have a well-defined module or code segment or something along those lines that can be tested. If you get into the idea of continuous integration and continuous deployment, then there should be some sort of a version, whether it's like a build date or build number release version, something like that. So the code that's being tested is that specific version. The testing group, the QA people, whoever they are, can test it. And when they have a response, when they get a result back, they will say that version ABC or build number 12345, this is what the results were. This is where we found the problem. Now this does go into some of the things we'll talk about in a future course when we're talking about implementation and version control, is that you do want to be able to rebuild essentially that situation that's being tested so that you can confirm that it's broken, so that you can fix it, and you can confirm that the fix was correct, that it actually fixed the problem. If you have a shifting sand of code coming in, then it's very hard to do that. You may very easily get in a situation where you can't actually reproduce that bug the same way again. That doesn't mean that it's fixed. It just means that you changed something. So now that bug shows up in a different way or in a different place. So the key to your implementation handoff is to do it in a way that is essentially nice and can be placed into equivalent of a box to say this code is being is ready for testing, and when you test it, your results will apply to this chunk of code, this state. If you do anything else, then you're going to really frustrate your QA efforts, and you're going to really frustrate the implementers because when QA responds with a bug or an error, some sort of correction, then the implementation group is going to struggle to figure it out because they won't be able to reproduce it. So whether you use code freeze, whether you're using some sort of version control, whether you're using a build process, whatever it is, make sure before you get into the handoff that you have defined that, that the parties involved understand what's going on and understand what signifies or labels code as being frozen and or, and actually I guess it would be and, ready to be tested. If you do, your process will go a lot smoother. If you don't, you're going to have a lot of headaches.