Encouraging Testable Code
After being a developer for several years, I recently started a new job as a tester on a .NET project that is just getting started. Since I'm in on this project from the very beginning, I think I've got a wonderful opportunity to encourage more test-oriented development than I would otherwise get if I were brought in at the end. In an interesting twist of circumstance, I actually have more real-world .NET experience than the developers (and they're not yet object-oriented guys) so I may be able to use the mentor role as additional influence.
Why not jump abroad the development team since you've got more experience and it's greenfields development, then hire somebody who is purely test focused and be a team leader across both areas.
The project manager wouldn't like that. He wants my input on the design phase, but that's it. Besides, I'm already mentally committed to being the best tester I can be. I really want to do this right. I figure it'll make me a better developer.
The second paragraph of your last comment is the key.
If you can get access to tools that will run the project's unit tests and tell you what percent of the application code is covered by them, that might be useful.
I wouldn't use energy on test coverage. I would say as long as there are proof of broken code, the developer should be (self) encouraged to add a new unit tests to locate the break. Then fix the code.
Actually, having a code coverage target is a very good thing. Just because QA clicks on buttons in the right order to execute a safe code path, doesn't mean the user will do the same. Users find ways to do things you don't expect. If it's worth coding extra paths to handle special conditions, then it's worth testing them. Like anything else, setting a target is a good way to gauge progress.
Developers are busy and lazy. They often won't want to write their own unit tests. When I worked in QA, we tried to "close the loop" and give some pre-checkin "smoke tests" to the developers. If you give them smoke tests that don't require much time or thought on their part, honest developers won't mind running your automated smoke tests before checking in new code.
I second Realist. Marvelous and important as testing is, there's something odd going on if the project manager explicitly stops you doing development when you have more .Net experience than the others. I'm presuming you are a good developer.
Yes we are busy and lazy. But we also want to be effective. When I say unit tests, I mean programmer's tests used as a code design tool. They are very effective. QA's tests would then be functional tests. They could use the same unit test framework, but does not have to. See http://www.xprogramming.com/xpmag/acsIndex.htm for an adventure in C#. Nice reading and a good tutorial.
I always write a test module in my application that can be executed via a command line parameter that self tests the application, basically it would run a heap of pre coded unit tests firing a range of paramaters at procedures and expecting certain results etc, any coded unit tests were added to the application itself, I think it's a great idea and I lost count of how many times it pointed to issues instantly.
Realist, same here. Only I do it out of necessity. Can you imagine performing integration with other developer's code without running your own unit tests and test apps first? Life is hard enough... its just necessity.
Whoops, no spite intended in my last post. After re-reading it, it has an edge that wasn't intended. Sorry.
No worries Nat, can you remember where you got the idea from? I wouldn't mind reading some of that stuff again.
Fog Creek Home