Menu

Co klienti SKUTEČNĚ očekávají od softwarových testerů?

what do clients really expect from software testers

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

V dnešním článku se chystám podělit o několik myšlenek na to, o čem věřím, že klienti od nás SKUTEČNĚ očekávají na základě mých zkušeností z první ruky s prací v klientských lokalitách s každodenními interakcemi tváří v tvář a spolupracující na moři prostřednictvím e-mailů nebo telefonních hovorů.

Služby IT jsou důležitou a nedílnou součástí softwarového průmyslu a pro úspěch je důležitá spokojenost zákazníků. Každý klient / organizace se může ve svém procesu lišit, může se řídit odlišným protokolem a může jednat s jiným typem podnikání.

Následující faktory jsou ale společné a záleží na nich obecně.

klienti pro testování softwaru

(obraz src )

Co se naučíte:

5 věcí, které klient očekává od softwarových testerů:

Očekávání klienta 1

# 1) Nákladová výhoda

Když přemýšlíte o prodeji nebo koupi něčeho, hraje důležitou roli cena a často je to jeden z důležitých rozhodujících faktorů. Nečekáme všichni netrpělivě na Černý pátek, výprodej Flipkart Billion Day nebo skvělý nákupní festival Amazon? Během doby prodeje se stáváme bláznivými kupujícími. Je to jednoduché lidské chování očekávat za naše peníze to správné nebo mimořádné.

Společnosti a zákazníci se neliší. Nákladové výhody posilují vztahy mezi zákazníky a službami a není neobvyklé, že servisní společnosti přijdou o nabídky kvůli nižší nabídce konkurentů.

Nákladová výhoda

Velká otázka nyní zní: Jak můžeme ukázat nákladové výhody našim zákazníkům?

Tyto body mohou pomoci:

  • Ukažte jim jejich hodnotu . Zdůvodněte a poskytněte podpůrné důkazy pro vaše odhady .
  • Přemýšlejte o kreativních způsobech, jak ušetřit na výdajích.
  • Přizpůsobte si nabídku. Místo toho, abyste se drželi standardního procesu, který stojí X peněz, poskytněte levnější alternativy. Například : Místo testování celého systému navrhněte testování kritických cest.
  • Poznejte svou konkurenci . Rychlá kontrola reality toho, co jiné servisní společnosti nabízejí svým klientům za jakou cenu, je důležité, aby váš model cenového modelu zůstal relevantní pro trh.

# 2) Kvalita práce

Kvalita a množství práce jsou dvě velmi odlišné věci.

Pryč jsou dny, kdy počet vytvořených testovacích případů nebo hlášených vad byl zvyklý na ukazatele produktivity nebo kvality. Už ne.

Situace se více podobá obrázku níže:

Kvalita práce

Kvalita práce 2

A) Vím, kdy říct „NE“

Všichni jsme byli na místech, kde jsme pracovali přesčas, byli jsme v pohotovosti o víkendech, účastnili jsme se pozdních nočních nebo brzkých ranních hovorů atd. Co si však neuvědomujeme, je, že můžeme říci NE, pokud se situace bude i nadále zhoršovat. Říkám NE je jediný způsob, jak můžeme udržet kvalitu práce a náš zdravý rozum neporušený.

Přitom předem upozorněte na své obavy a obhajujte kvalitu.

Zde je situace, ve které jsem byl, a to vám může poskytnout lepší představu o tom, o čem mluvím:

Moje společnost získala nové logo a v rámci migrace ze staré společnosti na mou společnost byly naplánovány relace přenosu znalostí. My, tým 6 členů, jsme cestovali na stránku klienta. Hned první den po představení nás sdílel plán KT. Zjistil jsem, že moje jméno bylo označeno proti více modulům. Jeden z těchto modulů měl být zcela mimo můj rozsah, protože jsem o této technologii ani nevěděl; v žádném případě to neodpovídalo mým dovednostem.

Šel jsem k vedoucímu přechodu znalostí a řekl jsem mu situaci -

  • Bylo mi přiděleno příliš mnoho pracovních položek, což zase zhorší kvalitu a moji schopnost zachytit 100% v relacích.
  • Naplánované položky měly oblasti, kde by se moje dovednosti neshodovaly, a protože jsem nebyl ten správný fit, nemusel jsem během přechodu 100% rozumět.

Vedení pochopil problém a revidoval plán KT.

c ++ vs java rozdíly

Doufám, že to pomůže potvrdit, že: Pokud je něco na našem talíři, neznamená to, že to musíme všechno sníst. Zvláště ne, pokud to znamená kompromis v kvalitě.

B) Úplnost testovacího případu

Kolik z vás se mnou souhlasí, pokud se o to pokusíme vylepšit způsob psaní testovacích případů , vede to k lepší kvalitě?

Níže uvádíme několik běžných chyb, které jsou běžné ve většině testovacích případů:

Součásti testovacího případuAktuální problémŘešení
Objektivní Cíl je nejdůležitější součástí každého testovacího případu, díky čemuž jsou všechny testovací případy odlišné. Častým chybám u Objective chybí jasnost.

Stejně jako všechny testovací případy vytvořené pro jednu funkci má jeden cíl, aniž by ukazoval, jak se každý testovací případ liší.		 Cíl / účel každého testovacího případu by měl být jasný, aby vysvětlil, jaké funkce a jaké testovací podmínky budou testovány jako součást daného testovacího případu.

Stejná funkce může mít pozitivní i negativní testovací případy, takže cíl by měl být dostatečně jasný, aby ukázal rozdíl. Dobrým nápadem je poslat testovací scénář k definování cíle.
Předběžné podmínky Mnoho testerů zcela postrádá zmínku o předpokladech, nebo mnoho jednoduše zkopíruje a vloží. Kopírování vkládání vede k chybám, protože každý testovací případ se může úplně lišit od jiného.Vyhněte se chybám kopírování a vkládání a věnujte pozornost detailům.
Testovací data Toto je pravděpodobně nejvíce přehlížené pole a většina testovacích případů bude mít prázdné nebo postrádá přesnou definiciUveďte příslušná data, která se mají zadat. Někdy to nemusí být přesné.

Například: Registrace uživatele může zaregistrovat uživatele Annu nebo Johna a to by nevadilo. Definování platného názvu, který má všechny znaky a měl by mít délku 4–10, vám ale pomůže vyjasnit mnoho věcí.
ID testovacího případu Přes zjednodušenou konvenci pojmenování nebo číslování. Řekněme, že testujete přihlašovací tlačítko. ID jsou často:
TC_1_Přihlášení
TC_2_Přihlášení		Udělejte je popisnějšími:
TC_1_Login_Invalid_User
TC_2_Login_Valid_User
Referenční dokumenty Nekonzistentní kopírování a vkládání z referenčních dokumentů nebo horší, s použitím nesprávného.Vždy je vhodné zmínit správný referenční dokument se správným číslem verze, řekněme, že u některých testovacích případů by byly postoupeny oba FRS a Tech Specs, takže testovací případ v referenční části by měl zmínit oba.
Kroky testovacího případu Chybějící kroky, většinou testery, kteří aplikaci velmi dobře znají. Mohli předpokládat věci a vynechat zmínku o krocích. To způsobuje problémy podniku, recenzentům a novým testerům.Měly by být použity správné kroky a pořadí.

Abychom to shrnuli, budou-li ve fázi návrhu brány v úvahu malé detaily, bude kvalita výstupního testu mnohem lepší.

# 3) Obchodní porozumění

Toto je jeden z nejdůležitějších faktorů, které zákazníci u testerů hledají. Je však smutné, že někteří testeři se domnívají, že jejich úkolem je psát testovací případy založené na FRS a nepokoušet se porozumět podnikání.

Zkuste nejprve znát podnikání a poté se podívejte na funkčnost; můžeš představte si potřeby svého klienta více a podle toho otestujte.

Zde je příklad- FRS uvádí „Zpráva XYZ by měla být generována se 3 sloupci jako Datum, Jméno a Stav“. Následují testovací případy, u kterých skončíte, když vezmete tento požadavek v nominální hodnotě:

  • Vygeneruje se zpráva o ověření XYZ
  • Ověření sestavy má 3 sloupce jako Datum, Název, Stav
  • Ověřte data ve 3 sloupcích.

Když ale budete mít na paměti obchodní použitelnost této zprávy, možná budete muset otestovat:

  • Jaký je obchodní účel této zprávy?
  • Generuje se tento přehled každý den?
  • Kdo jsou obchodní uživatelé, kteří se dívají na tento přehled?
  • Jaký je zdroj dat pro tento přehled?
  • Měl by být přehled generován, pokud nejsou k dispozici žádné údaje?

Toto je jen jeden příklad, ale myslím, že se všichni shodneme, že lepšího testování lze dosáhnout získáním povědomí o podnikání a odborných znalostí.

# 4) Dostupnost

Ať už jste jednotlivec podporující zákazníka nebo tým, měla by se vždy kontrolovat vaše dostupnost ( Rozsah zlepšení).

Dostupností to neznamená nepřetržitou podporu. Znamená to pouze jasnou a přímou komunikaci o volném čase, alternativních plánech a dosažitelnosti a nechodícím MIA.

Níže uvádíme některé z modelů, kterými se odvětví služeb řídí:

  • Model rozšiřování zaměstnanců - Pokud pracujete v modelu rozšiřování zaměstnanců a jste výhradním zástupcem vaší společnosti, je vhodné, aby byl zákazník informován o vašich časech práce a plánovaných absencích, aby bylo možné provést nezbytná opatření.
  • Model řízených projektů - V modelu spravovaného projektu, ve kterém se vytvářejí velké projektové týmy a jsou vedeny manažery dodávek / projektů, již nezůstává odpovědnost za záložní plán prostředků odpovědností zákazníků. PM potřebuje zvládnout plánované i neplánované volno. V tomto modelu je vhodné, aby se PM pokusili předem shromáždit údaje o plánované nepřítomnosti od svého týmu a podle toho se řídit. Existují případy, kdy zákazníci požadují víkendovou podporu nebo prodloužení pracovní doby. Tyto případy by také měly být plánovány střídáním zdrojů. Tým by se měl skládat z členů, kteří se mohou v případě potřeby navzájem zálohovat. Plánované podrobnosti by měly být sdíleny se zákazníkem.

# 5) Rozsah zlepšení

To je žádoucí nejen v softwarovém průmyslu, ale všude. Přinášet zlepšení není jednodenní práce. Na rozsahu zlepšení je třeba neustále pracovat a lze jej rozdělit na 3 kroky -

Přečtěte si také=> Jak vylepšit své testovací dovednosti a porazit konkurenci

Krok 1: Identifikujte

Proveďte důkladnou studii a určete oblasti / rozsah zlepšení. Řekněme, že když budete požádáni o několikanásobné otestování stejné funkce pomocí stejného procesu, přijde čas, kdy budete mít pocit, že se chcete z projektu buď přestěhovat, nebo změnit způsob jeho testování. Takto se přinášejí vylepšení, když se nudíme našimi stávajícími metodami, myslíme na změny a zlepšování .

Krok 2: Přineste zlepšení

Pokud by se věci děly ručně, dalo by se zkuste zautomatizovat pár věcí . Když řeknu automatizaci, nemusí to vždy znamenat nákup automatizovaného nástroje.

jak najdu klíč zabezpečení sítě

Cituji situaci:

Byl jsem součástí týmu pro testování databáze. Naše každodenní práce zahrnovala běh stejných skriptů SQL několikrát za den s jinou sadou parametrů. Když jsme zahájili projekt, byli jsme s těmito kroky v pořádku, ale nakonec jsme systému porozuměli lépe a mysleli jsme si, že stejné skripty SQL lze spustit jako součást uložených procedur místo toho, aby někdo ručně aktualizoval parametry a prováděl je.

Krok č. 3: Vyhodnoťte zlepšení

Kdykoli je implementován nový proces, budete muset zajistit, aby fungoval podle očekávání a neměl žádné vedlejší účinky. Rozšíření dřívějšího příkladu, zavedení uložených procedur, zkontrolujte, zda jsou výstup z nově vytvořeného automatizovaného způsobu a výstup z ručního způsobu stejné.

Druhou částí je sledování výhod po určitou dobu, abyste si byli naprosto jisti, a výsledky poskytněte svým klientům. V našem projektu jsme klientům ukázali zkrácení doby provedení testu o 30%, což následně snížilo náklady.

Závěr

Na závěr bych chtěl zmínit, že každý z nás má vrozené vlohy a každý má svůj vlastní jedinečný pracovní styl, a to bylo jen několik tipů, které podle mého názoru mohou našim klientům nabídnout lepší zážitek ze služeb.

O autorovi: Tento úžasný článek napsal člen týmu STH Priya R. Pokud nám chcete napsat a podělit se o své zkušenosti, prosím dejte nám vědět zde .

Doufám, že se vám tento článek líbil a shledal vás poučným! Dejte nám vědět, pokud máte jinou zkušenost ke sdílení.

Doporučené čtení

^