Unter den Menschen werden zunächst alle Qualitätssicherungsingenieure („auf unsere Art“ Ingenieure der Qualitätsabteilung) Tester genannt. Dies ist nicht ganz richtig, in der Realität ist das Testen nur ein Teil der QS-Aufgaben, aber wen interessiert das? Lassen Sie uns daher in den allgemeinen Trend gehen und wir werden den üblichen Antrieb für alle verwenden.
Was macht einen guten Tester aus? Wir werden uns nicht an die Plattitüden bücken und sagen: Achtsamkeit, Ausdauer, Geduld, Neugier, Talent, alle Pause und anderen Unsinn. Das ist natürlich alles wichtig, aber nicht die Hauptsache. Zuallererst sollte eine Person einen gesunden Menschenverstand und Verantwortungsbewusstsein haben.
Sie sagen zum Beispiel, die Hauptsache ist, das Talent zu haben, alles zu zerbrechen. Oft kann man hören, dass sie sagen, dass er nicht abholen wird, alles kaputt machen wird. Das ist natürlich lobenswert, aber die Aufgabe des Testers ist nicht die Hauptsache, um etwas zu zerbrechen. Hier hilft uns eine Definition, die bei Wikipedia nicht schwer zu finden ist.
Softwaretests sind der Prozess der Recherche und des Testens eines Softwareprodukts mit dem Ziel, die Übereinstimmung zwischen dem tatsächlichen Verhalten des Programms und dem erwarteten Verhalten anhand einer begrenzten Anzahl von Tests zu überprüfen, die auf eine bestimmte Weise ausgewählt wurden.
Es zeigt, dass bestimmte Anforderungen an die Software gestellt werden und dass diese erfüllt werden müssen. Wenn der Tester das Programm bricht, anstatt zu prüfen, ob es die ihm zugewiesenen Funktionen überhaupt ausführt, kann er als Ergebnis einen stabilen, aber nicht notwendigen Müll für den Kunden bekommen.
Ich verstehe, dass jeder Geschichten liebt, wie jemand Mist gebaut hat, ich habe sie. Für meine Arbeit habe ich an verschiedenen Orten und in verschiedenen Projekten gearbeitet, also war ich selbst Zeuge oder habe viele Geschichten von meinen Kollegen gehört. Einige von ihnen sind bereit zu erzählen. Nun und ja, das notwendige Mantra: Alle Zufälle sind zufällig und Namen sind erfunden.
Testen und mehr
Beginnen wir in der richtigen Reihenfolge. Wie ich eingangs sagte, testet der Tester nicht nur. Wie findest du so ein Wortspiel? In großen und angesehenen Unternehmen versuchen sie, das Testteam frühzeitig mit dem Projekt zu verbinden, d. H. in der Phase des Sammelns von Anforderungen, aber dies wird nicht überall und nicht immer durchgeführt.
Einmal während des Abnahmetests hat der Benutzer einen kritischen Fehler ausgelöst, weil eine der anforderungen wurde nicht erfüllt. Der Kern der Behauptung war, dass der Benutzer auf dem Bildschirm nicht das von ihm benötigte Attribut gefunden hat (für diejenigen im Tank - ein Feld mit einem Wert). Der Tester stieg natürlich in die Spezifikation ein, überprüfte, ob dieses Attribut in der Anwendung vorhanden war, und lief fröhlich, um dem Benutzer mitzuteilen, dass alles in Ordnung war.
Sie verstehen bereits, dass die Geschichte dort nicht endet.
Der Tester versuchte dem Benutzer zu erklären, woran er schuld war, und stieß dabei auf einen Teil der Negativität und Empörung. Der Benutzer setzte sich und entdeckte die Anforderungen, auf deren Grundlage die Spezifikationen erstellt wurden. Eine dieser Anforderungen lautet fast wörtlich: "Das Attribut muss auf jedem Bildschirm angezeigt werden." Ein Satz, aber wie viel Sinn! Dann öffnete er die Anwendung und begann nach dem Zufallsprinzip zu verschiedenen Bildschirmen zu navigieren. Er sagte: "Und wo ist dieses Attribut?" Es ist klar, dass der Benutzer offen verspottet, aber formal hatte er das Recht, dies zu tun. Das Problem ist, dass die Eskalation weiterging und immer mehr Menschen an der Diskussion des Problems beteiligt waren. Am Ende des Benutzers überzeugten ihn neben dem Tester selbst mehrere PMs und eine Menge von Analysten, und er war unnachgiebig und forderte das Unmögliche.
Als Ergebnis wurde ein Kompromiss gefunden, und in der Anforderung wurde eine Liste der erforderlichen Bildschirme angezeigt, auf denen sich das Attribut befinden sollte. Dies erforderte jedoch umfangreiche Änderungen im Programmcode. Dementsprechend musste der gesamte Entwicklungszyklus erneut ausgeführt werden, jedoch mit einem beschleunigten Tempo. Das Unternehmen gab zusätzliches Geld aus, ganz zu schweigen von den Reputationskosten für den Stress und die Verarbeitung der Mitarbeiter. All dies hätte vermieden werden können, wenn der Tester zu Beginn des Projekts angeschlossen gewesen wäre und die Anforderungen für die Mehrdeutigkeit gesehen hätte - zumindest oder später, um die Spezifikation auf Übereinstimmung mit den Anforderungen zu überprüfen. Und ja, Tester arbeiten häufig direkt mit realen Benutzern zusammen, weshalb sie sich mit Stressreduzierung, Psychoanalyse und außersinnlicher Wahrnehmung befassen müssen.
Kein Fanatismus
Wir gehen weiter, sehr ironisch, der Testprozess selbst ist durch eine bärtige Anekdote gekennzeichnet:
Sobald der Tester die Bar betritt.
Läuft in die Bar.
Schleicht in die Bar.
Tanzen, dringt in die Latte.
In eine Bar schleichen.
Bricht in die Bar ein.
Springt zur Bar.
Bestellungen:
ein Krug Bier
2 Gläser Bier
0 Gläser Bier
999999999 Krüge Bier,
Eidechse in einem Glas
-1 Tasse Bier
QWERTY-Bierkrüge.
Der erste echte Kunde kommt in die Bar und fragt, wo die Toilette ist. Die Bar geht in Flammen auf, alle sterben.
Nicht jeder versteht, dass Sie endlos testen können. Das Ideal ist unerreichbar, und Projekte haben sehr spezifische Fristen, in die sie passen. Es gab also einen Tester, der ihn beim Bestehen des Testfalls ständig im Stich ließ. Die Zeit verging, das Projekt war bereits zu Ende und der Entwickler überwand alle gefundenen Probleme. Und hier erklärt der Tester, dass die grundlegende notwendige Funktionalität nicht funktioniert. Jeder versteht: Es wird nicht funktionieren, es rechtzeitig zu beheben.
Im Laufe des Verfahrens stellte sich heraus, dass das Drehbuch während des Tests bis zum unglücklichen Moment nicht vollständig fertiggestellt wurde. Der Tester stellte zu Beginn des Prozesses einen Fehler fest, der testete, ein Ticket startete und zur Hälfte warf. Gleichzeitig konnten die Tests fortgesetzt werden, weil Alle gefundenen Fehler haben es nicht blockiert. Anschließend hat das gesamte Team traditionellen Stress und Verarbeitung.
Übrigens verpflichten sich einige Benutzer dazu, die Abnahme zu testen, den Fehler für kritisch zu erklären und die Arbeit zu beenden. Dies erschwert die Arbeit erheblich, weil Im allgemeinen Strom von Problemen, die im Allgemeinen kein Problem sein können, gehen wirklich kritische Fehler verloren.
Die Moral lautet: Ein guter Tester wird niemals aufhören, den ersten Fehler zu finden, der auftaucht. Es durchläuft das gesamte Skript von Anfang bis Ende und zeichnet gleichzeitig alle gefundenen Fehler auf. Wenn ein Fehler auftritt, der die Passage blockiert, wird nach einer Problemumgehung gesucht, d. H. Problemumgehung. Und wenn er überzeugt ist, dass es keine Problemumgehungen gibt, wird er aufhören.
Es gibt eine Einschränkung. Meistens werden Projekte unter engen Fristen oder nicht sehr eng, aber sehr spezifisch durchgeführt. Es kommt vor, dass eine Person auf eine endlose Prüfung eines Feldes gesprüht wird und alle möglichen und unmöglichen Wertevarianten in dieses Feld einbringt. Gleichzeitig ist es gemäß den Kundenanforderungen erforderlich, die von der Anwendung ausgeführte Funktion zu überprüfen, obwohl der Wert aus diesem Feld verwendet wird. Infolgedessen läuft er Gefahr, Zeit zu verschwenden und die Hauptsache nicht zu überprüfen. Der Tester sollte in der Lage sein, seine Stärken und kritischen Stellen der Anwendung richtig einzuschätzen. Es ist nicht erforderlich, Orte zu testen, die nicht getestet werden müssen. Hauptsache, die Applikation muss die ihr zugewiesene Funktion erfüllen. Zuerst müssen Sie die Ausführung eines direkten Szenarios erreichen und dann die Ausführungsqualität auf das gewünschte Niveau verbessern.
Meine Zunge ist mein Feind
Weiter ... Probleme mit der Dokumentation können nicht nur für Analysten, sondern auch für Tester sein. Es wurde wiederholt darauf hingewiesen, dass nicht nur die Entwickler den Inhalt des Tickets in dem entsprechenden Feld nicht klar beschreiben können, sondern dass die Tester selbst die Reihenfolge der Aktionen, die den Fehler verursachen, nicht richtig aufschreiben können. Das ist ein großes Problem. Jemand versteht einfach nicht, warum der Fehler auftritt, und kümmert sich nicht darum, die Schritte herauszufinden. Jemand hat überhaupt Lese- und Schreibprobleme.
Was bedeutet das alles? Hier ist die Antwort und der Igel verständlich, aber mit den Beispielen natürlich interessanter.
Es gibt eine Kohorte von Testern, die, wenn sie einen Fehler vor sich sehen, einfach diese Millionen Schritte aufzeichnen, einschließlich des Mülls, der zum Fehler geführt hat. Sie reproduzieren den Fehler nicht und stellen nicht fest, was genau die Ursache dafür ist. Gleichzeitig können sie eine Reihe von Schritten aufschreiben, die mit diesem Fehler überhaupt nicht verbunden sind. Der Entwickler wird versuchen, zu reproduzieren, irgendwann wird sein Kopf kochen und er wird sich persönlich mit dem Tester befassen. Sie werden es gemeinsam verstehen und beide werden viel Zeit mit unnötiger Kommunikation verbringen. Glücklicherweise wird all dies schnell nach Zeit und Erfahrung behandelt, obwohl es klinische Fälle gibt.
Die Alphabetisierung wird immer schwieriger. In meiner Praxis gab es einen Fall, in dem der QS-Leiter die Beschreibung von mehreren Dutzend Tickets korrigieren musste, weil Sie sollten in einem Fortschrittsbericht an den Kunden gesendet worden sein. Dies geschah, weil die meisten Teammitglieder ihre Gedanken nicht richtig auf Englisch formulieren konnten.
Aber es gibt auch weniger Probleme mit den Russen, Gott sei Dank. Hier ist alles beim Alten, eine schlecht geschriebene Beschreibung führt dazu, dass das Ticket wie ein Fußball zwischen Menschen galoppiert, ohne ins Tor zu kommen. Es ist gut, wenn sich alle im selben Raum befinden und nur sprechen können, ohne vom Monitor aufzustehen. Schwieriger - wenn das Team verteilt ist. Sehr schlecht, wenn auch mehrsprachig. Das Schlimmste, was am Ende passieren kann, ist, dass das Ticket aufgrund eines Missverständnisses falsch ausgeführt und tausendmal wieder geöffnet wird. Und selbst zum Kunden wird in einem der Releases mit invertierter Logik geflogen.
Persönlicher Raum
Ein weiteres Problem sind Prüfstände und Prüfdaten. In verschiedenen Unternehmen geschieht dies auf unterschiedliche Weise, aber es kommt häufig vor, dass einem Mitarbeiter Rechte für den Arbeitsserver eines Kunden gewährt werden oder er seine Datenbank zum Testen erhält. Es scheint, dass was schief gehen könnte?
Aber dofiga von was ... Wenn jemand Zugriff auf den Server des Kunden hat, ist es zum einen bequem, die Probleme aus den ersten Reihen zu betrachten und sich nicht in Bezug auf das Foto zu irren. Es besteht jedoch die Gefahr, dass die Kundendaten verfälscht werden, was zu schwerwiegenden Konsequenzen führen kann. Ich schweige bereits zu den Fällen, in denen ein solcher Zugriff gesetzlich generell verboten ist.
Es gab einen Fall, in dem ein Kunde drei Tage lang von einem Server fiel. Der Entwickler konnte die ganze Zeit nicht verstehen, warum dies geschah, und suchte verzweifelt nach einem Fehler, und das Unternehmen erlitt Verluste. Infolgedessen stellte sich heraus, dass das Unternehmen Inder für die Auslagerung engagierte, bei denen die Leute ohne weiteres alle Administratorrechte erteilten. Für alle - das bedeutet, dass sogar das Mädchen, das 3 Tage in der Firma gearbeitet hat und in ihrem Dorf keinen Computer hatte, eine kürzere Datierungsperiode hat. Aber das Mädchen stellte sich als schrecklich talentiert heraus, sie fand die grundlegende Essenz im Admin-Bereich und änderte ihren Typ, woraufhin natürlich alles abfiel und aufhörte zu arbeiten. Es ist leicht zu erraten, wie sie sich danach von der Karriereleiter gelöst hat.
Der gleiche Unsinn und mit Daten vom Kunden. Auch hier spreche ich nicht von Fällen, in denen dies gesetzlich verboten ist. Wenn es möglich ist, an echten Daten zu arbeiten, ist dies in Ordnung, aber man muss damit vorsichtig sein. Jeder hat wahrscheinlich Geschichten über das zufällige Senden von Briefen oder Nachrichten von einem Testserver an echte Benutzer gehört. Das sind also keine Witze. Das passiert wirklich und ziemlich oft. Okay, wenn diese Nachrichten als Testnachrichten berechtigt sind und einen vernünftigen Inhalt haben, tun die Leute jedoch so, als würden sie etwas schreiben, was das gesamte Anwendungsentwicklungsteam bereut.
Organisatorische Momente
Ich fing schon an, mich mit einer Fülle von Texten zu langweilen, also die letzte. Der Tester muss seinem Chef ständig aktuelle Informationen über seine Arbeit zur Verfügung stellen. Laut solchen Berichten, wenn sie richtig gemacht werden, macht der Leiter eine Schlussfolgerung über den Stand des Projekts als Ganzes. Nicht nur über die Arbeit eines Testers oder des gesamten Testteams, sondern auch über die Arbeit des Entwicklungsteams und die Phase, in der sich das Projekt befindet. Außerdem ermöglichen solche Berichte die Planung von Analysen für zukünftige Releases usw. usw.
Es gibt viele Beispiele, bei denen diese Arbeit nicht oder in unangemessener Weise geleistet wurde, woraus die Behörden ein Gefühl der Unsicherheit mit allen sich daraus ergebenden Konsequenzen ergaben. Ich sage dir das hellste.
Sobald der Tester auf ein neues Projekt gestellt wurde. Da er ihn nicht gut kannte, wurde er beauftragt, Beobachtungen zu sortieren und aufzuzeichnen. Da es etwas informelles war, einigten wir uns darauf, in Googledock zu schreiben. Der Mann fing an, die Aufgabe auszuführen, eine Woche später wurde diese Aufgabe überprüft, der Tester wurde auf die Schulter geklopft und er arbeitete weiter. Monate vergingen, die Behörden begannen sich Sorgen zu machen, warum es keine Tickets im Bugtracker gibt und nichts für das Projekt getan wird. Wir begannen es herauszufinden, es stellte sich heraus, dass eine Person weiterhin in diesem Googledock schreibt. Niemand sagte „Töpfchen, koche nicht“ und stoppte den Tester nicht. Er verstand und zeichnete regelmäßig Beobachtungen auf, ohne sich selbst zu informieren. Es gibt Bugs, und er hat sie gefunden, aber niemandem davon erzählt, sondern sie nur in eine Datei geschrieben, die alle eine Woche später vergessen haben.
In der Tat war die Erwartung, dass eine Person bereits formal weiterarbeiten würde, d.h. im Bug-Tracker geben Entwickler Tickets mit ihren Tickets, aber das ist nicht geschehen. Es schien, dass der Mann nichts tat, obwohl er arbeitete. Es ist klar, dass das Problem nicht nur auf Seiten des Testers lag, sondern dass Missverständnisse vermieden werden könnten, wenn er regelmäßig über seine Aktivitäten berichtete.
Der Mangel an Informationen führt oft zu dem Gefühl schlechter Produkttests, dass dieser oder jener Teil der Funktionalität nicht getestet wurde. Um dies zu verhindern, müssen Sie detaillierte Berichte erstellen. Dies ist besonders wichtig für große Projekte.
Fazit
Sie müssen verstehen, dass die Qualitätssicherung tatsächlich der Anwalt des Benutzers ist. In jeder unverständlichen Situation im Zusammenhang mit der Bewerbung sollte sich der Prüfer an seine Stelle setzen. Wenn sich durch diese einfache Manipulation des Bewusstseins herausstellt, dass die Anwendung mit etwas nicht zufrieden ist, müssen Sie ein Ticket starten. Und dies mag ein Knopf an der falschen Stelle sein oder eine andere Kleinigkeit aus der Sicht des Entwicklers, aber es kommt oft vor, dass diese Kleinigkeit für einen Benutzer zur Hölle und zu einem Punkt der Irritation wird. Beispielsweise können Sie eine unbegrenzte Anzahl von Popups in der Anwendung verwenden. Ja, das Programm führt seine Funktion aus, aber es ist schwierig, es zu verwenden, weil Die Ausführung dieser Funktion erfordert viel Zeit und Mühe eines Benutzers, der gezwungen ist, eine Reihe zusätzlicher Fenster mit Downloads und mehr zu drücken, anstatt die gesamte Arbeit auf einem Bildschirm zu erledigen.
Und wenn ein Mensch verantwortungsbewusst und mit gesundem Menschenverstand an seine Arbeit herangeht, kann er die meisten Probleme auf seinem Weg vermeiden, nicht nur im Bereich der Qualitätssicherung.