So, as promised, here is the post about the various types of testing. Maybe there aren’t thirty-one but there are perhaps more than you might expect, although I believe all the ones detailed here can make absolute sense to you. The first three derive directly from the documentation that can be used for large projects but which also offers its analogues in a few smaller applications.
The relevant bits of documentation are: the business requirements document; the system specification; and the technical specification. Business requirements record: As its name indicates, this document represents the user’s requirements. It is a scoping record for the task and explains, at a high level, all of the processing, and features that’s needed is. System specification: This describes in more detail how the system will be built, perhaps including screen mock-ups, business guidelines, and a database schema.
Technical standards: This is the document that is utilized by the programmer. It’ll include specific guidelines around insight validations, how the data source should forth be updated and so. The three main branches of testing – certainly the three that are mostly used – match each one of these three documents.
This is the standard form of screening yet, in many respects, the main. Indeed, there is an old IT adage that says that pests are ten times more costly to fix for every step down the tests path they stay undetected (not least because of the regression tests involved (see below)). At this stage the designer should …
