Testing

Searching for "software testing" on internet provides even more information than when searching for "information security". Therefor another overview in this knowledge section is not so valuable. What helps you better? In my view a highly condensed overview plus practical highlights from the Rominco experience.

Overview conform V-model
In the view of Rominco, the description of the V-Model on Wikipedia gives an objective and usable overview. Rominco likes the model, knowing that the simplicity of the model does not fully reflect the complexity of the daily practice. Accepting that limitation, please continue reading.

The V-model states that each building activity in the process of application creation has a matching verification activity. Building activities lead to small (units or single programs) and large (complete systems) deliverables, which all - at each level - require the appropriate types of testing. Common levels for testing are:

• Requirements test
• Program (or unit or applet) test
• System test (a completed system, consisting e.g. of a series of applets and/or services)
• Acceptance test (verification by the user organisation that the system works conform specifications)

The test plan details which tests, run when and by whom (or by what tool), with which techniques, are performed per level of the building process. Specified as well will be if test types like integration, performance, load, and security are relevant.

Acceptable pieces of work
One of the key issues is, when a system (a piece of work, valuable for a user) is acceptable. In the acceptance test experience of Rominco - which mainly regards applications that support business processes - an application is acceptable when the user representation confirms that the system works conform specifications. Once that is the case, the supplier (internal or external) can be discharged and the final part of the invoice be paid. Remaining shortcomings are solved during the maintenance period or next phase of the project. At the proper moment in the project these criteria must be agreed upon between project team, supplier and user management. However various types of formulation exist, in the end (in the Rominco experience), the criteria can be summarized in a sample table like this:

	Acceptable	Test Result	Conclusion
Blocking issues	0	0	Passed
Work-arounds	5	8	Failed
Minor issues	35	28	Passed

A list with the level of criticality for each business process to be tested accompanies this matrix. Such an overview makes objective discrimination between major and minor issues possible.

Agile testing

An agile development approach has two core effects on testing:

• Testing is performed more frequently (to continually) because of smaller pieces of work per delivery
• Testers are integrated in the build teams

Other formulations exists ("Testing no longer is a separate activity" or "Developers perform the testing"); in the opinion of Rominco these are other formulations derived from the same Agile principles. In other words: an agile approach does not necessarily result in additional or less test efforts. The test effort is distributed differently and that requires re-thinking of the usage of automated testing tools.

Earlier assignments

Rominco has been involved in testing for many years. Added all individual testing activities Rominco offers approximately 6 years of dedicated test experience, in various roles. Some examples are:

• Co-execute and coordinate the system test of a submarine class IT system
• Execution of the multi-platform (Mac and Windows) test of a time registration PC application
• Coordinate the system and acceptance test of a Management Information Portal
• Draft the system and acceptance test plan for a large railway project
• Manage the acceptance test of large SAP implementations