Eine Geschichte über Programmierer und QA, die paarweise arbeiten. Erfahren Sie mehr über die Vorteile und Risiken, denen Sie auch nach der Implementierung von Pair Programming ausgesetzt sein können.
A QUICK SUMMARY – FOR THE BUSY ONES
Angesichts der Herausforderung eines schnell wachsenden Teams und der häufigen Aufgabenänderungen im Projekt haben wir natürlich Paartests eingeführt, um die komplexe Softwareentwicklung anzugehen. Bedürfnisse.
Spontane Interaktionen zwischen Entwicklern und QA-Experten führten zu signifikante Prozessänderungen, wobei beide Parteien zusammenarbeiten, um die Testmethoden zu verbessern.
Um Paartests offiziell einzuführen, haben wir die Vorteile und unseren Plan offen mit dem gesamten Team besprochen. Wir nutzten Videoanrufe für Diskussionen aus der Ferne in Echtzeit und haben für bestimmte Aufgaben einen QA-Spezialisten mit einem Entwickler zusammengebracht, wobei die gemeinsame Arbeit protokolliert wurde. Dieser Ansatz ist zwar nicht für alle Aufgaben geeignet, hat aber verbesserte Zusammenarbeit und Produktivität in unserem Arbeitsablauf.
TABLE OF CONTENTS
Im dynamischen Bereich der polnischen IT-Branche kollaborative Exzellenz steht mit dem Aufkommen von Paartests im Mittelpunkt.
Paartests gewinnen zwar an internationaler Beliebtheit, sind aber in unserer lokalen Umgebung nach wie vor ein relativ neues Konzept. Durch seine Umsetzung Wir haben eine Reihe von Vorteilen erlebt, aber dies stellte unsere Kunden auch vor einzigartige Herausforderungen innerhalb unseres ausgereiften Softwareentwicklungsmodells.
Dieser Artikel bietet einen exklusiven Einblick in unsere Erfahrungen mit Pair-Tests aus erster Hand und enthüllt deren tiefgreifenden Einfluss und transformativen Einfluss auf Softwareentwicklungspraktiken.
Fangen wir von vorne an.
Fast von Beginn des neuen Großprojekts an standen wir vor einer außergewöhnlichen Herausforderung - ein enormer Arbeitsumfang zu Beginn, der von der frühen Entwurfsphase an umfassend umgesetzt werden musste, wobei nur sehr wenig Spielraum für Fehler bestand.
Zur gleichen Zeit das Team wuchs schnell, und als der Kunde zufrieden war, übertrug er uns noch mehr Aufgaben, was dazu führte, dass neue Teammitglieder hinzukamen.
In der kurzen Zeit seit Beginn des Projekts waren bereits mehrere Personen auf verschiedenen Ebenen beteiligt: erfahrene Full-Stack-JS-Spezialisten, DevOps-Experten, Geschäftsanalysten und natürlich ein kleines QA-Team. Wie so oft bestand das Team aus Personen mit unterschiedlichen Erfahrungen aus früheren Unternehmen und Projekten, jeweils mit ihre eigenen Präferenzen für Tools, Lösungen und Arbeitsmethoden.
Diese Situation erforderte die Annahme einer ausgeklügelter und experimenteller Ansatz für das Projektmanagement.
Unsere Kunden sind stark in den Produktentwicklungsprozess eingebunden, und wir kommunizieren häufig mit ihnen, holen ihren Input ein und beraten sie zu besseren Lösungen.
Auf der einen Seite ist dies ein Vorteil, da sie uns Folgendes bieten können schnell wertvolles Feedback und überprüfen kontinuierlich ihre Anforderungen. Auf der anderen Seite führte die Zusammenarbeit mit diesem speziellen Kunden zu häufige Änderungen vorhandener Aufgaben, was die Komplexität des Projekts und die damit verbundenen Abhängigkeiten erhöht.
Wenn ich jetzt zurückblicke, kann ich kaum glauben, wie spontane Interaktionen zwischen Teammitgliedern zu so signifikanten Prozessänderungen führen können.
Der Fall unseres Teams ist ein ziemlich interessantes Beispiel, von dem ich glaube, dass es in den meisten ähnlichen Projekten vorkommen kann. Alles begann ganz unschuldig mit einem regelmäßige Videokonferenzsitzung zwischen einem neuen QA-Mitglied und einem erfahrenen Entwickler - nichts Außergewöhnliches, so schien es zumindest.
Es hätte auch nur ein anderer Entwickler sein können, der einem Mitglied des QA-Teams erklärt hat, wie man eine bestimmte komplexe Backend-Funktionalität testet. Die Interaktion wurde jedoch so intensiv, dass entwickelte sich zu einem Gespräch, das nicht nur über die Funktionalität selbst ging aber auch darüber, wie man Tests dafür schreibt, wann man das macht und welche Techniken und Tools man verwendet.
Es Am Ende arbeiteten beide in derselben Branche, wo sie über eine vollständig implementierte und getestete Funktionalität mit API-Tests und Komponententests verfügten.
Zu dieser Zeit nannten wir es nicht offiziell Paartest, aber es löste eine faszinierende Dynamik aus.
Die Entwickler erkannten die Vorteile dieser kollaborativen Sitzungen und fragten die QA, wie sie Tests verbessern könnten, wenn sie helfen könnten und ob sie letztendlich buchstäblich ein paar Stunden zusammensitzen und eine Aufgabe von A bis Z erledigen wollten.
Wir begannen eine zu sehen gegenseitiges Bedürfnis, das die Grenzen unserer traditionellen Rollen, wie in unseren Lebensläufen angegeben, überschritten hat.
Schließlich begannen wir, regelmäßig gemeinsam an neuen Tests zu arbeiten, bestehende zu verbessern, sie zu pflegen und ungedeckte Testszenarien zu identifizieren. Dies war eine natürliche Folge unserer immer häufigeren Zusammenarbeit.
Entwickler und QA fingen einfach an, paarweise zu arbeiten.
Seitdem wir angefangen haben, paarweise an Tests zu arbeiten, haben wir eine Vielzahl von Vorteilen beobachtet.
In erster Linie haben wir festgestellt, dass wir Aufgaben viel schneller erledigen, und sie sind von höherer Qualität. Dies ist vielleicht das beste und wertvollste Ergebnis, das durch Paartests erzielt werden kann. Durch die Kombination der einzigartigen Fähigkeiten eines Testers und eines Entwicklers können wir Aufgaben effizienter ausführen.
Dank dieses neuen Ansatzes haben wir jetzt mehr Tests und Testfälle. Gemeinsam können wir während der Codierungsphase mehr potenzielle Probleme identifizieren, was sich letztendlich in folgenden Punkten niederschlägt Vollständigkeit unserer Tests.
Wir wickeln Tests mühelos ab und fügen neue hinzu auf verschiedenen Ebenen: API-Tests, Ende-zu-Ende-Tests, Integrationstests, Komponententests, und selbst in letzter Zeit haben wir Zeit für visuelle Tests gefunden.
Darüber hinaus hat die Arbeit im Pair-Testmodell, bei dem QA und Entwickler an einem einzigen Branch in unserem Monorepo zusammenarbeiten, Konflikte bei Merges oder Pull-Requests erheblich reduziert, weil wir beide arbeiten gleichzeitig an derselben Sache.
Ein weiterer spürbarer Vorteil ist die Reduzierung der Anzahl der gemeldeten Fehler nach der Veröffentlichung einer neuen Version der Anwendung. Das spart Zeit, weil anstatt verzweifelt Bugs in der Produktion zu patchen, können wir uns in Ruhe auf neue Funktionen und bevorstehende Aufgaben konzentrieren.
Man könnte sagen, dass wir während des kollaborativen Testens oder Testschreibens sogar eine Art frühes Code-Review durchführen. Wir fangen häufig Probleme im Code des jeweils anderen in den frühen Phasen der Codierung auf.
Darüber hinaus hat sich unsere Lieferzykluszeit für Aufgaben, die im Rahmen der Paarprogrammierung durchgeführt werden, merklich verkürzt. Bisher waren Programmierung und Testen oft separate Phasen, was den gesamten Prozess verlängerte. Jetzt, mit unserem neuen Ansatz, diese beiden Phasen greifen ineinander und laufen gleichzeitig ab, was zu kürzeren Implementierungszeiten und einer schnelleren Bereitstellung von Funktionen führt.
Paarprogrammierung hat sich als unschätzbares Instrument zur Reduzierung von Kontextwechsel erwiesen — ein Phänomen, das in der Regel die Arbeitseffizienz beeinträchtigt. Da Programmierer und Tester gemeinsam an einer einzigen Aufgabe arbeiten, müssen sie ihren Fokus nicht ständig ändern und zwischen verschiedenen Aufgaben wechseln. Das macht unnötige Ausfallzeiten wie das Einrichten von Umgebungen oder Datenbankmigrationen überflüssig und ermöglicht es ihnen, sich auf ein Problem zu konzentrieren. Ich bin der festen Überzeugung, dass Paarprogrammierung ein wirksames Mittel ist, um die negativen Auswirkungen von Kontextwechsel zu minimieren.
Natürlich können Paartests, wie jede neu eingeführte Technik, zunächst Nachteile zu haben scheinen. Es mag wie eine Verschwendung von Ressourcen erscheinen, wenn zwei Personen gleichzeitig an derselben Aufgabe arbeiten.
Jedoch Wenn wir die Ergebnisse dieser Methode betrachten, wird klar, dass es sich um eine Investition handelt, die uns auf lange Sicht weitaus größere Vorteile bringt.
Paartests sind in einfachen Worten:
Die Praxis des Paartests, bei der zwei Personen an einer einzigen Aufgabe zusammenarbeiten, um sie umfassend zu erstellen und zu testen.
In der Regel eine Person ist ein Testspezialist, während die andere ein Programmierer ist, der die technischen Aspekte der Anwendung versteht. Es ist erwähnenswert, dass dies keine strenge Regel ist, da es Fälle gibt, in denen mehr Personen an solchen Arbeiten beteiligt sind, beispielsweise Geschäftsanalysten.
Während des kollaborativen Testens wurde Der Tester hat die Möglichkeit, die detaillierten technischen Aspekte der Anwendung zu verstehen, gewinnen breitere Perspektiven, erweitern ihr Fachwissen und gewinnen ein besseres Verständnis der Funktionsweise des Systems.
Auf der anderen Seite Der Programmierer sieht die Anwendung mit den Augen des Testers, was ihm hilft, die Erwartungen und Qualitätsanforderungen an seinen Code besser zu verstehen.
Darüber hinaus fördern Paartests eine bessere Kommunikation, einen besseren Wissensaustausch und ein besseres Verständnis zwischen den Teammitgliedern und sorgen so für einen effizienteren Arbeitsablauf.
Ich möchte mit Ihnen teilen, was wir geändert haben und wie wir eine Einigung in Bezug auf Paartests erzielt haben. Die Änderung war nicht einfach, aber wie bei allem direkte Kommunikation war der Schlüssel.
Ich begann damit, alle Teammitglieder, sowohl technische als auch nichttechnische, über unsere Pläne zu informieren. Wir haben erklärt, was Pairtesting ist, welche Vorteile es bringen kann und wie wir es implementieren wollten.
Als überwiegend ortsunabhängiges Team haben wir während unserer regelmäßigen Kommunikation auf Messaging-Plattformen damit begonnen, Videoanrufe zu organisieren. Dies ermöglichte es uns, Gespräche in Echtzeit zu führen. Im Zeitalter der Telearbeit ist dieser Aspekt entscheidend, um Ideen auszutauschen und Unsicherheiten vor Ort zu klären.
Das haben wir gemerkt einige Aufgaben waren so umfangreich, dass es bei der Sprint-Planung oder beim Backlog-Review sinnvoll war, eine QA über einen längeren Zeitraum mit einem Entwickler zu verbinden.
Wir entschieden, dass unabhängig davon, wer mit einer bestimmten Aufgabe beauftragt wurde, beide Personen würden ihre Arbeitszeit protokollieren. Warum? Weil wir beide Mühe und Zeit dazu beitragen. Auf diese Weise stimmt alles überein und niemand hat fehlende Stunden, und unser Zeiterfassungstool zeigt wunderbar, wer was und wann in einer Aufgabe erledigt hat.
Abschließend möchte ich hinzufügen, dass sich Paartests zwar als wirksames Instrument erwiesen haben, nicht jede Aufgabe eignet sich für diese Art der Arbeit. Natürlich führen wir die meisten Aufgaben immer noch im normalen Modus aus, und wir verwenden Paartests als hervorragende Ergänzung, bei der wir am meisten von dieser intensiven Zusammenarbeit profitieren können.
Die Paartesttechnik hat uns gezeigt, dass es sich lohnt, im Streben nach Qualität manchmal unkonventionelle Schritte und Entscheidungen treffen, natürlich in Absprache mit dem gesamten Team und dem Kunden.
Deshalb haben wir Ermutigen Sie alle, die daran interessiert sind, ihren Testprozess zu verbessern, mit Paartests zu experimentieren. Es kann einige Änderungen in der Teamarbeit erfordern, aber die Endergebnisse werden Sie definitiv davon überzeugen, diesen Ansatz zu verfolgen.
Scheuen Sie sich also nicht, neue Techniken auszuprobieren, zu erforschen und zu erlernen, die sich ständig weiterentwickeln.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Senior QA Engineer mit 12 Jahren Berufserfahrung.
Senior QA Engineer mit 12 Jahren Berufserfahrung.
Read next
Popular this month
previous article in this collection
It's the first one.
