User Acceptance Tests (notes)
Categories: Risk Management, System design
This article is a compilation of notes on acceptance testing in my region.
Acceptance tests are conducted when a system or deliverable is defined as ready for acceptance. How a deliverable is determined as ready or complete is a matter for agreement between the project owner i.e. customer and the project team aka supplier. Generally the completeness of a deliverable should cover all aspects of contracted requirements. People's expectations in particular and specified granularity on requirement details for quality matters, can influence and change what will ultimately constitute the completeness of a project deliverable.
Acceptance tests are conducted in the presence of the customer, typically after the customer has agreed to take over a deliverable.
Testing considers the location and are conducted at both the following (always for large projects):
In brief, the following are performed leading to the actual test (see test categories):
The different test categories in sequence:
The number of tests can easily double when we factor in requirement for preliminary testing (the exception being the reliability test itself and audits - we can't tell auditors what to do). And yes, there will be corrections in every test category.
Upon completion of each test from the category list above - at the least, will incur the following activities:
Note that acceptance tests may be conducted:
A best practice approach to acceptance testing:
Read also User Acceptance Tests (documentation issues)
* I'll keep this as a live document. Hmm ..
Opinion on App Design
information communication technology,
Categories: App design, information communication technology, System design
This brief is intended to document & serve as a general guide on what typical technology features 'to look out for' when confronted with new ICT application projects or opportunities. At a high level overview of common system functions which are necessary to implement useful tech products, gleaned from experience. These notes may be biased towards using the Cloud.
IMO a useful piece of software should be designed & developed with minimally the following broad features:
The list above surmises my preferences. Yours may differ. And there are many other features, some which are essential to consider & in detail when specifying functional requirements of a piece of application software /device /in combination. Now that the application has some form of character, who uses it should be considered next.
The application should distinguish without elaborating, the following roles:
Users have their expectations too. A good piece of application should be accessible anywhere & anytime. There are limits though if the application is dependent on something or things beyond your control (design /development /operational).
High availability & ease of use to a user would be expectations for e.g. in software:
Are you ready to accede to requirements? Assuming money matters are outside your purview e.g. procurement of licenses, additional considerations would include ensuring:
Few pointers to think about for maintenance & maintainability of the application include: