Change requests. A brief description of the problem, the business needs, the context. Then a section analysing the changes – what will happen on the user interface, how will the code in the backend change. What parts will be affected. Finally a section on testing. How will we ensure, that the new parts of code will work as intended.
And now we’ll perform the entire thing in reverse. Writing a few but strategic test cases. When they succeed we can perceive the work as done. Then we continue to the code. The intention behind working analytic and structured is, that the actual coding will be extremely precise. You know exactly what to do. Maybe you come across additional problems to solve as you dive deeper into the details, but all in all, the biggest issues will be solved in the analysis. Finally – the context – the business problem – is now solved.
Then comes the time when you realise, that the problem you defined in the beginning, wasn’t that important after all, and the pursuit to define more important changes commences.
Step by step:
- Define the problem
- Analyse the technical as is and possible solutions
- Design strategically effective test cases
and vice versa…
3. Write out tests
2. Implement the code changes
1. Revisit the problem statement
Development of a developer 