| |
GETTING STARTED
FIT FOR PURPOSE (FFP)
Methodologies for ensuring the enterprise app and associated user experiences are fit for purpose - as all apps service a human purpose.
This is part of the user experience design getting started series.
Fit for purpose fits within the "Manage" part of the MADE methodology; as it is a key part of "continuous iterative improvement" (CII) - the checkpoints to ensure the app and the user story are aligned.
|
|
|
|
| |
MADE PRINCIPLES
| Manage |
Manage expecations and the process, including testing to ensure the execution matches the design.
Sample testing plan (docx) |
| Analyse |
Analyse and document the customer and user needs. |
| Design |
System and user experience design, including selection of best human interface and model interfaces (eg endpoints & methods). Example of a mapping diagram as used in Exchange integration. |
| Execute |
Build the application - modify the model structure as required and create the view and controller logic (eg if web-based update js/jQuery scripts) |
TYPES OF TESTING
| FUNCTIONAL |
Functional testing is the process of testing the prescribed functionality of an application or programme, and ensuring that the application is performing as per the documented specification, or to the requirements of its core user audience.
Functional testing is typically carried out in a number of errors, and is usually a mixture of both progression and regression testing
|
| Progression |
Progression testing is the execution in either a structure or unstructured manner (or both) of 'forward looking' test cases, i.e. test cases which seek to work through all areas of software functionality and user interaction.
|
| "V" model |
The testing V model allows for the visual and logical mapping of various test phases to the corresponding documentation set.
|
| Requirements based |
Requirements based testing is the most typically accepted functional testing methodology, and seeks to exercise and validate the documented core application functions and user interactions through the mapping of test cases to business or user requirements.
|
| Risk based |
Risk based testing may also be used. Risk based testing specifies a structure approach to the analysis of software component risk (i.e. functional areas which may be more prone to error on build, compilation or in use) and allows for the appropriate targeting of these areas.
Risk based testing can also be used to determine functional risk (i.e. business critical elements of the software) and allow immediate testing focus on these areas.
Risk based testing can both completed and or replace formal and fully structure requirements based testing.
|
| Holistic / exploratory |
The structure functional testing methodologies detailed above are also complemented with holistic and exploratory testing. These methodologies allow experienced testing professionals to focus initial testing on areas which through their experience, they deem more likely to contain bugs or defects, to have integration type issues etc.
|
| Shakeout |
Shakeout testing (often known as 'smoke' testing) is typically performed upon initial release of software into a particular test environment, and is typically composed of a small sub-set of prime functional test cases.
The chief purpose of shakeout testing is to quickly determine if the software is able to correctly start-up and correctly process commands and user interaction.
Once shakeout testing is completed, the formal and wider phases of functional testing are typically allowed to commence.
|
| Regression |
Shakeout testing (often known as 'smoke' testing) is typically performed upon initial release of software into a particular test environment, and is typically composed of a small sub-set of prime functional test cases.
The chief purpose of shakeout testing is to quickly determine if the software is able to correctly start-up and correctly process commands and user interaction.
Once shakeout testing is completed, the formal and wider phases of functional testing are typically allowed to commence.
|
| NON-FUNCTIONAL |
Non-functional testing is the process of validating areas of the system which are typically not open to primary and direct user interaction, but which nonetheless form important aspects of the overall system behaviour, stability and robustness.
Non-functional testing is typically performed in dedicated test environments as it may have a serious impact on ongoing parallel functional testing (for example when high loads are placed on the system during performance testing, or when security of the system is being explored and validated through security or penetration testing etc.)
|
| Performance |
Performance testing aims to validate the stability of the system at or beyond the required design loads (transactions per second, maximum number of connected users etc.). Commercial performance test tools may be used.
|
| Stability |
Stability testing aims to validate the longer term stability of the system at normal user loads. Stability y testing will typically highlight memory leaks, or long term degradation of the system through for example inefficient garbage collection, inefficient page file reutilisation etc.
|
| Security |
Security testing aims to validate the systems security robustness and ability to withstand 'attack' either by malicious tools or users.
|
| Redundancy |
Redundancy testing aims to validate the correct interaction and swap between redundant systems (i.e. active active, active standby systems) when one or more of the systems is taken offline either in an planned / structure approach, or in an unplanned scenario (i.e. simulating power loss, or loss of connectivity etc.)
|
| STATIC |
Static testing is the practice of verifying software, documentation or underlying development methodologies (which are in themselves likely to provide a guide to overall software quality) without needing to interact in real-time with the application or programme.
|
| Code inspection |
Inspecting the code files |
| Document inspection |
Inspecting the engineering documentation |
CLASSIFICATIONS
| Critical |
One or more major elements of the system is not functioning, or one or more major elements of the system are unstable to a degree that deployment into an end user environment would likely result in the non acceptance of the application.
|
| Major |
One ore more major elements of the system contain errors which are likely to serious impact end user interaction with the system, or result in business impact such as loss of revenue, loss of ability to interact with customer etc.
|
| Minor |
A small self contained area of the system is functional, may be occasionally unstable, slow to respond etc., but can still be used primarily as per specification.
|
| Cosmetic |
Typically a design flaw, spelling or grammar mistake etc.
|
|
|
| User Experience
"User experience" encompasses all aspects of the end-user's interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother.
Keep reading...
|
Useful links
Automated functional testing - good, bad, ugly
Agile
Incrementalism
|
|
|
