Today I took “half a day off” to work on developing a feature I’ve been wanting to add to PractiTest for a long time.
It’s fun to do it once in a while; to take a break, get my hands dirty, develop something for a bit and then go back to my regular work as a test manager and solution architect. It’s not that I don’t trust my development team, I guess I did it for the fun of it 🙂
I read somewhere that it is related to changing your focus and “going deep” on a task that is unrelated to what you do all day but still closely linked to your work and how this helps to refresh your mind by breaking out of your working routine.
Writing GOOD CODE is hard!
For me as a tester it is also a reminder of how hard development work really is, a chance to experience first-hand how non-trivial it is to write something that looks good on all browsers and works correctly in all Operating Systems.
I am sure that even though I tested my “small feature” thoroughly, once it reaches someone from my team for testing he or she will find at least one or two annoying bugs on scenarios I had not thought about. After all, isn’t this the art of testing?
Running GOOD TESTS is also hard!
The same is true about testing, you need to give a developer an end-to-end testing task for him to understand how difficult it is to test.
I heard this from a testing colleague in another company the other day, he works on an agile team where developers sometimes get testing tasks assigned to them, but then come back to him asking “if he can re-run the tests on his spare time” since they don’t feel god enough with their testing coverage.
Is this a case of someone wanting some reassurance and validation on his work, or someone who doesn’t want to take responsibility for his task and wants someone else to do it for him? The truth is that it is hard to tell…
Teach your developers to test!
It is important for developers to take responsibility for end-to-end testing tasks once in a while; it helps them to understand what matters to us when we do our job, and maybe even more importantly it teaches them to do their jobs better!
If a programmer experiences first hand how his code behaves on a “realistic” testing environment then he can take this experience and code accordingly next time he sits to work on developing a feature. It’s not about making him take responsibility for testing his own code, I think he simply can’t do this, but about learning to develop while been aware about additional factors that may affect his code.
To achieve this you cannot give him a 2 hours of testing task at the end of the sprint, he needs to take responsibility for a complete testing project and let him feel and live the work of a tester, even for a little while.
Doing this will not only provide you with some additional testing resources that can be used in times when the bottle neck sits in the QA department and Developers can help out, but it will also give them tools to stop bugs from crawling into the code in the first place.
Overall a win-win for the whole team.