Adastra Logo
 
header


Testování

Testování umožňuje organizacím snižovat rizika spojená s tvorbou a dodávkou softwarového produktu. Účelem testování je exaktní prokázání, že vyvíjený produkt dosáhl požadované a potřebné kvality. Testování samo o sobě kvalitu produktu přímo nezvyšuje, nicméně je pro její zvyšování nezbytné.

Vyplatí se testování?
Kvalitní, tedy zaměřené testování, jednoznačně ano. Dobrý test manažer totiž sám pozná, kdy vynakládá prostředky na testování účelně, a kdy už ne. Může tak usuzovat z porovnání metrik založených na pokrytí systému testy a metrik sledujících nalezené chyby.

Aby bylo testování výkonné a efektivní, je třeba, aby do procesu testování byly nejen poskytnuty vhodné vstupy, ale také aby pracovníci organizace znali vývojový i testovací proces a uměli vybírat a používat vhodné techniky designu testů, efektivně řídit průběh testování a včas a správně o průběhu a výsledcích testů informovat. Klíčová je schopnost testování zaměřit a provádět právě ty kroky, které mohou nejefektivněji napomoci ke zkvalitnění produktu. Právě v tom vám může pomoci tým zkušených specialistů společnosti Adastra, kteří:

  • Mají skutečný přehled v oboru – reálné zkušenosti s různými druhy software, různými architekturami, znalost životního cyklu software, modelování nebo programování
  • Mají odbornost v oborech s testováním souvisejících – jako např. Requirements Management, Configuration and Issue Management nebo Operation Management
  • Pravidelně procházejí nejrozšířenější mezinárodní certifikací z oboru testování software – ISTQB CTFL 

Metodika testování
V projektech z oblasti testování využíváme metodiky Adastra QVV.360, avšak tým zkušených testerů společnosti Adastra se rychle zorientuje i ve vlastních metodikách zákazníků, se kterými je následně schopný flexibilně pracovat.

Při práci podle Adastra QVV.360 lze, z hlediska řízení a průběhu projektu, testování chápat jako samostatný „projekt,“ který vyžaduje vstupy a poskytuje výstupy. Ty mohou být tím jediným, co projektového manažera na testování zajímá, protože mu poskytují veškeré potřebné informace jak o průběhu testování a jeho výsledcích, tak také o skutečné kvalitě vyvíjeného produktu. Protože se testování podle Adastra QVV.360 drží zásady úplné správy elementů testování, je kdykoli možné zjistit, jak výstupy vznikly, prohlédnout detailní informace o testování a trasovat výsledky testování zpět k požadavkům a specifikaci produktu.

Vstupy:

  • Požadavky – zachycují a prezentují informace získané při definici požadovaných vlastností dodávky
  • Use case model – model zamýšlených funkcionalit systému a jeho prostředí, slouží jako smlouva mezi zákazníkem a vývojářem
  • Build – provozuschopný systém nebo jeho část prokazující funkčnost podmnožiny schopností systému k danému datu. Tato funkčnost je určena k otestování
  • Produkt – ucelené balení softwarového produktu pro nasazení na trhu (k dodávce a instalaci)
  • Slovníček – jednoznačné vysvětlení pojmů používaných při práci. Mnoho potíží pochází z různého porozumění zdánlivě stejným pojmům

Výstupy:

  • Plán testů – účelem je stanovit a komunikovat záměry testování v příslušném období. Harmonogram testování, na nějž je tento pojem často zužován je jednou z jeho částí
  • Vyhodnocení testování – měří a vyhodnocuje postup a výsledky testování, zejména vzhledem k Test plánu. Veškeré informace musí být dostupné co nejdříve po ukončení testování, některé ale již v jeho průběhu
  • Problémy/nedostatky – zejména jednotlivé záznamy o chybách, „bugy“ v nástroji pro jejich správu. V úplném chápání ale také libovolné další „body k řešení“ – požadavky na změnu, žádosti o např. o přístupy apod.

Dokumenty 

 


foot link