Problémák a tesztelés - a vizsgálati eredmények
Fordítás: Olga Alifanova
A tanfolyam Rapid Software Testing adok diákok ezt a gyakorlatot: kérem őket, hogy mindent felsorolni, a saját szemszögéből, megnehezíti vagy késlelteti a tesztet. A válaszok általában azonos típusú - Rendszeresen hallani ugyanazt a változatot (például ilyen válaszok megtalálhatók, például a vita a Stack Exchange). Általában ez olyasmi, mint az alábbi listából:
- Én csak tesztelés, és a dolgozó több fejlesztő (vagy egyik tesztelők, és csapatunk egy csomó fejlesztő).
- Én nagyon rövid ideig. Folyamatosan jönnek az új változathoz, és kiadjuk hetente vagy kettő.
- A termék (ek), amely azt teszteli, hogy nagyon nehéz önmagában.
- Két termék egységek (vagy különböző termékek), a beállított kölcsönös függőségek.
- Látom, hogy számos probléma merül fel, mert ezek a kapcsolatok - egy kis változás egy modulban vezethet katasztrófához a másik.
- Úgy vélem, hogy annak érdekében, hogy elkapni ezeket a hibákat kell üldözni teljes regresszió minden új építésű.
- Próbálom megbirkózni a feladattal, az automatikus teszt, de bonyolítja a termék megnehezíti teszt automatizálás - „horgony” az automatizált vizsgálatok minimális vagy hiányzik, és a gyakori változások termék bonyolítja automatizálás támogatást.
- Az Autotest támogatás elég sokáig tart, és nincs ideje, hogy vizsgálatokat, hogy szeretne megszabadulni.
- Mindez nagyon fárasztó, de próbálok megbirkózni.
És egy plusz, hogy a fenti,
- A cég, ahol dolgozom, azt mondja, hogy dolgozik Agile
- Amellett, hogy a kéthetes ismétléseket, valójában használjuk maximum pár kapcsolatos gyakorlatok Agile-megközelítés - mint általában, a napi dulakodás találkozó vagy kanban fórumon.
És a hab a tortán:
- Coming vizsgálatra épül nagyon instabil. A rendszer hatálya alá tartozik a legalapvetőbb füst-vizsgálatok, és azt kell várni, és / vagy újjáépíteni helyett épít, hogy részt vesz a közvetlen üzleti.
Hogyan tudom elemezni ezeket a megfigyeléseket?
Mi lehet tekintenek rájuk, mint egy teszt a problémát, de azt is nézd meg őket másképp - a vizsgálati eredményeket.
A vizsgálati eredmények nem azt mondják, hogy valami nincs jól vagy rosszul. Ezek adatszolgáltatásra vonatkozó döntéshozatal, értékelés, és hasonló dolgok. Részesülő emberek a vizsgálati eredmények, dönt arról, hogy probléma van a termékben, és mik azok, amit szükséges, hogy megtudja, milyen döntéseket hoz. Ez bevonását igényli élők, értékeli a különböző tényezők, és számos lehetséges értelmezések.
Ahogyan ez a helyzet autotests és egyéb vizsgálati eredmények, fontos figyelembe venni a teljes spektrumát a lehetséges okokat és értelmezését meta-eredmény vizsgálat - kapcsolatos észrevételeit a vizsgálat. Ha nem tesszük, azt kockáztatjuk, kimaradnak fontos kérdések, amelyek veszélyeztetik a minősége mind a vizsgálatok és maga a termék.
Dzherri Vaynberg könyvében „Perfect szoftver és egyéb illúziói tesztelés” megjegyzi, hogy amit kapunk eredményeként - mindenekelőtt az információkat. Ha a vizsgálat szerint Jerry - az információgyűjtés céljából annak továbbítása a döntéshozók, nem hagynak maguk után potenciálisan fontos megfigyelés.
A tesztelés során gyakran szembesülnek a különböző problémákat. Azonban ahelyett, hogy kezelni őket, mint egy probléma vizsgálatára, mi is gondolunk rájuk, mint a tünetek a termék vagy projekt problémák - a problémákat, hogy a tesztelés megoldani.
Például, ha a tesztelő szenved, mert a számos fejlesztő, vagy ha a tesztelő nem elég ideje kipróbálni - ez a teszt eredményét. Gyakran ez az érzés okozza, hogy a programozók generál sok összetett problémákat, hogy a tesztelő egyszerűen nem tud megbirkózni velük egyedül. Az összetett, hogyan és minőség - a kapcsolat az ember és valami mást. Önmagában a komplexitás nem feltétlenül jelent problémát, szemben az emberek reakcióiról is. Néz hogyan reagálnak az emberek szubjektív komplexitás és a kockázatok, tanulhatunk sokat.
- Akár segítünk a tesztelők, kollégái, hogy tisztában legyenek a kockázatok - különösen a „fekete hattyú” - általában társított összetettsége?
- Amikor az emberek elképzelni a kockázatokat, hogy azok odafigyelni rájuk? Vajon pánik, vagy csak figyelmen kívül hagyja, abban a reményben, hogy minden rendben lesz? Vagy valami más?
- Vajon az emberek reagálnak nyugodtan és gyakorlatiasan? Vajon felismeri a bonyolultsága a termék, akár próbál megbirkózni vele?
- Ha bonyolítja a termék vagy folyamat nem lehet csökkenteni, úgy ez is valamit annak érdekében, hogy a termék / folyamat könnyebb megérteni?
- Előfordul, hogy a programozók kódot írni, vagy olyan gyorsan változnak, hogy egyszerűen nincs ideje, hogy kitaláljuk, mi folyik valójában?
- Ha valaki úgy véli, hogy a csapat több kell tesztelők, miért gondolja? (Én már megvitattuk ezt a kérdést néhány évvel ezelőtt)
Hogyan lehet megtalálni a választ ezekre a kérdésekre? Ennek egyik módja -, hogy egy közeli pillantást az eredményeket és a meta-vizsgálati eredményei:
- Úgy véli, hogy valaki a csapatban, hogy a tesztelés nehéz vagy időigényes? Ki?
- Miért gondolja így, milyen feltételezések oda vezetett, hogy az ötlet?
- Ez nem romlik teszt lefedettség, amit teszterek töltenek sok időt, hogy tanulmányozza a helyét és a design a hibákat? (Én írtam ezt a problémát, mielőtt).
- Akár vizsgálatának eredménye következetes mintát hibák?
- Szisztematikusan, hogy ezek a hibák és minták meglepetést programozók?
- Vajon a kis kód megváltozik nagy vagy körmönfont probléma?
- Nos, ha a programozók megérteni a belső kapcsolatokat a terméket? Szükség van-e a termék kapcsolata, vagy el lehet kerülni?
- Ne fejlesztők tett lépéseket, hogy megakadályozza vagy megelőzésére kapcsolatos problémák interfészek és interakciók?
- Ha az automatikus ellenőrzés nehéz létrehozni és fenntartani, azt mondja, ha a helyzet a szakmai tudással a tesztelők, mint egy automatizálás felületet, vagy a skála a vizsgálatok? Vagy ez azt jelzi, valami mást?
- Ne akadályozza instabil épít mély teszt?
- Lehetséges, hogy értelmezze az instabil épít annak jeléül, hogy a termék olyan sok komoly probléma, hogy megtalálja még egy felületes vizsgálat?
- Ha egymás utáni instabil épít végre van egy stabil -, ahogy az valójában stabil?
Talán a választ ezekre a kérdésekre, akkor több kérdést.
- Mivel ezek a problémák fenyegetik a siker a termék rövid és hosszú távon?
- Ha a vizsgálat feltárja, szisztematikus mintát a hibák és a kapcsolódó kockázatok, így a csapat ezt az információt?
- Ne programozók kötelesek kizárólag biztosítani a kódot, vagy azok köteles a kódot, hogy garantálják, hogy a kód azt teszi, amit kell (és nem csinál, amit nem), hogy mennyit tud? Hogy őszinte programozók inkább a második lehetőség?
- Lehetővé teszi, hogy valaki a programozók, hogy fenntartsák időzítés / munka mennyiségét, hogy valójában nem tud eleget tenni?
- Lehet programozók és tesztelők ellenállni a rájuk kiszabott idő és munka mennyisége, ha ezeket a feltételeket növeli az élelmiszer vagy a projekt kockázatok?
- Ne hallgass azokra az aggályokra az üzleti csapat? Tudják, a kockázatok által talált tesztelők és a fejlesztők? Amikor a fejlesztőcsapat utal meglévő kockázatokat, figyelembe, hogy a vezetés / üzleti megfelelő lépéseket válaszként erre?
- Függetlenül attól, hogy a csapat dolgozik a kényelmi üzemmód, vagy a termék / projekt komolyan zúzott összetettsége, a belső viszonyok, a törékenység és a nehézségeket, amelyek kívül esnek a fejlesztési / tesztelési lehetőségek megbirkózni velük?
- A csapat dolgozik Agilis, Agile kiáltvány megfigyelése? Lehet, hogy a „rugalmasság” használják a rakomány kultusz - és a leletek gyakorlatban csak elfedik a butaság a projekt?
A tesztelők gyakran hiszik, hogy a feladat -, hogy keressen, vizsgálja meg, és jelentsd a hibákat a szoftver teszt alatt. Általában ez a helyzet, de egy pillantást a vizsgálat rendkívül korlátozott. A termék - minden, ami valaki tett: a program követelményeinek, a diagram, specifikáció, ütemezése, prototípus, folyamat, gondolat ... Tesztelés kereshet információt bármely olyan termék, ha kapnak kellő figyelmet.
Egyrészt, a felsorolt problémák a cikkben korábban, már meg komoly teszt problémákat. Talán így van, de ez nem minden, ami mögöttük. Ha felidézzük a meghatározása Dzherri Vaynberga - „testing - gyűjteménye információt továbbítani kell a döntéshozók, a” kiderül, hogy mindaz, amit talál, és figyeljük a tesztelési folyamat - ez a teszt eredményét.