Wie QS eine effektive Interaktion mit Entwicklern aufbaut. Ein möglicher Weg

Einer , ergänzt durch einen anderen , erwies sich als ein möglicher Leitfaden für diejenigen, die noch keinen „eigenen Stil“ gefunden haben und nicht sicher sind, wo sie anfangen sollen.

Einige antworteten, dass ich über „gemeinsame Wahrheiten“ schreibe, aber gleichzeitig erhielt ich eine gute Antwort in den Kommentaren und persönlichen Nachrichten aus der Kategorie „war nützlich“, „was ich jetzt brauche“ usw. Aber es gab Fragen. Die Fragen beschränkten sich größtenteils auf den „Schmerz“, der in seiner Karriere keine einzige Qualitätssicherung bestanden hat:

• Wie kann man effektiv mit Entwicklern interagieren?
• Wie kann man die Arbeit mit ihnen so arrangieren, dass sie akzeptieren: Gibt es eine andere Meinung zum Projekt, die Meinung der Qualitätssicherung, und ist es auch wichtig?
• Wie können sie zur Interaktion ermutigt werden, beispielsweise beim Aufbau einer gemeinsamen Testautomatisierung, wenn sie nicht für die Zusammenarbeit konfiguriert sind?
• Wie verhalten Sie sich, wenn Ihre technischen Fähigkeiten im Stapel der verwendeten Technologien einfach nicht ausreichen?

Ich muss sofort sagen, dass das Thema sehr heikel ist. Wenn man darüber spricht, muss man immer kurz davor stehen, den Stolz der Entwickler und der Qualitätssicherung selbst nicht zu verletzen. Deshalb bitte ich Sie, mit kaltem Herzen zu lesen und nur einige nützliche Punkte hervorzuheben und in der Praxis auszuprobieren.

Einführung

Erstens, wie die Praxis zeigt, häufig diejenigen QS, die es nicht schaffen, in die vom Beruf geforderte Entwicklung einzudringen

• einfach nicht selbstbewusst. Sie können nicht erreichen, dass sie gehört wurden, weil sie unhörbar und nicht vernünftig sprechen und ständige Zweifel äußern;
• Sie haben Angst, Fehler zu machen und zusätzliche Verantwortung zu übernehmen.
• komplex aufgrund unvollständiger technischer Kenntnisse.

Zweitens empfinden die Entwickler im Team die Qualitätssicherung als einen Anhang, der einfach die Tasten drückt, bevor er das Produkt an den Kunden weitergibt, oder sich einfach nicht vorstellt, wie er mit ihnen interagieren soll. Dies kann daran liegen, dass

• Sie denken immer noch an QA als Tester vor 10 bis 20 Jahren, als sie es wirklich waren.
• alle vorherigen QAs, mit denen sie genau gleich gearbeitet und sich verhalten haben, und sie wissen einfach nicht, was sonst passiert;
• Im Prinzip wissen sie nicht, worauf es bei der Arbeit des QS-Ingenieurs ankommt, weil sie es einfach nicht brauchen - sie entwickeln ihre Fähigkeiten weiter.
• Die Codeentwicklung ist bereits gut etabliert und etwas daran zu ändern ist nur Faulheit.

Beginnen wir mit dem ersten Problem.

QS-Ingenieur! Machen Sie einen Frühjahrsputz in Ihrem Kopf

Arbeiten Sie daran, Ihren Beruf zu verstehen

Wenn Sie die Welt verändern wollen, beginnen Sie mit sich selbst. Bekannte und sehr relevante Wahrheit in unserem Thema.
Als QS-Ingenieur schadet es Ihnen nicht, herauszufinden, für welche Position Sie arbeiten. Wenn Ihr Projekt immer noch nach den Prinzipien der Wasserfallarchitektur lebt und Sie einfach von einem manuellen Tester eingestellt wurden, der wie OTC in Unternehmen die Bereitschaft des Endprodukts überprüft, dann ist dies eine Sache, und hier ist alles ziemlich transparent.

Und wenn Sie sich in der Position eines vollwertigen QS-Ingenieurs befinden, was mittlerweile fast universell ist, bedeutet dies, dass Ihre Verantwortung, die von den Kanonen dieses Berufs in [1] festgelegt wurde, nicht nur darin besteht, das fertige Produkt zu testen, sondern auch direkt an der Organisation der Prozesse seiner Erstellung und der Interaktion der Teilnehmer teilzunehmen das ganze Projekt. Bitte denken Sie daran, dass es ohne klare Prozesse und Organisation des Teams fast unmöglich ist, ein Qualitätsprodukt zu erhalten. Daher sollte die Stimme der Qualitätssicherung in diesem Bereich zuversichtlich und klar klingen. Um das Auftreten von Fehlern zu verhindern und nicht nachträglich zu beheben, sind dies viele gut organisierte Teams. Das QA-Team bemüht sich, die Anzahl der Fehler zu minimieren. (Der Kreis schließt sich.)

Erinnern Sie sich daher zunächst an alle grundlegenden Dinge über die Prinzipien, Typen, Teststufen und den Wortlaut der Definition des Berufs des QS-Ingenieurs. Verstehe das berüchtigte "Wer bin ich?" und "Warum bin ich hier?"

Hier finden Sie Antworten auf Fragen

Wenn das professionelle Selbstgraben vorbei ist, skizzieren Sie einen Plan für sich selbst, was Sie tun werden, Sie können Ideen aus meinen Artikeln übernehmen oder Ihren eigenen Plan erstellen, der Ihren Umständen entspricht. Jeder Punkt Ihrer Aktivität sollte Ihnen selbst klar sein - warum ist es, wie man es umsetzt, was ist der Gewinn.

Nur in diesem Fall können Sie sicher über das Projekt sprechen. Auch wenn Sie bisher nur die Antworten auf die Fragen „Warum“ und „Was ist der Nutzen“ kennen, wissen Sie aber nicht „Wie“. Seien Sie schon jetzt zuversichtlich, dass Sie die Vorderseite der Arbeit sehen. Die richtige Formulierung der Aufgabe ist 80% Erfolg.

Der nächste Schritt besteht darin, die Fragen aufzuschreiben, die Sie lösen müssen, um die Frage „wie“ zu beantworten. Und gehen Sie zu Leuten mit diesem Thema, dh besprechen Sie es mit dem Team - in einem speziell organisierten Meeting, bei einem Gespräch zwischen Geschäftsleuten oder informell in der Küche bei einer Tasse Kaffee spielt es keine Rolle. Es ist wichtig, dass Ihr Projekt voll von Menschen ist, die unterschiedliche Erfahrungen und andere Kenntnisse haben, dieses Lager mit nützlichen Informationen nutzen, kommunizieren, fragen und alles wird geklärt.

Lassen Sie die Erfahrung fallen, dass Sie nicht perfekt sind

Wenn Sie sehr schüchtern oder ein Maximalist im Leben sind, der immer danach strebt, ein Führer zu sein, wird es schwierig sein, die Rolle der Qualitätssicherung zu spielen. Da QA Engineer ein Ingenieur ist, ist er an der Entwicklung beteiligt. Gleichzeitig befinden wir uns in Projekten mit einem anderen Stapel von Technologien und Architekturen, während Entwickler ihre eigene Spezialisierung haben. Zu erkennen, dass Sie für manche Menschen „nicht zum Thema gehören“, bedeutet, sich selbst in ein „schwaches Glied“ zu schreiben. Und das war mein Problem, mit dem ich lange, lange zu kämpfen hatte. "Muss ich sagen, dass ich nicht weiß, dass ich nicht weiß, was ich nicht verstehe ?!" - Mehr als einmal war ich in Diskussionen über alle technischen Aspekte verblüfft.

Aber erst irgendwann wurde mir klar, dass es keine Schande ist, nicht zu wissen. Ich schäme mich, mich weiterhin "in der Muschel zu verstecken" und nicht zu versuchen, es herauszufinden. Und zu schweigen, allverständlich zu wirken, liegt sich lieber.

Sie wurden eingestellt, sie haben Ihren Lebenslauf gelesen (Sie sind sich Ihrer Fähigkeiten sicher;)), Sie haben beim Vorstellungsgespräch mit Ihnen gesprochen und Sie wurden eingestellt. Ihr Stapel an technischen Fähigkeiten ist also für alle in Ordnung, und diejenigen, die Sie eingestellt haben, haben erraten, was Sie erwartet. Daher macht es jetzt keinen Sinn, über den Kopf zu springen. Und wenn Sie sagen: „Ich habe noch nie damit gearbeitet, aber ich möchte es herausfinden, helfen Sie mir, dies und das zu verstehen.“ Dies ist eine absolut normale, gesunde und korrekte Situation (bringen Sie nicht nur das Wichtigste auf den Punkt der Absurdität Wissen - Definitionen und Formulierungen - aus dem Internet lernen). Und wenn Sie anderen mitteilen, dass Sie diesen technischen Hintergrund nicht verstehen, halten sie es zum einen bereits für notwendig, einfacher zu kommunizieren, und zum anderen können Sie mit gutem Gewissen klärende Fragen stellen. Wenn Sie den Code ein- oder zweimal geschrieben und die interne Architektur des Projekts vollständig verstanden hätten, wären Sie wahrscheinlich direkt an der Entwicklung beteiligt, oder?

Und mein kleiner Lieblingstrick ist es, immer anderen zu helfen, wenn ich dazu in der Lage bin - durch Tat, Rat, freundliche Worte kommt dies mit dem gegenseitigen Wunsch anderer zurück, mir zu helfen.

Haben Sie keine Angst, Fehler zu machen

Nehmen Sie an, dass Workflows eine Diskussion aller möglichen Optionen beinhalten. Die Wahrheit wird in einem Streit geboren. Ihre Aufgabe ist es nicht, richtig zu sein, sondern die besten Lösungen zu finden. Und wenn Sie etwas anbieten möchten, aber befürchten, dass es albern klingt, dann glauben Sie mir, wie viele Teams ich gesehen habe, die gleichgültigsten stillen Kollegen sehen den Verlierer aus. Einige unserer Fehler zu erkennen, die besten Ideen zu unterstützen und enthusiastisch zu deren Umsetzung beizutragen, ist ein gesunder Workflow.

Denken Sie daran, dass sich die Heldin von Muravyeva im Film "Moskau glaubt nicht an Tränen" vor dem Besuch der Bibliothek aufgestellt hat: "Wenn Sie herausplatzen, platzen Sie selbstbewusst heraus - dann wird dies als Standpunkt bezeichnet." Es funktioniert wirklich.

Haben Sie keine Angst, Aufgaben zu übernehmen, die Sie nicht erledigen können. Denken Sie daran, dass Sie in einem Team arbeiten und sagen, dass etwas nicht funktioniert, und dass es normal ist, das Team um Hilfe zu bitten.

Und selbst wenn Sie im Verlauf Ihrer Arbeit zu dem Schluss kommen, dass Sie dies nicht tun müssen, wird dies ein Fortschritt sein, da der nächste Schritt darin besteht, die beste Lösung zu finden.

Veraltete Standards freigeben, in die Zukunft schauen

Diese Grundlagen, dass QS eine niedrige Position ist, ist nicht so wichtig und nicht so wichtig auf die eine oder andere Weise in Teams zu finden. Und während Sie selbst so denken, unterschätzen Sie diese Tendenz, leider beim Füttern.

Sie arbeiten jeden Tag, Sie bemühen sich jeden Tag, verbessern das Produkt und das Team, Sie verbringen Zeit und Energie, Ihre Position wird im Rahmen von Projekten festgelegt - das heißt, es ist wichtig und notwendig. Das ist alles. Lassen Sie keinen Raum für Nachsicht und lassen Sie keinen Raum in Ihrem Kopf für „Verspottungen“ von denen, die glauben, dass Sie ein niedrigerer Status als er sind. In diesen Zeiten, als es einfache Handprüfer für Affentester gab, die in Vergessenheit geraten sind, sind QS-Ingenieure in Zukunft „eine Abteilung von Elite-Spezialeinheiten, deren Erfolg von exzellenten Taktiken und modernen Waffen abhängt“ [2].

Denken Sie daran, dass heute in führenden Unternehmen wie beispielsweise Microsoft und Google „Entwickler für die Qualität verantwortlich sind. Wenn das Produkt nach der Veröffentlichung kaputt geht, fliegen die Zapfen zu dem Entwickler, der das Problem verursacht hat, und nicht zu dem Tester, der es nicht gefunden hat. “[2] In solchen Unternehmen ist es daher ein Privileg für Entwickler, ein QS-Team zu haben, das bei der Erstellung eines Qualitätsprodukts hilft.

Und es liegt in Ihren Händen, fortschrittliche Prinzipien in Ihrem Unternehmen einzuführen, anstatt auf frühere Stereotypen zurückzublicken.

Aber ich komme noch einmal auf die Tatsache zurück, dass Sie in Ihrem Projekt ständig wachsen müssen. Wenn Sie zu dem Projekt gekommen sind, sechs Monate vergangen sind und Sie immer noch keine effektive Testautomatisierung gefunden haben, versuchen Sie nicht herauszufinden, was das Team tut, analysieren Sie nicht die vorhandenen Autotests, dann sind Sie nicht ganz die Elite, über die Bücher schreiben.

Es gibt Teams, die überhaupt ohne QA Engineer-Position leben, ich kenne diese. Und wenn Sie bereits heute versuchen, in das Projekt einzutauchen und zu lernen, wie man Autotests mit Entwicklern schreibt, können Sie eines Tages Ihre Kompetenzen auch dort verkaufen und dort ein Software-Ingenieur im Test werden.

QS-Ingenieur! Feinabstimmung der Teamarbeit

Wenn die Arbeit an sich selbst beendet ist, ist es Zeit, eine Zusammenarbeit mit den Entwicklern aufzubauen.

Das Wichtigste

• Ihre Handlungen sollten für das Team klar und transparent sein. Am einfachsten und effektivsten ist es, ihnen ihre Mission zu vermitteln. Wenn Sie ohne Grund mit der Frage „Welche Art von Tests haben Sie hier?“, „Aber Sie müssen noch einen solchen Test schreiben“ in den Pool klettern, lautet die erste (schützende) Reaktion „ wohin gehst du ?! ”,“ wer bist du / so, um meine Arbeit zu kritisieren ?! ”. Möglicherweise hat er diesen Brunch eine Woche lang gekocht, schließlich ausgeatmet und dann die Qualitätssicherung durchgeführt. Sagen Sie ihnen daher im Voraus, was Sie tun werden, warum und welche Vorteile dies für das Projekt und das Team hat. Bereiten Sie den Boden vor.
• Ihre Teilnahme an der Entwicklung von vornherein sollte als Segen angesehen werden, als etwas, das die Arbeit des Entwicklers qualitativ verbessert. Werde sein Partner. Informieren Sie sich beispielsweise darüber, wie Kunden die Funktionalität wahrscheinlich nutzen, welche Fehler bereits aufgetreten sind und welche vermieden werden sollten. Überlegen Sie sich daher gemeinsam, welche Tests und warum wichtig sind. Kommunizieren Sie nicht in einer imperativen Stimmung. Sie können sogar auf psychologische Tricks zurückgreifen - um diejenigen zu vermerken, die in einigen Abschlussberichten die Berichterstattung über Selbsttests im Format „Wir sind alle gut gemacht!“ Erhöht haben. Es ist immer schön, wenn Ihre Arbeit geschätzt wird. Traditionelle QS-Überprüfungen mit automatischer Testabdeckung sind auch eine Motivation zur Zusammenarbeit.

Lassen Sie die Änderungen am Projekt reibungslos sein. Wenn Sie eines Morgens zur Arbeit kommen und sagen: "Ich habe einen Artikel über Habré gelesen, und Sie werden anfangen, einen Schuh auf einer bedingten Plattform zu verprügeln und die Luft zu schütteln, sagen sie, jetzt werde ich Ihnen Kuzkins Mutter zeigen!", Sie werden Sie als seltsam ansehen, das ist eine Tatsache. Ja, und es wird schwierig für Sie sein - angesichts der Probleme an allen Fronten - wird es einen unwiderstehlichen Wunsch geben, die ganze Idee der Verbesserung der Arbeit der Qualitätssicherung aufzugeben.

Stellen Sie besser kleine verständliche Aufgaben für alle auf, erreichen Sie sie und übernehmen Sie Folgendes. Gehen Sie vorsichtig vorwärts, die Zeit vergeht schnell, eines Tages wird es schön sein, umzukehren.

Antworten auf bestimmte Fragen

Nach meinem zweiten Artikel , der eine enge Arbeit in Bezug auf Qualitätssicherung und Entwicklung bot, lief das Publikum aus der Kategorie "Wir haben es versucht, aber der Teamleiter der Entwickler wollte sich nicht wirklich treffen" aus. Aus meiner derzeitigen beruflichen Entwicklung kann ich nur Folgendes empfehlen.

Sei freundlich und behandle mit Weisheit diejenigen, die deine Arbeit nicht so annehmen, wie du es erwartest. In meiner Praxis traf ich viele verschiedene Entwickler und alle, die wirklich beruflich ausgereift waren, kamen immer zu mir, halfen mir immer und wir erzielten hervorragende gemeinsame Ergebnisse, sie waren alle zufrieden. Diejenigen, die „schnauben“ und „von dir wegwinken“, gehören leider zur Kategorie der „professionellen Teenager“. Sie haben noch nicht gelernt, mit ihren Gefühlen umzugehen, und betrachten sich als die rechtsradikalsten (und das körperliche Alter spielt hier keine Rolle). Sie wissen einfach nicht, wie man in einem Team arbeitet, und Sie sind dessen integraler Bestandteil. Sie können ihnen nur beim Wachsen helfen, aber leider wachsen einige nie. Und hier können Sie sie nur durch die Unterstützung der Führung und die kollektive Autorität des restlichen Teams beeinflussen, das Sie unterstützen wird. Wenn Sie die besten Möglichkeiten kennen, teilen Sie!

Es gab auch eine interessante Frage, wie man sein soll, wenn man nur noch nicht weiß, wie man den Entwicklercode liest, kann man ihre Autotests nicht herausfinden.

Ich werde meine Antwort hier lassen, damit sie nicht verloren geht, vielleicht wird jemand nützlich sein. Wenn Sie es nicht lesen können, würde ich darauf bestehen, eine Liste der entwickelten Autotests in die PR-Beschreibung aufzunehmen und mich darauf zu konzentrieren. Ich glaube, dies ist das volle Recht und die Pflicht des QS-Teams, sich der Abdeckung des Produkts mit Autotests so bewusst wie möglich zu sein, da sonst die gesamte Idee der Qualitätssicherung verloren geht. Wenn wir die Situation schwerwiegender zeitlicher Einschränkungen des gesamten Teams, einschließlich des Entwicklers, berücksichtigen, würde ich auf der Überprüfung bestehen Abdeckung kritischer / strategischer Szenarien durch Autotests für die Integration. Für alle anderen Szenarien habe ich separate Aufgaben dokumentiert, um sie später auszuführen. In jedem Projekt gibt es ruhige Zeiten, in denen es keine Fristen gibt. Dann lohnt es sich, den Produktmanager / Teamleiter / Scrum Masters darauf zu konzentrieren, wie diese Aufgaben aufgenommen werden können: komplizierter - lassen Sie die Entwickler dies tun und lernen Sie die einfachsten selbst.

Fazit

Ich kann nicht sagen, dass alles, was oben geschrieben steht, Ihnen sicherlich helfen wird. Schließlich habe ich das Gefühl, dass meine eigene professionelle Stimme und mein Stil mit Erfahrung und durch verstopfte Unebenheiten einhergehen. Es ist unmöglich, das Arbeitsskript eines anderen über eine Schablone auf Ihr Projekt anzuwenden. Aber wenn mein Kritzeln Sie dazu veranlasste, sich nicht mit Momenten abzufinden, die Sie nicht mögen, und Sie Ideen im Kopf hatten, die Sie für sich selbst, für das Team, für das Produkt gut machen können, dann habe ich die Zeit nicht umsonst verbracht. Und ja, glaube nicht, dass ich QA Shark porträtiere, der alles weiß, alles weiß. Ich lerne und verändere mich ständig. Mir ist klar, dass sich meine Arbeitsprinzipien in einem Jahr ändern können. Immer sehr zufrieden mit Feedback und ich werde gerne aus Ihren Erfahrungen lernen, schreiben;)

Und wenn Sie etwas lesen möchten, um Ihre eigene Motivation zu stärken, beginnen Sie mit zwei wunderbaren Büchern, auf die ich im Text Bezug genommen habe:

1. Grundlagen des Softwaretests: ISTQB-Zertifizierung
von Dorothy Graham, Rex Black, Erik van Veenendaal und Isabel Evans
2. So testen Sie bei Google
James Whittaker, Jason Arbon und Jeff Carollo

Vielen Dank für Ihre Aufmerksamkeit!