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.
pondělí 30. ledna 2012
úterý 8. listopadu 2011
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:
Nejdřív základy:
sobota 23. dubna 2011
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é.
pondělí 11. dubna 2011
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).
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).
čtvrtek 31. března 2011
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.
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.
středa 16. března 2011
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.
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.
pondělí 14. března 2011
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řihlásit se k odběru:
Příspěvky (Atom)