Jak na bezpečnostní testy

Bezpečnostní test je typem funkčního testu, který má za úkol odhalit možné slabiny testovaného systému proti útoku hackerem, a tím snížit pravděpodobnost a úspěšnost napadení. Podobně jako u jiných typů funkčních testů, i tady rozeznáváme fáze test analýzy, test designu, test exekuce a vyhodnocení testu.
Bezpečnostní testy by měl připravit a vykonat specialista na tento typ testů, nicméně ve fázi test analýzy bude nutně potřebovat pomoc od test analytika, znalého funkcí testovaného systému.

Nestíhám to otestovat - co teď?

Kolem prioritizace testů se již popsalo hodně článků a metodik - od těch jednoduchých až po vědecké přístupy. Přesto má řada test manažerů problém, jak správně prioritizovat testy a obecně řešit krizové situace v testování.
Nejdřív základy:

Kam na ISTQB certifikaci?

Poslední dobou na tento blog přichází hodně lidí hledajících ISTQB kurzy nebo certifikační zkoušky. Pro zájemce tedy uvádím aktuální informace, které mám k dispozici - pokud máte něco k doplnění, podělte se prosím také.

Jak psát srozumitelné testovací případy pro akceptační testy

V praxi se často setkávám s tím, že test analytici neumí napsat srozumitelné testovací případy pro uživatelské akceptační testy (UAT) - uživatelé, kteří mají podle nich testovat aplikaci a rozhodnout, jestli tuto aplikaci "akceptují" do ostrého provozu, mají problém se zjištěním, co vlastně mají udělat a proč.
Zde jsou principy, kterými se doposud úspěšně řídím (některé částečně patří i do oblasti test manažmentu):

1. Testovací případy dejte psát test analytikovi, který byl s aplikací důkladně obeznámen
Tím nemyslím klasickou test analýzu z dokumentace dodanou business analytikem/vývojem (to je samozřejmé, že z této dokumentace se při tvorbě testů vždy vychází), ale že by samotné test cases měl ideálně psát někdo, kdo tu aplikaci testoval v systémových testech, nebo má takového testera "po ruce".
Důvodem je skutečnost, že takový test analytik umí vhodně zvolit úroveň detailu, do které má při psaní scénářů jít a navíc může uživatelům v průběhu jejich UAT snažení dělat podporu, pokud se na něčem "zaseknou". Nehledě na to, že finální aplikace se dost často liší od "business zadání" (drobné úpravy "za pochodu" přímo do implementace a následné neaktualizování analytické dokumentace).

Příprava testovacích dat II. - data z produkce

Nejčastějším způsobem přípravy testovacích dat je jejich "zkopírování" z produkčního prostředí do testovacího prostředí. Dnes uvedu pár tipů, jak na to a na co si dát pozor.

Především je důležité správné plánování celého procesu, to zahrnuje:

1) Musí být stanoven datum a čas, ze kterého bude vytvořen "snapshot" produkčních dat z jednotlivých systémů, případně i stanovení postupnosti "přeplachů" jednotlivých systémů. Je to kritické hlavně v případech, pokud jsou data uložena ve více nezávislých systémech (propojených přes integraci) - zabráníte tím velké nekonzistenci dat. 

Pro pobavení - projektový tým a plánování dítěte

Tenhle vtípek pochází z jedné diskuze na Test Republic , docela mě pobavil, tak ho předkládám i zde:


1) Project Manager is a person who thinks nine women can deliver a baby in one month.
2) Developer is a person who thinks it will take 18 months to deliver a baby.
3) Onsite Coordinator is the one who thinks single woman can deliver nine babies in one month.
4) Client is the one who doesn't know why he wants a baby.
5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
6) Resource Optimization Team thinks they don't need a man or woman as they'll produce a child with zero resources.
7) Documentation Team thinks they don't care whether the child is delivered or not, they'll just document 9 months.
8) Quality Auditor is the person who is never happy with the PROCESS to produce a baby.

...and...

9) Tester is a person who always tells his wife that this is not the RIGHT baby.

Jako další zdroj pro pobavení můžete použít blog Is there a problem here? , kde najdete screenshoty zajímavých chyb aplikací, které se testerům nepodařilo zachytit.

Czech Test Conference - jaké to bylo

Sice jen na jeden den z důvodu pracovního vytížení, přesto se mi povedlo aspoň na chvíli přijít na Czech Test Conference - pilotní běh (doufám že časem) pravidelné české testerské konference s mezinárodní účastí. Jak to všechno probíhalo?

Příprava testovacích dat I.

V dnešním článku bych se rád s vámi podělil o zkušenosti při přípravě testovacích dat.

Přípravě testovacích dat by se měla věnovat stejná pečlivost, jako přípravě testovacích scénářů - zejména v případech, kdy je množství dostupných dat omezeno. Nekvalitní data mohou mít za následek reportování problémů, které nejsou ve skutečnosti chybou kódu, ale pouze chybou zvolených testovacích dat - což významně snižuje reputaci týmu testerů.

Testování na produkčním prostředí

Testům na produkci by se měli testeři obecně vyhýbat, bohužel jsou situace, kdy je takové testování nevyhnutelné (například když testovací prostředí plně neodpovídá produkčnímu a něco na něm nelze udělat).

Při testech je potřebné zachovávat několik pravidel, jinak může dojít k vážným malérům - od poškození produkčních dat, účetních problémů až po poškození dobrého jména firmy. Obzvlášť to platí v případech, pokud již na produkci existuje reálný provoz (tedy nejedná se o pilotní test čistého systému).

Často se na produkčním prostředí pro účely testování vytvoří "testovací objekt", nad kterým se pracuje - například v CRM systému se vytvoří "testovací zákazník". I přes "relativně bezpečnou" práci nad "nezávislou entitou" je potřebné si dát velký pozor na tyto věci:

Automatizované funkční testování Siebelu 8

V poslední době se stává v českých končinách populárním Siebel, jakožto CRM nástroj. Je to poměrně rozsáhlá webová aplikace, která kombinuje více technologií (ActiveX, Java applety, vlastní webový protokol), a proto se velmi špatně testuje nástroji pro automatizované testy - pokud ovšem nástroj nemá přímo uvedenou podporu pro Siebel.

Siebelový webklient může "fungovat" ve 2 režimech:

1) "Standard-interactivity" - jedná se o klasickou "nenáročnou" internetovou aplikaci složenou ze standardních webových ovládacích prvků, takže se dá dobře automatizovat v jakémkoliv nástroji podporujícím web technologie (stránka je složená z klasického HTML kódu + javascriptů). Poznávací znamení = běží i ve Firefoxu, od verze 8 se ale používá sporadicky.

2) "High-interactivity" - tohle je oříšek, kterého se bude týkat další text.

Šablona pro testovací plán

Další šablonou, kterou přidávám do Google Docs je Test Plan.

Není to "čistá šablona", vyplnil jsem ji vzorovým projektem - pro představu jak by to mohlo asi vyplněné vypadat (smazat část obsahu můžete vždy). Pokud po vyplnění obsahu bude testovací plán rozsáhlejší, doplňte si na samostatný list seznam kapitol (obsah).

Teď něco málo k obsahu test plánu. Různé metodiky mají pro něj různě sofistikované definice, případně se liší pořadí kapitol, někdy částečně i obsah. Co je ale podstatné z praktického hlediska - musí mít zahrnutou v sobě odpověď na tyto otázky:

Šablona XLS pro řízení manuálních testů

Konečně jsem přišel na to, jak přidávat přílohy k článkům - respektive že se to na Blogspotu nedá udělat a musím na to jít jinak - takže mohu začít publikovat zajímavé šablony související s testováním, které vám mohou sloužit jako inspirace, nebo je můžete přímo používat na svých projektech.

Průzkum o stavu testingu v ČR

Po delší pauze způsobené mou svatbou a dvojnásobným stěhováním přidávám další článeček - spíše prosbu o spolupráci.

Na Vysoké škole ekonomické v Praze v současnosti probíhá zajímavá dotazníková studie zaměřená na analýzu současného stavu testování v ČR. Pokud se tedy zabýváte testováním (ať již na testerské nebo programátorské pozici) a pracujete v ČR, vyplňte dotazník na http://studiekvality.vse.cz. Jedná se o seriózní studii, takže prosím vyplňujte jen pokud patříte do "cílové skupiny".
Nejenže tím pomůžete dobré věci (je to nejspíš první dotazník svého druhu, samozřejmě anonymní), ale navíc podle slov řešitelky Mgr. Anny Borovcové budou výsledky po 1.1.2011 na téže stránce dostupné pro všechny.

Mohla by to být ve výsledku zajímavá statistika, co říkáte? :-)

Zlepšení procesu testování

V poslední době se setkávám s dotazy kolegů, jak zlepšit proces testování bez velkých nákladů.  Všichni by chtěli zlepšovat, zvyšovat efektivitu, ale investovat do toho čas a peníze - to ne :-)
Problematikou zlepšování procesů obecně se zabývá mnoho metodik, mezi nejznámější patří CMMi, BPI, Six Sigma, ISO9001 a RUP.
Pro testování se nejčastěji uplatňují TMMi a TPI (součást metodiky TMap), základní principy jsou také popsány v syllabu pro certifikaci ISTQB.

Pokud se Vám nechce studovat metodické příručky a hledáte spíš něco praktičtějšího, zde je checklist, který používám pro zlepšení procesu testování:

Vzdělávání testerů

Jak uchopit vzdělávání testerů? Následující poznatky vycházejí z mé zkušenosti, takže je berte s rezervou - ne vše půjde aplikovat "univerzálně".

Zásadním kritériem při výběru vzdělávání je, jak zkušenou skupinu testerů máte - podle toho je vhodné rozčlenit "zaměření jednotlivých vzdělávacích aktivit. Kromě toho samozřejmě záleží na tom, kolik prostředků (zejména finančních) můžete na vzdělávání vyčlenit.

Testování integrace

V každém komplexním systému, který je tvořen množinou nehomogenních subsystémů se nachází vrstva, která zajišťuje vzájemnou komunikaci těchto "nekompatibilních součástí" - integrace, alias integrační platforma. Často se dělá přímo na míru (každý klient si vyvíjí vlastní), nebo se upravují již existující řešení (například produkty Tibco).
V dnešním článku zmíním některé postupy, které je vhodné použít při testech integrační platformy.

ISTQB - mít či nemít certifikaci

Chtěla bych reagovat na Martinův příspěvek zamyšlením, zda tester musí mít „papír“ na to, že je testerem.
Já osobně jsem držitelem ISTQB certifikace a vnímám ji jako „nice to have“ do profesního životopisu, ale že bych se za někdy u klienta setkala s tím, že by byla vyžadována jako „must have“, to nemůžu říct.

Napadají mě 2 příklady, kdy tuto certifikaci musíte mít:

1. Projekty v zahraničí, kde se tester bez ISTQB certifikace vůbec nemá šanci dostat
2. Projekty v ČR, pokud se jedná o multinacionální korporaci a „matka“ v zahraničí diktuje podmínky náboru zaměstnanců a externích spolupracovníků – pro testery to rovněž znamená nutnost mít certifikaci.

Kdy tedy zaváží, že certifikaci máte či nemáte?
Podle čeho se klient nakonec rozhodne, zda si vás / vaše testery na projekt vybere?

1. Pokud vás klienti neznají osobně nebo na základě referencí, rozhodují se podle vašeho profesního životopisu. Pro klienta je málo zajímavý fakt, že jste certifikován, pokud nejste ten správný kandidát na danou práci. A obráceně, pokud vás berou jako experta pro danou oblast, certifikát je posléze už nezajímá.
   
2. Pokud zákazník kandidáty nezná a má se rozhodnout mezi dvěma testery, kteří jsou oba vhodní pro konkrétní projekt a dle CV stejně schopní, rozhodne se pro toho s certifikací. Je to ovšem pouze hypotetický příklad. V praxi se málokdy stane, že by dva kandidáti byli stejně schopní :-)
   
3. U koho hodně zaváží, že máte titul ISTQB certified tester, jsou headhounteři a personální agentury. Měla jsem svého času možnost pozorovat při práci člověka zodpovědného za nábor pro velké IT společnosti a na mou otázku, proč upřednostňuje ty certifikované kandidáty, odpověděl, že na základě předchozích zkušeností se mu osvědčilo posílat ke klientům kandidáty, kteří neváhali investovat do svého vzdělání v oboru čas a finanční prostředky. Procentuální úspěšnost při pohovorech se zaměstnavateli byla několikanásobně vyšší.

A to v dnešní době, kdy je n kandidátů na jedno pracovní místo, není něco, co by se mělo brát na lehkou váhu… ;-)

Ing. Silvia Valientová
ISTQB certified tester

Krize, nebo úpadek v IT?

Poslední dobou přemýšlím, co se to v tom IT děje. Nemám pocit, že by byly projekty nějak výrazně složitější než v minulosti, přesto mám dojem, že výrazně klesá kvalita, s jakou jsou dodávány - a je prakticky úplně jedno, kdo je dodavatelem.

Jádro problému spočívá hlavně v motivaci zaměstnanců. Kdysi jsem byl obklopen spoustou lidí, co chtěli něco dokázat, záleželo jim na kvalitě své práce, jménu firmy, jaké budovali u zákazníků, pracovali týmově a prostě - byla to "parta", co držela vždy spolu a kde chyběla kvalita u jednotlivce, tam se to se dohnalo kvalitou týmu.

Testování migrace dat

V posledních dnech jsme úspěšně spustili dlouho vyvíjený projekt a mám konečně čas něco napsat. Tématem dnešního příspěvku je testování migrace dat při přechodu na novou verzi nějaké aplikace.

Jako první věc je potřebné si uvědomit, co všechno obnáší migrace dat.
Obvykle se tím rozumí převod dat ve formátu "staré aplikace" do formátu dat "nové aplikace":

• načtení vstupních dat a jejich validace
• úprava a transformace dat do výstupního formátu podle pravidel migrace
• uložení transformovaných dat na správné místo pro novou aplikaci

Testeři a certifikace

Dnes jsem si přečetl nové číslo časopisu Testing Experience a zjišťuji, že kromě některých parádních článečků o testování je doslova přecpaný reklamami (asi jako všechno co je "zdarma ke stažení"). Většina reklam souvisí s testerskou certifikací ISTQB, což mě přivedlo k zamyšlení nad certifikacemi vhodnými pro testery.