AyMINE – Technical documentation
Task, project & quality management
Manager approval with the task report
Why some data can't be deleted
Region / project / methodology
Change management process in a project
Qualification of user or contact
Right to Manage Qualifications
Methodology and Quality Management systems
What a methodology / QMS consists of
Objects affected by the problem
Sample tasks and methodologies of the area
Effect of the task on the right to modify the attached object
Objects related to the task pattern
Contacts and directories module (CRM)
Address book or people and companies
Web management and automation
Receiving a message from the web
Asset management module
Sabre plugin module
Enterprise Architect connector
Database link to Enterprise Architect database
The AyMINE framework module
Configure how your system looks and works
Gestures and keyboard shortcuts
How the system works and how it protects data
Private notes and tags for objects
Filtering in the list of records
Additional functions with files
Copying and moving files between objects
Files (documents) linked to the object
Tests are used to describe the checks that must be performed before the product is put into operation.
Examples of the use of tests are
- Checking the software after integration
- Production unit check before launch
- Acceptance check of the completed unit
All of these cases have a defined inspection procedure, which usually includes product-specific points, and the tests are derived from the product itself and its characteristics, but also from general standards (e.g. electrical inspection requirements). The test for a product or part of a product therefore contains a description of what is to be checked, with the possibility of referring at the same time to the regulations and standards that are taken into account in the test.
How to use the tests
Tests are primarily an integral part of the description of a product or part of a product (e.g. an interface). However, they are separate descriptions and the same test can be part of the inspection of multiple products. Tests should therefore be stored together with products (in the same project or area).
A test can also be created separately in a project and does not have to be linked to a product. These tests do not focus on the product, but on the correctness of the project itself – they are therefore audits. They should not be aimed at checking the product itself, which should always be checked by the tests that are attached to it.
A test is not the execution of a test
The test itself is the documentation of how to perform the testing. It is not a record of the testing activity. Proper test planning requires that you create a test assignment – a task to perform a specific test on a specific product (e.g. a manufactured production line). The test task should therefore always be linked to the product being tested and the tests that were used for verification.
You plan a test by creating a new test task in the project – within the test task you attach the test or tests and the product that is being tested. In addition, you add who will perform the testing and when.
You can't create a protocol for the test
A test is a documentation of how to perform a specific test – effectively a test assignment. The test itself is performed on the basis of a task; ideally a test task.
A protocol is automatically created from the task on the individual progress steps (on the activity tabs). New Protocol button can also create a complex protocol and insert all necessary attachments in documents.
You can't add a request to the test
You can add a request to the test. On the relations tab you can select a request and attach it. Directly by the New (relationship) button.