Wir haben für Sie eine Übersetzung eines Artikels von Dmitry Yarygin, QS-Ingenieur mit Erfahrung in großen Projekten der Welt seit mehr als 8 Jahren, einem Lehrer des Kurses für mobile QA-Ingenieure bei OTUS, vorbereitet. Ist es interessant, sich in diese Richtung zu entwickeln? Wir laden Sie zu einer kostenlosen zweitägigen intensiven "Einführung in die Automatisierung des Testens mobiler Anwendungen auf Selen und Appium" ein.

Qualitätsprüfung. Wer ist dafür verantwortlich? Viele Jahre lang war die einzige Antwort auf diese Frage in meinem Kopf. Natürlich ein QS-Ingenieur! Schließlich gehöre ich selbst zu den QS-Ingenieuren.

Ich weiß mit Sicherheit, wie wichtig es ist, die Qualität eines Softwareprodukts zu testen, dessen Markteinführung geplant ist. Ich habe jedoch einige Muster festgestellt, die beim Testen auftreten. Sie ließen mich über den gesamten Testprozess nachdenken und darüber, wie er verbessert werden könnte.

Sollten Entwickler ihren Code testen?

Danke, dass Sie gefragt haben. Wenn Sie ein Entwickler sind, kennen Sie alle Feinheiten und Fallstricke in Ihrem Code, oder Sie wissen zumindest mehr über Ihren Code als ein QS-Ingenieur. Sie kennen Ihren Code weit und breit und wissen, wo das Problem auftreten kann.

Wenn Sie wissen, wo der Problembereich liegen könnte, informieren Sie den QS-Techniker. Ja, er selbst wird es zu einem bestimmten Zeitpunkt finden, aber Sie kennen die Anwendungsarchitektur immer noch besser. Tester sind dankbar, wenn Sie ihnen sagen, wo sie Probleme erwarten können.

Wir sind QS-Ingenieure, wir werden uns darauf konzentrieren und es mit Tests abdecken, damit Sie weniger besorgt sind. Alle zusätzlichen Informationen, die Entwickler möglicherweise bereitstellen, sind eindeutig von Vorteil.

Unit-Tests sind definitiv etwas, was Entwickler tun sollten, dies ist ihr Verantwortungsbereich. Unit-Tests helfen dabei, unnötige Fehler und unnötige Berichte darüber zu vermeiden. Vermeiden Sie den Fehler besser, bevor der Code beim Testerteam eingeht, oder?

Ein paar Worte zum Testen Ihres eigenen Codes. Ich glaube, dass Entwickler zumindest Rauchprüfungen ihres Codes durchführen sollten. Es sind keine umfangreichen Tests erforderlich. Überprüfen Sie einfach, ob der Code für einen Eingabedatensatz geeignet ist, und geben Sie ihn an das Testerteam weiter, damit dieser bereits weiter daran arbeitet.

Wenn der Code zu diesem Zeitpunkt noch nicht funktioniert, warum sollte er dann überhaupt der Qualitätssicherung übergeben werden? Sie erhalten Dutzende von Fehlermeldungen, obwohl Sie bereits wissen, dass es Probleme gibt - dies verlangsamt nur den Entwicklungsprozess.

Wir haben den Fehler verpasst. Sind die Tester schuld?

Ja und nein. Jedes Mal, wenn ein Fehler festgestellt wird, insbesondere in der Produktion, haben Sie und Ihr Team etwas zu besprechen. Es gibt mehrere Gründe, warum der Fehler erst zu diesem Zeitpunkt aufgetreten ist:

1. Der Ort, an dem der Fehler auftrat, hatte für Tester nie Priorität. Sehr oft dachte niemand an den Fehler, der bei der Produktion auftrat. Dies ist das Ergebnis mangelnder Kommunikation zwischen Entwicklern und Testern. In Bezug auf die Frage, wie wichtig es ist, einen Bereich zu überprüfen, wurde kein gegenseitiges Verständnis erzielt. Klassische Beispiele für diese Nachlässigkeit sind Leistungs- und Sicherheitsprobleme. Wenn Sie wissen, dass diese Bereiche für Ihre Anwendung von entscheidender Bedeutung sind, teilen Sie dies dem Team mit.
2. Die Qualitätssicherung verfügt nicht über die erforderlichen Kenntnisse auf dem getesteten Gebiet. Dies ist auch ein häufiges Problem. Die Entwickler haben die Funktion geschrieben und automatisch angenommen, dass die Qualitätssicherung versteht, wie sie von und nach funktioniert. Annahmen zu treffen war noch nie eine gute Strategie, um die Qualität eines ernsthaften Projekts zu analysieren. Wenn Sie einen wichtigen Aspekt sehen, stellen Sie sicher, dass der Haupt-QS-Ingenieur und sein Team ihn auch sehen und verstehen. An diesem Schritt führt kein Weg vorbei.
3. Entwickler kümmern sich nicht wirklich darum. Wir sind alle Menschen. Und wir alle haben ein Leben außerhalb der Arbeit. Einige Entwickler arbeiten hart und hart daran, ein qualitativ hochwertiges Produkt zu entwickeln. Sie sprechen mit Testern, informieren sie über mögliche Probleme und dergleichen. Und es gibt Entwickler, die sich nicht darum kümmern. Sie verwenden dieses Produkt nicht jeden Tag und verstehen seine Bedeutung nicht. Für sie ist dies nur eine Nebenaufgabe, die erledigt und vergessen werden muss. Einfach ausgedrückt ist es ihnen egal, dass das Endprodukt von unzureichender Qualität ist.
4. QS-Ingenieure kümmern sich nicht darum. Hier ist die Kehrseite der Münze. Nicht alle Tester interessieren sich für das Projekt. Einige müssen nur die Tests beenden, einen schönen Bericht erstellen und ihn vergessen. Eine qualitativ hochwertige Testabdeckung stört sie nicht, sie möchten nicht mit Entwicklern kommunizieren. Sie können Fehler diskutieren, aber solche Tester finden sie möglicherweise einfach nicht wichtig oder registrieren sich sogar.
5. Tester sind nicht qualifiziert genug. Ein weiteres Problem kann darin liegen, dass Tester einfach nicht qualifiziert genug sind, um Ihre Anwendung zu testen. Zum Beispiel müssen Sie Penetrationstests durchführen, und alles, was Ihnen zur Verfügung steht, ist ein Team von Testern, die nur manuelle Tests durchführen können. In diesem Fall wissen sie einfach nicht, wie sie sich ihm nähern sollen. Hier müssen Sie sich entweder auf Entwickler verlassen oder mehr auswählen
   Qualifizierte QS-Ingenieure, die genau wissen, wie man diesen speziellen Bereich testet.
6. Mangel an Nutzerforschung. Entwickler wissen, wie man eine Anwendung erstellt, und QS-Ingenieure, wie man sie bricht. Was ist mit Benutzern? Benutzer sind echte Menschen, die Ihre Anwendung in der realen Welt verwenden. Sie werden es nicht brechen. Es ist nur so, dass sie alle unterschiedlich sind und unterschiedliche Ziele haben, aber sie alle möchten sie mit Ihrer Anwendung erreichen. QS-Ingenieure können sich an den Fehler gewöhnen und feststellen, dass er selten auftritt. Daher spielt er keine große Rolle. Der Benutzer wird dies nicht tolerieren. Wenn Ihre Anwendung abstürzt, müssen Sie sie im nächsten Schritt entfernen und dann nach einer Alternative suchen. Das ist die Realität. Die Untersuchung einer Benutzergruppe und / oder eine Testbenutzergruppe sind zwei strategisch wichtige Dinge.
7. Schlechte Organisation des Kommunikationsprozesses. Idealerweise benötigen Sie einen einfachen Fehlersortierungsprozess, mit dem Sie Fehler aus der Qualitätssicherung bewerten (oder zumindest richtig einstufen) und an Entwickler weitergeben können, damit diese ihre Arbeitslast verstehen. Bei Missverständnissen sollten sich Tester und Entwickler immer in der Lage sein, sich innerhalb weniger Minuten oder Stunden zu nähern und dieses Problem zu lösen. Wenn dieser Prozess nicht etabliert ist und beide Seiten es nicht eilig haben, nach der Ursache des Missverständnisses zu suchen, wird nichts Gutes daraus. Beide Seiten werden Aktivitäten imitieren, aber in Wirklichkeit werden sie beide in einer Sackgasse sein und auf jemanden warten, der kommen und die Situation auf magische Weise lösen kann. Dies ist grundsätzlich der falsche Ansatz.
8. Nicht genug Tester. Eine Anwendung kann komplex sein und erfordert möglicherweise Tests auf mehreren Plattformen und Browsern. Nur ein paar QS-Ingenieure für diese Aufgabe reichen möglicherweise nicht aus. Ziehen Sie in Betracht, mehr Mitarbeiter einzustellen oder die vorhandenen Ressourcen so zu verteilen, dass der Schwerpunkt verstärkt auf Tests liegt.
9. Entwickler sind überlastet. Um Sie herum sind vielleicht ideale und hochqualifizierte Spezialisten, aber sie arbeiten unter ständigem Stress und niemand kann ihnen helfen. Ja, sie stehen unter Druck und haben einfach keine Zeit, mit dem QS-Team zu sprechen. Dies ist ein sehr häufiges Problem und einer der Hauptgründe, warum die Software von schlechter Qualität ist.
10. Qualität steht nicht im Rampenlicht. Betrachten Sie auch dieses Szenario. Hier und da gab es ein paar kleinere Fehler. Keiner von ihnen ist kritisch. Benutzer mögen die Anwendung jedoch nicht. Bewertungen sind schlecht. UX ist unterdurchschnittlich. Und warum? Ja, weil niemand daran gedacht hat, ein Qualitätsprodukt zu schaffen. Die Entwickler haben ihre Arbeit gemacht, die Tester haben ihre eigene gemacht, aber niemand hat den Qualitätskontrollprozess selbst verfolgt. Die Anwendungsentwicklung sollte Teams zu einem Ganzen zusammenfassen. Wenn das Kollektiv keine solche Stimmung hat, kümmert sich niemand um die Qualität.

Fazit

Anwendungen werden heute immer schwieriger. Wenn Sie herausfinden möchten, wer für das Scheitern des Projekts verantwortlich ist, ist dies ganz einfach. Die Schuld können QS-Ingenieure, Entwickler und Führungskräfte sein. Oder alle zusammen. Die Hauptfrage ist, warum wir nach Schuldigen suchen sollten, anstatt Verantwortung für die Qualität des Projekts zu übernehmen. Jeder, der nicht erkannt hat, wie wichtig es ist, eine bestimmte Funktion zu testen, kann an die Stelle der Schuldigen treten.

Die Frage sollte nur lauten: "Machen wir ein wirklich gutes Produkt?" . Wenn die Antwort auf diese Frage Ja lautet, sollte es keinen Zweifel geben, dass alle Teams eine große Sache tun.

Niemand wird schuld sein müssen und jeder wird glücklich sein, denn Qualitätssicherung ist eine häufige Aufgabe!