Veröffentlicht: November 1, 2023
Vermeiden Sie diese verletzungsverursachenden Probleme beim Softwaretesten
Ich kann die Antworten schon hören. Es hört sich an, als würden Hunderte von Tastaturen gleichzeitig klappern, um mir zu sagen, dass QA-Ingenieure und Softwaretester ihre Arbeit hauptsächlich am Computer erledigen. Dies stellt kaum einen gefährlichen Zustand dar und erfordert sicherlich keine große körperliche Anstrengung. Es ist in der Tat unwahrscheinlich, dass diese Personen berufsbedingte körperliche Verletzungen erleiden.
Tatsächlich birgt eine Karriere am Computer einige Risiken. Überanstrengung der Augen, wiederholter Stress und andere ergonomische Probleme im Zusammenhang mit längerer Computernutzung sind möglich. Es gibt auch psychische Probleme im Zusammenhang mit Stress und Arbeitsanforderungen. Wir wissen, dass Arbeitgeber Unterstützung und Ressourcen für das Wohlergehen ihrer Mitarbeiter bereitstellen sollten.
Aber das ist nicht wirklich der Grund, warum wir heute hier sind. Werfen wir einen Blick auf einige alternative Verletzungen, unter denen Ihre Qualitätssicherungs- und Testteams leiden könnten.
Release Déjà Vu
Das Ergebnis eines banalen Entwicklungsprozesses. Wenn Ihr Unternehmen nicht innovativ ist oder Ihre Entwickler keine neuen Funktionen und Verbesserungen erkunden, kann dies zu einem Gefühl des „Schon alles schon erlebt“ führen. Eine Möglichkeit, Ihre Entwickler und Tester negativ zu beeinflussen, besteht darin, ihnen die Herausforderung zu nehmen und ihre Arbeit eintönig zu machen. Das führt zu schlecht motivierten und unzufriedenen Teammitgliedern. Wenn Ihre Releases sich wiederholen, kann dies auch zu Selbstgefälligkeit bei den Teammitgliedern führen, die wahrscheinlich Mängel übersehen, da sie diese bereits gesehen haben. Die Kultur der Innovation und Verbesserung, die gestärkt werden sollte, wird dazu beitragen, Releases einzigartiger zu machen und gleichzeitig die Softwarequalität aufrechtzuerhalten.
Vom Entwickler verursachte blaue Flecken auf der Tastatur
In vielen Organisationen sind die Entwickler- und Testteams teilweise uneins. Die beiden Rollen sind unauflöslich miteinander verbunden, ja sogar voneinander abhängig. Entwickler sind diejenigen, die die Apps erstellen. Tester sind diejenigen, die sicherstellen, dass sie für den Endbenutzer ordnungsgemäß funktionieren. Diese beiden Persönlichkeiten geraten bei ihrer Arbeit in isolierten Umgebungen oft aneinander. Entwickler lehnen Testerempfehlungen häufig ab, da sie Tests nicht als Teil des SDLC betrachten. Dies führt zu Spannungen zwischen beiden Teams, da die Entwickler der Ansicht sind, dass die Qualitätssicherung ihren Fortschritt behindert. QA-Mitglieder müssen in der Lage sein, Entwicklern „Nein“ zu sagen. Als letzte Verteidigungslinie zur Fehlererkennung vor der Produktion ist eine Arbeitsbeziehung zwischen beiden Teams unerlässlich.
Burnout beim Skripttest
Das ist der Fluch aller Tester. Einige Unternehmen verwenden Skripttests als einzige Testmaßnahme. Dies ist ein Problem, da bei skriptbasierten Tests die Tester einfach dem geschriebenen Skript folgen müssen, ohne dass analytische oder kritische Überlegungen erforderlich sind. Es handelt sich um eine restriktive Art des Testens, die wenig zur Gesamtqualität der getesteten App beiträgt. Es verstärkt nur die gleiche Wiederholung. Es spiegelt auch nicht die tatsächliche App-Nutzung wider, da Menschen bei der Interaktion mit ihren Apps keine Skripte befolgen. Ihre Verwendung ist chaotisch und unvorhersehbar. Einige Organisationen unterstützen nicht nur skriptbasierte Tests, sondern weigern sich auch, ihre Prozesse zu erweitern und zu verbessern. Das würde für jeden Tester zum Ausfall führen.
Voraussetzung: Brain Freeze beim Lesen
Die Herausforderung für Tester ergibt sich in dieser Hinsicht aus den Anforderungen an das Testen selbst. Anforderungsdokumente sind langwierig und voller spezifischer Details und technischer Sprache, die für einige Mitglieder des Testteams verwirrend oder schwer verständlich ist. Einige Anforderungsdokumente sind noch schlimmer. Unklar, mehrdeutig und inkonsistent – diese Aspekte erschweren das Verständnis der Frage. Anforderungen ändern sich häufig, was die Komplexität erhöht, wenn man versucht, mit den Änderungen Schritt zu halten. Es reicht aus, um selbst dem hartgesottensten und erfahrensten Tester das Gehirn einzufrieren. Stakeholder und Entwickler sollten lernen, klare Anforderungsdokumente zu verfassen und die Kommunikationswege offen zu halten.
Tatsächlich sind technische Berufe und Büroarbeiten nicht besonders verletzungsanfällig. Sicherlich muss man nicht befürchten, aus großer Höhe zu fallen oder von einer Klinge verbrannt oder aufgeschlitzt zu werden. Das heißt aber nicht, dass es nicht auch einige reale und spekulative Gefahren gibt, wie wir oben beschrieben haben. Die wirklichen Gesundheitsprobleme, etwa die Art und Weise, wie Menschen ihre Stühle benutzen oder ob sie sich ausreichend bewegen oder nicht, sind ziemlich gut dokumentiert, und es werden ständig weitere Untersuchungen durchgeführt. Die zufälligen Verletzungen im Zusammenhang mit Arbeitsstress, schlechter Kommunikation und dem Fehlen klar definierter Prozesse mögen albern erscheinen, sind aber auf jeden Fall eine Untersuchung wert.
Um darüber zu erfahren, lesen Sie unbedingt unseren Leitfaden: Digital.ai Continuous Testing, klicken werden auf dieser Seite erläutert.
Auch interessant
Automatisierungs-Frameworks jenseits von Appium & Selenium
Ein Team veröffentlicht eine React Native App und eine Marketingkampagne…
Was eine großartige Testplattform ausmacht: Eine Checkliste für Enterprise-Teams
Jedes QA-Team in einem Unternehmen stößt irgendwann an dieselbe Grenze. A…
5 Herausforderungen bei der Skalierung von Tests, die jedes regulierte Unternehmen kennt (und wie man sie löst)
Die Skalierung der Testautomatisierung stellt jedes große Unternehmen vor eine Herausforderung. Aber…