Welche Programmierkenntnisse benötigt jemand in der Qualitätssicherung, um in extremen Programmierprojekten effektiv arbeiten zu können?

Nun, der Titel sagt wirklich alles, aber um ein wenig näher darauf einzugehen, können Sie eine zufällige, normalerweise effektive QS-Abteilung nehmen und sie lernen lassen, in einer XP-Umgebung zu arbeiten (mit einer Lernkurve, um den XP-Workflow zu erlernen) oder Würden sie mehr Programmierkenntnisse benötigen, um effektiv zu sein? Wenn ja, was müssten sie wissen?

QA Team Konvertierung auf XP?

Diese Frage, die Sie stellen, ist eine, von der viele traditionelle Tester abhängen, um ihre Karriere zu überleben.

Kurze Antwort ist vielleicht. Sie haben Recht, den Arbeitsablauf als Problem zu identifizieren, aber der Arbeitsablauf ist im Vergleich zu Schulungen für Programmierung und Entwicklung einfach. Tester zu Programmierern zu machen, kann eine Brücke zu weit sein. Es gibt viele andere Fähigkeiten, die eine engere Beziehung zu den aktuellen Fähigkeiten Ihrer Tester haben.

Ich denke, es gibt eine Rolle für Software-Testingenieure, aber zwei neue Kreaturen sind vor Ort, der Test Driven Developer und der Software Development Engineer in Test, die eine Menge Rasen übernehmen werden, der früher zur STE gehörte.

XP-Workflow

Bei einem XP-Workflow liegt der Unit-Test in der Verantwortung des Entwicklers. In der Regel umfasst der Workflow das Erstellen der Story Card, das Ausarbeiten eines Anwendungsfalldiagramms und einiger Anwendungsfälle und das anschließende Verwandeln dieser in Testfälle. Die Testfälle würden die Entwicklung in einer Methodik namens Test Driven Development (TDD) vorantreiben. In jeder Minute, in der das Programm vorhanden ist, muss zuerst ein Testfall implementiert werden, gefolgt von einem Code, der zunächst fehlschlägt. Nach zusätzlicher Arbeit besteht dieser Test. Wenn alle auf den Story Cards identifizierten Tests bestanden sind, ist das Produkt fertig. Oder zumindest ist das letzte Inkrement fertig. Unit-Tests werden sprachabhängig erstellt und sind Teil des Codes. Es gibt viele Referenzen, aber für eine kurze Einführung überprüfen Sie Wikipedia, dann die folgende Webseite von Scott Ambler.

http://www.agiledata.org/essays/tdd.html#WhatIsTDD

Es gibt auch erhebliche Überschneidungen mit den Systemakzeptanztests, da die Testfälle aus den Story Cards und Anwendungsfällen stammen. ATDD (Acceptance TDD) macht eine Unterscheidung, aber ich denke, es könnte irgendwie willkürlich sein.

Nicht jeder nimmt Tests mit gleichem Ernst. Manager können Entwickler dazu drängen, nicht zu testen. Sie können darauf drängen, dass Tester nicht auch testen. Ich war ein Jahr lang ziemlich hart im Nehmen, als die Entwickler in meinem Team ungefähr im Budget waren, aber die Tester des Projekts testeten mehrere Stunden pro Woche Fehlerbehebungen und neue Funktionen, obwohl sie nach dem Projektplan am Ende nur zwei Wochen arbeiteten. Es schien das Richtige zu sein, und das Projekt war immer noch rentabel und die Kunden hatten ein besseres Produkt.

Entwickler müssen testen. Es ist sehr verschwenderisch, wenn dies nicht der Fall ist, da Tester ausgeführt, gemeldet und wiederholt werden müssen. Die Softwarequalität liegt nicht weniger in der Verantwortung der Entwickler als der Tester. Dieses Teilen sollte das Leben des Testers weniger frustrierend machen, aber es erhöht auch die Nachfrage nach viel Wissen und Können für alle.

Wenn Entwickler das Testen nicht ernst nehmen, können sich die Anforderungen an die Tester erhöhen, da Sie täglich Builds erhalten. Für eine Weile hört man vielleicht Leute sagen: "Warum scheinen wir einen Schritt vorwärts und zwei Schritte zurück zu machen?" Die Antwort wird sein, dass Sie jetzt ein System verwenden, bei dem das Team eine Sichtbarkeit hat, wie sie es noch nie zuvor hatte, und bevor diese Leute erst bei der 90% -Marke über die bevorstehende Katastrophe Bescheid wussten.

Die Verlagerung des Testens auf Entwickler

Ich habe die Erfahrung gemacht, dass es zur Beschleunigung der Entwicklung hilfreich sein kann, von Testern erledigte Aufgaben in die Entwicklung zu verlagern. Dies gilt für alles, vom Testen der Benutzeroberfläche eines Touchscreens bis zum Testen des Windows Hardware Quality Lab eines sehr komplexen Elements wie eines Windows-Treibers für WLAN.

Betrachten Sie Tage vor dem PC, an denen Ingenieure einer Sekretärin Memos und technische Informationen diktierten, um sie zu tippen, zu duplizieren und zu verteilen. Vergleichen Sie dies mit einem Entwickler, der E-Mail, ein Intranet-Wiki, Kommentare in den Tools zur Fehlerverfolgung, Quellcodeverwaltung oder Codeüberprüfung, Instant Messaging usw. verwendet. Wir haben einfach zu viele Änderungen, die wir testen müssen, und die damit verbundene Kommunikation und der Wissenstransfer sind so Es ist entmutigend, dass ein Großteil unserer Tests für die direkte Implementierung durch Entwickler ohne Delegierung zum Testen automatisiert ist.

Mehrwert für Tester

Ich habe mit einigen Testern gearbeitet, die Systemingenieure sein könnten, und mit einigen, die verrückte gute Kommunikationsfähigkeiten haben (fast Gedankenlesen / Telepathie). Meine effektivste Arbeit mit ihnen war, wenn sie gute Arbeit geleistet haben, um unerwartetes Verhalten zu erklären, das sie im System gesehen haben, normalerweise schriftlich im Bug-Tracker, obwohl oft eine Demonstration äußerst hilfreich war.

Ein weiteres wichtiges Kriterium ist, dass der Aufwand für eine Codeübergabe so gering wie möglich war. Für eine Weile waren die Entwickler erleichtert, als Tester ihre eigenen Builds erstellen konnten. Jetzt verwenden wir Server mit konstanter Integration, sodass Entwickler nur die Quelle festschreiben müssen. Sofern wir TDD richtig verwendet haben, gibt es viele Tests, die sich selbst ausführen und zurückmelden.

Der globale Wettbewerb verschiebt die Zykluszeiten und die Nacharbeit wird aus dem System heraus überarbeitet. Wenn ich morgen von einem Tester von einem Defekt höre, den ich heute hinzugefügt habe, wie kann ich dann mit dem Typ konkurrieren, der heute keinen Defekt gemacht hat (oder ihn selbst gefunden hat)? Wir sind noch nicht da, aber ich denke, die Tage der Cut-and-Try-Programmierer sind gezählt. Ich habe Demos von Google-Entwicklern gesehen, die vielleicht viel geprobt haben, aber sie scheinen in der Lage zu sein, ein Programm von Anfang bis Ende während einer 90-minütigen Vorlesung einzugeben, und erklären, wie sie mit wenigen oder keinen Problemen im Änderungs- und Ausführungszyklus tippen . Tester schaffen Mehrwert, indem sie die Zeit zwischen Arbeit und Nacharbeit verkürzen. Daher ist eine frühzeitige, präzise Berichterstattung über den heutigen Build ein großes Plus.

Neue Testrollen

Viele Organisationen entwickeln Rollen für SDET - Software Developer Engineer in Test. Diese Jungs schreiben Skript, Code und Code. Der folgende Link führt zu einem Blog für ein SDET bei Microsoft.

http://aliabdin.wordpress.com/2007/03/31/what-does-an-sdet-do/

Er beschreibt auch Software Test Engineers (STE), die die gefundenen Fehler an SDET weiterleiten. Eine andere Sache, die mich an der SDET-Rolle beeindruckt hat, ist, dass sie im Gegensatz zu herkömmlichen Softwareentwicklern bei fehlerhaften Systemen Code für das gesamte System kennen müssen, da fast jeder Teil die Ursache des Problems sein kann. Daher hilft ihnen die umfangreiche mentale Karte finde es auf.

Eine Vision entwickeln, die zu einem erfolgreichen Übergang führt

Ich habe ein ähnliches Problem mit einem Projektmanager festgestellt, der nicht weiß, wie er diese Rolle in Scrum einpassen soll. Scrum Master zu sein war ihr Übergangsziel. Es ist eine klar definierte Rolle, und es gibt Schulungen dafür. Suchen Sie weiter und finden Sie möglicherweise etwas Ähnliches zum Testen.

Weitere Informationen zu agilen Tests finden Sie hier:

http://www.ambysoft.com/essays/agileTesting.html#AgileTestingStrategies

und über das unabhängige Testteam hier:

http://www.ambysoft.com/essays/agileTesting.html#IndependentTestTeam

Scott Amblers Beobachtungen über das Verhältnis von Entwicklern zu Testern in agilen und traditionellen Ansätzen werden Ihren Tag nicht bereichern (15: 1 vs. 3: 1). Ich würde vorschlagen, eine Vision für Ihr Testteam zu verstehen und zu erstellen, die auf den Fähigkeiten und Fähigkeiten der Fachkräfte basiert:

• Vollständige Sprachkompetenz mit Bug-Tracker.
• Grundlegendes zu Quellcodeverwaltungskonzepten auf Entwicklerebene wie Commit, Branch, Tag.
• Sie können Berichte über Code-Commits und deren Kommentare vom Quellcodeverwaltungssystem ausführen.
• Lernen Sie, Entwickler zu entschlüsseln, sprechen Sie in Commit-Kommentaren und ordnen Sie sie dann der Benutzeroberfläche zu, und manuelle Tests werden nicht automatisch ausgeführt.
• Holen Sie sich das Verständnis eines Systemingenieurs für das System, helfen Sie jedoch dabei, zu klären, was nicht dokumentiert und mehrdeutig ist, anstatt Entscheidungen zu treffen.
• Machen Sie einen täglichen Zyklus mit Entwicklern. Dies kann eine viel häufigere und schnellere Neukonfiguration der getesteten Geräte und Testwerkzeuge bedeuten.
• Abhängig von Ihrer Umgebung verwenden Entwickler möglicherweise ein viel breiteres Toolset als Tester. Wenn Ihr Labor das hat, was es verwendet, ist es schmeichelhaft und eine gastfreundlichere Umgebung für Face-Time- und Ad-hoc-Schulungen von Entwicklern. Beispiele hierfür sind die Verwendung von Managern und VMs für virtuelle Maschinen, Remote-Debugging oder -Diagnose über Netzwerke mit SSH oder Remotedesktop, die Möglichkeit, den Gerätestatus oder das Erscheinungsbild der Benutzeroberfläche durch Bildschirmaufnahme oder durch Aufnehmen eines Fotos mit einer Kamera oder einem Smartphone zu speichern und sich anzumelden Netzwerkverzeichnisse oder USB-Sticks.
• Vorläufige Analysen unter Verwendung von Protokolldaten wurden in Tabellenkalkulationen verschoben und in Diagramme umgewandelt. Es wird viel über Big Data geschrieben, und manchmal kann die Testausgabe von Labor- oder Betatestseiten Big Data sein.
• Erfahren Sie, wie Sie die Kundenschnittstelle während des Betatests vereinfachen. Dies kann das Abrufen von Protokolldateien durch Dokumentieren und Trainieren von Kunden über das Telefon umfassen, oder es kann in ein automatisiertes System eingebunden sein, das Crash-Dumps direkt an den Entwickler (oder an Sie, wenn Sie die Fähigkeit zur Triage haben) liefert.
• Unterstützen Sie die quantitative Analyse von Produkten auf Software- und Systemebene (wie zuvor, aber möglicherweise sogar noch mehr).
• Suchen Sie nach Möglichkeiten, um Entwicklern bewusst zu machen, wie viele verschiedene Testmethoden und -tools Ihnen zur Verfügung stehen und welche Funktionen gut geeignet sind, um ihre Arbeit anzufordern. Dies ist nicht nur am Ende des Projekts, sondern wöchentlich oder täglich qualitätsgesichert.
• Fragen Sie die Entwickler in Ihrem Unternehmen, welche Vision sie haben, wie Tester ihnen helfen können. Es sollte gut gehen, wenn Sie sich bisher gegenseitig beobachtet haben. Sie sollten großartige Ideen zusammen bekommen.

Viel Glück beim Übergang zu XP und bei der Vorbereitung Ihres Teams darauf.

Für eine typische testgetriebene Entwicklung ist es wahrscheinlich nicht erforderlich, dass Ihre Qualitätssicherungen überhaupt keine Programmierung kennen.

Wenn Sie jedoch eine verhaltensorientierte Entwicklung durchführen, ist es für Ihre Qualitätssicherung von Vorteil, eine Sprache wie Cucumber zu kennen . Insbesondere, wenn Ihre Geschäftsanalysten Story-Anforderungen im Given-When-Then-Stil schreiben.

Es hängt jedoch wirklich von Ihren „Mitarbeitern“ und den Tools ab, mit denen Sie arbeiten. Ich würde sagen, es ist möglich, dass sie ohne Programmierkenntnisse effektiv sind, aber es würde sicherlich nicht schaden und sie möglicherweise effektiver machen.