Make it better
Easter vacations are over and we are finally getting back to work. I have a few exciting things happening this week as my role as project leader is getting more familiar. One of the things is a full day unit-test workshop with my project members.
Testing we do today:
1. Your own testing when you have written the functionality
- Verifies that you do not have any obvious errors
2. Someone else tests the functionality after your description of how to test it
- Verifies that you have not skipped the testing? Sometimes people do different approaches here..
3. We run a robot-test on main functionality of the solution.
- This ensures that we do not have errors that stops the solution or influence the core functionality.
After this our solution leaves the office and is delivered for testing by the customer.
This approach would work great if it had not been for the time between our beginning of the programming/coding and the time we get feedback. It has a high risk of creating a gap between what the customer wants and what he gets. To help with this gap, we have iterations in the implementation phase which is highly influenced by customer feedback.
All well and good so far.
The issues start showing up in Jira (our bug tracker) some time later. This might be issues connected to integration or even several years old code. The amount of code lines and the number of integration points are increasing every day. To avoid the problem of having feedback this late I think we need to increase the release cycle and write unit-tests before we code. The "write the test first" (or TDD) rule will enable us to think differently before we start coding. As well as seeing implications earlier and taking these in account when implementing our functionality. One of our goal is to increase the quality of both code and functionality and this will work as an enabler. After doing this a while we will hopefully be able to start with nightly builds and catch more bugs this way.
Oops..This post got a bit more technical than planned, but anyway thats the main thoughts.
You might ask "why we need a 1 day workshop on this?". The keyword is ownership and engagement. If I just say that we are from tomorrow writing tests before we code new functionality, who would do it?
By doing this together we lower the barrier for something new and we increase everyones competence by working together on the different problems that comes up. We have focus on this for a whole day and might actually remember it.
The ultimate goal is an increase in quality and pride in what we deliver. Even if we work with legacy code and others mistakes, we can make it better! And we will!
