Wie sich die Anforderungsspezifikation auf das Testen auswirkt

Wie sich die Anforderungsspezifikation auf das Testen auswirkt

Man könnte meinen, dass es nach 20 bis 30 Jahren globaler Erfahrung mit IT-Projekten völliger Unsinn wäre, ein Projekt ohne eine durchdachte, umfassende und von den Endnutzern akzeptierte Anforderungsspezifikation (auch als Lastenheft bekannt) zu starten. Und doch passiert es selbst heutzutage erstaunlich oft, dass die Entwicklung und Einführung von IT-Systemen entweder ohne diese Dokumentationen beginnt – oder sogar komplett ohne sie abläuft.

Sorgfältig entworfene und nach einem einheitlichen Standard modellierte Geschäftsprozesse sowie die dazugehörigen funktionalen Beschreibungen gewährleisten nicht nur die qualitativ hochwertige Umsetzbarkeit der Entwicklung, sondern bilden auch das Fundament für die Tests.

Sie bilden also auch das Fundament des Testens. Ohne sie geraten Projekte in der Regel aus der Bahn, was zu ineffizienten Abläufen, hohen Kosten, minderwertiger Qualität sowie unzufriedenen Nutzern und Auftraggebern führt. Im nächsten Artikel zeigen wir detailliert, wie eine hochwertige Anforderungsspezifikation und der Testfallkatalog miteinander verknüpft sind.

Die Rolle der Anforderungsspezifikation (auch bekannt als Lastenheft)

Um die Verbindung zwischen Anforderungen und Tests aufzuzeigen, müssen wir uns zunächst mit der Bedeutung der Anforderungsspezifikation vertraut machen. Diese Spezifikation ist ein Dokument, das (im Idealfall) unmissverständlich festlegt, welche Eigenschaften die zu entwickelnde Software haben soll:

• Prozesse
• Funktionalitäten
• Eigenschaften
• Designelemente
• Leistungsparameter
• Zukünftige Nutzergruppen und ihre Zugriffsrechte

Es ist wichtig zu betonen, dass eine Anforderungsspezifikation ein standardisiertes Geschäftsdokument mit einer klar definierten Struktur, Formulierung und Inhalt ist. Das bedeutet nicht, dass technische Anforderungen ausgeschlossen sind, jedoch legt das Format den Fokus eher auf den geschäftlichen Nutzen und die erwarteten Geschäftsabläufe statt auf technische Details.

Dokumentation von Softwareanforderungen

Die standardisierte und mehrstufige Dokumentation von Anforderungen ist unerlässlich, um spätere Missverständnisse und Lücken zu vermeiden. Dank moderner Methoden und Tools stehen uns heute verschiedene standardisierte Anforderungsspezifikations-Methodologien zur Verfügung. Entscheidend ist, dass die von uns gewählten Planungs-, Analyse- und Spezifikationsverfahren auf die zu modellierenden Systeme und Geschäftsprozesse abgestimmt sind. Zudem spielen das Fachwissen unserer Analysten sowie die verfügbaren Modellierungswerkzeuge eine wesentliche Rolle.

Eine bewährte Vorgehensweise besteht darin, zunächst sowohl die End-to-End- als auch die internen Systemprozesse zu definieren, die die finale Lösung unterstützen muss. Diese Prozesse sollten dann schrittweise in immer detailliertere Abschnitte unterteilt werden, wobei die erwarteten Geschäftsabläufe als Leitfaden dienen.

Die so entstehende mehrstufige Architektur (Prozess, Schritt, Funktion) bildet das Grundgerüst der Anforderungsspezifikation. Diese Architektur erzwingt strukturell eine kompromisslose Durchdachtheit und Dokumentation der Anforderungen. Neben den funktionalen Erwartungen müssen wir uns auch mit den Ergebnissen der einzelnen Prozesse und den geschäftlichen Entitäten befassen. Der Grund dafür ist, dass alle Eigenschaften erfasst werden, die im späteren Betrieb genutzt werden sollen.Zudem ist es unerlässlich, klar zu definieren, welche Benutzergruppen unterschieden werden sollen, welche Berechtigungen und Zugriffsrechte sie erhalten und welche möglichen Einschränkungen für sie gelten sollen.

Einsatz von Tools zur Anforderungsspezifikation

Für die vollständige Durchführung der Anforderungsspezifikation lohnt es sich, Modellierungswerkzeuge und spezialisierte Softwarelösungen einzusetzen, die folgende Aspekte unterstützen:

• die eingesetzte Anforderungsspezifikations-Methodologie unterstützen,
• die strukturierte Organisation von Informationen erleichtern,

sowie die Kommunikation und Zusammenarbeit zwischen Projektteammitgliedern, Fachexperten und Entscheidungsträgern fördern.

Erstellung der Anforderungsspezifikation

Um das Thema vollständig zu verstehen, ist es ratsam, sich zunächst einen allgemeinen Überblick über den Ablauf eines typischen IT-Projekts zu verschaffen. Unabhängig von der gewählten Projektmethodik – sei es ein klassisches, bewährtes Modell oder eine als moderner geltende agile Vorgehensweise – können die grundlegenden Prozessschritte nur in einer bestimmten Reihenfolge durchgeführt werden.

Sobald geschäftliche Anforderungen entstehen, folgt die Abfolge der Schritte:

Anforderungsspezifikation,

2. fejlesztés

3. tesztelés.

Természetesen előfordulhat, hogy párhuzamosan több iteráció is zajlik, így a gyakorlatban az egyes lépések tulajdonképpen folyamatosan történnek. Azonban, ha egy jól körül határolt funkcióhalmazra (pl.: sprintre) tekintünk, ez a sorrend fixnek mondható.

Az igények pontos meghatározása

Mind a fejlesztés, mind a tesztelés ugyanazon követelményspecifikáció alapján történik. Ez az, ami miatt nélkülözhetetlen, hogy az abban szereplő igények, precízen, hiánytalanul, egymással értelmezhető logikai összefüggésben kerüljenek megfogalmazásra és dokumentálásra. Máskülönben a projekt zátonyra fut, nehéz helyzetbe hozva ezzel a megrendelőt.

A specifikációk módosítása

Csodálatos dolog lenne, ha minden esetben képesek lennénk már a projekt kezdeti, igényspecifikációs szakaszában elképzelni, megfogalmazni és dokumentálni egy nagyvállalati alkalmazás teljes működését.

Ettől azonban a valóság távol áll.

A gyakorlatban egy projekt alatt rendszeresen változó és újonnan felmerülő üzleti igényekkel találkozunk. Ezen felmerült „új” elvárások megvalósítása érdekében rugalmasan kell tudnunk kezelni a követelményspecifikáció változásait. Ehhez egy megfelelő, jól definiált belső igénykezelési folyamat és eszköztámogatás szükséges, amely lehetővé teszi a változások követését, kezelését, az üzleti szereplők és a projekttagok (pl.: szoftver minőségbiztosító csapat) informálását. Garantálva ezzel a következetes és hibamentes projektműködést.

Wie sich die Anforderungsspezifikation auf das Testen auswirkt

Talán a legtöbbször felmerülő és legtöbb megrökönyödést kiváltó kérdés, amit a szakmai találkozókon kapunk az az, hogy mi alapján írjuk a teszteseteket. Egészen pontosan nem is a kérdés okozza a meglepődésbe burkolt aggodalmat, hanem az arra adott válaszunk, ami így hangzik: a követelményspecifikáció alapján.

Ekkor a fennakadás leggyakoribb oka, hogy a megrendelő sok esetben nem rendelkezik megfelelő követelményspecifikációval, markánsan megnehezítve ezzel a tesztelésre való felkészülést. A leggyakoribb hiányosságok, amivel találkozunk az alábbiak:

• nincs, vagy hiányos a specifikáció
• nem friss, vagy nem tartalmazza a bevezetés óta módosított funkciók leírását a dokumentum
• több helyen, több fájlban megtalálható a specifikáció, így nincs központi nyilvántartás és verziókezelés
• már nincs ott a kolléga, aki írta, így nem lehet értelmezni
• elavult más rendszerekre vagy dokumentumokra való hivatkozásokat tartalmaz
• már lejárt a licence a vállalati tervező/elemző alkalmazásnak, emiatt nem elérhetőek benne bizonyos adatok
• és így tovább…

Jó hír, hogy ha ilyen szituációban találjuk magunkat, feloldva ezt a rossz érzést általában rögtön az első pillanatba jelezzük, hogy természetesen a tesztesetek írása, a tesztkészlet létrehozása ennek hiányában is elvégezhető, csak az elvártnál jóval több energiát, időt és ráfordítást vehet igénybe. Ennek oka, hogy a tesztesetek írásához szükséges rendszerismereti, folyamati tudást más forrásokból kell összegyűjteni.

De mit is gyűjtünk össze pontosan, mi az, amit szeretnénk kiolvasni egy specifikációból és miért ez számunkra a legmegfelelőbb dokumentum?

A tesztelési stratégia összeállítása

Első lépésben a specifikációt megvizsgálva, a tesztelési folyamatunk nagy egészére vonatkozó információkat igyekszünk összegyűjteni. Körbejárjuk a főbb folyamatok, az alkalmazás alapvető funkcionalitását, megértjük az alkalmazás alapvető üzleti hasznát. Ezek alapján megkezdjük a tesztelés nagyvonalú tervezését. Megismerve a folyamatok és funkciók számát, bonyolultságát, a kapcsolódó rendszerek tulajdonságait egy tesztelési tervet alakítunk ki, amely a projekttervhez, annak ütemezéséhez kell, hogy igazodjon.

A tesztkészlet lefedettsége, terjedelme

Ismereteink bővülésével egyre inkább a teljesség lefedésére törekszünk, az egyes folyamati, logikai vagy üzleti kérdések, hiányosságok és hibák feltárása mellett. Ezt követően a specifikáció részleteit felhasználva a mélyebb és precízebb, a folyamatok apróbb, kevésbé gyakori lefutási ágaira, eseteire koncentrálunk, létrehozva ezzel a tesztesetek halmazát, a tesztkészletet.

A tesztadatok kinyerése a követelményspecifikációból

1. Miután megismertük a folyamatokat, a funkciók működését, megvizsgáljuk az azok futtatásához, végrehajtásához szükséges üzleti entitásokat, pontosabban azok attribútumait.
2. Ezen tulajdonságokat összegyűjtve és rendszerezve felépítjük a tesztadatok összességét, a variánsokat.
3. Meghatározzuk, hogy egy általános tesztelési körben a tesztesetek futtatásához adott tesztadatból hány variánst, milyen darabszám mellett kell létrehozni a tesztelési kör hiánytalanul végrehajtható lehessen.

A követelményspecifikáció és a tesztuserek

Ami a tesztelés során a tesztuser, az az éles működésben a végfelhasználó. Emiatt a tesztesetek és tesztadatok összegyűjtésével egyidejűleg a felhasználók típusát és azok jogosultságait is gyűjtjük rendszerezzük a későbbi, (a valóságnak leginkább megfelelő) szerepkörhelyes tesztelés lefuttatásához. Szerencsés esetben rendelkezésünkre áll a specifikáció részeként, vagy annak csatolmányaként egy szerepkör-jogosultság mátrix, ami egyértelműen bemutatja a rendszer használatának felhasználói feltételeit, amivel kiegészítve a tesztkészletet már szinte nyert ügyünk is van.

A teszteset-követelmény összerendelés

Amennyiben az igényspecifikáció alapján képesek voltunk egy számunkra megfelelő tesztkészletet és a futtatáshoz szükséges tesztelési forgatókönyveket összeállítani, azokat betöltjük egy tesztmenedzsment alkalmazásba.

E célra célszerű olyan alkalmazást választani, ami „ismeri, érti és kezeli” a követelményt, mint entitást.

Ezzel támogatva a későbbi tesztelési metrikák precízebb, üzleti szemléletű kimutatását. Ennek segítségével ugyanis a tesztelés későbbi fázisaiban minden teszteset követelményhez kapcsolható, azzal relációban áll, permanens információt biztosítva az alkalmazás aktuálisan működő funkcióinak üzleti lefedettségéről. Természetesen egy specifikációban megjelenő funkciót több teszteset fed le, és egy teszteset is reprezentálhat több funkciót, a lényeg, hogy az egyes tesztelési körök eredményeit képesek leszünk a specifikációra, annak terjedelmére vetíteni, valós üzleti képet adva ezzel a projekt aktuális sikerességéről, a funkciók tényleges használhatóságáról.

Összegzés és ajánlások

Talán ez a pár sor elegendő volt arra, hogy nagyvonalúan bemutassuk a követelményspecifikáció és a tesztelés között fennálló erős kapcsolatot. A projekt sikerességének kulcsa tehát a pontosan definiált folyamatokban és követelményekben, valamint azok precíz adminisztrációjában rejlik, lehetővé téve ezzel a ráépülő tevékenységek, a fejlesztés és a szoftverminőségbiztosítás végrehajthatóságát.

Amennyiben felkeltettük érdeklődését, további információra lenne szüksége, vegye fel velünk a kapcsolatot!