Hogyan válassz szoftvertesztelési partnert? 10 kérdés, amit érdemes feltenni ajánlatkérés előtt

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.

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

T&M vagy fix projekt? Melyik tesztelési modell mikor működik jobban?

Amikor egy cég külső tesztelési partnert von be, az egyik legkorábbi kérdés nem szakmai, hanem pénzügyi: milyen konstrukcióban dolgozzunk együtt? A válasz sokszor a beszerzési reflexből születik: „adjatok egy fix árat, hogy tudjam, mennyibe kerül”. Érthető igény, de nem mindig a legjobb döntés. A fix ár és a másik klasszikus modell, a T&M (Time and

Miért buknak el a nagyvállalati IT projektek?

A nagy IT projektek kényelmetlenül nagy arányban nem úgy végződnek, ahogy tervezték. Csúsznak, túllépik a büdzsét, vagy elkészülnek ugyan, de nem hozzák a várt üzleti értéket. Ez nem néhány szerencsétlen eset, hanem évtizedek óta ismétlődő minta. Amikor egy ilyen projekt megbukik, a szervezet ösztönösen egyetlen bűnöst keres: egy rossz technológiai döntést, egy hibás rendszert, egy

A legtöbb tesztstratégia már a projekt elején elbukik

Amikor egy projekt a végén minőségi gondokkal küzd, a reflex szinte mindig ugyanaz: a tesztelést okoljuk. „Nem teszteltek eleget”, „átcsúszott egy hiba”, „a QA nem fogta meg”. Kényelmes magyarázat, mert a folyamat legvégére mutat, oda, ahol a baj láthatóvá vált. Pedig a valódi ok gyakran nem a tesztelésben rejlik. Maga a tesztstratégia dönti el jó

Scroll to Top

Elérhető tesztelőink

Nézze meg szakértőink profiljait, tapasztalatát és kompetenciáit, és találja meg a projektjéhez illő szakembert.

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.