Was ist Smoke Testing?

Smoke Testing hat nichts mit mechanischen Rauchtests zu tun.
Foto: kiadtisuk seedapan – shutterstock.comSind Sie auch schon im IT-Umfeld über den Begriff “Smoke Test” gestolpert und haben sich gefragt, was eigentlich ein “Rauchtest” mit moderner Softwareentwicklung zu tun hat?Smoke Testing – DefinitionIn der Halbleiterbranche wird nach Fertigstellung eines Schaltkreises erstmalig eine Spannungsquelle angeschlossen, um ein Bauelement in Betrieb zu nehmen. Überlebt nun ein Halbleiter das Einschalten des Stromkreises und fängt nicht an abzurauchen, wurde der erste und initiale Test – also ein Smoke Test – bestanden. Im Gegenzug kann es vorkommen, dass ein Halbleiter nicht ordnungsgemäß konzipiert wurde und das Bauelement nach Anlegen der Betriebsspannung zu schmoren anfängt und somit in Rauch aufgeht.Innerhalb der Softwareentwicklung wurde nun der Begriff Smoke Test für rudimentäre, also initiale und grundlegende, Tests einer Programmfunktion übernommen.Smoke Tests für Software – AnwendungsfälleSmoke Testing wird bei agiler Softwareentwicklung automatisiert und in allen Stufen des Entwicklungsprozesses durchgeführt. Am Anfang der Entwicklung stehen einzelne Programmeinheiten (Units) zur Verfügung. Durch das Smoke Testing dieser Units wird die grundlegende Funktionalität durch die sogenannten Unittests gewährleistet. Erst wenn alle Programmfunktionen fehlerfrei durchlaufen, kann die Software automatisiert zusammengebaut und somit erstellt werden.Nach dem Bauen der Software steht erstmalig die gesamte Programmfunktionalität zur Verfügung, die mit weiteren Tests überprüft werden muss. In dieser Stufe der Softwareentwicklung wird von den sogenannten Integrations- oder End-to-End-Tests gesprochen. Auch hier ist das anfängliche Smoke Testing sehr sinnvoll, da aufwändige Tests nur dann laufen müssen, wenn die Software grundlegend funktionsfähig ist.Automatisierte Tests bilden hierbei die Grundlage für effiziente Softwareentwicklung. Denn bei jedem Fehlverhalten muss die Software neu erstellt werden. Bereits gelaufene Tests sind hinfällig und müssen wiederholt werden. Manuelles (händisches) Testen sollte nur in Ausnahmesituationen durchgeführt werden, denn die immer gleichen, stupiden Testabläufe verschwenden wertvolle Ressourcen und sind letztendlich fehleranfällig, weil wenig motivierend. Die für das automatisierte Testing eingesetzten Programme prüfen nun grundlegende Funktionen wie z.B.:Öffnet sich eine Webseite?Kann eine Verbindung zu einem System aufgebaut werden?Ist ein Windows Fenster vorhanden?Erst wenn alle grundlegenden Fragestellungen positiv beantwortet wurden, macht weiteres, umfangreicheres Testing Sinn.




Smoke Test – BeispielEin Beispiel für einen einfachen Smoke Test mit der Fragestellung “Kann eine Verbindung zu einem System aufgebaut werden?” kann mit einem “ping” realisiert werden. Das auf vielen Betriebssystemen vorhandene “ping” Kommando wird verwendet, um einen Host (Hostname oder IP-Adresse) anzupingen, um ein “Lebenszeichen” von diesem System zu erhalten. Das nachfolgende Beispiel zeigt eine erfolgreiche Antwort mit dem “ping google.com” Kommando:>ping google.comPing wird ausgeführt für google.com [142.250.181.238] mit 32 Bytes Daten:Antwort von 142.250.181.238: Bytes=32 Zeit=16ms TTL=118Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0(0% Verlust)Das nachfolgende Beispiel zeigt eine erfolglose Antwort mit dem “ping bla.com” Kommando:>ping bla.comPing wird ausgeführt für bla.com [38.127.92.75] mit 32 Bytes Daten:Zeitüberschreitung der Anforderung.Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1(100% Verlust)Der Weg hin zu einem Test-Automatismus mit aussagekräftigen Testreports gestaltet sich relativ einfach, denn intelligente Testframeworks (Robot Framework) bieten gute Möglichkeiten zur Integration dieser Kommandos.Lesetipp: Softwaretesting – Installationen und Funnktionstests automatisierenSmoke Tests bestehen somit aus einer Vielzahl von unterschiedlichen Fragestellungen, um neue oder geänderte Software grundlegend testen zu können. (bw)10 Dinge, die Software-Entwickler austicken lassenProdukt- & ProjektmanagerGanz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. Dazu hat auch David Fox von devRant eine Meinung: “Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die ‘Besitzer’ von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen.”ChefsGenau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. “In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben”, merkt Fox an.RecruiterSoftwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden – dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: “Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe – selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt – etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen.”DokumentationGibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: “Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation – aber selber machen wollen sie es nicht.”MeetingsMeetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift ‘I survived another meeting that should have been an email’ erhältlich.Coworking SpacesMit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden – insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen – sagen zumindest die Zahlen von devRant. David Fox erklärt: “Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten – oder eben das Gegenteil davon.”KollegenSelbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis.VorstellungsgesprächeWenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: “Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht”, so Fox.Fehler & BugsSoftwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: “Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an.”Quality AssuranceDie Quality Assurance (QA) – oder Qualitätssicherung – ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. “Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten.”