ASWI - Pokročilé softwarové inženýrství » ASWI 2024 » Zachycení scénáře průchodu webovou aplikací - VUŠ

h1. Demo schůzka 1. iterace (5-3-2024)

h2. Vize

** Cíle - zdůraznit, že se jedná o průchod a na konci lze poznat, že jsme došli do nějakého konce, potřebujeme asserty

** Nenavazuje se na žádnou práci - dostaneme kontakt na diplomanta, ten nám ukáže s čím má už zkušenost (končí letos)

** Spíše nepoužívat názvosloví "Jednotkový test" (spíš testů, generování GUI testů)

** Jednotlivé požadavky

*** Doplnit "Upravení/Smazání kroku", nechceme začínat pokaždé znovu pokud se uklikneme

*** Uživatel nebude nejspíš schopný upravovat v textovém souboru, spíše to rozbije - umožnit vrácení kroku

** Dokumentace v angličtině

** Diskuze o jádrech prohlížečů - Chrome, Mozzilla (diskuze o Safari) - ve specifikaci "pouze jeden must-have"

** *Vize s pohledu zadavatele v pořádku*

h2. Specifikace

** Specifikace uživatelů - nejsou to programátoři

** Aplikace by neměla být obtěžující, ale mělo by být jasně vidět, že se nahrává (po akci nějaká neinvazivní notifikace) - neříkat "nebude notifikován"

** Vždy je dobré vědět, jestli aplikace udělala to co jsme očekávali (dobré nějaké potvrzení) - potřeba zpětné vazby

** On demand ovládací okno - návrh UI (probíráno později

** Možnost vypnutí / zapnutí scénáře - zobrazení scénáře akce po akci (čitelně pro člověka - co víme to prozradit - co nejvíce vysokoúrovňová informace pro uživatele)

*** Pro uživatele lepší reprezentovat pomocí jména, typu (co je vidět na obrazovce)

*** Pro stroj nutné reprezentovat pomocí ID

** Označení cílové stavu - jak poznat že je to cílový stav (barva, v políčku je něco napsáno) - analýza jak různé weby notifikují uživatele o něčem

*** Uživatel by měl mít možnost vybrat co je cílem (možná i více stavů, které potvrzují stejný stav úspěchu)

*** Nutno vymyslet nějaký dialog pro zadání cílového stavu

*** Aplikace určitě nepokryje všechny možnosti - zaměřit se na ty běžné

*** Na konci si v podstatě vybrat co je cílový stav - vzít v potaz akce, které byly provedeny předtím (možná vybrat z nich)

** Dokumentace (možná přeložit pomocí překladače?)

** Import - nice-to-have s nejnižší prioritou

*** Problém s importem v momentě kdy nemáme stránku ve stejném stavu (což se téměř nepravděpodobné)

** Cílem není dodělat produkt pro diplomanta - dobrá spolupráce mezi ním a týmem, momentálně dělá experimenty, generování

*** Možnost více formátů výstupu (experimentálně), důležité aby jsme měli kompletní data a exporter umožňovat je nějak modifikovat (různé podoby exportovaných dat)

*** Transformace může být prováděna ex-post (ze stringů), implementace rozhraní (doplnění modulů pro různé exporty)

** *Zadavatel souhlasí se specifikací*

h2. Obchody rozšíření

** Probrán poplatek 5 dolarů (zadavatel zaplatí sám, fakulta nejspíš žádný účet nemá - p. Pešička možná bude mít)

** Účet by byl veden na p. Lipku, aby bylo možno pokračovat ve vývoji (dokáže zařídit - *poskytnout nějaký odkaz - nasměrovat přes Discord*)

** Schválení rozšíření cca 3 - 30 dní

h2. Návrh uživatelského rozhraní

** Ukázáno několik možných uživatelských rozhraní pro různé use-casy

** Úprava bude ještě upravena - závisí na provedené analýze

** Nepřekrývat procházenou stránku, umožnit vidět záznam stránky v tabu, okně mimo (dá se i pokud by to bylo vidět v nástroji pro vývojáře)

** Uživatel by neměl být nucen zvětšovat / zmenšovat stránku

** Okénko odděleno, nebude přímo v DOM stránky

** Vše závisí na tom co zjistíme při vývoji

h2. Ostatní poznámky

** Doplňky uživatele nebrat v úvahu - jen webovou stránku

** Ovlivňování doplňků mezi sebou

h2. Gitlab

** Zadavatel přidán do projektového GitLabu

h2. Výstupy

** Zadavatel nám předá kontakt na diplomanta

** Zadavatel zajistí profil v obchodu

** Nezkoušet programovat nic konkrétního, spíš naučit se jak zacházet s technologií, incializovat plugin, Hello Word

** Další schůzka 19. 3.