A szoftvertesztelés kiszervezése ma sok cégnél természetes lépés, a jó szoftvertesztelési partner megtalálása viszont korántsem az. A rossz választás pedig drága: nem csak a számla lehet magas, hanem sokba kerül a kiesett idő, a gyenge minőség, az elpazarolt bizalom, és az a felismerés, hogy fél év után újra kell kezdeni a keresést.
A legtöbb rossz döntés megelőzhető néhány jól feltett kérdéssel, még az ajánlatkérés előtt. Az alábbi szempontrendszer ehhez ad támpontot. A cél nem egy adott cég ajánlása, hanem hogy a döntés tudatos és összehasonlítható legyen.
Egy jó partner ugyanis két dolgot ad egyszerre: szakmai minőséget és megbízhatóan, gyorsan bevonható kapacitást. A kérdések egy része az elsőre világít rá, másik része a másodikra, arra a gyakorlati kockázatra, ami akkor merül fel, amikor külső embert vonunk be a projektbe.
Mikor érdemes külső szoftvertesztelési partnert bevonni?
Nem minden helyzet kíván külső partnert. De van néhány jellemző jel, amikor érdemes elgondolkodni rajta:
- Kapacitáshiány. A fejlesztőcsapat gyorsabban termel, mint amennyit a jelenlegi keret ellenőrizni tud.
- Hiányzó szakértelem. Speciális tesztelési terület (teljesítmény, biztonság, automatizálás) belső tudás nélkül.
- A független, elfogulatlan nézőpont igénye. Amikor a menedzsmentnek objektív képre van szüksége a minőségről, nem a fejlesztőcsapat érthető, de nem elfogulatlan optimizmusára. Hogy miért nem elég, ha „a fejlesztő majd leteszteli”, arról a Miért nem szabad a fejlesztőnek a saját kódját tesztelnie? cikkben írtunk részletesen.
A 10 kérdés, amit érdemes feltenni
Ezt a tíz kérdést érdemes kéznél tartani a következő ajánlatkérésnél. A válaszok együtt sokat elárulnak a leendő partnerről.
1. Kizárólag teszteléssel foglalkoznak, vagy csak mellékesen? Ha a tesztelés csak egy a sok szolgáltatás közül, könnyen másodrendűvé válik. A fókusz szakmai mélységet és elkötelezettséget jelez.
2. Mennyire függetlenek a fejlesztéstől? Ha ugyanaz a cég fejleszt és tesztel, ugyanaz az érdek húzódik mindkét oldalon. A fejlesztéstől való függetlenség a tárgyilagos minőségi kép feltétele, még akkor is, ha a tesztelő egyébként a megrendelő csapatában, annak folyamataiban dolgozik.
3. Milyen mély a szakmai tapasztalatuk, és kérhető-e valós referencia? Nem a logók száma számít, hanem hogy hasonló méretű és kockázatú projekteken dolgoztak-e már. Érdemes konkrét, beszélhető referenciát kérni.
4. Milyen tesztelési szinteket és típusokat fednek le? Manuális és automatizált tesztelés, teljesítmény, biztonság, integráció. Fontos, hogy a lefedettség a projekt valós kockázataihoz igazodjon, ne csak ahhoz, amihez a partner ért.
5. Milyen gyorsan tudnak releváns tapasztalatú tesztelőt biztosítani? Egy belső tesztelő felvétele a hirdetéstől a felmondási időn át gyakran két-négy hónap, miközben a projekt már most ég. Egy felkészült partnernél ugyanez inkább napok vagy hetek kérdése. A reakcióidő önmagában komoly üzleti érték.
6. Szakmailag előszűrik a jelölteket, vagy csak önéletrajzot továbbítanak? Egy általános IT staffing cég a kulcsszavak alapján szűrt önéletrajzokat küldi tovább, a szakmai megítélés terhe pedig a megrendelőn marad. Egy valódi tesztelési partner maga is szakmailag előszűri és próbára teszi a jelölteket, mielőtt bemutatja őket.
7. Áll-e a kihelyezett tesztelő mögött senior csapat és tudásbázis? Ha a bevont tesztelő elakad egy speciális technológiával vagy tesztfeladattal, van-e mögötte céges háttér és tapasztalt kollégák, akiktől azonnal segítséget kérhet? Ez az egyik legnagyobb különbség egy magányos szabadúszóhoz képest.
8. Mi történik, ha a bevont tesztelő kiesik? Betegség, tartós szabadság vagy felmondás esetén tud-e a partner zökkenőmentes, betanított pótlást biztosítani, hogy a projekt ne álljon le? A folytonosság garanciája sokszor többet ér, mint egyetlen kiváló, de pótolhatatlan ember.
9. Igazítható-e a létszám és az együttműködési modell a projekt fázisaihoz? Fel lehet-e bővíteni a csapatot például az átvételi teszt (UAT) előtt, majd csökkenteni a lecsengéskor, anélkül hogy a megrendelőnek a saját állományát kellene átszerveznie? És rugalmas-e a pénzügyi konstrukció: fix áras, ráfordítás alapú vagy hibrid? Erről bővebben a T&M vagy fix projekt? Melyik tesztelési modell mikor működik jobban? cikkben.
10. Hogyan illeszkednek a meglévő folyamatokba, és hogyan látszik a munkájuk? A jó partner nem külön szigetként dolgozik: beépül a megrendelő csapatába, annak eszközeibe és folyamataiba, miközben a minőség állapotát átláthatóan és érthetően jeleníti meg a döntéshozók felé. A cél nem a párhuzamos adminisztráció, hanem hogy a vezetés bármikor lássa, hol tart valójában a projekt.
Piros zászlók, amikre érdemes figyelni
Néhány jel, amely óvatosságra int, függetlenül attól, milyen meggyőző az ajánlat:
- Csak hibaszámot ígérnek, üzleti érték helyett. Aki a talált hibák mennyiségével méri magát, nem biztos, hogy a valódi kockázatra figyel.
- Csak önéletrajzot küldenek, szakmai előszűrés nélkül. Ilyenkor a jelölt megítélésének teljes terhe a megrendelőre hárul.
- Nem kérdeznek vissza az üzleti célokra. Aki nem érti, mi a tét a megrendelő oldalán, az nem is tud a lényegre koncentrálni.
- Átláthatatlan riportálás és homályos árazás. Ha már az ajánlati fázisban nehéz világos képet kapni, az együttműködés alatt sem lesz jobb.
- A „100%-ban hibátlan” ígérete. Komoly partner ilyet nem ígér, mert tudja, hogy nem létezik. A minőségbiztosítás a kockázat csökkentéséről szól, nem a nulla hibáról.
Hogyan értékeljük a válaszokat?
A válaszokat nem külön-külön, hanem együtt érdemes nézni. Egyetlen tökéletes válasz még nem tesz jó partnerré valakit, és egyetlen bizonytalanság sem feltétlenül kizáró ok. A minta a fontos: az a partner, amelyik következetesen a projekt kockázatára és a megrendelő üzleti céljaira figyel, jó eséllyel az együttműködés alatt is így viselkedik majd. Az pedig, amelyik már az ajánlati fázisban kitér a konkrét kérdések elől, ritkán lesz átláthatóbb később.
Egy példa, hogyan világít rá a tíz kérdés a különbségre. Képzeljünk el egy döntéshozót, aki három, nagyjából azonos árú ajánlatot kap, és papíron mindegyik „teljes körű szoftvertesztelést” ígér. A kérdések feltevése után kiderül: az egyik cég valójában fejlesztőcég, amelynél a tesztelés mellékszolgáltatás; a másik csak önéletrajzokat továbbít, szakmai háttér és pótlási garancia nélkül; a harmadik viszont pontosan elmondja, milyen gyorsan tud embert adni, ki áll mögötte, és hogyan illeszkedik a meglévő folyamatokba. Az ár ugyanaz volt. A kockázat nem.
Összegzés
A jó tesztelési partner nem feltétlenül a legolcsóbb. Az, aki a legjobban csökkenti az üzleti kockázatot: szakmailag mély és független, gyorsan és megbízhatóan ad kapacitást, és akkor is a projekt érdekét nézi, ha az kellemetlen hír.
Ezt a tíz kérdést és a piros zászlók listáját érdemes kéznél tartani a következő ajánlatkérésnél. Nem azért, hogy egy adott cég mellett szóljon, hanem hogy a döntés tudatos és összehasonlítható legyen, olyan, amit fél év múlva sem kell megbánni.


