qualitycommunications

WinRunner Stiefkind von Mercury?

noreply@blogger.com (Christian Walter) — Thu, 14 Jul 2005 19:05:00 +0200

Das funktionale Testautomatisierungstool WinRunner der Firma Mercury ist in einem Ranking der besonderen Art enthalten. Auf der Website www.dreckstool.de können unzufriedene Benutzer von Softwaretools ihren Unmut Luft machen. WinRunner steht derzeit auf Platz 77 von 143 Softwaretools mit 68 Meldungen (im Jahr 2004: 335, 2002: 110, erstmals 2001: 33). Eine relativ hohe Anzahl gemessen am Verbreitungsgrad der Software gegenüber anderen Tools, wie z.B. Microsoft Outlook.

Woher stammt diese Unzufriedenheit der sonst so zuverlässigen und gut zu bedienenden Tools von Mercury? Handelt es sich hierbei um überzogene Wunsch-Anforderungen, die nicht erfüllt wurden? Liegt es an einem Mißvertändnis, was Tools dieser Art leisten können? Oder liegt es daran, dass Testautomation auf dieser Ebene im Allgemeinen mit Schwierigkeiten verbunden ist und daher unbedingt Spezialisten hinzugezogen werden sollten? Oder ist die Umfrage nicht repräsentativ genug?

Der ideale Tester

noreply@blogger.com (Christian Walter) — Wed, 13 Jul 2005 22:21:00 +0200

Wie im vorhergehende Artikel von mir beschrieben, steigt die Nachfragen nach Testspezialisten. In diesem Artikel erfahren Sie, welche Anforderungen der ideale Tester erfüllt.

Was verbirgt sich hinter dem Begriff Tester? Oft wird dieser Begriff als Verallgemeinerung für eine Vielzahl von Rollen verwendet. Die Aufgaben sind rollenabhängig organisatorischer, fachlicher oder technischer Natur. Die Projektgröße bestimmt, wie die Rollen auf die Projektmitarbeiter verteilt werden. Kleinere Projekte neigen dazu, viele Rollen in einer Person zu vereinen, während bei großen Projekten Spezialisten eingesetzt werden.

Die folgende (unvollständige) Liste stellt eine Sammlung von etablierten Rollen dar: Testmanager, Teilprojektleiter Qualitätssicherung, Testautomatisierer, Testcase-Designer, Testsystem-Administrator, technischer Tester, fachlicher Tester, Testdatenadministrator, Defectsmanager, Performance-Tester, usw.

Jede dieser Rollen beinhaltet spezifische Anforderungen, die sich nicht verallgemeinern lassen. Fachliche Tester benötigen das entsprechende fachliche Wissen, oft werden daher Mitarbeiter der Fachabteilungen dafür eingesetzt. Dies führt leider oft zu einem Konflikt, wenn neben der normalen Arbeit auch noch die Projektmitarbeit gefordert wird. Nicht immer können die Mitarbeiter freigestellt werden.

Technische Tester haben technisches Know-How, z.B. Kenntnisse bestimmter Betriebssysteme, Datenbanksysteme, Anwendungssoftware, Kommunikationsprotokolle, etc. Für Black-Box-Tests sind keine Programmierkenntnisse gefordert, die wiederum für White-Box-Tests (z.B. Modultests mit JUnit) unabdingbar sind. Testmanager und Teilprojektleiter beherrschen Kommunikation und Koordination. Test-Case-Designer benötigen gute analytische Fähigkeiten.

Die Anforderungen sind weit diversifiziert und orientierten sich an einer oder mehreren Rollen, die eine Person ausführen soll. Den idealen Tester gibt es also nicht. Einige Eigenschaften sollten jedoch alle hier genannten Rollen erfüllen: eine gewisse Affinität für die Fehlersuche und genaues Arbeiten sowie eine hohe Frustrationstoleranz sollte jeder Mitarbeiter der Qualitätssicherung mitbringen.

Nachfrage nach Testspezialisten wächst

noreply@blogger.com (Christian Walter) — Sun, 10 Jul 2005 17:29:00 +0200

Die Stellenanzeigen der wichtigen Tageszeitungen haben wieder an Umfang zugenommen. Neben den allgemeinen Stellenangeboten ist bei Unternehmen die Nachfrage nach Spezialisten im Bereich Testing gewachsen.

Vor wenigen Jahren war die Qualitätssicherung eher lästiger Bestandteil von Software-Projekten. Einer von vielen Gründen dafür war die Tatsache, dass die Qualitätssicherung erst nach der Entwicklung stattfand und nicht mit konstruktiven Maßnahmen von Beginn im Projekt integriert war.

Mit der Erkenntnis, wie wichtig die Qualitätssicherung bzw. das Thema Qualität ist, ist auch die Nachfrage nach Spezialisten gewachsen, die mit modernen Vorgehensweisen einen echten Mehrwert für jedes Projekt darstellen. Das führt dazu, dass sich ein schärferes Stellenprofil abzeichnet. Gesucht werden keine Programmierer mit Nebenjob Tester, sondern erfahrene Testmanager, die ggf. auf Erfahrungen aus der Softwareentwicklung zurückgreifen können. Neben Vorgehensweisen und Techniken, werden Kenntnisse und Erfahrungen der Projekt-/Testplanung verlangt. Ergänzt werden diese Anforderungen durch gezieltes Know-How von marktüblichen Testwerkzeugen.

Dieser als positiv zu bewertende Trend wird durch weitere Initiativen unterstützt. So versucht das International Software Quality Institute (iSQI) mit Seminaren und Zertifizierungen einen Standard im Gewirr von unterschiedlichen Terminologien und Ausbildungsständen zu etablieren.

Beide Trends lassen darauf schließen, dass Qualität einen höheren Stellenwert in Software-Entwicklungsprojekten bekommt und gleichzeitig seitens Spezialisten eine höhere Qualität an Leistungen erbracht wird, quasi eine Qualitätssteigerung in der Qualitätssicherung.

Die zehn goldenen Regeln für Softwarequalität

noreply@blogger.com (Christian Walter) — Thu, 23 Jun 2005 21:46:00 +0200

Herr Hubert Keller vom Institut für angewandte Informatik am Forschungszentrum Karlsruhe erhebt die folgenden zehn goldenen Regeln für Softwarequalität (Quelle: Computer Zeitung Nr. 22, 30 Mai 2005, S. 17):

Saubere Analyse der Kundenanforderungen, Festlegung der Begriffswelt und Sprache des Kunden
Erfassung der Sytem- und Architektur-relevanten Requirements
Projektion der Systemarchitektur und –anforderungen in die Zukunft der Systemweiterentwicklung zur Absicherung der Tragfähigkeit der Architektur
Iterative und inkrementelle Entwicklung eines Systemmodells mit klarer Konzentration auf die logische Sicht und Konsistenzprüfung
Detaillierung des Modells (technische Realisierungsnähe)
Umsetzung in Porgrammcode mit Werkzeugen der Model Driven Architecture
Festlegung von Prozess und Vorgehensmodell mit Rollen und Verantwortlichkeiten
Fachliche Schulung der Mitarbeiter, um in abgesicherten Verfahren technisch fit zu sein
Frühe Beachtung von Usability und von Security Aspekten
Permanente Reviews und Überprüfung in der Gruppe sowie Nachweis der Anforderungserfüllung, Test- und Konfigurationsmanagement

Vergolden würde ich diese Regeln nicht, da sie deutliche Zeichen vom aktuellen Forschungs-/Wissenstand hinsichtlich der Vorgehensweisen zeigen (z.B. der Hinweis auf Model Driven Architecture). Um das Prädikat „goldene Regel“ zu bekommen, sollten diese Regeln allgemeiner formuliert sein.

Eines machen die Regeln deutlich: Softwarequalität wird sehr stark durch konstruktive Maßnahmen bestimmt und Qualität bezieht sich nicht allein auf die Fehlerfreiheit, sondern auch weitere Kriterien z.B. hinsichtlich der Güte der Architektur, der Sicherheit und Usability.

Performance-Testing mit JUnit

noreply@blogger.com (Christian Walter) — Sun, 6 Mar 2005 21:26:00 +0100

Mit Performance-Testing kann das Lastverhalten einer Applikation unter Laborbedingungen geprüft werden. Dazu bieten Hersteller von Testtools eigene Werkzeuge, deren Einsatz größere Investitionen zur Folge haben. In diesem Artikel wird der Einsatz von JUnit als Alternative aus dem Open Source Bereich untersucht.

Moderne Software-Architekturen bestehen aus mehreren Applikationsebenen/-schichten. Für den Rahmen dieses Artikels ist es ausreichend, die folgenden drei Schichten zu betrachten:

Präsentationsschicht (Präsentationslogik, realisiert durch Thin- oder Fat-Client)
Applikationsschicht (zentrale, serverseitige Anwendungslogik)
Datenbank oder sontige Anbindung von Back-End-Systemen

Ziel des Performance-Tests ist es, das Lastverhalten der Applikation zu ermitteln, bzw. zu prüfen, ob die Anforderungen an die Applikation erfüllt werden. Das bezieht sich auf alle serverseitigen Komponenten. Eine funktionale Korrektheit muss für diese Tests angenommen werden, sie ist nicht Bestandteil der Tests.

Lasttesttools bestehen mindestens aus den folgenden drei Bausteinen:

„Skripte“: in Testskripten werden die Business-Cases definiert (durch Programmierung oder Aufzeichnung)
Lastgeneratoren: mittels eines Lastgenerators werden die Business-Cases ausgeführt und greifen parallel auf die Applikation zu. Dazu bedienen sie sich dem Konzept der „Concurrent User” oder „Virtual User“. Jedem Skript wird ein virtueller User zugeordnet, der sich den Zustand der Applikation bis zur Beendung eines Skript-Durchlaufs merkt und ggf. mit speziellen Testdaten versorgt.
Monitore: an verschiedenen Stellen der Architektur (Messpunkte) werden Daten abgegriffen und ermöglichen eine Auswertung (Anzahl Threads, Prozessor-Auslastung, Laufzeiten, etc.)

Die bekannten Hersteller von Testtools (Mercury International, IBM Rational, Compuware, um nur wenige zu nennen) warten mit einer Reihe von sehr komfortablen Funktionen auf. Die Testskripte werden in der laufenden Anwendung aufgezeichnet und in einer Skript-Sprache zur weiteren Bearbeitung dargestellt. Aufgezeichnet wird das Kommunikationsprotokoll, z.B. die HTTP-Requests bei einer klassischen Web-Applikation. Bereits hier ist es wichtig zu beachten, welches Protokoll verwendet wird, da jedes Tool nur ein begrenztes Angebot an Protokollen unterstützt.

Die Lastgeneratoren werden durch eine Zentrale gesteuert, die die Einbindung weiterer Rechner zur Erzeugung der Last ermöglicht. Dazu gehört auch die automatische Verteilung der Testskripte auf diese Rechner. Bei der Planung von Lasttests ist ein ausreichendes Sizing der Lastgeneratoren sicherzustellen, damit genügend Rechenleistung für die virtuellen User bereitsteht.

Die Monitore gehören nicht zum Lieferumfang und müssen zusätzlich zum Basispaket erworben werden. Wie bei den Protokollen gilt hier: für die Auswahl eines Lasttesttools muss darauf geachtet werden, dass alle Architekturkomponenten durch Monitore abgedeckt sind.

Die Bedienung ist in der Regel sehr komfortabel gestaltet und ermöglicht auch Nicht-Programmieren einen schnellen Einstieg. Nachteilig wirken sich die hohen Kosten aus, die für die Basis-Anwendung, zusätzliche Monitore sowie die virtuellen User (abhängig von der Anzahl) anfallen.

Für die Alternative, dem JUnit-Framework, fallen keine Lizenzkosten an. Dafür wartet dieses Framework nicht mit einer komfortablen Benutzeroberfläche auf. Die Skripte werden in einer Entwicklungsumgebung (z.B. Eclipse) in der Progammiersprache Java implementiert. Sie können nicht aufgezeichnet werden. Allerdings besteht die Möglichkeit, Test-Skripte der Modultests wiederzuverwenden, so dass der Programmieraufwand minimiert werden kann. Ein weiterer großer Unterschied zeigt sich hier: die Skripte sind nicht von einem Kommunikations-Protokoll abhängig, sondern liegen eine Schicht darüber. Dieser Unterschied wird zum Vorteil, wenn die Applikation mithilfe eines Fat-Clients bedient wird, der auf ein weniger verbreitetes Protokoll zurückgreift. Dieses Argument wird jedoch mit der Zeit geschwächt, da die Tool-Hersteller darauf eingehen und die Palette unterstützter Protokolle erweitern.

Als Lastgenerator wird JUnitPerf verwendet. Die Testszenarien weren ebenfalls im Java-Quellcode erstellt. Eine Verteilung auf weitere Rechner wird nicht unterstützt und muss mit anderen Mitteln realisiert werden.

Für das Monitoring ist etwas mehr Aufwand zu betreiben. Die Laufzeitmessung sollte mindestens innerhalb der Test-Skripte durch ein standardisiertes Logging erfolgen. Standardisiert insofern, als dass eine spätere automatische Auswertung auf Basis von MS Excel o.ä. erleichtert wird. Zusätzliche Messpunkte sind sinnvoll und sollten mit Unterstützung durch die Entwicklung in der Applikation platziert werden. Für die Messung der Systemauslastung, Speicherverbrauch, etc. kann z.B. der System- oder Application-Server-Monitor verwendet werden (sollte jedes Betriebssystem/ jeder Application-Server mitliefern).

Zusammenfassend betrachtet stehen die hohen Kosten beim Einsatz käuflicher Tools dem geringen Komfort und dem manuellen Aufwand beim Einsatz von Junit gegenüber. Dieser Aufwand ist nicht zu unterschätzen, da er mit zusätzlichen Kosten verbunden ist. Sollten nicht weitere Faktoren, wie z.B. die unterstützten Protokolle die Entscheidung beeinflussen, so kann man von einer Bauchentscheidung sprechen. Man sollte sich auf keinen Fall durch die optisch sehr gut gestalteten käuflichen Tools beeinflussen lassen. Die Qualität des Junit-Ansatzes steht der ersten Alternative nach praktischen Erfahrungen in nichts nach.

Site-Feed

noreply@blogger.com (Christian Walter) — Sun, 13 Feb 2005 21:41:00 +0100

Dieses Blog verfügt über ein Site-Feed, dass Sie über die folgende URL bekommen:

http://softwarequalitaet.blogspot.com/atom.xml

Einen RSS Feed bekommen Sie hier: