Dieser Artikel ist für diejenigen von Interesse, die genau wie wir vor dem Problem stehen, einen geeigneten Spezialisten auf dem Gebiet der Prüfung auszuwählen.
Seltsamerweise, aber mit der Zunahme der Anzahl von IT-Unternehmen in unserer Republik steigt nur die Anzahl der würdigen Programmierer, aber nicht der Tester. Viele sind begierig auf diesen Beruf, aber nicht viele verstehen seine Bedeutung.
Ich kann nicht für alle IT-Unternehmen sagen, aber wir haben unseren Qualitätsspezialisten die Rolle der Qualitätssicherung zugewiesen. Sie sind Teil des Entwicklungsteams und beteiligen sich an allen Entwicklungsphasen, von der Forschung bis zur Veröffentlichung einer neuen Version.
Der Tester im Team sollte bereits in der Planungsphase alle funktionalen und nicht funktionalen Anforderungen berücksichtigen, um die User Story zu akzeptieren. Er sollte nicht schlechter als Programmierer oder sogar besser sein, um die betrieblichen Eigenschaften des Produkts zu verstehen und dem Team zu helfen, in der Planungsphase keine falschen Entscheidungen zu treffen. Der Tester sollte eine klare Vorstellung davon haben, wie die implementierte Funktionalität funktioniert und welche Fallstricke auftreten können. Unsere Tester erstellen selbst Testpläne und Testfälle und bereiten alle notwendigen Prüfstände vor. Das Testen gemäß der fertigen Spezifikation als Affenklicker ist nicht unsere Option. Er arbeitet im Team und sollte helfen, ein anständiges Produkt herauszubringen und rechtzeitig Alarm zu schlagen, wenn etwas schief geht.
Was uns bei der Suche nach Testern begegnet ist
In der Phase des Studiums vieler Lebensläufe schien es Spezialisten mit geeigneter Erfahrung für uns zu geben, und es würde keine Probleme geben, einen Tester in unserem Team auszuwählen. In persönlichen Meetings wurden wir jedoch zunehmend mit Kandidaten konfrontiert, die in Wirklichkeit weit von der Welt der Informationstechnologie entfernt waren (zum Beispiel konnten sie die Prinzipien der Browser- und Webserver-Interaktion, Sicherheitsgrundlagen, relationale und nicht relationale Datenbanken nicht erkennen und hatten keine Ahnung von Virtualisierung und Containerisierung), aber gleichzeitig bewerteten sie sich auf der Ebene der Senior QS. Nach mehr als einem Dutzend Interviews kamen wir zu dem Schluss, dass die Anzahl der für uns geeigneten Spezialisten in der Region vernachlässigbar ist.
Als nächstes werde ich Ihnen sagen, welche Schritte wir unternommen haben und auf welchen Rechen wir getreten sind, um die sehr lang erwarteten Kämpfer für Qualität zu finden.
Wie wir versucht haben, die Situation zu beheben
Nachdem wir unter der Beschaffung von vorgefertigten Spezialisten gelitten hatten, begannen wir, auf die nahe gelegenen Gebiete zu schießen:
- Wir haben versucht, Bewertungspraktiken anzuwenden, um unter der großen Anzahl von „Fluchtleuten“ diejenigen zu identifizieren, aus denen wir starke Spezialisten entwickeln können.
Einer Gruppe potenzieller Kandidaten mit ungefähr demselben Wissensstand wurde angeboten, Aufgaben zu erledigen. Sie beobachteten ihren Denkprozess und versuchten, den vielversprechendsten Kandidaten herauszufinden.
Insbesondere haben wir Aufgaben zur Überprüfung der Aufmerksamkeit, zum Verständnis der Fähigkeiten von Technologien und der Merkmale des Multikulturalismus entwickelt:

- Es wurden Treffen für Tester abgehalten, um die Grenzen des Verständnisses des Berufs für das bestehende Kontingent zu erweitern.
Ich werde Ihnen ein wenig über jeden von ihnen erzählen.
Ufa Software QA und Testing Meetup # 1 ist unser erster Versuch, diejenigen zu sammeln, denen der Beruf nicht gleichgültig ist, und gleichzeitig zu verstehen, ob die Öffentlichkeit an dem interessiert sein wird, was wir ihnen vermitteln möchten. Grundsätzlich ging es in unseren Berichten darum, wo Sie anfangen sollten, wenn Sie sich entschieden haben, Tester zu werden. Helfen Sie Anfängern, die Augen zu öffnen und sich die Tests für Erwachsene anzusehen. Wir haben über die Schritte gesprochen, die Anfänger-Tester unternehmen müssen, um in den Beruf einzusteigen. Was Qualität ist und wie sie unter realen Bedingungen erreicht werden kann. Und auch, was automatisches Testen ist und wo es angemessener ist, es anzuwenden.

Im Abstand von 1-2 Monaten hielten wir zwei weitere Mitaps. Es gab bereits zweimal mehr Teilnehmer. Bei Ufa Software QA und Testing Meetup # 2 sind wir tiefer in den Themenbereich eingetaucht. Wir sprachen über Fehlerverfolgungssysteme, UI / UX-Tests, berührten Docker, Ansible und sprachen über mögliche Konflikte zwischen dem Entwickler und dem Tester und wie man sie löst.
Unser drittes Mitap „Ufa Software QA und Testing Meetup # 3“ bezog sich indirekt auf die Arbeit von Testern, war jedoch nützlich, um Programmierer rechtzeitig an ihre technischen und organisatorischen Aufgaben zu erinnern: Lasttests, e2e-Tests, Selenium beim Selbsttest und Schwachstellen in Webanwendungen.
Während dieser ganzen Zeit haben wir gelernt, in Sendungen unserer Veranstaltungen normales Licht und Ton zu erzeugen:
→ Erste Schritte beim Testen - Ufa Software QA und Testing Meetup # 1
→ UI / UX-Test - Ufa Software QA und Test Meetup # 2
→ Sicherheitstests, Lasttests und automatische Tests - Ufa QA und Test Meetup # 3 - Und am Ende haben wir beschlossen, einen Hackathon für Tester zu versuchen
Wie der Hackathon für Tester vorbereitet und durchgeführt wurde
Zunächst versuchten sie zu verstehen, was für ein "Biest" dies ist und wie es normalerweise ausgeführt wird. Wie sich herausstellte, fanden solche Veranstaltungen in der Russischen Föderation nicht so oft statt, und es gibt keinen Ort, an dem man Ideen ausleihen könnte. Zweitens wollte ich in einem zweifelhaften Ereignis auf den ersten Blick nicht sofort viele Ressourcen investieren. Aus diesem Grund haben wir beschlossen, kurze Mini-Hackathons nicht für den gesamten QS-Arbeitszyklus, sondern für separate Phasen durchzuführen.
Unser Hauptproblem ist der Mangel an lokaler Testpraxis bei der Erstellung verständlicher Testkarten. Sie widmen der Recherche in der Phase vor der Implementierung von User Stories und der Erstellung von Akzeptanzkriterien, die für Entwickler hinsichtlich funktionaler und nicht funktionaler Anforderungen, UI / UX, Sicherheit, Arbeit und Spitzenlasten verständlich sind, keine Zeit. Aus diesem Grund haben wir uns zum ersten Mal entschlossen, den interessantesten und kreativsten Teil ihrer Arbeit zu durchlaufen - die Analyse und Bildung von Anforderungen für die Forschung vor dem Projekt.
Sie schätzten die potenzielle Teilnehmerzahl und entschieden, dass wir mindestens 5 Rückstände für MVP-Releases, 5 Produkte und 5 Personen benötigen, die als Produktbesitzer fungieren, Geschäftsanforderungen entschlüsseln und Entscheidungen über Einschränkungen treffen.
Folgendes haben wir:
Rückstände für den Hackathon .
Die Hauptidee war es, Themen zu entwickeln, die so weit von der täglichen Arbeit der Teilnehmer entfernt sind, und ihnen Raum für kreative Fantasie zu geben.


Welche Fehler haben wir gemacht und was kann besser gemacht werden
Die Anwendung von Bewertungspraktiken, die im Bereich der Aufnahme von Verkäufern und Managern auf niedrigerer Ebene so beliebt sind, erforderte viel Energie, ermöglichte es uns jedoch nicht, jedem Teilnehmer ausreichend Aufmerksamkeit zu schenken und seine Fähigkeiten zu bewerten. Im Allgemeinen führt diese Auswahloption zu einem negativen Image des Unternehmens, da viele Menschen nicht genügend Feedback erhalten und in Zukunft die Auswirkungen der Tyrannei des Arbeitgebers haben (die Kommunikation in den IT-Communities ist sehr entwickelt). Infolgedessen haben wir buchstäblich zwei potenzielle Kandidaten mit einer sehr weit entfernten Perspektive.
Hier sind Mitapas eine gute Sache. Es wird eine umfangreiche Basis für das Studium geschaffen, das Gesamtniveau der Teilnehmer wird erhöht. Das Unternehmen wird auf dem Markt zunehmend erkennbar. Die Komplexität solcher Unternehmen ist jedoch nicht gering. Es muss klar sein, dass in einem Jahr ungefähr 700-800 Mannstunden benötigt werden, um Sitzungen abzuhalten.
Wie für die Hackathon-Tester. Solche Veranstaltungen hatten noch keine Zeit, sich zu langweilen, da sie im Gegensatz zu Hackathons für Entwickler viel seltener stattfinden. Der Vorteil dieses Vorhabens besteht darin, dass Sie auf eindeutige Weise eine große Menge an praktischem Wissen austauschen und das Niveau jedes Teilnehmers ziemlich genau bestimmen können.
Nachdem wir die Ergebnisse des Ereignisses analysiert hatten, stellten wir fest, dass Haufen Fehler machten:
- Der unverzeihlichste Fehler war zu glauben, dass 4-5 Stunden für uns ausreichen würden. Infolgedessen dauerte nur die Einführung und Bekanntschaft mit Rückständen fast 2 Stunden.
Die Zusammenarbeit mit den Eigentümern der Produkte in der Anfangsphase und die Zeit, um in den Themenbereich einzutauchen, nahmen ebenso viel Zeit in Anspruch. Die verbleibende Zeit reichte also eindeutig nicht aus, um Karten umfassend zu testen. - Es gab nicht genug Zeit und Energie für ein detailliertes Feedback zu jeder Karte, da es bereits Nacht war. Daher ist dieser Teil von uns eindeutig gescheitert und sollte ursprünglich der wertvollste im Hackathon sein.
- Wir haben uns entschlossen, die Qualität der Studie durch eine einfache Abstimmung aller Teilnehmer zu bewerten und für jedes Team 3 Stimmen hervorzuheben, die sie für die Arbeit von höchster Qualität abgeben können. Vielleicht wäre es besser, eine Jury zu organisieren.
Was hast du erreicht?
Wir haben unsere Aufgabe teilweise gelöst und jetzt haben wir 4 mutige, gutaussehende Männer, die den Rücken von 4 Entwicklungsteams abdecken. Ein bedeutender Pool potenziell starker Kandidaten und spürbare Veränderungen im Niveau der QS-Community der Stadt wurden noch nicht bemerkt. Aber es gibt einige Fortschritte, und das kann nur Freude bereiten.