AyMINE – Technická dok. (anglicky)
Moduly
Řízení úkolů, projektů a kvality
Řízení úkolů, projektů a kvality
Administrace modulu Řízení úkolů
Systémová práva modulu správy úkolů
Grafy pro dokumentaci problémů a tiketů
Kvalifikace, schopnost / dovednost
Kvalifikace uživatele, pracovníka nebo kontaktu
Právo spravovat kvalifikace uživatelů
Úrovně kompetencí a kvalifikací
Metodika a systém řízení kvality
Co tvoří metodiku / SMJ objectsSVG
Adminitrace oblastí, projektů, kalendářů
Správa jedinečných identifikátorů
Šablony pro jedinečné identifikátory
Problémy, tickety a jejich řízení
Generování odpovědi zákaznického centra
Objekty, kterých se problém týká
Problémy, incidenty, helpdesk tikety
Řízení incidentů, neshod v kvalitě
Grafy pro dokumentaci vývoje zpracování úkolů a problémů
Tým projektu nebo tým k pracovnímu postupu
Vrátit plán projektu podle baseline
Tlačítka pro aktivaci události
Vzorové úkoly a metodiky oblasti
Vzorový úkol – Pracovní postup
Objekty vztahující se ke vzorovému úkolu
Proč nejdou některé údaje smazat
Souhlas vedoucího s výkazem práce
Vliv úkolu na právo měnit připojené objekty
Kontakty, adresáře, smlouvy
Systémová práva a nastavení modulu CRM
Ochrana osobních a obchodních údajů
Posílejte hromadné zprávy v souladu s GDPR
Jak korektně zapomenout údaje o osobě
Odhlášení a nastavení preferencí
pro hromadnou poštu
Odhlášení a nastavení preferencí
pro hromadnou poštu
Přehled objednávek pro zákaznické skupiny
Správa a automatizace webu
Nastavení základních web služeb
Uložit přístup k webové stránce
Odpovídací formulář – nastavení
Uživatelská dokumentace AyMINE
Modul Personalistika
Bezpečnost modulu personalistiky
Personalistika – uživatelská oprávnění
Synchronizace pracovníků a uživatelů systému
Správa údajů o oddělní / divizi
Produkty, aktiva, nákup a prodej
Produkty, aktiva, nákup a prodej
Správa modulu Majetek & Obchod
O kritériích kvality u produktů
Přepočítat nabídku a objednávku
Přístupová práva k nabídkám a cenám
Přijatá objednávka na zboží nebo služby
Vlastnost produktu nebo výrobku
Správa financí
Metriky a měření
Souhrny práce z generovaných dat
Technické moduly
Modul Sabre
Konektor mezi AyMINE a Enterprise Architect
Databázový link do databáze Enterprise Architect
Konektor mezi AyMINE a Enterprise Architect
Systémové moduly
Framework – systémový základ
Nastavte si, jak váš systém vypadá a funguje
Soukromé poznámky a značky k záznamům
Správa systému
Zabezpečení příspěvků a interních diskuzí
Kopírování a přesouvání souborů mezi objekty
Nastavení brán pro externí zprávy
Nastavení IMAP brány pro emailovou komunikaci
Nastavení brány pro internetové volání
Skupiny, týmy a pracovní pozice (role)
Vožení podřazené skupiny / role
Propojení uživatelů s VOIP ústřednou
Automatické potvrzení příchozí zprávy
Pravidla pro automatickou odpověď
Pravidla pro odesílanou zprávu
Typy testů
Typy testů rozlišují etapy ověřování výrobku
- Typ testů podle úrovně
- Další typy testů
- Metodiky stanovující testování
- Ptáte se aneb co vás o testování zajímá
- Kam dál
Typ testů podle úrovně
Unit testy
Unit testy jsou testy na nejnižší úrovni vývoje. Zabývají se základními jednotkami – funkcemi, obvody, základními díly.
Unit testy v podstatě na nejnižší úrovni ověřují, že celek stavíme ze spolehlivých dílků.
Do unit testů by měly být zařazeny všechny funkce – uživatelské, systémové a samozřejmě obsluha všech rozhraní.
Dokumentace Unit testů
U unit testů je zásadní, jakým způsobem je provádíte. Pokud jsou unit testy automatizované, jsou samozřejmě dokumentované díky svému předpisu.
Pokud automatizované nejsou, je obvyklé, že je provádí vývojář ihned po vyvinutí funkce (před commitem do repository). Zápis toho, jak unit test probíhal, by nedával smysl a neúměrně by práci zatěžoval. Nezapomeňte ale, že pokud vývoj probíhá v souladu se standardy jako např. ASPICE, je i dokumentace unit testů povinná.
Základem pro unit testy jsou detailní požadavky na hardware, software, mechatroniku.
Jak unit testy dokumentovat
Pro testy musí existovat metodika, co je třeba testem ověřit. Tester potvrzuje dodržení.
Příklad unit testů pro software:
Standardy požadují statické prověření kódu. To zahrnuje
- Code review – dokumentací je vykonaný úkol, který se kontrolovaného kódu týkal
- Analýza kódu (manuální nebo více či méně automatizovaná) – dokumentací je výstup z analytického nástroje nebo opět potvrzení od toho, kdo analýzu provedl
- Kontrola konzistence (např. kontrola, že jedna funkce volá druhou pro správný účel a se správnými parametry)
Příklad pro hardware (elektroniku):
- Kontrola všech signálových cest
- Analýza v návrhářském software simulací proudových toků
- Ověřením, že hardware dělá, co má, např. nahraje software do paměti, resetuje software, který nereaguje („watch dog“) apod.
Příklad pro mechatroniku:
- Test pevnosti součástek namáháním
- Kontrola odporů pohybujících se dílů (např. lanka v ohybu)
Integrační testy
Smyslem integračních testů je ověřit, že samostatně vyvinuté a na úrovni jednotek otestované části spolu fungují správně.
Integrační testy jsou typicky víceúrovňové pro postupnou integraci.
Nezapomeňte, že integrace probíhá mezi všemi částmi vyvíjeného výrobku – hardware, software, mechatronika.
Vstupem pro integrační testy jsou systémové požadavky.
Akceptační / kvalifikační testování
Cílem těchto úrovní testování je ověření, že celé řešení – výrobek, software – se chovají správně v prostředí, pro které jsou určeny.
Vstupem pro kvalifikační / akceptační testy jsou uživatelské požadavky, omezující podmínky, předpisy a standardy, které musí řešení splňovat
Další typy testů
Testy se člení nejen podle úrovně ale i podle zaměření. Obecně není možné říct, na které úrovni se které typy testů dělají, protože často jsou několika úrovňové stejně, jako funkční testy.
Nejčastěji jsou povinné testy
- Testy kyberbezpečnosti – ověření, že výrobek je odolný proti narušení zvenku. Testy kyberbezpčnosti se provádí na všech úrovních testování
- Testy bezpečnosti (safety) – kontrola, že výrobek je bezpečný. Většinou jde o testy na úrovni akceptačních testů. Patří ale mezi ne např. i testy jednotlivých součástek na teplotní odolnost pro prostředí, ve kterém budou, což je reálně nejnižší úroveň testování.
- Testy odolnosti – Zkoušení různým způsobem namáhání a kontrola, zda výrobek vydrží namáhání, které by měl vydržet po dobu očekávané životnosti
- Zátěžové testy – Blízké testům odolnosti, ale zaměřené na to, jak velkou zátěž výrobek nebo jeho díl snese.
Metodiky stanovující testování
Typy testů jsme si nevymysleli, jsou přesně definované mnoha metodikami. Nejsnáze dostupnou metodikou je SPICE resp. jeho varianta pro automobilový průmysl, ASPICE. Hodně se tomu věnuje i standard vývoje software, ISO/IEC 12204.
Ptáte se aneb co vás o testování zajímá
Jaké typy testů musíme dělat?
Typy testů obecně stanovuje projektová metodika. Pokud máte metodikou ve firmě stanovenou, je třeba se řídit podle ní.
Důležité je, jestli výrobek, který vytváříte, musí splňovat normy. Např. veškerý software do aut, výrobních strojů nebo i přístrojů, které se používají při výrobě, musí projít všemi typy testů. Požadují to normy jako ISO 26262, CMMI i další.
Žádnou normu dodržovat nemusíme, tak se nás povinnosti netýkají
Pokud není vývoj řízen normou povinně, není ani vnější standard. Pro kvalitní ověření fungování software jsou ale přesto nezbytné minimálně
- Unit testy (testování programátora a návrháře řešení) a
- Kvalifikační testy (uživatelské / funkční testování). Bez těchto dvou úrovní zcela určitě zůstane ve výsledném řešení řada nedostatků
Kam dál
Obecně o testech v AyMINE se píše zde.
Školení o testování
Pokud si s testováním nejste jisti, doporučujeme vám školení o testování, kde se všechno naučíte.
Testování je až poslední krok kvality
Standardy kvality se na testování dívají až jako na (skoro) poslední krok, kdy se řeší kvalita výrobku. Kvalita ale začíná už u definice zadání, pokračuje přes návrh až k vývoji a probranému testování.
Celé problematice kvality se věnuje např. toto školení.