Software und Spezifikationen
Wer mit Software zu tun hat, hat sicher auch schon mit Spezifikationen zu tun gehabt. Wissentlich oder auch unwissentlich, als Auftraggeber, als Entwickler, als Verkäufer oder Käufer oder zumindest als Nutzer. Werfen wir also einen genaueren Blick auf diesen Begriff, speziell natürlich aus der Sicht des Softwaretestens.
Was sind Spezifikationen
Spezifikationen beschreiben die Anforderungen an eine Software. Sie geben vor, was die fertige Software können soll und evtl. wie sie es können soll. Sie sind somit Richtlinie für die Entwicklung und gleichzeitig auch für das Testen.
Einerseits schaffen sie ggf. einen rechtlichen Rahmen zwischen Auftraggeber und Softwarehersteller, im Idealfall sind sie auch das von allen Entscheidungsträgern sowie Stakeholdern gemeinsam anerkannte und hoffentlich auch gleich interpretierte Ziel, was die Software letztendlich liefern können soll. Andererseits sind sie Vorgabe für die Programmierung, ein Leitfaden, an dem sich die Entwickler orientieren können. Gleichzeitig sind sie auch Quelle für die Planung des Testens der Software. Kann der Code das, was versprochen wurde (Verifikation)? Stimmt das in Entwicklung befindliche Produkt (sowie in weiterer Folge natürlich das Endprodukt) mit der Absicht überein (Validierung)? Somit sind Spezifikationen die Grundlage für die Planung des Softwareprojekts und gleichzeitig für die Planung des Testens, noch bevor auch nur eine Zeile Code geschrieben wurde.
Wo finde ich diese?
Diese Spezifikationen können sich aus vielen unterschiedlichen Quellen speisen, wobei zwischen expliziten (z.b. in Verträgen festgehaltenen) und impliziten (=mitzubedenkenden) Spezifikationen unterschieden wird:
- Verträge zwischen dem Auftraggeber und dem Softwareunternehmen, die festlegen, was die fertige Software können muss [explizit]
- Intern festgehaltene Anforderungen, z.B. in Bezug auf Sicherheit oder Usability der zu erschaffenden Software [explizit]
- Normen und gesetzliche Regelungen, die rechtliche Rahmenbedingungen für spezifische Branchen schaffen (z.B. Bankwesen, Versicherungssektor, Gesundheitssektor etc.) [implizit]
- Dokumente, die die Software für Stakeholder oder Entscheidungsträger beschreiben (und damit z.B. auch den Rahmen dafür bilden, was Vertrieb und Marketing den Kunden versprechen dürfen) [implizit]
- Produktbeschreibungen im Vertrieb [implizit]
- Erwartungen von Kunden an die Software (was ist in diesem Bereich Standard, der z.B. auch von Konkurrenzprodukten geboten wird?) [implizit]
- u.v.m.
Welche Folgen haben Abweichungen der Software von den Spezifikationen
- Bei vertraglich vereinbarten Spezifikationen ist eine Abweichung Gegenstand der Gewährleistung. Je nach Schwere sind mehr oder weniger aufwändige Nachbesserungen nötig, es kann auch zu Pönalen und zum Rücktritt vom Vertrag kommen.
- Bei internen Spezifikationen hängt es von der Schwere der Abweichung ab: ist die Abweichung gering, so hat das vermutlich wenig Gewicht, ist sie groß, so kann es sein, dass die Software nicht die in sie gesetzten Erwartungen erfüllt. Gesetzlich vorgeschriebene Anforderungen sind jedenfalls zu erfüllen.
- Bei Software, die öffentlich verkauft wird (die also jeder und jede kaufen kann, z.b. über einen Webshop), müssen a) gesetzliche Vorgaben jedenfalls erfüllt werden und b) ist es eine Frage der Gewährleistung, dass die versprochenen Leistungen auch geboten werden.
Welche Bedeutung haben Spezifikationen fürs Testen?
Spezifikationen geben uns einen wichtigen Anhaltspunkt für das Testen. Sie helfen uns bei der Testplanung, noch bevor es den Code überhaupt gibt. Sie dienen als Quelle für Testideen während des Testens. Und sie helfen uns zu verstehen und zu beurteilen, ob ein bestimmtes Verhalten der Software einen Fehler darstellt oder nicht. Dabei geben sie uns Anhaltspunkte dafür, was wir unbedingt testen sollten, niemals aber dafür, wie wir testen sollen, denn wer weiß schon, auf welche Ideen Kunden bei der Nutzung der Software kommen können?
Wie kann man sich Spezifikationen gut erarbeiten?
Es macht keinen Sinn, Spezifikationen von a bis z lesen zu wollen. Das führt leicht zu Ermüdung und birgt die Gefahr, dass wesentliche Informationen nicht hängen bleiben. Vielmehr gilt es “aktiv” zu lesen. Aber was heißt das? Aktives Lesen bedeutet, Informationen für sich selbst zu ordnen und zu organisieren. Dabei gilt es, zunächst einen Überblick zu gewinnen (z. B. Inhaltsverzeichnisse, Überschriften, Abstracts), den Gesamtsinn zu erfassen und in weiterer Folge nach spezifischen Begriffen zu suchen.
Testen bedeutet, Fragen an die Software zu stellen, und genau so kann man die Sache auch angehen. Notiere dir Fragen, die für dich relevante Informationen generieren und suche nach den Antworten, halte sie fest und ergänze sie schrittweise. Kategorisiere die Informationen, arbeite mit Mindmaps, befülle die so erstellten Kategorien nach und nach. Hinterfrage das neu gewonnene Wissen und verknüpfe es mit bekanntem Wissen. Erkläre das, was du dir erarbeitet hast, anderen Personen, um dein eigenes Verständnis zu überprüfen. Und nicht zuletzt: Speichere die Informationen und organisiere sie.
Georg Brandenburg
QA Engineer
Georg Brandenburg hat Volkswirtschaftslehre studiert und zusätzlich einen Master für systemischisches Coaching. Seit 2016 ist er Betreiber eines Co-Working-Spaces in Klagenfurt am Wörthersee (Businesscampus Ehrenhausen). Er ist leidenschaftlicher Community Manager und außerdem begeisterter Podcaster (MutmacherInnen).