how improve test release process
Podívejme se na typický proces dodávající software z „vývojové fáze“ do „testovací fáze“ úspěšné vydání softwaru bez chyb do produkce / klienta .
Tyto procesy softwarové společnosti buď přehlížejí, nebo přeskakují, což má za následek špatnou správu testů a tím „ kočárek „Software se vydává klientovi, což vede k“ nespokojení zákazníci “.
Přestože testovací tým věnuje spoustu času a úsilí při každém vydání , když vydaný software nemá definovanou nebo srovnatelnou kvalitu nebo nesplňuje očekávaná kritéria, ovlivní to nejen reputaci společnosti u zákazníků, ale také demotivuje a demoralizuje projektový tým, nejdůležitější je testovací tým jako celek .
Pokud jste v tomto scénáři součástí testovacího týmu, můžete si dál myslet, „jak zlepšit své testovací schopnosti a existuje lepší způsob, jak tuto situaci překonat“.
Chci dát několik tipů a návrhů na základě mých zkušeností s různými testovacími týmy zapojenými do vydávání softwarových aplikací a podnikových produktů s více doménami a platformami a s více testovacími rámci. jak zlepšit procesy uvolnění testu , což vám zjednoduší profesionální život testovacího inženýra nebo testovacího manažera pro poskytování softwaru světové úrovně.
Co se naučíte:
- Proces uvolnění testu
- Vylepšení procesu uvolnění testu:
- Správa a kontrola obsahu testovací verze
- Ukázka šablony zprávy o vydání:
- Závěr:
- Doporučené čtení
Proces uvolnění testu
Níže uvedená tabulka poskytuje přehled procesu uvolnění testu se třemi univerzálními fázemi, jako je vstup, proces a výstup.
top 10 stránek pro stahování mp3 zdarma
| VSTUP | PROCES | VÝSTUP |
|---|---|---|
| 7 | Kontrolní seznam kontroly kódu byl aktualizován a je k dispozici ve VSS? | |
| Předchozí proces Rozvoj | Proces začíná na • Instalace uvolněného softwaru na testovacím serveru | Potřeby dalšího procesu • Software, který prošel testem kouře / zdravého rozumu |
| Informace / reference k dokumentu • Dokument o požadavcích uživatele • Specifikace softwarových požadavků • Plán testování jednotky • Standardy kódování • Kontrolní seznam kontroly kódu • Vývojový plán • Plán zajištění kvality • Přidělení úkolu • Pracovní balíček • Časový plán projektu • Plán projektu • Plán správy konfigurace • Plán řízení rizik. | Dílčí procesy • Příprava testovacích případů pro všechny jednotky • Vývoj a testování jednotek • Řešení neshodných postupů • Implementace plánu správy konfigurace. • Implementace plánu řízení rizik • Monitorování pokroku projektu • Opravy chyb a kontroly | Interní potřeby zákazníka • Software vytvořený s číslem verze • Zpráva o vydání • Testovací případy / dokument Test Suite • Plánování provedení testu • Matice sledovatelnosti • Testovací data |
| Ověření příchozího vstupu • Dokumenty projektu jsou zkontrolovány a schváleny? • Standardy kódování, kontrolní seznam kontroly kódu jsou k dispozici pro referenci? • Přidělena úloha a aktualizován pracovní balíček? • Funkční specifikace, plán rozvoje a plán kvality jsou zkontrolovány a schváleny? • Plán řízení rizik má zmírnění a nepředvídané události, aby zvládl rizika? • Efektivnost časového plánu projektu na včasné dodání produktu? | Specifikace procesu • Testovací případy jednotky by měly sestávat ze všech vstupních a výstupních kritérií • Dodržování kódu s kódovacími standardy • S NCP by se mělo zacházet podle pokynů • Kroky správy konfigurace by se měly řídit plánem správy konfigurace • Řešení rizik by mělo být v souladu s Plánem řízení rizik • Testování kouře vyhovuje všem hlavním funkcím a funkcím | Potřeby externího zákazníka • Bug Free Software |
| Podpůrné procesy • Přidělení lidí / hardwaru / softwaru / zdrojů • Údržba při poruše hardwaru • Školení členů týmu | Proces končí • Provedení testování kouře / duševního zdraví na uvolněné sestavě | Parametry účinnosti • Každá jednotka by měla projít prvním kolem testování • Úkoly, které je třeba splnit podle harmonogramu projektu • Zkouška kouře by měla proběhnout před uvolněním • Testování vášně týmu k testování softwaru |
Každý testovací tým by měl vytvořit unikátní kontrolní seznam pro vydání softwaru, podle domény a platformy softwaru a metodiky řízení projektů (jako je Agile Scrum atd.) a podle rámce pro manuální / automatizované testování, přijměte uvolněné sestavení před zahájením provádění testu, abyste ušetřili čas a úsilí.
Toto je jeden z nejdůležitějších parametrů účinnosti ve fázi uvolnění testu.
Vylepšení procesu uvolnění testu:
1) Zkontrolujte zprávu o vydání pro novou funkcionalitu, přizpůsobení / úpravy stávajících funkcí, opravy chyb z předchozího sestavení, které se rozhodnou zahájit provádění testu kouře nebo testování příčetnosti nebo jejich kombinace.
dva) Zkontrolujte aktualizaci Testování dokumentů podle nových funkcí a oprav chyb, pokud již nejsou aktualizovány. Za normálních okolností se během životního cyklu vývoje softwaru tyto dokumenty aktualizují testovacím týmem na základě pravidelných týdenních kontrolních schůzek projektu.
3) Zkontrolujte sestavení softwaru v úložišti konfigurace je aktualizován pro číslo sestavení, číslo verze, označený nebo komentovaný názvem verze podle standardů definovaných v plánu projektu. Zajistěte také, aby byla sestava úspěšně zkompilována a nainstalována na testovacím serveru.
4) Naplánujte si po vydání rychlou schůzku o přezkoumání projektu diskutovat o výhodách a nevýhodách vydaného sestavení, známých chybách a kritických funkcích atd., vyhnout se jakékoli nedorozumění a zkontrolovat všechny důležité požadavky klienta. Přísně se vyvarujte jakékoli ústní komunikace mezi vývojovými a testovacími týmy, protože to má velký dopad na kvalitu vydání softwaru.
5) Zajistěte, aby byl nástroj pro sledování chyb správně nakonfigurován , pro přidělený testovací tým a vývojový tým projektu, čísla sestavení a vydání softwaru a také moduly / funkčnost softwaru, které pomohou efektivně zaznamenávat chyby. Pokud tomu tak není, mělo by to být předáno vedoucímu projektu nebo vedoucímu testu na základě vysoké priority.
6) Vraťte sestavení vývojovému týmu bez jakýchkoli kompromisů, pokud sestavení selže při testování kouře nebo duševního zdraví. Přísně by testování nemělo pokračovat, když systém selže při kouřovém testování. To ušetří spoustu času a úsilí a zlepší kvalitu softwaru vydaného v následujících verzích.
7) Naplánujte vydání projektu na 1SvatýDen v týdnu který pomůže testovacímu manažerovi naplánovat nadcházející testovací cyklus na základě stability sestavení a také zaslat rychlou testovací zprávu projektovému manažerovi, který v dostatečném předstihu eskaluje kvalitu softwaru. Pokud vývojový tým naplánuje vydání projektu na pátek, víkend lze využít pro jakékoli skluzy i pro jakékoli problémy s sestavením v rámci pro ruční nebo automatizované sestavení.
8) Zajistěte, aby byli testeři v doméně správně vyškoleni což pomůže testovacímu týmu dodržet testovací plán a získat čas na další kolo testování. Testovací tým by měl být také vyškolen a měl by být vystaven požadované technologii, jako je skriptování a SQL, pokud projekt vyžaduje bílý rámeček.
9) Vyhněte se alokaci testerů ve více projektech protože to výrazně ovlivňuje kvalitu provedení testu v reálném čase. V praxi dokonce i zkušení testeři přehlížejí funkce a funkce a přeskakují testovací případy za předpokladu, že některé testovací případy nikdy selžou, když jsou přetíženy prací nebo přiděleny na více projektů s termíny.
10) Oceňujte testovací tým, abyste měli vášeň protože testeři by neměli pracovat pro „Den“ nebo komentovat „Nazvěme to dnem“. Pokud má software více modulů a funkcionalista je zcela nebo zčásti integrovaný nebo vzájemně propojený, měli by mít testeři vášeň pro psaní / provádění testovacích případů s velkým pokrytím a sledovatelností matice se zaměřením na kvalitu finálního softwaru / produktu. Protože i kosmetický problém je „chyba“ a počítá se jako „1 chyba“.
jedenáct) Zajistěte, aby instalace softwaru byla snadná a přímá protože pomáhá testovacímu týmu v případě potřeby znovu nainstalovat software, místo aby čekal na vývojového manažera nebo manažera instalace, který provede stejnou práci, což zbytečně zabije dostupnou dobu testování. Například i když je instalace založená na systému Windows snadná, ale pokud zahrnuje více webových serverů a rozsáhlých sítí ve víceúrovňovém testovacím prostředí, může instalace softwaru trvat několik hodin. Pokud kryty testování softwaru a instalace, odinstalování , opravy nebo aktualizace softwaru, je pravděpodobnější, že bude podrobně projednán proces provádění testovacích případů s testovacím týmem.
12) Zajistěte, aby byly automatizované nástroje k dispozici s licencí pro rámec testování automatizace . Provádění testovacích případů v automatizovaném rámci je snadné ve srovnání se scénářem ručního testování, pokud jsou automatizované nástroje správně nakonfigurovány a licencovány pro více uživatelů. Zejména pokud testovací plán zahrnuje testování výkonu a zátěže kromě pravidelného provádění testovacích případů a regresního testování, testeři by měli pokrýt provádění testovacích případů na více prostředích, jako je více serverů, více prohlížečů, více uživatelů atd.
13) Zajistěte, aby duchovní stroje byly nastaveny pro testování před zahájením provádění testu. Duchové stroje jsou stroje s odlišným testovacím prostředím. Například lze naplánovat testování softwaru webové aplikace v různých prostředích, jako je Windows 7 & Access DB nebo Windows 2008 & SQL Server nebo Windows 8 & Oracle nebo Mainframe & DB2 atd., Se všemi prohlížeči, jako jsou Chrome, Firefox, Internet Explorer , Safari atd., Některé „testování systému“ dokonce vyžaduje úplné formátování pevného disku a instalaci nového softwaru nebo aktualizaci stávajícího softwaru pomocí oprav a aktualizací atd.
14) Vyhněte se implementaci nových funkcí / požadavku na změnu zastavením provádění testu a opětovným vydáním softwaru pro opětovné uvedení fáze testování. To je velmi špatná praxe v mnoha softwarových organizacích, pokud jde o obchodní požadavky uspokojit externí zákazníky nebo alespoň splnit požadavky řídícího výboru managementu nebo někdy prodejních / marketingových týmů. I když jsou požadavky na změnu od zákazníků v prostředí projektu „Agile“ vždy podporovány, mělo by to být správně naplánováno a implementováno před vydáním softwaru testovacímu týmu.
Správa a kontrola obsahu testovací verze
Správa a kontrola obsahu testovací verze je nejdůležitější pro jakýkoli software IT nebo dokonce pro jakékoli jiné softwarové prostředí, než je IT, které bude znázorněno na obrázku níže.
- Manažeři projektu nebo řídící výbor projektu závisí na autoritě organizační matice a je odpovědný za výběr obsahu pro každé vydání.
- Jakmile budou chyby a / nebo nové funkce a požadavek na změnu od zákazníků identifikovány a schváleny, bude to implementováno vývojovým týmem, který by měl být před zahájením vývoje / implementace naznačen zúčastněným stranám projektu.
- Na základě implementovaného finálního vydání testovací tým aktualizuje související dokumenty a podle toho se připraví na testování.
- Testovací tým zahájí testování Smoke / Sanity podle definovaných požadavků ve zprávě o vydání.
- Jakmile Sanity projde, testovací tým zahájí provádění testu podle plánu a přidělených úkolů, viz. Funkční testování, Nefunkční testování, Testování bezpečnosti, Testování systému, Testování výkonu, Testování zatížení, Testování přijatelnosti uživatelů atd.
- Jakmile je dokončeno první kolo testovacího cyklu, budou testovací zprávy zaslány všem zúčastněným stranám a manažerovi vývojového týmu, aby naplánovali další iteraci provádění testu.
- V závislosti na stavu protokolů o testu a závažnosti a složitosti chyby bude naplánován kompletní cyklus druhého kola provádění testu nebo regresního testování spolu s testem přijetí uživatelem.
- Po dokončení plánovaných cyklů provádění testů budou testovací zprávy zaslány všem zúčastněným stranám projektu pro úspěšné / neúspěšné / zmeškané funkce, funkce a opravy chyb.
Ukázka šablony zprávy o vydání:
Poznámka : Níže je k dispozici ke stažení ukázková šablona MS Word pro sestavu Release.
Níže naleznete „ Ukázka zprávy o vydání „Který pokrývá hlavní aspekty procesu vydání, díky čemuž je profesionální život celého projektového týmu mnohem šťastnější než kdykoli předtím.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Rozsah
GPS Navigace pro XYZ Company Limited je uvolněna pro interní testování. Vydaná verze je 1.0.7, číslo vydání je 14.0 a číslo sestavení 105.25.03. Toto vydání softwaru obsahuje nové funkce a hlavní opravy chyb z předchozího vydání. Testování kouře prochází vývojovou fází, ale před přechodem na regresní testování je vyžadován kouř a zdraví.
# 2) Odkazy
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Popis vydání
Toto vydání je řízeným vydáním navigace GPS a obsahuje následující funkce a funkce.
Funkce označené * jsou v této verzi nové.
Následující funkce nejsou v tomto vydání implementovány.
1. Modul 1
1.1 Funkce 1
1.1.1 Funkčnost 1
# 4) Správa konfigurace
Jako nástroj pro správu konfigurace používáme Visual Source Safe. Sestavení je k dispozici v následující cestě.
Interní odkaz: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Externí odkaz: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Pokyny k instalaci a kroky
Poskytněte týmu QA / Testing podrobné informace o instalaci sestavení.
# 6) Opravené problémy / chyby
Stav chyb se aktualizuje v systému sledování defektů.
# 7) Problémy / chyby, které je třeba opravit
# 8) Výsledky
# 9) Známé chyby / problémy
# 10) Uvolněte kontrolní seznam
| Ano ne / | Popis | Ano / ne |
|---|---|---|
| 1 | Byly všechny soubory zkontrolovány v Visual Source Safe? | |
| dva | Byl štítek umístěn na správnou složku ve VSS podle interních standardů? | |
| 3 | Je vydání identifikovatelné jako „externí“ / „interní“ vydání ve VSS? | |
| 4 | Byla v komentářích uvedena verze ve VSS? | |
| 5 | Byl v komentářích uveden krátký popis ve VSS? | |
| 6 | Kód byl zkontrolován a problémy s kontrolou kódu jsou zaznamenány v Clear Quest? | |
| 8 | Byl připraven a přezkoumán jednotkový testovací dokument? | |
| 9 | Byly provedeny testovací případy jednotky a výsledky aktualizovány pro stav? | |
| 10 | Aktualizovaný dokument testovacího případu jednotky je k dispozici ve VSS? | |
| jedenáct | Všechny problémy Clear Quest pro toto vydání byly vyřešeny / uzavřeny? | |
| 12 | Všechny úkoly pracovního balíčku byly dokončeny a aktualizovány ve VSS? | |
| 13 | Je testování kouře hotové a prošlo? |
=> Stažení: Kliknutím sem stáhnete šablonu zprávy o vydání zprávy ve formátu MS Word.
Závěr:
Jak průběžně vylepšovat proces uvolnění testu
Tip č. 1) Vytvořte tým techniků vydání, který se postará o kritické faktory udržování vydání a sestavení softwaru a odpovídá za centralizované systémy správy konfigurace softwaru.
Tip č. 2) Motivujte a oceňujte projektové týmy pro sledování procesu zapojeného do životního cyklu vývoje softwaru, životního cyklu vývoje produktu a životního cyklu testování softwaru. Můžeme definovat proces, ale dokud a pokud ho nebudou dodržovat zúčastnění lidé, není definování procesu k dispozici.
Tip č. 3) Odhadněte testovací úsilí na základě zkušeností a předchozí historie. Psaní testovacích případů se úplně liší od provádění stejných. Testeři by měli rozumět tomu, co testovat, jak testovat a kdy testovat, jinak bude úsilí vynaložené na testovací cyklus zbytečné, přestože proběhlo několik kol testovacího cyklu.
Tip č. 4) A konečně, pokud je to možné a proveditelné, automatizujte fázi testování pomocí některých všeobecně přijímaných testovacích nástrojů. Použití nástrojů pro automatické sestavování a nástrojů pro automatické testování snižuje úsilí o testování o více než 50% zlepšením kvality softwaru a zajišťuje 100% kvalitu, pokud je správně navržen rámec automatizace.
Tip č. 5) V neposlední řadě není testovací vydání jen prací, je to umění usnadnit a zpříjemnit život všem zúčastněným stranám v projektu.
O autorovi: Balu A. je zkušený technicko-funkční IT profesionál s více než dvěma desetiletími zkušeností s IT softwarem a desetiletí zkušeností se správou projektů a testů, které poskytují podnikové aplikace a řešení mobility napříč doménami pomocí technologií Microsoft, Oracle, Java a Mobile. Je v zásadě lídrem s vášní propagovat lidi, aby se stali lídry se správným přístupem, miluje práci v procesně orientovaném prostředí a věří, že proces zvyšuje efektivitu, kvalitu a produktivitu zaměstnanců.
vdalší tutoriál, naučíme se - Jak na to Zlepšete účinnost testovacích případů.
Sdělte nám své myšlenky / dotazy v komentářích níže.
Připravte si vydání softwaru podle postupu!
Kompletní testování podle plánu s velkou produktivitou a úsilím !!
Pokuste se dosáhnout dodávek softwaru bez chyb a zajištění kvality !!!
Pokud se vám tento článek líbí, zvažte jeho sdílení se svými přáteli!
Doporučené čtení
- Kurz testování softwaru: Ke kterému institutu pro testování softwaru bych se měl připojit?
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Úloha pomocníka QA při testování softwaru
- Co je Testování opic při testování softwaru?
- Výběr testování softwaru jako vaší kariéry
- Práce na volné noze se softwarem pro testování technického obsahu Writer
- Ukázka hlášení o chybě
- Praktické testování softwaru Tok procesu QA (požadavky na vydání)