Starting a new test project

Starting to test a project is always a challenge. You don’t necessarily know what to expect of the software. It is supposed to be almost ready, but the definition of ready varies a lot based on the individual developer. And not only of the developer. There are many external factors affecting the project and pushing things along. A project can have, and usually has, schedule pressures and any single person does not want to be the one to blame for the delays. For example, a release or iteration could have 20 new features, which are supposed to be completed on a specific date. The development team does not want to be the one delaying the project and releases the software to QA. As it turns out, only 10 of the features are really implemented and 5 actually work. This is a bit of an extreme scenario, but nonetheless one that many QA people have faced. If external factors have too much affect on the project, the software quality will be a bit of a hit and miss.

Even with all of the problems mentioned here, the initial period on working on the new software is very rewarding. Testers learn how the new software works and find plenty of defects. They look at the product with an open mind and get new ideas and approaches to testing it. A lot of progress can be made in a short time. When the work becomes more routine later on, many times there will also be less innovation.

It’s also a time when test cases evolve rapidly. The initial set is based on the specifications, which don’t necessarily completely reflect the real functionality. The test cases are going to be refined during the initial testing rounds. More test cases will also be added. Very rarely will the initial set of tests have full coverage for the software although it is possible in highly organized development team where quality is what matters most. In practice, most organization can not spend the time it takes to plan for full test coverage, and they probably should not either. Test planning is a continuous process, where both more details to the test cases for current functionality and more test cases for new functionality in new releases are added.

The fact that test cases are in practice a result of a long continuous process makes it even more important to keep track of the early test cases, which can be used to build upon. The cases might not be perfect, but will serve as a foundation for future work.


Written by: Mark Barzilay

Graduated with honors from TU Delft in 2007 studying Electrical Engineering and Media & Knowledge Engineering. Founded spriteCloud in 2009 and worked on test automation ever since, helping out small and large companies with their test automation strategy and infrastructure. Mark is also leading the development on, an online platform for all your automated test results.

Subscribe to our mailing list!

Stay up-to-date on all things quality assurance,
test automation, and cybersecurity.

We’re spriteCloud, a leader in software and cybersecurity testing.


Have a look at our testing solutions.