QA a akceptace
QA má potvrdit, že klient dokáže projít skutečný provozní workflow, nejen že se načítají jednotlivé obrazovky. Tuto stránku používejte před spuštěním, po větších konfiguračních změnách a po produktových změnách, které ovlivňují uživatele, přiřazení, reporting nebo integrace.
Akceptační princip
Sekce “Akceptační princip”Scénář je akceptovaný jen tehdy, když owner umí odpovědět na tři otázky:
- Co jsme čekali, že se stane?
- Co se skutečně stalo v UI, reportu, API nebo webhooku?
- Jaký důkaz výsledek potvrzuje?
Důkaz může být screenshot, řádek exportu, API response, webhook delivery log nebo interní poznámka s přesným prostředím a časem.
Hlavní QA scénáře
Sekce “Hlavní QA scénáře”| Scénář | Kroky | Očekávaný výsledek | Důkaz |
|---|---|---|---|
| Vytvořit aktivního uživatele | Přidat uživatele ručně nebo dohodnutým importem/API cestou. | Uživatel je v prostoru se správnou rolí, stavem a identifikátorem. | Screenshot detailu uživatele nebo API response. |
| Přiřadit školení přes skupinu | Přidat uživatele do skupiny s přiřazeným obsahem. | Uživatel dostane očekávané školení. | Pohled studenta a screenshot skupinového přiřazení. |
| Přiřadit školení přímo | Přiřadit obsah přímo jednomu uživateli. | Uživatel dostane školení i bez členství ve skupině. | Pohled studenta a detail přiřazení. |
| Práce s termínem | Přiřadit obsah s termínem. | Reporting ukazuje očekávané datum splnění. | Řádek reportu nebo exportu. |
| Dokončení | Dokončit test nebo kurz jako student. | Dokončení je v reportingu a certifikát se chová správně. | Obrazovka dokončení, řádek reportu, stav certifikátu. |
| Odebraný uživatel | Odebrat nebo archivovat uživatele. | Uživatel už není aktivní účastník, ale historie zůstává dohledatelná. | Detail uživatele a historický report. |
| Změna verze obsahu | Aktivovat nebo převzít novější verzi obsahu. | Nová přiřazení používají očekávanou verzi; chování rozpracovaných studií je pochopené. | Detail verze obsahu a vzorek participation. |
| Doručení integrace | Vyvolat nakonfigurovaný API/webhook tok. | Externí systém dostane nebo umí přečíst očekávaný stav. | API response, webhook delivery nebo externí log. |
Checklist pro sign-off ownera
Sekce “Checklist pro sign-off ownera”| Kontrola | Kritérium splnění |
|---|---|
| Uživatelé | Vzorek uživatelů pokrývá ownera, admina, běžného studenta a odebraného uživatele. |
| Skupiny | Je ověřené alespoň jedno skupinové a jedno přímé přiřazení. |
| Obsah | Vlastní a koupený obsah jsou zkontrolované zvlášť, pokud existují oba typy. |
| Reporting | Owner umí najít dokončenost, prošlá školení a stav certifikátu. |
| Integrace | Retry a error handling jsou popsané, pokud se používá API nebo webhooky. |
| Screenshoty | Povinné screenshoty existují nebo jsou výslovně označené jako chybějící. |
| Otevřené problémy | Každý známý problém má vlastníka, závažnost a další krok. |
Regression pack
Sekce “Regression pack”Menší regression pack spusťte po změnách obsahu, importu uživatelů, logiky přiřazování, reportingu nebo API integrace:
- vytvořit nebo upravit jednoho uživatele,
- přidat uživatele do skupiny,
- ověřit přiřazený obsah,
- dokončit jedno školení,
- zkontrolovat reporting a stav certifikátu,
- ověřit integrační výstup, pokud je zapnutý.
Log známých mezer
Sekce “Log známých mezer”Dokud není hotový specializovaný feedback tooling, držte nevyřešené problémy v jednoduché tabulce:
| ID | Oblast | Problém | Důkaz | Owner | Stav |
|---|---|---|---|---|---|
QA-001 | Příklad | Tento řádek nahradit reálným problémem z rollout. | Screenshot nebo cesta k exportu. | Vlastník projektu | Otevřeno |
Až bude hotový paragraph-level feedback tooling, tabulka má odkazovat na přesný zpochybněný odstavec nebo screenshot.