The first tips are usually the most obvious, but they can also be the most overlooked. To save yourself and your supervisors hours of reworking & re-reviewing, here are some tips:
1. Thorough, intuitive unit testing
Unit testing is the start of it all. If you manage to cut down the problems at this stage, it's like weeding out wild grass at its root, you'll save a great deal of time, both for yourself and for your supervisors.
Thorough means that you systematically test your unit, from the very beginning, and step-by-step work your way towards the end. Don't skip out on any parts, unless you're very, very sure that they can be done so. MOST importantly, you will need to make sure that your unit works correctly. That means, verifying the source data, the process, and the outcome of data. Are the calculations correct? Are there any duplicate entries in the output?
It is extremely easy to say that you've tested one unit just because the output is... well, tidy, or pretty (or the outcome didn't shortdump). But that doesn't mean that it is correct. Verify input, process, and output!
It is also easy to just focus on the main functionality of your unit. For example, remember that your unit may work correctly for, say, its functionality to display a nice, tidy, and correct ALV report, but it may be completely incorrect and/or messy when it comes to outputting it to, say, a form or a local file. Test each piece of the functionality, and before you say you've tested it, make sure you've actually done it and the results are OK.
Intuitive means don't just test what the scenarios written in the functional design told you to test. Think outside the box. Position yourself as if you are the user. Would you be satisfied with your own work? The functional designer may not explicitly say to test one thing, but if you, as a user, would be annoyed or confused at the approach you take when coding the unit, then it is logical to either improve or reconsider that approach.
2. Assume only when it is safe, not just when it is convenient to do so (i.e. avoid assumptions!)
It might be convenient to assume one thing when you're developing, but a wrong assumption may lead to extensive rework, or, on the contrary, may lead to extensive development when it is not required (or even must not exist).
There are some things that can be directly assumed, such as, your unit will work if the server is not somehow hit by lightning or an earthquake, but if it is not unambiguously written, then do confirm. And when you confirm, make sure you have evidence that the other party has confirmed.
3. Get a pair of extra eyes
It can be generally said that developers know more (at least technically) about his/her own units than other people. While this is expected and it's natural, this could lead to the "alpha-tester syndrome" (yes, I made the term up), which means that the developers may subconsciously assume things or may overlook things because he/she was the one who developed it.
Ask a colleague or your supervisor, if they're not busy, to come and give a look about your unit's results. See if they notice something that may be useful for you to either detect a bug and fix it, or change a part of the code to improve the unit.
4. Learn outside the scope
Your scope may be in development, but don't let that stop you from learning about the functionality and your unit's place inside the "big picture", i.e. what your unit contributes to the overall business process.
Knowing about the background of your unit will enable to get a sense of what the users will expect of your unit, so you could anticipate those by implementing things that may improve the user experience with your unit. You may even see an "invisible" hole that might've been overlooked by the functional designer, or even suggest a better approach.
Well, that's it for part 1. If I ever have the urge for part 2, I'll post it here. Hopefully the above will help you in doing your assignments and improve our overall quality.
Subscribe to:
Post Comments (Atom)