Menu

Ako rozhodnete, ktoré chyby sú prijateľné pre uvedenie softvéru do prevádzky?

how do you decide which defects are acceptable

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Softvér Go-Live je vždy veľkou udalosťou pre akýkoľvek softvérový produkt. Je dôležité absolútne sa ubezpečiť, že všetko funguje a že sme vydávanie kvalitného softvéru používateľom .

Zlý alebo predčasný, nestabilný alebo ťažko použiteľný produkt môže spôsobiť veľa strát finančne a môže tiež spôsobiť, že používateľ stratí dôveru v samotnú značku.

Často počujeme, že testovanie by sa malo robiť, kým nesplníme výstupné kritériá. Tiež sme počuli, že chyby musia byť opravené na prijateľnú úroveň.

Aj keď ide o vynikajúce znejúce pokyny, sú neurčité.

kritériá na spustenie softvéru

Aby som bol konkrétnejší:

  • Koľko percent vád je prijateľných pre spustenie softvéru?
  • Ako rozhodujete o otvorených chybách, s ktorými môže softvér začať pracovať?
  • Čo druhy vád sú vážnejšie ako ostatné?

Odporúčané čítanie => Kedy prestať s testovaním?

Mali ste niekedy tieto otázky? Tento článok vám potom pomôže odpovedať na ne. Pokračuj v čítaní…

Komplexný softvér nie je bezchybný a jedná sa o slepačie a vajíčkové rozprávanie o odstránení chýb vo vzťahu k fungujúcemu softvéru.

Čím viac chyby opravíte, tým vyššia je pravdepodobnosť, že došlo k vpichnutiu novej chyby pri jej odstraňovaní. Takže

  • Ako sa rozhodujete o rozsahu vád a druhu vád, s ktorými sa môžete vysporiadať?
  • Ako si pripravíte základňu pre nasadenie softvéru?
  • Ako koordinátori UAT volajú k uvedeniu na trh alebo nie?
  • Podľa akých parametrov by sa mal softvér posudzovať?
  • Ako odpovedáme - Je softvér vhodný na použitie a bude prínosom pre zúčastnené strany?

Spustenie výroby je hlavným míľnikom pre zákazníka aj pre dodávateľa, pretože je zvyčajne spojené s míľnikmi platieb. Obaja majú rovnakú zodpovednosť za zabezpečenie úspechu veľkých transformačných projektov.

Moje skúsenosti ukazujú, že zákazníci chcú mať svoju hodnotu za peniaze a majú výstupné kritérium aby mohla UAT žiť.

Uvedené výstupné kritériá by viac-menej definovali prijateľný rozsah problémov vo všetkých oblastiach aplikácie, ako napríklad:

  1. Funkčné
  2. Výkon a zaťaženie
  3. Použiteľnosť
  4. Bezpečnosť
  5. Integrácia s externými systémami
  6. Správy
  7. Migrácia údajov

Domnievam sa, že každý jeden z týchto typov chýb musí byť vysvetlený ďalej. A to je presne to, čo teraz urobíme:

najlepší softvér na obnovu dát pre Windows

# 1. Funkčné chyby:

Ak je softvér vytvorený podľa špecifikácií uvedených zákazníkom, musí spĺňať požiadavky. Všetky odchýlky sa zaznamenávajú ako funkčné chyby.

Funkčné chyby sa potom klasifikujú podľa závažnosť a priorita .

Nasledujú dôležité úvahy:

  • Vysoká závažnosť a prioritné chyby sú zvyčajne chyby, ktoré by mali vplyv na každodenné používanie softvéru. Tieto typy defektov musia byť opravené skôr, ako uvedieme do prevádzky. Bez výnimky.
  • Niekedy sú funkčné chyby klasifikované ako požiadavky na zmenu, pretože neboli súčasťou pôvodne daných požiadaviek. Také CR, ktoré sú nevyhnutnosťou pre fungovanie podniku po uvedení do prevádzky, je takisto nevyhnutné zaviesť.
  • Klasifikáciu chýb a stanovenie priorít funkčných chýb robia koordinátori UAT v spolupráci s obchodnými používateľmi a obchodnými analytikmi. Zákazník má zvyčajne výstupné kritériá, koľko% chýb môže byť otvorených na spustenie.

# 2. Poruchy výkonu a zaťaženia:

Poruchy výkonu je dôležité zvážiť uvedenie do prevádzky a ešte viac, ak majú softvér používať externí používatelia.

Ak je softvér pre daný počet používateľov pomalý, používatelia by sa vyhli používaniu softvéru, pretože jeho načítanie trvá veľa času. Používatelia majú tendenciu prechádzať na stránky konkurencie, ak je softvér veľmi pomalý, čo vedie k strate podnikania.

Na výkon môžu niekedy mať vplyv aj časti aplikácie, ktoré nie sú postavené pred klienta.

Napríklad: Ak existuje dávkový proces, ktorý beží na konci každého dňa, a ak doba odozvy aplikácie počas tejto doby trpí, potom je potrebné zohľadniť aj výkon dávky.

  • Výkon sa zvyčajne meria z hľadiska doby odozvy obrazoviek na vykreslenie a sprístupnenie používateľom, zatiaľ čo v systéme je určitý počet súbežných používateľov.
  • Testy výkonu sa robia pomocou nástrojov ako napr LoadRunner , WebLoad , Neoload atď.
  • Výkon softvéru pri danom zaťažení a pri budúcom predpokladanom zaťažení je zvyčajne zdokumentovaný v zmluve a musí byť preukázaný pred uvedením do prevádzky.
  • Obrazovky alebo časti aplikácie, ktoré používatelia používajú menej, sa po zverejnení odložia na vyhodnotenie.
  • Výkon závisí aj od typu hardvéru a sieťových podmienok, na ktorých je softvér nasadený.
  • Testy výkonu sa počas UAT uskutočňujú na určenom hardvéri pomocou výkonnostných nástrojov a ich chyby sa sledujú podobným spôsobom ako funkčné chyby. Majú tiež prioritu a je dosiahnutý konsenzus o splnení výstupných kritérií pre spustenie.
  • Testy výkonu a zaťaženia v UAT sa zvyčajne vykonávajú po dokončení funkčného UAT obchodnými používateľmi a dosiahnutí prijateľného výstupného kritéria pre funkčné chyby.

# 3. Chyby použiteľnosti:

Softvér bol vytvorený by mali byť ľahko použiteľní pre koncových používateľov pomocou rôznych klávesových skratiek, skratiek, minimálneho počtu navigácií na obrazovke, stránkovania atď. Softvér musí byť inteligentný a intuitívny.

Ak dôjde k príliš veľkému pohybu stránky pred prechodom na príslušnú obrazovku, používatelia zvyčajne prejavia menší záujem o používanie softvéru.

  • Pokyny na použiteľnosť sa vytvárajú pred vytvorením softvéru. Softvér musí dodržiavať tieto pokyny.
  • Pri vytváraní softvéru môžu existovať aj obmedzenia týkajúce sa nástrojov, ktoré je potrebné inteligentne prekonať, aby bol softvér konečnými používateľmi použiteľný.
  • Vďaka vysoko použiteľnému softvéru môže koncový používateľ zadávať údaje až 5-násobne oproti bežnému softvéru.
  • Vzhľad a dojem zo softvéru musí byť ostrý a pred uvedením do života musia byť vyriešené aj právne problémy.
  • Mnohokrát je menovaný konzultant použiteľnosti, aby používateľom zaistil bezproblémový zážitok z použiteľnosti.
  • Dokumentácia, ktorá musí vychádzať so softvérovou aplikáciou, musí tiež dodržiavať prísne pokyny pre použiteľnosť, pretože sa môžu legálne používať.
  • Poruchy použiteľnosti zaznamenané testermi UAT / externými testermi sú tiež uprednostňované ako funkčné a výkonnostné defekty a musia spĺňať výstupné kritériá pre spustenie.

# 4. Chyby zabezpečenia:

Bezpečnosť softvéru je aktuálny problém, pretože softvérovú aplikáciu je možné hacknúť a citlivé údaje zákazníkov môžu byť odcudzené v čo najkratšom čase.

Spoľahlivý softvér by preto nemal umožniť ani veľmi kompetentnému hackerovi dostať sa do aplikácie bez náležitých privilégií.

  • Testovanie bezpečnosti sa vykonáva v UAT so špecifickými vstupmi do softvéru, aby sa zabezpečilo, že nie je napadnuteľný.
  • Testovanie bezpečnosti vykonávajú legálni hackeri, ktorí sa pokúšajú hacknúť softvér a skontrolovať, či je zraniteľný.
  • Pred spustením systému do prevádzky musia byť odstránené všetky chyby zabezpečenia.
  • Zabezpečenie tiež znamená Prihlásenie a roly a privilégiá pre rôznych používateľov (externých aj interných) na použitie rôznych sekcií aplikácií a tiež na vytváranie a schvaľovanie údajov.

# 5. Integrácia s externými softvérovými systémami:

Softvérová aplikácia, ktorá sa má nasadiť u zákazníka, musí byť obvykle prepojená s akýmkoľvek existujúcim softvérom, ktorý tam už môže existovať.

Napríklad: S tlačovým systémom sa používajú alebo by to mohli byť externé systémy, ako napríklad fakturačná aplikácia alebo systémy s údajovými obrazovkami. Nasadzovaná softvérová aplikácia by sa mala bezproblémovo integrovať do týchto externých systémov. Všetky vstupy a výstupy do týchto systémov by mali pracovať synchrónne. Táto technológia v súčasnosti zahŕňa mobilné aplikácie a rôzne softvérové ​​platformy, ktoré táto aplikácia musí byť kompatibilné s .

Kontrola rozhrania externého systému by sa mala rozsiahlo vykonávať počas fáz systému a UAT. Malo by to byť nevyhnutnosťou pri kritériách výstupu, ktoré by mali byť splnené pred uvedením do prevádzky.

# 6. Správy:

Správy zo softvérovej aplikácie sú kritickým spôsobom, ako preukázať, že údaje vo vnútri aplikácie sa zhodujú.

Napríklad: všetky údaje spojené s fakturáciou sa musia zhodovať v kreditných a debetných zostatkoch.

  • Všetky údaje v softvéri sa musia zosúladiť. Toto zosúladenie údajov v rámci softvéru sa zobrazuje prostredníctvom správ a tieto údaje musia fungovať tak, ako majú.
  • Platí to najmä vtedy, ak je primárnym zámerom aktuálneho vydania migrácia údajov zo starého systému do nového systému.

# 7. Migrácia dát:

Ak sa starý systém nahrádza novým, dáta zo starého systému sa presunú do nového (po dosiahnutí konečného dátumu pomocou nového systému). Migrované údaje by mali byť podporované novým systémom, ako je definované počas zhromažďovania požiadaviek.

Všetky staré údaje nemusia byť v novom systéme dostupné; v novom systéme však môže byť k dispozícii snímka starých údajov. Tieto údaje by mali byť k dispozícii podľa dohody.

Poznámka : Vyššie uvedený zoznam nie je úplný. V závislosti od typu aplikácie môže byť potrebné overiť viac vecí, alebo nemusí platiť všetko, čo je uvedené vyššie. Preto je pri vývoji komplexných výstupných kritérií nevyhnutné dôkladné pochopenie softvéru, obchodných cieľov, očakávaní používateľov a architektonických alebo hardvérových závislostí.

Príklad výstupných kritérií pre spustenie:

Toto je iba príklad. Môže sa líšiť od projektu k projektu.

  • 100% nedostatkov priority 1 je uzavretých (závažnosť kritická a priorita 1)
  • 90% defektov priority 2 je uzavretých (závažnosť vysoká a priorita 2), pričom pre zvyšok 10% defektov je k dispozícii logické riešenie. A je k dispozícii plán na odstránenie zvyšných 10% chýb.
  • Kontrolný zoznam nasadenia výroby a zdravotného stavu je pripravený.
  • Tím podpory výroby bol zostavený a pripravený na uzatváranie lístkov.
  • 70% závad priority 3 je uzavretých a je vypracovaný plán na uzavretie zvyšných 30% nedostatkov.

Niekoľko poznámok:

  • O všetkých definíciách závažnosti a priorít sa rozhoduje počas obchodných stretnutí medzi zákazníkom a dodávateľom na začiatku programu.
  • Po zaznamenaní všetkých defektov UAT a uzavretí všetkých ostatných defektov sa stretnú koordinátori UAT a obchodní sponzori, aby vyhodnotili nevyriešené a otvorené defekty. Ak sú odstránené všetky chyby, ktoré sú potrebné na uvedenie do prevádzky v Deň 1, sponzori firiem uvidia ich pripravenosť na uvedenie do prevádzky a uvedenie softvéru do výroby.

Na záver

Dúfame, že vám tento článok poskytol informácie o niektorých dôležitých úvahách, ktoré smerujú k vytvoreniu skalopevných výstupných kritérií, ktoré chránia softvér pred potenciálnymi zlyhaniami vo výrobe.

O autorovi: Toto je hosťovský článok Krishnana Venkatramana. Má takmer 18 rokov skúseností v testovaní softvéru. Pracoval na mnohých veľkých a zložitých projektoch testovania softvéru.

Neváhajte a pošlite svoje dotazy alebo komentáre nižšie.

Odporúčané čítanie

^