6 dos and don’ts for using an outside agency to write your automated tests

Companies often know they should be writing automated tests but “don’t have the time”.  As a result, they may pay an outside agency to write their automated tests for them or assign it to a QA team.  This situation is far from ideal: Developers should be writing the automated tests for their code.  An outside agency or QA team can be used to write more functional, higher level tests as a safety net to that.  I really believe this is the only correct way to do it.  But, if you insist on having an outside agency or QA do it, here are some important dos and don’ts:

Continue reading

Continuous Integration means CONTINUOUS Integration

I’ve consulted for a company in the past that had a continuous integration server set up correctly and building their project, but they made the mistake of having their developers decide when to start the build process.  This misses the whole point.  It’s called “continuous” integration, not “developer-decides-when” integration.  Your continuous integration server should build your project and run its tests whenever a change has been made and as soon as possible.  The benefit to this is faster feedback.

Continue reading

Developers should not have to interact with human beings to set up a new environment

It’s typical for a developer to have to wait on some person to be able to get a new environment set up.  For example, when the new project has its first acceptance test, a new server will probably be needed to run that test on.  At your typical company, this developer will depend on another team to set up that server.  Usually, that team is very busy working on more pressing matters (e.g., a production server seems to be low on RAM), so the developer’s needs are relatively low priority.

This type of situation should not even exist.  Developers should not have to interact with human beings to set up a new environment.  Continue reading

Prevent your production issues from ever happening again

This is a scenario that’s all too common: The product gets released and then a serious problem is discovered.  You think, “That couldn’t have been caused by me”, but then you realize that it was.  After you’re done beating yourself up about the mistake you should ask yourself this question next:  How can I prevent this problem from ever occurring again?

If your answer is, “be more diligent in the future” or “don’t do that”, bzzz, wrong answer.  That’s not good enough.  It allows other employees to make the same mistake in the future.  If your answer is, “update the documentation to say ‘don’t do this'”, bzzz, wrong answer.  If this mistake can take down an environment, it’s too risky to assume someone will read the documentation to avoid this in the future.  Don’t give someone the opportunity to miss this information.

Continue reading