Dieser Artikel wird für diejenigen interessant sein, die wie wir vor dem Problem stehen, einen geeigneten Spezialisten im Bereich Testen auszuwählen.
Seltsamerweise steigt mit der Zunahme der Zahl der IT-Unternehmen in unserer Republik nur die Zahl der würdigen Programmierer, nicht aber der Tester. Viele Menschen möchten unbedingt in diesen Beruf einsteigen, aber nicht viele verstehen seine Bedeutung.
Ich kann nicht für alle IT-Unternehmen sprechen, aber wir haben die Rolle der QA/QC unseren Qualitätsspezialisten übertragen. Sie sind Teil des Entwicklungsteams und nehmen an allen Phasen der Entwicklung teil, von der Forschung bis zur Veröffentlichung einer neuen Version.
Ein Tester in einem Team muss bereits in der Planungsphase alle funktionalen und nichtfunktionalen Anforderungen für die Annahme einer User Story durchdenken. Er muss die Betriebseigenschaften des Produkts genauso gut verstehen wie die Programmierer und noch besser, und dem Team helfen, schon in der Planungsphase keine falschen Entscheidungen zu treffen. Der Tester muss ein klares Verständnis davon haben, wie die implementierte Funktionalität funktioniert und welche Fallstricke es geben kann. Unsere Tester erstellen selbst Testpläne und Testfälle und bereiten alle notwendigen Prüfstände vor. Das Testen nach einer vorgefertigten Spezifikation wie bei einem Monkey Clicker ist nicht unsere Option. Im Team muss er dazu beitragen, ein würdiges Produkt auf den Markt zu bringen und rechtzeitig Alarm schlagen, wenn etwas schief geht.
Was uns bei der Suche nach Testern begegnet ist
Beim Studium vieler Lebensläufe schien es, dass es Spezialisten mit geeigneter Erfahrung für uns gab und es keine Probleme geben würde, einen Tester für unser Team auszuwählen. Aber bei persönlichen Treffen trafen wir zunehmend auf Kandidaten, die eigentlich ziemlich weit von der Welt der Informationstechnologie entfernt waren (zum Beispiel konnten sie die Prinzipien der Interaktion zwischen einem Browser und einem Webserver, die Grundlagen der Sicherheit, relationale und nicht-technologische (Sie hatten keine Ahnung von Virtualisierung und Containerisierung), schätzten sich aber gleichzeitig auf der Senior-QA-Ebene ein. Nach Dutzenden von Interviews kamen wir zu dem Schluss, dass die Zahl der für uns geeigneten Fachkräfte in der Region verschwindend gering ist.
Als nächstes erzähle ich Ihnen, welche Schritte wir unternommen und welche Fehler wir begangen haben, um die lang ersehnten Kämpfer für Qualität zu finden.
Wie wir versucht haben, die Situation zu beheben
Nachdem wir uns damit beschäftigt hatten, fertige Spezialisten zu finden, begannen wir, gezielt auf nahegelegene Gebiete zu zielen:
- Wir haben versucht, mithilfe von Beurteilungspraktiken unter den vielen „Leave-it“-Leuten diejenigen zu identifizieren, aus denen wir starke Spezialisten entwickeln können.
Wir haben eine Gruppe potenzieller Kandidaten mit annähernd gleichem Wissensstand gebeten, Aufgaben zu erledigen. Wir haben ihren Denkprozess beobachtet und versucht, den vielversprechendsten Kandidaten zu identifizieren.
Insbesondere haben wir uns Aufgaben ausgedacht, um die Aufmerksamkeit, das Verständnis für die Fähigkeiten der Technologie und die Merkmale des Multikulturalismus zu testen:
- Wir haben Treffen für Tester abgehalten, um die Grenzen des Berufsverständnisses innerhalb des bestehenden Kontingents zu erweitern.
Ich werde Ihnen ein wenig über jeden von ihnen erzählen.
Das Ufa Software QA and Testing Meetup Nr. 1 ist unser erster Versuch, diejenigen zusammenzubringen, denen der Beruf am Herzen liegt, 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 man am besten anfängt, wenn man sich entschieden hat, Tester zu werden. Helfen Sie Anfängern, die Augen zu öffnen und die Prüfung wie ein Erwachsener zu betrachten. Wir haben über die Schritte gesprochen, die unerfahrene Tester unternehmen müssen, um in den Beruf einzusteigen. Darüber, was Qualität ist und wie man sie unter realen Bedingungen erreicht. Und auch, was automatisches Testen ist und wo es sinnvoller ist, es einzusetzen.
Dann haben wir im Abstand von 1-2 Monaten zwei weitere Treffen abgehalten. Es gab bereits doppelt so viele Teilnehmer. Beim „Ufa Software QA and Testing Meetup #2“ sind wir tiefer in das Themengebiet eingetaucht. Sie sprachen über Bug-Tracking-Systeme, UI/UX-Tests, berührten Docker und Ansible und sprachen auch über mögliche Konflikte zwischen einem Entwickler und einem Tester und Möglichkeiten, diese zu lösen.Unser drittes Treffen, „Ufa Software QA and Testing Meetup #3“, bezog sich indirekt auf die Arbeit der Tester, war aber hilfreich, um Programmierer rechtzeitig an ihre technischen und organisatorischen Aufgaben zu erinnern: Lasttests, E2E-Tests, Selenium beim Autotest, Schwachstellen in Webanwendungen .
Die ganze Zeit über haben wir gelernt, wie man in den Übertragungen unserer Veranstaltungen normales Licht und Ton erzeugt:
→
→
→ - Und am Ende haben wir beschlossen, einen Hackathon für Tester zu veranstalten
Wie wir einen Hackathon für Tester vorbereitet und durchgeführt haben
Zunächst haben wir versucht zu verstehen, was für ein „Biest“ das ist und wie es normalerweise ausgeführt wird. Wie sich herausstellte, fanden Veranstaltungen dieser Art in der Russischen Föderation nicht oft statt, und es gibt keinen Ort, an dem man sich Ideen ausleihen kann. Zweitens wollte ich nicht sofort viele Ressourcen in eine auf den ersten Blick zweifelhafte Veranstaltung investieren. Aus diesem Grund haben wir beschlossen, kurze Mini-Hackathons durchzuführen, nicht für den gesamten QS-Arbeitszyklus, sondern für einzelne Phasen.
Unser Hauptproblem ist die mangelnde Übung der lokalen Tester bei der Erstellung klarer Testkarten. Sie verschwenden keine Zeit damit, User Stories vor der Implementierung zu recherchieren und für Entwickler klare Akzeptanzkriterien für funktionale und nichtfunktionale Anforderungen, UI/UX, Sicherheit, Arbeitslasten und Spitzenlasten zu erstellen. Deshalb haben wir uns zum ersten Mal entschieden, den interessantesten und kreativsten Teil ihrer Arbeit durchzugehen – die Analyse und Bildung von Anforderungen während der Vorprojektrecherche.
Wir haben die potenzielle Anzahl der Teilnehmer geschätzt 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.
Das haben wir bekommen: .
Die Grundidee bestand darin, Themen zu erarbeiten, die möglichst weit entfernt von der alltäglichen Arbeit der Teilnehmer liegen und ihnen Raum für kreative Fantasie geben.
Welche Fehler haben wir gemacht und was könnten wir besser machen?
Der Einsatz von Bewertungspraktiken, die bei der Einstellung von Verkäufern und Führungskräften auf niedrigerer Ebene so beliebt sind, erforderte einen enormen Aufwand, erlaubte 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 unzureichendes Feedback erhalten und in der Folge bei sich selbst und anderen den Effekt einer Tyrannei des Arbeitgebers erzeugen (die Kommunikation in IT-Communitys ist sehr entwickelt). Infolgedessen bleiben uns buchstäblich zwei potenzielle Kandidaten mit einer sehr fernen Zukunft.
Meetups sind eine gute Sache. Es wird eine umfassende Ausarbeitungsgrundlage geschaffen und das allgemeine Niveau der Teilnehmer steigt. Das Unternehmen wird auf dem Markt immer bekannter. Die Arbeitsintensität solcher Unternehmen ist jedoch nicht gering. Sie müssen sich darüber im Klaren sein, dass die Durchführung von Meetups etwa 700–800 Arbeitsstunden pro Jahr in Anspruch nehmen wird.
Was den Test-Hackathon betrifft. Langeweile sind solche Veranstaltungen noch nicht geworden, da sie im Gegensatz zu Hackathons für Entwickler deutlich seltener stattfinden. Der Vorteil dieser Idee besteht darin, dass Sie auf entspannte Weise viel Praxiswissen austauschen und das Niveau jedes Teilnehmers recht genau ermitteln können.
Nachdem wir die Ergebnisse der Veranstaltung analysiert hatten, stellten wir fest, dass wir viele Fehler gemacht hatten:
- Der unverzeihlichste Fehler war zu glauben, dass 4-5 Stunden für uns ausreichen würden. Dadurch dauerte allein die Einführung und Einarbeitung in die Backlogs fast 2 Stunden.
Die Zusammenarbeit mit den Produktbesitzern in der Anfangsphase und die Einarbeitung in das Themengebiet nahmen genauso viel Zeit in Anspruch. Für eine umfassende Entwicklung der Testkarten reichte die verbleibende Zeit also eindeutig nicht aus. - Es fehlte die Zeit und Energie für detailliertes Feedback zu jeder Karte, da es bereits Nacht war. Daher haben wir diesen Teil eindeutig nicht bestanden, obwohl er ursprünglich als wertvollster Teil des Hackathons gedacht war.
- Wir haben beschlossen, die Qualität der Entwicklung durch eine einfache Abstimmung aller Teilnehmer zu bewerten und jedem Team 3 Stimmen zuzuteilen, die es für die qualitativ hochwertigste Arbeit abgeben konnte. Vielleicht wäre es besser, eine Jury zu organisieren.
Was haben Sie erreicht?
Wir haben unser Problem teilweise gelöst und jetzt arbeiten vier mutige, gutaussehende Männer für uns, die den Rücken von vier Entwicklungsteams bilden. Ein nennenswerter Pool potenziell starker Kandidaten und spürbare Veränderungen im Niveau der QA-Gemeinschaft der Stadt sind bisher nicht zu beobachten. Aber es gibt einige Fortschritte und das kann nur eine Freude sein.
Source: habr.com