Observations In Effective Software Development - Part 1 – Functional Specifications – Where are they?

It seems like only yesterday that my involvement in software testing/quality assurance adventures began, but in reality it has been well over 20 years! It has been a slow, winding journey through many various types of software including video colorization tools, entertainment CD-ROMs, video-on-demand applications, animated 3D shopping apps, chat rooms, educational CD-ROMs, disk utilities, web sites and visualization/prototyping tools. The testing approach for each of these products has been challenging to say the least, however the QA methods are usually very similar, though outwardly the look, feel, functionality and purpose of these products are strikingly different.

There are several items that can make the development process more painful than need be. The first and most simple common issue that many software projects fail to address in the very early stages of the development process is the lack of precise and final product design/functional specification documents. Or if we want to consider the worst case scenario, that would be thecomplete lack of any specification documents… period! Yes, it sounds absurd in today’s software development world to not have prepared any documented specs at all, but it does happen and it happens more often than one would imagine.

In this unimaginable scenario of zero specs, the problems created down the line, especially for QA personnel, is by far not a comfortable situation. Whenever this occurs, QA will often be performing ad hoc testing at first and hopefully find a few software defects. Having a seasoned team of QA folks on board is very vital as ad hoc involves experience and imagination in making reasonable progress in finding defects without any docs to refer to. Good luck to any QA team who is facing this! Usually, having good relations with the product design team and programmers is essential because there will be many questions raised during early testing cycles such as “Is this a feature or a bug?”, “Should navigation really be this slow?”, “Is this the correct graphic?” etc.

In any case, attempting to apply quality assurance methods against a product with non-existent documentation is never a good approach to successful software development and should be avoided. It slows the process, sometimes to a standstill and causes confusion, frustration and wasted resources.

Read Part 2 of this three part article