Menu

Jak rozhodnete, které vady jsou přijatelné pro uvedení softwaru do provozu?

how do you decide which defects are acceptable

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Software Go-Live je vždy velkou událostí pro jakýkoli softwarový produkt. Je důležité absolutně se ujistit, že vše funguje a že jsme vydávání kvalitního softwaru uživatelům .

Špatný nebo předčasný, nestabilní nebo obtížně použitelný produkt může způsobit finanční ztráty a může také způsobit, že uživatel ztratí důvěru v samotnou značku.

Často slyšíme, že testování by mělo být provedeno, dokud nesplníme výstupní kritéria. Také jsme slyšeli, že vady musí být opraveny na přijatelnou úroveň.

I když jsou to skvěle znějící pokyny, jsou vágní.

kritéria pro spuštění softwaru

Byt více specifický:

  • Jaké procento vad je přijatelné pro uvedení softwaru do provozu?
  • Jak se rozhodnete pro otevřené vady, se kterými může software fungovat?
  • Co druhy vad jsou vážnější než ostatní?

Doporučené čtení => Kdy zastavit testování?

Už jste někdy měli tyto otázky? Tento článek vám pak pomůže odpovědět. Číst dál…

Komplexní software není bezchybný a jedná se o slepičí příběh o uzavírání defektů ve srovnání s fungujícím softwarem.

Čím více defektů opravíte, tím větší je pravděpodobnost, že při zavírání defektu byl vložen nový defekt. Tak,

  • Jak se rozhodujete o rozsahu vad a druhu vad, se kterými se můžete setkat?
  • Jak nastavíte základní úroveň softwaru, který má být nasazen k uvedení do provozu?
  • Jak koordinátoři UAT volají k uvedení do provozu nebo ne?
  • Podle jakých parametrů by měl být software posouzen?
  • Jak odpovíme - Je software vhodný k použití a přinese hodnotu zúčastněným stranám?

Zahájení výroby je hlavním milníkem pro zákazníka i prodejce, protože je obvykle spojeno s milníky plateb. Oba mají stejnou odpovědnost za zajištění úspěchu velkých transformačních projektů.

Moje zkušenost ukazuje, že zákazníci chtějí svou hodnotu za peníze a mají výstupní kritérium pro UAT, s nímž bude žít.

Uvedená výstupní kritéria by víceméně definovala přijatelný rozsah problémů ve všech oblastech aplikace, například:

  1. Funkční
  2. Výkon a zatížení
  3. Použitelnost
  4. Bezpečnostní
  5. Integrace s externími systémy
  6. Zprávy
  7. Migrace dat

Věřím, že každý z těchto typů vad je třeba dále vysvětlit. A to je přesně to, co nyní uděláme:

jak inicializovat seznam v Javě

# 1. Funkční vady:

Pokud je software vytvořen podle specifikací daných zákazníkem, musí splňovat požadavky. Jakékoli odchylky se zaznamenávají jako funkční vady.

Funkční vady jsou poté klasifikovány podle závažnost a priorita .

Toto jsou důležité úvahy:

  • Vysoká závažnost a prioritní vady jsou obvykle ty, které by měly dopad na každodenní používání softwaru. Tyto typy vad jsou ty, které je třeba opravit, než uvedeme do provozu. Žádné vyjímky.
  • Někdy jsou funkční vady klasifikovány jako požadavky na změnu, protože nebyly součástí původně daných požadavků. Takové CR, které jsou nezbytnou podmínkou pro to, aby podniky fungovaly i po spuštění, je rovněž nutné zavést.
  • Klasifikaci vad a stanovení priorit funkčních vad provádějí koordinátoři UAT ve spolupráci s obchodními uživateli a obchodními analytiky. Zákazník má obvykle výstupní kritéria, kolik procent vad může být otevřeno pro uvedení do provozu.

# 2. Vady výkonu a zatížení:

Vady výkonu je důležité zvážit uvedení do provozu a ještě více, pokud má software používat externí uživatelé.

Pokud je software pro daný počet uživatelů pomalý, uživatelé by se vyhnuli používání softwaru, protože jeho načítání trvá hodně času. Uživatelé mají tendenci přecházet na stránky konkurence, pokud je software velmi pomalý, což vede ke ztrátě podnikání.

Výkon mohou někdy ovlivnit i ty části aplikace, které nejsou pro klienta.

Například: Pokud existuje dávkový proces, který běží na konci každého dne a pokud doba odezvy aplikace trpí, zatímco to pokračuje, pak je také třeba zvážit výkon dávky.

  • Výkon se obvykle měří z hlediska doby odezvy obrazovek na vykreslení a zpřístupnění uživatelům, zatímco v systému je určitý počet souběžných uživatelů.
  • Testy výkonu se provádějí pomocí nástrojů, jako jsou LoadRunner , WebLoad , Neoload atd.
  • Výkon softwaru při daném zatížení a při budoucím předpokládaném zatížení je obvykle dokumentován ve smlouvě a musí být před spuštěním uveden do provozu.
  • Obrazovky nebo části aplikace, které uživatelé používají méně, se po uvedení do provozu odloží na vyhodnocení.
  • Výkon závisí také na typu hardwaru a podmínkách sítě, na kterých je software nasazen.
  • Testy výkonu se provádějí během UAT na zadaném hardwaru pomocí výkonových nástrojů a jejich vady jsou sledovány podobným způsobem jako funkční vady. Jsou také upřednostňovány a je dosaženo shody ohledně splnění výstupních kritérií pro uvedení do provozu.
  • Testy výkonu a zátěže v UAT se obvykle provádějí po dokončení funkčního UAT obchodními uživateli a dosažení přijatelného výstupního kritéria pro funkční vady.

# 3. Vady použitelnosti:

Vytvořený software by měl být snadno použitelný koncovými uživateli pomocí různých klávesových zkratek, zkratek, minimálního počtu navigace na obrazovce, stránkování atd. Software musí být chytrý a intuitivní.

Pokud je před přesunem na příslušnou obrazovku příliš mnoho pohybů stránky, uživatelé obvykle projeví menší zájem o používání softwaru.

  • Pokyny k použitelnosti jsou vytvořeny před vytvořením softwaru. Software musí tyto pokyny dodržovat.
  • Při vytváření softwaru mohou existovat také omezení nástrojů, která je třeba chytře překonat, než bude software použitelný koncovými uživateli.
  • Díky vysoce použitelnému softwaru může koncový uživatel zadávat data až pětkrát vyšší než běžný software.
  • Vzhled a chování softwaru musí být ostrý a před spuštěním musí být vyřešeny také právní problémy.
  • Mnohokrát je jmenován konzultant použitelnosti, aby uživatelům zajistil bezproblémový zážitek z použitelnosti.
  • Dokumentace, která musí vyjít se softwarovou aplikací, musí také dodržovat přísné pokyny k použitelnosti, protože je lze legálně používat.
  • Vady použitelnosti zaznamenané testery UAT / externími testery jsou také upřednostňovány jako funkční a výkonové defekty a musí splňovat výstupní kritéria pro uvedení do provozu.

# 4. Vady zabezpečení:

Bezpečnostní softwaru je horký problém, protože softwarová aplikace může být hacknuta a citlivá data zákazníků mohou být ukradena během chvilky.

Spolehlivý software by proto neměl umožnit ani velmi kompetentnímu hackerovi dostat se do aplikace bez patřičných oprávnění.

  • Testování zabezpečení se provádí v UAT se specifickými vstupy do softwaru, aby se zajistilo, že není hackovatelný.
  • Testování zabezpečení provádějí legální hackeři, kteří se pokoušejí hacknout software, aby zjistili, zda je zranitelný.
  • Před spuštěním systému musí být odstraněny všechny bezpečnostní vady.
  • Zabezpečení také znamená Přihlášení a role a oprávnění pro různé uživatele (externí i interní), aby mohli používat různé sekce aplikací a také pro vytváření a schvalování dat.

# 5. Integrace s externími softwarovými systémy:

Softwarová aplikace, která má být nasazena u zákazníka, musí obvykle komunikovat s jakýmkoli existujícím softwarem, který tam již může existovat.

Například: S tiskovým systémem se používají, nebo by to mohly být externí systémy, jako je fakturační aplikace nebo systémy datových obrazovek. Nasazená softwarová aplikace by se měla bezproblémově integrovat do těchto externích systémů. Všechny vstupy a výstupy do těchto systémů by měly fungovat synchronně. Technologie dnes zahrnuje mobilní aplikace a různé softwarové platformy, které aplikace musí být kompatibilní s .

Kontrola propojení externího systému by měla být rozsáhle prováděna během fází systému a UAT. Mělo by to být nutností u výstupních kritérií, která by měla být splněna před uvedením do provozu.

# 6. Zprávy:

Zprávy ze softwarové aplikace jsou kritickým způsobem, jak ukázat, že se data uvnitř aplikace shodují.

Například: všechna data související s fakturací se musí shodovat v kreditních a debetních zůstatcích.

  • Všechna data v softwaru se musí sladit. Toto sladění dat v softwaru se zobrazuje prostřednictvím zpráv a musí fungovat správně.
  • To platí zejména v případě, že primárním záměrem aktuálního vydání je migrace dat ze starého systému do nového systému.

# 7. Migrace dat:

Pokud je starý systém nahrazován novým, budou data ze starého systému přesunuta do nového systému (po dosažení mezního data pomocí nového systému). Migrovaná data by měla být podporována novým systémem definovaným během shromažďování požadavků.

Všechna stará data nemusí být v novém systému k dispozici; v novém systému však může být k dispozici snímek starých dat. Tyto údaje by měly být k dispozici podle dohody.

Poznámka : Výše ​​uvedený seznam není vyčerpávající. V závislosti na typu aplikace může existovat více věcí, které musíte ověřit, nebo nemusí být použitelné všechno výše. Pro vypracování komplexních výstupních kritérií je tedy nutné důkladné porozumění softwaru, obchodním účelům, očekáváním uživatelů a architektonickým či hardwarovým závislostem.

Příklad výstupních kritérií pro spuštění:

Toto je jen příklad. Může se lišit od projektu k projektu.

  • 100% vad priority 1 je uzavřeno (závažnost kritická a priorita 1)
  • 90% vad priority 2 je uzavřeno (vysoká závažnost a priorita 2) a u zbývajících 10% vad je k dispozici logické řešení. A je k dispozici plán uzavření zbývajících 10% vad.
  • Kontrolní seznam pro nasazení výroby a zdravý rozum je připraven.
  • Tým podpory výroby byl vytvořen a je připraven na uzavírání lístků.
  • 70% vad priority 3 je uzavřeno a je vytvořen plán pro uzavření zbytku 30% vad nízké hodnoty.

Několik poznámek:

  • O všech definicích závažnosti a priorit se rozhoduje během obchodních jednání mezi zákazníkem a prodejcem na začátku programu.
  • Po zaznamenání všech vad UAT a uzavření všech ostatních vad se sejdou koordinátoři UAT a obchodní sponzoři, aby provedli inventuru nevyřízených a otevřených vad. Pokud jsou všechny závady, které jsou vyžadovány pro uvedení do provozu 1. den, uzavřeny, obchodní sponzoři uvidí jejich připravenost na uvedení do provozu a uvedení softwaru do výroby.

Závěrem

Doufáme, že vám tento článek poskytne několik poznatků o některých důležitých úvahách, které se týkají vytváření skalopevných výstupních kritérií, která chrání software před potenciálními poruchami ve výrobě.

O autorovi: Toto je hostující článek Krishnana Venkatramana. Má téměř 18 let zkušeností s testováním softwaru. Pracoval na mnoha velkých a složitých projektech testování softwaru.

Neváhejte a pošlete své dotazy / komentáře níže.

Doporučené čtení

^