Potřebný člověkočas na testování v závislosti na komplexnosti software

pe25tr

Zdravím Vás a prosím o radu.

V jedné polostátní firmě pracuji na vývoji simulačního software.

Dosud se jednalo o software víceméně pro interní použití.

Vedení firmy, mám takový pocit, si myslí, že naše „interní“ kódy lze dodávat např. některým složkám integrovaného záchranného systému, ČEZu, Ministerstvu obrany/vnitra, …

Rád bych střednímu managementu, v rámci interního auditu jednoho z projektů, sdělil, že:
- je silně zanedbaná část verifikace a testování kódu,
- s potřebným časem a počtem lidí na testování se v harmonogramu projektů vůbec nepočítá (tady bych dodal, že se většinou nejedná o čistě „softwarové“ projekty, vývoj nového software bývá pouze jedním, nikoliv nejhlavnějším bodem).

Představuji si něco jako graf/grafy, kde proti různým ukazatelům komplexnosti software (počet modulů, rozsah zdrojového kódu, množství člověkohodin potřebných k vývoji) bude vyneseno množsví člověkohodin potřebných pro testování (různé úrovně testování).

V takovém grafu/grafech si představuji, že bych mohl ukázat, kde se zhruba pohybují naše „interní“ kódy.

Účelem je sdělit, že člověkočas, který je nám/tvůrcům dán, sotva stačí na programování, ověření, zda lze kód přeložit a spustit a na základní validaci celku (zda výsledek simulace nějakého demonstračního příkladu „dostatečně“ souhlasí např. s experimentem nebo nějakou teorií).
Na důkladnou analýzu toho, zda každý modul dělá to, co si myslíme, že by dělat měl, zda moduly (bývá jich mnoho desítek až málo set) spolu interagují tak, jak si to představujeme, zda to, co si představujeme, je správné, zda může nastat scénář, se kterým nikdo nepočítal, jak celek reaguje na nekonzistentní nebo chybné vstupy, …, téměř nikdy nemáme potřebný člověkočas.

Tedy, chtěl bych našemu střednímu managementu sdělit něco jako: „Jestliže vývoj tohoto simulačního software do provozuschopného stavu trval N člověkohodin, tak na jeho důkladnou verifikaci/testování byste potřebovali XkrátN člověkohodin a tato položka ve vašich rozvahách zcela chybí“.

Netřeba nic „exaktního“, stačí jen řádově odhadnout/ukázat potřebný člověkočas na testování. Něco jako  graf množství dolarů potřebných pro odstranění chyby, v závislosti na tom, v jaké fázi se objeví.
http://2.bp.blogspot.com/_vdqOsYKAf0Y/S8c-xw2lfqI/AAAAAAAAA58/2IR5sEuXDms/s1600/Price+of+buggy+code.png

Samozřejmě si nenamlouvám, že se něco stane, komunikace se středním managementem je prakticky jednosměrná, jen bych chtěl mít možnost říct, až nastane nějaký průser, že „jsem vám to před XX měsíci/lety říkal...“.

Sám nejsem z IT oboru, mám na starosti implementaci a validaci fyzikálních modelů, o testování software mám spíš jen mlhavou představu…

Kdybyste někdo znal odkaz na stránku, která toto nějak graficky popisuje, moc by mi to pomohlo.
Zatím jsem našel mraky stránek o testování software, ale ne v té formě, jakou bych potřeboval.
« Poslední změna: 19. 10. 2017, 10:10:24 od Petr Krčmář »


Problém popisujete přesně, ale testování by mělo být součástí harmonogramu na vývoj. Tedy, vývojové oddělení by mělo mít interní testování ve svém čase - a je už na domluvě, jestli se vykazuje odděleně jako testování, nebo jestli se testuje v rámci vývojového času.

Druhým kolečkem jsou UAT - uživatelské akceptační testy. Každý požadavek na vývoj by měl mít stanovená akceptační kritéria. Pokud je software splní - pak vývojář splnil úkol. Pokud zadavatel (garant) zapomněl do akceptačních kritérií něco vyjmenovat, je to jeho problém, a musí dovývoj zaplatit ze svého budgetu.

Proč píšu o UAT? Protože to je docela přirozený způsob, jak zadavatele zavedete dovnitř a do vnímání (spolu)zodpovědnosti  za výsledek. Vývojářům jasná kritéria zase rozváží ruce, protože jim ubude "testování na slepo", kdy si domýšlejí, co vlastně zadavatel chce.


pe25tr

Jde o to, že ústav, kde pracuji, vůbec není softwarová firma, nicméně vedení to neví, nižší management si vývoj software představuje dětsky naivně, střední management si myslí, že můžeme dodávat software, i když netuší, jak jeho vývoj (u nás) reálně probíhá, ani jak by (ideálně) probíhat měl (jaká infrastruktura/postupy jsou k tomu potřeba), no a vyšší management vůbec netuší, co "my" děláme a "my" zase netušíme, co dělá vyšší management :)...

To, co jste vyjmenoval, u nás v ústavu prakticky neexistuje a vedení o tom neví.
Software píší nějakého druhu fyzikové, matematici a další lidé z technických/přírodovědeckých oborů, kteří vesměs v rámci svého vzdělání prodělali také nějakou "výuku programování". Mojí snahou je poukázat na fakt, že to zdaleka nestačí.

Každopádně dík za reakci, i tohle mi pomůže ;).

Kiwi

Software píší nějakého druhu fyzikové, matematici a další lidé z technických/přírodovědeckých oborů, kteří vesměs v rámci svého vzdělání prodělali také nějakou "výuku programování". Mojí snahou je poukázat na fakt, že to zdaleka nestačí.

Ono by to k programování i stačilo, ale měli by mít i nějaké zkušenosti mimo akademickou sféru, nebo alespoň nějakého projektového manažera, který má zkušenosti z byznysu, aby jim právě dělal tu softwarovou inženýřinu.

Zkus si někde opatřit knihu The Mythical Man-Month od F. Brookse, tam jsou přesně tyhle věci rozebrány a analyzovány formou, která by měla být pro akademiky poměrně vstřebatelná.

pe25tr


... nebo alespoň nějakého projektového manažera, který má zkušenosti ...


No v podstatě o tohle mi asi jde, sdělit střednímu managementu, že nikdo takový mezi námi není, že postupy a mechanismy potřebné k přetvoření "interního" kódu v "produkt", neexistují/nejsou nastaveny (tím myslím u nás).

To vše formou, kterou střední management pochopí, tedy v prezentaci, která by ukázala, že je-li na "kódění" potřeba N člověkohodin, tak na otestování je k tomu potřeba ještě  dalších N? 2N? 0.5N? člověkohodin, přičemž v té části "člověko" nám schází člověk, který ví, jak se to má dělat.


gll


... nebo alespoň nějakého projektového manažera, který má zkušenosti ...


No v podstatě o tohle mi asi jde, sdělit střednímu managementu, že nikdo takový mezi námi není, že postupy a mechanismy potřebné k přetvoření "interního" kódu v "produkt", neexistují/nejsou nastaveny (tím myslím u nás).

To vše formou, kterou střední management pochopí, tedy v prezentaci, která by ukázala, že je-li na "kódění" potřeba N člověkohodin, tak na otestování je k tomu potřeba ještě  dalších N? 2N? 0.5N? člověkohodin, přičemž v té části "člověko" nám schází člověk, který ví, jak se to má dělat.

Testy praci naopak v prumeru urychluji. Projektovy manazer vam nepomuze. Na to musite prijit sami.

karbous

napsani programu vs testovani a finalni doladeni  20:80 tedy 4N by my oko... 

Milfaus

Argumenty:

  • Na jednání přečíst vyjádření programátora "je to v pohodě" nebo "neručíme za to" třetí možnost je "no možná"
  • Ukázat chybu, může být i relativně banální a říct "vidíte, jsou to kokoti, prý je to v pohodě a je tam hromada chyb" nebo "vidíte, oni vědí, co říkají" poslední jejich vyhýbavá odpověď "řekli možná je to v pohodě, ale jak vidíte, jsou v tom chyby a oni sami netuší, jaké"
  • Uvážit řešení

Platí tu obvyklé:
Kdo nechce hledá důvody, kdo chce, hledá způsoby.

To je věta, kterou lze zopakovat přímo na jednání.
Pro jednání potřebuješ tři věci: vyjádření tvůrců, ARGUMENTY (CHYBA) a plán

Plán může být "sereme na to" nebo "hele, dáme to programátorům na dopečení, zatím je to jako motokára z garáže, na které jezdí u nás z kopečka, s tím přeci NEMŮŽEME JÍT MEZI LIDI...... dramatická pauza ...... programátoři si po sobě neumí zkontrolovat kód, proto ho musíme otestovat profesionálně!"

To by byl můj postup.

  • pojmenovat stav jejich slovy
  • ukázat svůj pádný argument (člověk si tím posílí pozici)
  • navrhnout řešení

Otázka částky je následující:
Programátoři jsou kašpaři, flákači a obecně banda zaostalých autistických hovad.
Stačí se podívat na Windows, jak je rozmrdanej nebo Linux, jak už se 20let potácí okolo 4% a desktop nikdo nedokázal dotáhnout dokupy. Bez rázného vedení, bez terorizování, bez toho, aniž by programátory někdo tejral a nutil je tvrdě makat, vymýšlí hovadiny, sekají chyby a píšou sračky.

Proto počet hodin, kteří ti programátoři řeknou, že potřebují, aby kód učesali, musíš vynásobit třemi.
Oni budou brouzdat po netu, pít kafe, žvanit spolu, to je čas, který musíš zohlednit.
Navíc, když se v tom budou jebat, začnou něco přepisovat, proto ne dvěmi, ale třemi.

Před testováním musí být kód v dobré stavu!
Jak se v tom ta hovada budou vrtat, třeba v budoucnu kvůli nějakým úpravám, když ho budou měnit, půjde testování do totální řitě! Prostě to zeserou a rozmrdají!

Aby mělo smysl kód testovat, musí být dobrý a být provedené základní unit testy atd.
Pak má smysl ten kód nechat otestovat testery proti dobrému scénáři.

Tj. vzorec je:
  • Čas člověka, který zhodnotí přístupnost, pokud je tam UI, jestli je potřeba udělat změny
  • Čas vedoucího programátorů / 2 (většinou kompetentní lidé a nechávají si rezervu)
  • Čas programátorů na uklizení kódu, aby to mělo vůbec smysl testovat *3 (když jsou to debílci *4)
  • Čas testerů jako 1/2 času programátorů, pokud chceš i specifikaci, pak stejně jako programátoři
  • Čas grammar nazi, většina lidí v IT jsou pologramotná hovada, někteří ani nepoužívají háčky a čárky
  • Tvůj čas s vedením projektu 12+ (Σ jejich času/5)

Pro jistotu, můžeš přidat ještě Bulharskou konstantu (výsledek vynásobíš 1.6 pro tyto projekty).

http://necyklopedia.wikia.com/wiki/Bulharsk%C3%A1_kon%C5%A1tanta

Všechen čas navíc vykážeš jako úspory!!!
Díky mému efektivnímu vedení se povedlo vykázat hodinovou úsporu bla bla blaaaaa.

Argumenty:
Proč to musí vidět specialista na UI a přístuponost?
No aby to ty lidi vůbec mohli používat!
Když se to bude celé později předělávat, tak zahodíme práci testerů!
Proč to musí vidět manažer programátorů?
Hele, je to nejchytřejší člověk a víte, jaký jsou ti naši kluci někdy kuliši (kuliši = eufemismus pro parta debilů).
Proč se v tom mají ti programátoři vrtat?
No protože to chceme pořádně otestovat a dát tomu formu, pokud by to později rozvrtávali jako blbí, testování půjde do řidi, znáte je, jsou to hrozný kuliši! ( hrozný kuliši eufemismus pro = zasraná banda retardovanejch a polokompetentních debilů)
Proč to má vidět tester?
Protože ti naši kuliši si to po sobě nemohou otestovat, programátor si po sobě neumí opravit kód! Navíc, tester to uvidí víc očima zákazníka, případně jejich správce, chceme přici dodat sofware v nějaké dobré kvalitě ne?
A proč to máš řešit ty?
A kdo jiný je na to kompetentnější a má čas???

phi

Nepisete jestli vubec mate unit testy.
Odhadnout ten koeficient z hlavy je dost tezke (jak to napriklad vypada s testovatelnosti coby s jednim z pozadavku na aplikaci), nicmene optimisticka predpoved je, ze pokud mate nejakou alfu, na ktere prochazeji unit testy bez chyb a na tu jste spotrebovali N clovekohodin, N/3 na testing a N/3 na zaplaty a podporu testovani.
Co jsem tak videl v praxi, tak pokud se kazdy sprint vydava build a ten je nejak otestovan (a pak jde do UAT, kde nebudou zadne kriticke chyby, ale porad muzou uzivatele prijit s necim, co se prehlidlo nebo je nesikovne vyreseno), je pomer vyvojari ku  testeri nekde mezi 6:1 k 2:1.   

phi

Kouknete se na 29. slide tehle prezentace https://www.slideshare.net/Softwarecentral/embedded-software-testing, je tam jednoduche porovnani devs versus tester pro ruzne typy projektu.

To vše formou, kterou střední management pochopí, tedy v prezentaci, která by ukázala, že je-li na "kódění" potřeba N člověkohodin, tak na otestování je k tomu potřeba ještě  dalších N? 2N? 0.5N? člověkohodin, přičemž v té části "člověko" nám schází člověk, který ví, jak se to má dělat.

Těžko říct, podle situace bych se bál, že testování a dovedení do produkčního stavu může být klidně i 10N, protože podle popisu máte i základní vývoj na vodě.

Pokud management nemá respekt ke složitosti vývoje, nezbude Vám, než s nimi projít tu mentální cestu a být managementu průvodcem. Tedy, nechat to běžet samospádem - máte výhodu, že jste v uvažování o kousek dál - a můžete to mírně moderovat. Jinak asi management nepřesvědčíte.

Bohužel, na akademické půdě je 80 % práce neviditelných, a 20 % je pak od draftu do separátu (ta viditelná část práce). Je to tedy úplně opačně.