techiehenry

This is the sixth part in a mini-series here in this blog.

By now, every unit has been implemented and tested, and it is assumed that internal bugs have been cleared out. The next step would be to test how each unit would work with another — as it was originally planned to be.

The testing method in this part is never really different from the preceding one. The obvious change would only be the coverage of the testing — whereas before the internal workings of a unit is the one being scrutinized, now we widen our scope.

6. Test How The Units Work Together

   What specifically is being done in this stage? Each developer of a unit will now check how many other units have a connection — or an interface, to it. Then, one by one these connections are tested, the primary question being: “Is the information supplied by unit A to unit B correct?”

   This usually is the most time-consuming of the testing steps. Developers should come up with a strategy for the following:

   1. There should be a system where the latest files can be obtained by all members of the testing group. This should be done so as to avoid detecting bugs that would later turn out to be due to files that weren’t updated by the tester.
   2. There should be a system where each developer of a unit can communicate with each other on the details of each unit’s design. This is to avoid some things being reported as bugs whereas the procedure states it to be as such.
   3. There should be a schedule set for bug reporting. This should be done on a periodic basis, so that there can be time for the bugs to be sorted and prioritized, solved, and verified by the developer before being released again for testing.
   4. There should be a system to inform the testers which bugs are already solved, and which ones are still being ivestigated upon. This would allow the testers to concentrate on finding new bugs instead of discovering and reporting old ones.

   Other things to consider may come up, depending on the size of the development group, the location of each developer, and the complexity of the project itself.

That will be all there is for this step. Again if you have comments or questions, please leave a comment so that we can clarify things. Keep visiting this site for more updates on the series.

Software Development Series: Part 1 Part 2 Part 3 Part 4 Part 5