AyMINE – Technical documentation
Interfaces to other systems
Enterprise Architect Connector
CalDav, WebDav using Sabre
Business excelenece
Balance Scroecards
Task & Project Control
- Helpdesk ticket - reply to customer
- Test
- Qualification of user or contact
- Project role
- What makes up the methodology / QMS
- dragdrop
- Location
- My areas
- Kanban Task Overview
- Personal Task
- Internal helpdesk
- Customer Care Centre
- Project baseline
- Return project plan by baseline
- Project Schedule
- Processing time sheets
- Records managed by a project
- Activation buttons
- Why some data can't be deleted
- Starting events
- Qualification of user or contact
- task_taskobjects
- Project
- Reminders and Messages
- eventobj_raisingevents
- decision_decobjects
- eventobj_startingevents
- eventobj_eventbuttons
- Type of tests
- Deal management
- FMEA - Detection
- FMEA - Features
- FMEA Methodology | AyMINE
- FMEA - Occurence analysis
- FMEA Severity analysis
- FMEA
- Management of responsibilities - RACI Matrix
- RACI Matrix for Project
- Improvements and Preventive Measures
- Notice – example of use
- tskproblem_terminology
- 8D report
- Task Scheduling
- Administration of the Task Management Module
- Adminitration of areas, projects, calendars
- Discussion
- GDPR and record of qualifications
- System rights for the task management module
- Project Planning
- Employee Tasks
- Incident and Quality Issue Management
- Collaborative Resolution of Multiple Problems
- List of business areas
- Required qualifications
- Plan template / strategy
- Decision
- Configuration Package
- Record template
- Change management process in a project
- Task list
- Requirements
- Team Member
- Right to Manage Qualifications
- Input requirements
- Obligation
- Competencies and Skills
- Problems, tickets and their management
- Meeting
- Package definition
- Phrases and terms
- Data Area
- Risk
- Task
- Business event
- Task, project & quality management
- Records and protocols
- Directives and Policies
- Events
- Risk Pattern
- Information
- Project definition
- Activity log
- eventinstances
- Personal calendar
- Objects of decision making
- Event activation buttons
- Objects affected by the problem
- Variant decision-making
- Recorded activities
- Self-Reminders
- QMS and Task Management
- Objects related to the task pattern
- Effect of the task on the right to modify the atta
- Level of Competence
- Manager approval with the task report
- Region / project / methodology
- Manage your marks
- tskdefusertask
- Quality Management System (QMS)
- tsktask_batasks
- Project Team
- Events and meetings
- Events and meetings
- List of event instances
- moduleclientoptions
- Processed objects
- Mark patterns
- Notification events
Interprocess management
Human Resources
- hrstcontract
- roles
- Human resources
- Digital Personnel Archive
- Personalistics – User Permissions and roles
- Registration of job seekers
- Manage department / division data
- Job Position
- Worker
- Worker overview
- An overview of your staff
- Responsible HR Manager
- Synchronizing staff and system users
- modulesafety
Asset Management
- Products, assets and sales
- Tendering and purchasing
- Analytical model
- Product Supplier
- Product Categories
- Product or Product Property
- Project Goal
- Business Offer
- Offers summaries
- Recalculate bid
- Offer and Price Access Rights
- Creating and processing orders
- System order status query
- Order Reports
- Pricing
- Pricing – volume discounts
- Products and Goods
- Product status and change
- Product Units
- Quality criteria
- Why are the Quality criteria usefull
- DFMEA - Product FMEA
- Hara | Hazarad & Risk Analysis
Customer Relationship - CRM
- Contacts and directories module (
- System Permissions and CRM Module Settings
- Customer Order Overview
- Address books
- Address book list and management
- Privacy policy
- Send bulk messages in compliance with GDPR
- Bulk email footer
- Unsubscribe and set preferences
for bulk mail - How to correctly forget a person's details
- Bulk Emails
- Contracts
- Partner in a contract
- Message patterns
- Groups of contacts
- Order overview for customer groups
- Directory or people and companies
- Contact per person or company
- Quickly available contacts
Finance management
System modules
System management
- moduleclientoptions
- digiSign
- formattedtexts
- System Configuration
- Processes in use
- Client
- Configure gateways for external messages
- Message with the outside world
- Email messages
- Secure business communication
- Send SMS directly from CRM
- Call directly from CRM
- Documents and files
- Additional functions with files
- Copying and moving files between objects
- Picture presentation
- Public link to the document
- Recent Files
- Dashboard
- Object location on the board
- Client items
- Revisions and comments
- Securing posts and internal discussions
- Translations
- Record Relationships
- Relation types
- sysrole
- User Processes
- System module
- System User
- User administration
- User Administration
- Secure login to the sytem
- Connecting users to VOIP PBX
- Secure Key Wallet
Framework
- frmobjectextension
- introhelp
- introhelp_mobile
- introhelp_aplikace
- versioninfo
- releases
- AyMINE modules and basic types
- cliplink
- introhelp_settings
- introhelp_deleting
- introhelp_dragdrop
- list_filtering
- AyMINE intro
- AyMINE access security
- AyMINE Modules
- Object locks
- System rights
- introhelp_keyshortcuts
- introhelp_shortcuts
- introhelp_icons
- list
- introhelp_generalinfo
- introhelp_objectdetail
- introhelp_objectlist
- introhelp_privateobjectnotes
- AyMINE User Rights Control
- introhelp_dashboard
Type of tests
Test types distinguish the stages of product verification
- Test type by level
- Other types of tests
- Methodologies defining testing
- You ask or what you want to know about testing
- Where to go next
Test type by level
Unit tests
Unit tests are tests at the lowest level of development. They deal with basic units – functions, circuits, basic parts.
Basically, unit tests at the lowest level verify that the whole is built from reliable parts.
Unit tests should include all functions – user, system, and of course the operation of all interfaces.
Unit test documentation
With unit tests, how you perform them is critical. If unit tests are automated, they are of course documented due to their code.
If they are not automated, it is usual that they are performed by the developer immediately after the feature is developed (before commit to the repository). Writing down how the unit test was run would not make sense and would burden the work disproportionately. Remember, however, that if development is done in accordance with standards such as ASPICE, documentation of unit tests is also mandatory.
The basis for unit tests are detailed requirements for hardware, software, mechatronics.
How to document unit tests
There must be a methodology for the tests, what needs to be verified by the test. The tester confirms compliance.
Example of unit tests for software:
The standards require static code review. This includes
- Code review – documentation is the task performed that involved the code being reviewed
- Code analysis (manual or more or less automated) – the documentation is the output from the analysis tool or, again, confirmation from whoever performed the analysis
- Consistency check (e.g. checking that one function calls another for the correct purpose and with the correct parameters)
Example for hardware (electronics):
- Check all signal paths
- Analysis in design software by simulating current flows
- Verifying that the hardware is doing what it is supposed to do, e.g. loading software into memory, resetting software that is not responding ("watch dog"), etc.
Example for mechatronics:
- Stress test the strength of components
- Checking the resistance of moving parts (e.g. cables in bending)
Integration tests
The purpose of integration tests is to verify that separately developed and unit-level tested parts work together correctly.
Integration tests are typically multilevel for incremental integration.
Remember that integration takes place between all parts of the product under development – hardware, software, mechatronics.
The input for integration tests is the system requirements.
Acceptance/qualification testing
The goal of these levels of testing is to verify that the entire solution – product, software – behaves correctly in the environment for which it is intended.
The input for qualification/acceptance testing is the user requirements, constraints, regulations and standards that the solution must meet
Other types of tests
Tests are categorized not only by level but also by focus. In general, it is not possible to say at which level which types of tests are done, because they are often multi-level in the same way as functional tests.
The most common tests are mandatory tests
- Cybersecurity tests – verify that the product is resistant to external intrusion. Cybersecurity tests are performed at all levels of testing
- Security tests – checking that the product is secure. These are usually acceptance level tests. But they include, for example, tests of individual components for temperature resistance for the environment they will be in, which is realistically the lowest level of testing.
- Resistance Tests – Testing under various stresses to see if the product can withstand the stresses it is expected to withstand over its expected lifetime
- Stress Tests – Close to endurance tests, but focused on how much stress a product or part can withstand.
Methodologies defining testing
We did not invent the types of tests, they are precisely defined by many methodologies. The most readily available methodology is SPICE, or its automotive variant, ASPICE. There is also a lot of work on software development standard, ISO/IEC 12204.
You ask or what you want to know about testing
What types of tests do we need to do?
The types of tests are generally defined by the project methodology. If you have an established methodology in your company, you need to follow it.
The important thing is whether the product you are creating must meet the standards. For example, all software for cars, production machines or even instruments that are used in production must pass all types of tests. Standards such as ISO 26262, CMMI and others require this.
We do not have to comply with any standard, so we are not affected by the obligations
If the development is not driven by a mandatory standard, there is no external standard. However, for a good verification of the functioning of the software, at least
- Unit tests (testing of the programmer and solution designer) and
- Qualification tests (user/functional testing). Without these two levels, there are bound to be many flaws in the final solution
Where to go next
General about AyMINE tests here.
Training on testing
If you are unsure about testing, we recommend training on testing to learn everything.
Testing is the last step in quality
Quality standards look at testing as (almost) the last step, where the quality of the product is addressed. But quality starts at the definition of the brief, continues through design to development and testing.
The whole issue of quality is covered in this training, for example.
