Tag Info

Hot answers tagged

13

Starting testing during development is too late, and starting testing before deployment is usually a recipe for disaster, missed deadlines, and high unexpected costs. Testing should start as early as possible. If you have a prototyping stage, then testers should be involved in the prototyping before any requirements / stories are solidified. Early ...


11

The right time depends on the development process you are following. Using a simplified interpretation of an agile process would probably work best - pretty much anything that preaches interative development with fast & often builds + test execution after every build will do just fine. One thing to have in mind is Test-driven development which mandates ...


6

I noticed you did not ask whether it was better to start testing during project development or before deployment; you asked which was more efficient. You also did not specify whose efficiency you wanted to maximize. You did not say who would be doing the testing, but since you mentioned testing before deployment, I assume your refer to testing by someone ...


5

You should clarify your question to define what is meant with "start testing". Take a look on this diagram (taken from here): There are various aspects of tests. They are defined and run at all phases across Software Development Life Cycle (SDLC): Acceptance Tests are defined just at the same time with Business Requirements - e.g. they are defined at ...


5

There are a number of techniques that need to be combined for this sort of thing. Tradeoff approach The tradeoff approach (aka tradeoff triangle) needs to be agreed and documented up front, with the key stakeholders. This is great way to discuss and decide something that they normally won't budge on. The trade-off triangle conceptualizes the idea that ...


4

Testing team should be involved in the project from the very beginning. Especially important are gathering system requirements and design phases. Basically speaking you have to design your system for testability. It's quite difficult to implement test automation if your system hasn't been designed to support test automation. It also depends on your ...


2

Katrina, there are some great answers here already but I would like throw a monkey wrench into the mix. Requirements have been mentioned a few times. Requirements are nice but in the development team where I work, they are nonexistent. I test when the code is delivered to me, sometimes 2-4 weeks prior to deployment, and with zero requirements. Is this ideal? ...


2

The number of features in a release is the most flexible piece, honestly. Quality can NEVER suffer, that's a given. With heavy customer demand, most likely release dates can't shift. So, you are limited (time-boxed) based upon how many man hours are available until the release goes out. So, quality is boxed, time is boxed, the only thing left is to limit ...



Only top voted, non community-wiki answers of a minimum length are eligible