Používateľ nahrá do systému faktúru, zaradí ju do kategórie „Faktúry“, pridá tag „dodávateľ“ a vyplní rok 2026. Dokument uloží bez chyby.
Neskôr však zistí, že sa dokument nezobrazí vo výsledkoch filtrovania podľa roku. Kolegyňa navyše môže rovnakému dokumentu pridať tag „Dodávateľ“ s veľkým začiatočným písmenom. V systéme tak vzniknú dva tagy s rovnakým významom.…
Táto šablóna slúži na vytvorenie samostatnej znalostnej položky, ktorú môže používať človek, interné vyhľadávanie, AI asistent alebo RAG riešenie.
Jedna znalostná položka má riešiť jednu konkrétnu tému, postup, pravidlo alebo problém. Nemá spájať viac nesúvisiacich oblastí do jedného dokumentu.
Názov znalostnej položky:
Interný identifikátor:
Typ znalosti:
Modul alebo oblasť systému:
Produkt:
Verzia produktu:
Prostredie:
Rozsah platnosti:
Používateľská rola:
Cieľová skupina:
Séria: Ako písať dokumentáciu a manuály v IT projekte
Pracovníčka supportu riešila používateľa, ktorý sa po niekoľkých neúspešných pokusoch nemohol prihlásiť do systému. Interného AI asistenta sa opýtala:
„Ako odblokujem používateľa po troch nesprávnych heslách?“
AI jej ponúkla postup na obnovenie zabudnutého hesla.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
Pracovníčka supportu sa interného AI asistenta opýtala:
„Ako môžem zákazníkovi znovu vystaviť faktúru?“
AI odpovedala konkrétnym postupom:
Príklad
Aplikácia umožňuje ukladať dokumenty do štruktúry:
Klienti
Používateľ vytvorí dokument pre Firmu A a vyberie typ „Faktúra“.
Na prvý pohľad je test jednoduchý: dokument sa uložil.
Lenže nestačí overiť, že súbor niekde existuje. Dôležité je aj to, či skončil presne tam, kde má.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
Pracovníčka supportu riešila objednávku, ktorá po úspešnej platbe zostala v stave Čaká na platbu. Interného AI asistenta sa opýtala:
„Ako máme opraviť stav objednávky po úspešnej platbe?“
AI našla konkrétny postup:
Séria: Ako písať dokumentáciu a manuály v IT projekte
Interný AI asistent mal pomáhať supportu pri riešení problémov s objednávkami. Do znalostnej bázy sme preto pridali dokument, ktorý opisoval celý proces platby:
Séria: Ako písať dokumentáciu a manuály v IT projekte
Testerka požiada interného AI asistenta:
„Priprav mi testovacie scenáre pre zmenu spôsobu platby.“
AI vytvorí prehľadný zoznam testov. Overí výber platobnej metódy, úspešnú platbu, zamietnutie platby aj zobrazenie chybovej správy. Odpoveď pôsobí profesionálne a na prvý pohľad jej nič nechýba.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
Používateľ nahlásil, že po odoslaní objednávky nedostal potvrdzovací e-mail.
V znalostnej báze sme našli tri dokumenty:
Prvý dokument opisoval nastavenie e-mailového servera. Druhý obsahoval zoznam udalostí, pri ktorých systém posiela notifikácie.…
Príklad
Portál zobrazuje verejné podujatia aj ich detail. Neprihlásený návštevník môže vidieť názov, dátum a miesto verejného podujatia. Zoznam účastníkov, interné poznámky, možnosť upravovať podujatie a export údajov však majú byť dostupné iba prihláseným používateľom s príslušným oprávnením.
Pri testovaní nestačí overiť, že sa anonymnému návštevníkovi nezobrazilo tlačidlo Upraviť.…
Príklad
Projektová manažérka zdieľa návrh zmluvy dvoma spôsobmi. Kolegom vo firme pošle interný link, ktorý má fungovať len po prihlásení do firemného účtu. Dodávateľovi pošle externý link s právom iba na zobrazenie a platnosťou do piatka.
Pri teste nestačí overiť, že sa dokument po kliknutí otvorí.…
Séria: Ako písať dokumentáciu a manuály v IT projekte
Firma sa rozhodne nasadiť AI asistenta pre support. Do nástroja pripojí priečinok s návodiami, export starých tiketov, FAQ a niekoľko interných dokumentov.
Po prvých otázkach prichádza sklamanie.
Používateľ sa opýta, prečo sa mu nevytvorila faktúra.…
Príklad
Aplikácia má tri používateľské roly:
Séria: Ako písať dokumentáciu a manuály v IT projekte
V piatok má ísť do produkcie verzia 2026.09.
Projektový manažér si vypýta podklad k release notes. V Jire je uzatvorená user story, niekoľko vývojových taskov a tri bugy. Špecifikácia obsahuje zmenu schvaľovania objednávok, ale v jednom bug reporte je dôležitá výnimka, ktorá sa do pôvodného návrhu vôbec nedostala.…
Príklad
V systéme na správu dokumentov existuje priečinok Projekty, do ktorého majú členovia tímu právo dokumenty zobrazovať. V jeho podpriečinku Projekty/Financie sú však citlivé rozpočty. Vedúca financií tu potrebuje upravovať dokumenty, ostatní členovia tímu ich nemajú ani vidieť.
Tester potrebuje overiť, či sa práva z nadradeného priečinka prenášajú na podpriečinky podľa nastavených pravidiel, či výnimka dedenie správne preruší a či sa obmedzenie nedá obísť priamou URL adresou alebo API.…
Séria: Ako písať dokumentáciu a manuály v IT projekte](https://www.itpomocnicka.sk/tvorba-pouzivatelskej-a-technickej-dokumentacie/)
Release je nasadený. Vývoj uzavrel ticket, testerka otestovala zmenu, product owner potvrdil správanie. Technicky je všetko hotové.
Potom príde otázka zo supportu:
„Čo sa vlastne zmenilo? Máme to niekde popísané?“
V release notes je jedna veta:
„Upravené správanie objednávkového procesu.“…
Séria: Ako písať dokumentáciu a manuály v IT projekte
Testerka hlási:
„Objednávka je zaplatená, ale stále má stav Čaká na platbu.“
Platobná brána ukazuje úspešnú platbu.
Peniaze boli odpočítané.
Objednávka existuje.
Na prvý pohľad sa zdá, že sa po zaplatení nezmenil stav objednávky.…
Príklad
Firma používa systém na správu dokumentov, v ktorom pracujú zamestnanci, vedúci oddelení a administrátori.
Bežný zamestnanec môže dokument zobraziť, ale nemôže ho upraviť ani odstrániť. Editor môže dokument zobraziť a upraviť. Administrátor má oprávnenie dokument zobraziť, upraviť aj odstrániť.
Tester musí overiť nielen to, či sa používateľovi zobrazujú správne tlačidlá, ale aj to, či systém zakázanú operáciu odmietne pri priamom volaní API alebo pri otvorení upravenej URL adresy.…
Príklad
Preview dokumentu patrí medzi funkcie, ktoré používatelia používajú denne. Chcú si rýchlo overiť obsah bez nutnosti sťahovania súboru. Ak sa však dokument zobrazí nesprávne, môže používateľ pracovať s neúplnými alebo skreslenými informáciami. Preto nestačí otestovať len to, že sa náhľad otvorí.
Príklad
V systémoch na správu dokumentov sa často používa mechanizmus check-in / check-out. Keď používateľ začne dokument upravovať, dokument sa zamkne, aby nedošlo k súčasnej úprave viacerými ľuďmi.
Cieľ je jednoduchý – zabrániť strate zmien a prepísaniu práce iného používateľa. Ak však zamykanie nefunguje správne, môže dôjsť k blokovaniu práce alebo naopak k prepísaniu údajov.…
