Vlákno názorů k článku Co to znamená „pořádně“ otestovat webovou aplikaci? od M. - Pekny clanok, dufam, ze si z tohoto serialu...
-
\neq (neregistrovaný)
No, já bych si přál, aby se objevilo i něco podobného, z čeho by si mohli vzít ponaučení lidi, kteří řídí lidi vyvíjející software.
Jinými slovy, můj hlas vývojáře „naše aplikace opravdu potřebuje aspoň nějaké testování“ je totiž poněkud... neslyšen. Resp. jsem vždy poučen o tom, že školní teorie (je potřeba identifikovat, jaký rozsah testů je vhodný pro daný sw a pak je implementovat) není reálnou praxí (na testy nejsou peníze a investice do testů negeneruje nic, co by investoři viděli).
-
Ondra Satai NekolaZlatý podporovatelJe to obvykle chyba managementu/procesu.
Protoze programatori pri nejlepsi vuli chyby (v ruznem mnozstvi a s ruznou zavaznistu) delaji, tak je potreba je obalit procesem, ktery omezuje moznost, ze se ta chyba dostane do produkce.
(Samozrejme jsou i situace, kdy to je chyba programatora, trebas pokud z nedbalosti oignoroval dohodnuty postup. Ale bohuzel i pokud programator je chytry a opatrny a nedela hloupe chyby, stale dela chyby.)
-
Presne tak,
trvalo nam cca 4 roky a zmenu nekolika devel manageru, nez jsme se dostali k procesu Development -> Testing -> UAT -> Pre-Production -> Production Release. A to jsme pouhe interni BI oddeleni o nekolika desitkach developeru a nekolika dedikovanych testerech. Dnes uz konecne mame unit testing nad DWH a MOLAP modely. Dashboardy a reporty se testuji bohuzel rucne, vse ostatni nam resi TestRail a Jenkins, ted uz mame celkem blizko k CI/CD, ale i tak to vidim jeste na nekolik let. Bohuzel snadno se rika jak to ma byt, ale cesta k cili je vetsinou dost trnita. Ono nakreslit to na papir je vetsinou celkem snadne, ale dostat to do praxe je v mnoha korporacich nemozne. Dodnes slysime, ze nas release cycle je 2-3x pomalejsi, nez byl predtim, nicmene pri tak striktnim procesu co jsem popsal vyse, se neni cemu divit. -
Trident (neregistrovaný)
Co vas v te skole uci? Projit zkouskami? Chyby na urcite urovni komplexity podporene lidskym faktorem jsou nevyhnutelne. Softwarove produkty jsou jedny z nejkomplexnejsich stroju ktere clovek kdy vyvinul. Kazdy zkuseny manazer akceptuje chybovost pri vyvoji jako bezny jev se kterym je treba pocitat.
Procesy testovani (oddelene od i od primarniho vyvoje) jsou zakladni praktiky inzenyrstvi. Pisi inzenyrstvi protoze je to vec ktera jde skrz mnoho oboru a netyka se jen software.
-
sid1 (neregistrovaný)
To slovo inzinirstvi je presne ten zakladny problem. Moja skusenost je ta, ze kedze sa to nemoze zrutit ako most tak naprosta vacsina manegerov pristupuje k testom ako niecomu co pokial mozno treba osekat ako sa da a kedze sa nenamahaju tomu rozumiet tak jedina metrika co poznaju je pokrytie kodu testami co je vyzera na prvy pohlad fajn ale o skutocnej kvalite testov to az tak moc nehovori. Keby aspon trocha uvazovali ako pises tak by kvalita skokovo vzrastla. Len by potrebovali miesto debilnych grafov obcas aj vzdelat a nielen 5 minut cez google
-
disenchantment (neregistrovaný)
Nebudem sem davat url iba citujem:
Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same.
Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”
-
nemo22 (neregistrovaný)
Ano, az na to ze kolko rokov, desatroci, storoci sa vyvyjalo stavebnictvo, materialy. Pri montazi aut, v stavebnictve sa pouzivaju standardizovane dielce, maju standardne rozmery atd. Nikto pocas stavby nezmeni zrazu priemer odpadovych rur s tym ze ine sa uz nebudu dat zohnat. Pri vyrobe sa nezmenia zavity na skrutkach z noci na den, co je celkom bezny jav pri sw - rozne automaticke updaty. Nehovoriac o tom ze vecsina strojov, pristrojov sa daju rozobrat na relativne jednoduche zakladne suciastky alebo aspon moduly (vynimajuc digitalnu elektroniku ale to sme zasa pri IT). Pri SW to ide dost tazko.
-
anonym (neregistrovaný)
Realita: Zakaznik kupuje burger z obrazku za 6eur. Cim skor ho ma tym menej ho trapi za co zaplatil.
To je bezny kontrakt b2b. To ze ludia ktory to vyvijaju maju nervy a ludia co to pouzivaju maju nervy nikoho nezaujima.Predpokladajme ze nikde inde niesu chyby iba v aplikacii a ze zakaznik dodal uplne deterministicku specifikaciu na urovni pravdivostnych tabuliek a programator by kopiroval specifikaciu. Pekne db,b-e,f-e,vcs,bs,ds,ts,pps,ps.... naplanovane devops ako zo skatulky. Tak tam tie chyby ozaj robi iba programator.
Zvycajne projekt taha ten jeden programator. Robi uplne vsetko potyka sa s chybami ktore sa nedaju casto predpokladat. Ma 10% casu na vyvoj. Zvycajne caka na doplnenie specifikacie ci pridanie disk space niekam. Nic poriadne nemoze zmenit lebo vsade su neake zavislosti a nieje podla coho zistit ako to ma fungovat alebo nema prava.
Zadania uz maju matematicke/logicke chyby/nepresnosti. Priklad nieco neplati do 15teho roku je to 14.99, 15, 15.99? Zakazte platbu MC proste sa neratalo s tym ze niekto pouzije Amex a nie Visu. Dajte to na druhu az na to ze casom prisli na to ze to vracia iba kladne hodnoty....Snad som v niecom vyjasnil ze kde su chyby. Snazil som sa pisat co najmenej a nejde mi to.
V texte su asi chyby nakolko som sa snazil to zosekat na co najmenej. -
Petr M (neregistrovaný)
Chyby jsou všude.
Jako když jedna firma v v online šachách ukládala partie do DB naserveru a indexovala je typem uint. V aplikaci na klientovy uint bylo uint32_t, na serveru uint bylo uint64_t. Po 2^32 partiích začala být dobrá sranda... Testama to prošlo, nikoho nenapadlo poslat dost vysoký číslo partie během testování.
Nebo hloupý string. Widlí appka má CP1250, verze pro Linux UTF-8 (díky za to, Schroedingerova kočko) a server je nějaký bastl s UTF16. Testuje se to na datech výhradně z ASCII charsetu. A je krásně vymalováno...
Nebo latence serveru byla zaručena specifikací do 10ms, expert dal do klienta s UDPčkem timeout 10ms (podle specifikace přece server odpoví), ale vůbec ho nenapadlo, že klient bude od serveru 500km (rychlost šíření signálu) a zůstane to občas viset někde v buffer u na routeru... Většinou to jelo, ale při "blbým počasí" to mělo výpadky, data ze serveru přišla až na klienta, jenom klient je ignoroval. Po změně na 15ms všechno bez problémů (najít jim to trvalo tři týdny).
Tož asi tak...
-
gui tes (neregistrovaný)
Ano presne tak Seleniun IDE (skripty).
Web zahlasil ze heslo neresetol co bolo ucelom testu otestovat pravidla. Ale heslo nastavil aj ked nesplnalo kriteria.
Nema to nic so selenium. Proste prides na web zmenit heslo web zahlasi ze heslo nesplna kriteria. Ides sa lognut a zistis ze tam je nove heslo. Ktore vraj nenastavil.Pointa je ze GUI testy nemaju uplne velku vypovednu hodnotu.
-
\neq (neregistrovaný)
"No a kdo jiny? Kdo tam ty chyby nasekal? Uklizecka?"
Omlouvám se, vyjádřil jsem se nejasně. Myslel jsem to tak, že my, vývojáři, jsme obviňováni za to, že zákazník chce odejít. To, že sekáme chyby nijak nepopírám, problém je jiný: my vývojáři dostaneme určitý čas na implementaci a kvalita (logicky) odpovídá onomu času (tedy chybí prostor na dostatečné testování pro daný typ sw). Po té vyšší vedení sw prodává a kvalitu prezentuje na poněkud jiné úrovni, kterou zákazník tedy očekává. Jenže při setkání s realitou je (logicky) zklamán a odstupuje od smlouvy. A za to jsme pak my, vývojáři. A to je to, s čím mám problém.
-
L. (neregistrovaný)
Je zajímavé, že Q&A se normálně řeší i v klasickém průmyslu. Nejen v sériové výrobě, ale i při vývoji nových produktů se samozřejmě musí řešit, zda a jak moc splňují požadavky, takže to je běžná součást manažerské práce; netuším, proč si lidé myslí, že v SW to bude jinak a výrobek bude "by default" bezchybný.
-
Petr M (neregistrovaný)
Taky se často zapomíná, že kvalita je funkce mnoha proměnných a jednou z nich je i kvalita zadání...
Navíc pozor na chytáky. Pokud bude nejasný zadání, tak si zákazník vždycky najde důvod ke slevě. Třeba v věta v zadání "bude implementován TCP/IP":
- "A kde je IPv6? Nedodali jste to kompletní, je toho jenom půlka, zaplatím jenom půlku."
- "My ale nechtěli IPv6, polovinu práce jste dělali zadarmo, nikde o tom nebylo ani slovo."
A ty si, jako vývojář, vyber... Implementovat, nebo neimplementovat? :( -
\neq (neregistrovaný)
@Petr M
"Taky se často zapomíná, že kvalita je funkce mnoha proměnných a jednou z nich je i kvalita zadání..."A zde hodně narážíme i na to, že zde hodně záleží i na kvalitě komunikace. Už dávno jsem se naučil, že zákazník neví co přesně chce a v podstatě to od něj ani nemůžeme chtít. Tedy vezmeme jeho zadání, nějak jej interpretujeme, z toho vygenerujeme specifikaci, kterou zákazník schválí - nebo přijde na to, že to není tak úplně ono.
Jenže toto je pěkná teorie, avšak v praxi tyto věci opět domlouvá vedení (nebo grafik -.-), kteří (logicky) pořádně ani neví, že je rozdíl, zda implementujeme IPv4, IPv6 nebo obojí.
A jestliže mi řekne šéf-programátor "máš tam null-reference exception" (tou dobou jsem dělal na dvou projektech zároveň) (to v uvozovkách je kompletní bug-report), tak jediné řešení, na které jsem přišel, je flegmatismus.
-
Petr M (neregistrovaný)
@ \neq
V předminulé práci jsme měli tým, který připravoval zadání. Já v něm měl na starost HW. Nabídka neodešla, dokud jsem neměl vypracovaný tři možnosti jak to řešit po stránce HW, odhad jejich ceny a rizik. Tam se dalo i něco dělat.
V předchozí práci šok. Se zákazníkem jednali jenom ti, co mají v titulu funkce sprostý slova na M - Markeťáci a Manažeři. Šéf s tím nebyl schopný nic udělat, jenom nám doporučil brát si 3x denně Fakitol...
-
\neq (neregistrovaný)
Myslíte to, jak zákazník odchází? Jistě, ano, vidí, jenže chyba nikdy není na jejich straně, na tom, že nedali dostatečný prostor odladit aplikaci. Ve skutečnosti je chyba v nás, vývojářích, kteří jsme práci odflákli.
Jinými slovy, myslel jsem to tak, že testování je něco, co investoři nevidí přímo, tedy vloží X hodin a vypadne z toho Y featur. Místo toho vidí, že vloží X hodin a ... nevypadne z toho nic.
-
Pavel Herout (neregistrovaný)
Právě protože tyto "stesky" vývojářů dobře znám, vznikla tato minisérie článků. Počkejte, prosím, na druhý a zejména třetí díl, kde budou uváděna konkrétní čísla a pak také něco jako "dobré rady", plynoucí z konkrétních zkušeností, a to i pro manažery projektů.
BTW: Samozřejmě, pokud někdo na testování nechce dát prostředky (čas a peníze), tak může mé zkušenosti snadno zpochybnit, protože pocházejí z akademické sféry a ne z reálného života ;-) -
NetestujemCoNetreba (neregistrovaný)
Prosim ak mate, tak tam dajte cisla aj proti opacnemu extremu, ktorym je 100% test coverage. Potom mame testy potvrdzujuce lubovolnu zmenu v kode, co prinasa iba mechanicke opravy.
Mam na mysli utrpenie ako
testErrorMessage() { assert(Convertor.getErrorMessage() == "Konverze selhala!!! "); }spolu s pripadnou lokalizaciou retazcov alebo len upravou, ktora zrusi opakovane vykricniky.
-
M. (neregistrovaný)
Toto je unit test a za to su zodpovedni vyvojari. 100% pokrytie unit testami je fajn, ale je otazka, ci to nieco prinasa tak, ako uz bolo spomenute v clanku. Podla mna je lepsie pre kvalitu aplikacie si stanovit mieru pokrytia unit testami, napr. 90% a vyhnut sa takymto absurditam, ktore by mohli byt generovane automaticky. Usetreny cas, mozete venovat pisaniu integracnych alebo systemovych testov.
Pokial by vas sef namietal, ze potrebuje mat 100% pokrytie unit testami, tak by mu bolo dobre vysvetlit, ze zeleny(pripadne modry) vysledok unit testov este neznamena, ze tam nie je chyba a je efektivnejsie venovat tu pracu na ine testovanie, napr. CI/CD
Pokial by ste chceli ziskat argumenty pre svojho sefa, tak doporucujem sa ohanat nejakou normou, napr. ISTQB, kde su sylaby dostupne zdarma. IEEE ma nieco podobne, ale tam je pristup plateny.
-
nemo22 (neregistrovaný)
Ja sa este skor stretavam s "manazerskym pohladom" v zmysle ako je mozne ze ten sw ma vobec chyby. Ved ked vam zadam sucet, a+b tak tam nieje co pokazit. A ak nahodou sa spravy preklep, tak vas na to predsa upozorni kompiler/editor/ide (z pohladu manazera proste word podciarkne zle slovo :-).
A druhy problem ktory byva je ze sa zacne nieco vyvijat v case t ked sa pouzije aktualny sw, prostredie, kniznice a skonci sa o par mesiacov/rokov, tak zrazu veci nefunguju ako by mali. Este sa da zmrazit vyvojove prostredie, pripadne test ale pride zakaznik ktory povie ze ma proste taketo prostredie a musi updatovat koli bezpecnosti a ma svojich klientov ktory pouzivaju uplne inu verziu browseru atd. A nie vzdy je mozne tlacit ze sw funguje len na specifickej verzii os/kniznic/aplikacii. Dnes aplikacie zavysia od obrovskeho mnozstva kniznic, prostredi atd. a je tazke odhadnut co ktora zmena/update prinesie respektive urobi s vyvijanou aplikaciou. Teda pokial niesu aspon nejake testy, aj ked vsetko sa obsiahnut asi neda. -
Pavel Herout (neregistrovaný)
"A druhy problem ktory byva je ze sa zacne nieco vyvijat v case t ked sa pouzije aktualny sw, prostredie, kniznice"
Zde jste naprosto přesně pojmenoval ten problém, který automatizované testy pomáhají alespoň detekovat. Možných změn u webové aplikace je spousta. Více o tom bude ve třetím díle této minisérie. -
nemo22 (neregistrovaný)
Osobne z praxe tomu moc neverim. V dnesnej dobe ked je popularne a in na vypisane jedneho riadku pouzit nejaky mega framework s x zavyslostami, ked web browser je uz pomaly samostany os mi to pride ako skoro nemozne. Bezne som sa stretol s bankovymi aplikaciami ale aj v medicnie kde sa to uzamkne na konkretnu verziu jvm a dalsich podpornych knizniciach inak to nebude fungovat. To je bezna prax a zakaznik to musi akceptovat. Pri podobnych projektoch to este ako tak ide, ide o vela penazi a komplexne systemy ale ak sa dodava nieco mensie a vela zakaznikom tak je dost tazke stanovit si striktne poziadavky. Nehovoriac ze potom staci ak nejaky admin zabudne pri konfiguracii vypnut automaticky update a je problem.
-
L. (neregistrovaný)
> Bezne som sa stretol s bankovymi aplikaciami ale aj v medicnie kde sa to uzamkne na konkretnu verziu jvm a dalsich podpornych knizniciach inak to nebude fungovat.
Ono je to logické. Tyhle aplikace potřebují mít vysokou míru spolehlivosti. Takže se pečlivě testují. Aby to testování bylo relevantní, tak provoz musí probíhat v prostředí co nejpodobnějším testům - jinak jsou testy pro kočku. Proto jsou jasně speficikovány podmínky, tedy verze knihoven, za kterých se aplikace testuje a pak provozuje.
-
Trident (neregistrovaný)
Takovy manazer timto potvrzuje ze neni clovek na svem miste protoze chyby k vyvoji sw patri. Mel by se spise zajimat o to jake chyby a kde dochazi k chybovani. Jedna se o typo, zbytecna cyklomaticka komplexita, nejasna struktura ci spatny navrh architektury? Embedded vyvoj je uplne treba jina liga kde se nelze spolehat ani na signaly a typicky embedak pochybuje nekdy i o tom ze funguji fyzikalni zakony :-))) (specialne pro postizene : toto je sarkasmus).
Jak uvadis. Dnesni u jeje bejvy webovy sw neni staticka vec. Je to zivy ekosystem. To by opet manazer mel vedet a nechat si zpracovat vstupy na zaklade kterych se rozhodne zda-li updatovat komponentu /neupdatovat/patchovat/ placat to vsechno jak v Dedina systems. Po par cyklech zjisti naklady na manualni sjeti vsech testu a zacne prosazovat automaticke testovani. Protoze v strednedobem a dlouhodobem meritku usetri.Nemuzeme vzit manazera ze sroubarny a posadit ho k vyvoji sw. Takhle to proste nefunguje. SW dev management je dosti specifickym odvetvim (to poznali uz blahe pameti v IBM a pri vyvoji sw pro lety apollo).
-
Petr M (neregistrovaný)
Hele, já jsem embeďák a řeknu ti, že fyzikální zákony opravdu leckdy nefungují. Jako když chtěl zákazník dát do zařízení PoE switch, do kterýho pustí veškerou šťávu pro zařízení i downlink porty po uplink portu :D Zákazníkovi jsme dali nabídku na normální switch bez PoE + PoE napájení nebo normální zdroj + PoE switch nebo bez switche. Dva měsíce se rozhodoval a pak se zeptal, jak teda dostaneme těch 100W do zařízení pro napájení PoE, když po PoE přitáhneme max. 15W. Je to marný.
Datasheetům taky nevěřím, dokud si to sám neoměřím. Beztak tam nejdůležitější věci ani nedávají. A knihovny od výrobců beru jenom jako velmi, velmi, velmi volnou inspiraci...
Testy jsou opravdu náročná věc, fixturu s automatikou na pět prototypů nikdo nezaplatí a až při přípravě výroby se řeší, jak to otestovat na lince... Standard
-
nemo22 (neregistrovaný)
Na to odpoviem ze nemusim asi vsetkemu rozumiet :-). Poznam viacero projektakov, manazerov , ktory volekedy davno boli programatori, a dnes riadia projekty. A to co niekedy stvaraju, respektive aky maju pohlad je pre mna obcas nepochopitelne. Ono to bude asi tym ze prechodom na web aplikace (fuj) a zasadnym zvysenim koplexity dnesneho sw sa vsetko zrychlilo, skomplikovalo ? Bud si to neuvedomuju lebo to beru z pohladu svojej optiky z pred x rokov alebo to proste nechcu lebo su uz radi ze to nemusia drvit a studovat. Len to potom tak vyzera.
-
Pavel Herout (neregistrovaný)
Číslo 2 až 3 krát jsem uvedl zhruba, protože (jak bude uvedeno v dalších dílech) je kódu testů (v mém případě!!!) zhruba tolikrát více, než kódu aplikace.
Pokud se bavíme o skutečných nákladech, platí Boehmův zákon: "čím dříve se na defekt přijde, tím je její oprava levnější"
Kvantifikován je ve:
McConnell, Steve: Code Complete (2nd ed.). Microsoft Press (2004); ISBN 0-7356-1967-0
Ale to je tabulka, kterou sem nedokáži vložit. :-(
Velmi zjednodušeně řečeno - pokud defekt vznikl ve fázi kódování a přišlo se na něj ve fázi používání, pak je jeho oprava 10 až 25 krát dražší, než kdyby se na něj přišlo např. jednotkovými testy.
Ale ještě jednou zdůrazňuji - berte tento komentář jen jako velmi stručnou a nepřesnou odpověď. -
Míra Kroc (neregistrovaný)
Náklady je nutné vidět v kontextu celého produktu a současně v dlouhodobějším horizontu.
Pokud teď investuji desítky hodin měsíčně do psaní regresních testů na objevené chyby, tak tím můžu ušetřit čas technické podpory v budoucnu, která bude se zákazníkem řešit méně chyb.
V důsledku toho bude potřeba méně servisních verzí s opravami chyb.
To zpětně sníží náklady na vývoj, který se může věnovat jiným úkolům.Tady je nutné ještě říct, že každé testy je nutné kontrolovat, ladit a udržovat. Při pravidelném automatickém spouštění řádově ve stovkách spuštění za rok testy z různých důvodů občas "spadnou" i bez chyby v aplikaci nebo testu. Působí tady řada vnějších vlivů.
Z mých bohatých zkušeností vyplývá, že komplexní testy lze reálně prosadit pouze u dlouhodobého vývoje. To je typicky vývoj krabicového sw.
U zákaznického vývoje, kde se fakturují konkrétní malé úkoly to zákazník platit nechce. Zahrnout náklady ns testy do hodinové sazby programátora taky nejde protože pak by firma nebyla schopná konkurovat ostatním.
Jak už jsem psal výše, tak efekt vynaložených nákladů se často projeví až za dlouho dobu.
Dalo by se toho napsat ještě spoustu ale i tohle je hodně dlouhé. Tím by to zatím uzavřel.
-
pomazanka (neregistrovaný)
Pochybuju, ze to byl sarkasmus, absolutne s tim nazorem souhlasim. Za poslednich 8 let sem vystridal 3 firmy - do te treti sem nastoupil cca pred 3 mesici. Nez sem nastoupil, chodil sem nekolik mesicu po pohovorech a potkal se s hroznou spoustou manazeru a sw architektu a podobnejch leaderu. A moje pohovory uz probihaj trosku jinak nez drive - spise nez by se oni ptali na me, tak se nejdriv ptam ja jak to funguje u nich a jakym zpusobem se testuje. A pokud me nepresvedeci, ze jejich procesy davaji smysl, tak podam ruku a odchazim. Poptavka po testerech je dneska enormni, kor kdyz ma clovek alespon zakladni zkusenosti s automatizovanym testovanim. Firmy uz si davno uvedomily, ze kvalitni testovaci tym je z dlouhodobyho hlediska neskutecnym prinosem a v zadnym pripade nesmi chybet na zadnym sw projektu. Hodne to tahnou zahranicni firmy, ktery si u nas (napr Praha) otevrely pobocky a ktery si jedou moderni zpusoby vyvoje (TDD apod). Ve firme kde sem ted je pomer testeru na vyvojare cca 2:1 (2 testeri na jednoho vyvojare), coz je velice prijemnej extrem, kterej neni uplne normalni, ale v kontextu nasi firmy (zdravotnictvi) je vyslovene nutnej. Takze ano, testeri maji v dnesni dobe na vyber a muzou si vybrat firmu, ve ktery uz davno pochopili, ze QA je nedilnou soucasti vyvoje sw a neda se na tom setrit.
