Re: Re: Re: End to End testing

[barbie]

There are lots of things that can fail. The network, your network card, the database daemon among many other things. You shouldn't be testing those so why test whether DBI can do them? If your interfaces are correct, then the fault will lie elsewhere and is down to the user to fix. If the database daemon isn't running for whatever reason, why should that mean you have a failed install? If you are correctly testing that the functionality of your modules is correct, then you shouldn't have to worry about whether DBI can talk to a live database.

If you ever get involved with designing a large system, then testing the interfaces is all you can do. The GEC Telecommunications project for designing a System X telephone exchange, took 3 days to do an end to end run. If we had ever had to install it elsewhere, doing an install test like that would been laughed at. As such we tested what went in was processed correctly and what came out met the agreed expected output, both for garbage and accurate data. It meant we could run the regressions tests on small parts of the system that could be slotted in when bugs were fixed, and we knew it would work within the whole system, because the interfaces were correct.

[zby]

I agree that the installation testing should be more timely than a full development testing. I just want to suggest that End to End testing is the most effective way of testing - so I would do some End to End rather then interface testing during installation because this can catch errors faster than the other way.

If I install some software and connect it to a database that that is not compatible with that software I'd like to be told about that during the installation proces. Otherwise I would use that software and possibly not even notice that it fails in some subtle way.