In agil wie Entwicklung sollte, die Testfälle schreiben? [geschlossen]

https://stackoverflow.com/questions/194790

10-07-2019
|

Frage

Unser Team hat ein Task-System, wo wir kleine inkrementelle Aufgaben zu jedem Entwickler zugewiesen posten.

Jede Aufgabe in einer eigenen Niederlassung entwickelt wird, und dann wird jeder Zweig getestet, bevor sie an den Stamm zusammengeführt werden.

Meine Frage lautet: Ist die Aufgabe erledigt ist, der sollte die Testfälle definiert , die auf dieser Aufgabe getan werden sollte?

Im Idealfall ich denke, die Entwickler der Aufgabe selbst ist am besten geeignet für den Job, aber ich habe viel Widerstand von den Entwicklern hatte, die denken, es ist eine Verschwendung von ihrer Zeit, oder dass sie einfach nicht mögen, es zu tun.

Der Grund Ich mag es nicht meine QA Menschen es tun haben, ist, weil Ich mag die Idee nicht von ihnen ihre eigene Arbeit zu schaffen. Zum Beispiel könnten sie Dinge weglassen, die einfach zu viel Arbeit zu testen sind, und sie können nicht die technischen Details wissen, die benötigt wird.

Aber auch die nach unten Teil der Entwickler die Testfälle zu tun, ist, dass sie die Dinge auslassen kann, dass sie brechen denken. (Auch unbewusst vielleicht)

Als Projektmanager, landete ich für jede Aufgabe der Testfälle Schreiben auf mich, aber meine Zeit wird besteuert, und ich möchte, dies ändern.

Verbesserungsvorschläge?

EDIT: Mit dem Testfall ich die Beschreibung der einzelnen QA Aufgaben bedeuten, die den Zweig getan werden sollte, bevor es den Stamm zusammengeführt werden soll. (Black Box)

Lösung

Das Team.

Wenn ein Defekt an einem Kunden bekommt, ist es das Team Fehler, daher das Team sollte Testfälle zu schreiben, um sicherzustellen, dass Fehler nicht erreichen die Kunden.

Der Projektmanager (PM) sollte die Domain besser als jeder andere im Team verstehen. Ihre Domain-Wissen ist vital Testfälle mit, den Sinn in Bezug auf die Domain zu machen. Sie müssen beispielsweise Eingaben geben und Fragen über die Erwartungen an ungültigen Eingaben zu beantworten. Sie müssen zumindest, um den ‚glücklich Pfad‘ Testfall.
Die Entwickler (s) wird den Code kennen. Sie deuten darauf hin, die Entwickler für die Aufgabe am besten sein kann, aber dass Sie Blackbox Testfälle suchen. Jegliche Versuche, die ein Entwickler kommt mit sind White-Box-Tests. Das ist der Vorteil, dass Entwickler von Testfällen schaffen - sie wissen, wo die Nähte im Code sind.

Gute Entwickler auch mit Fragen an die PM kommen „Was geschehen soll, wenn ...?“ - jeder von ihnen ist ein Testfall. Wenn die Antwort ist komplex "Wenn a und x , aber wenn b und y , außer donnerstags" - gibt es mehrere Testfälle.
Die Tester (QA) wissen, wie Software zu testen. Tester sind wahrscheinlich mit Testfällen kommen, dass die PM und die Entwickler würden nicht denken - das ist, warum Sie Tester haben

Andere Tipps

ich glaube, der Projektmanager oder Business Analyst sollten diese Testfälle schreiben.
Sie sollten sie dann auf die QS-Person übergeben zu konkretisieren und zu testen.

Auf diese Weise kann keine fehlenden Lücken zwischen der Spezifikation gewährleisten, und das, was tatsächlich getestet ist und ausgeliefert.

Der Entwickler sollte auf jeden Fall es nicht tun, da sie ihre Unit-Tests testen werden. So ist es eine Verschwendung von Zeit.

Neben diesen Tests werden Fehler finden, das der Entwickler niemals finden, da sie wahrscheinlich auf ein Missverständnis in der Spezifikation oder ein Merkmal oder eine Route durch den Code nicht korrekt durch und umgesetzt gedacht wurde.

Wenn Sie feststellen, Sie haben nicht genug Zeit dafür, mieten jemand anderes oder jemand fördern auf diese Rolle, da es ein hervorragendes Produkt zu liefern. Schlüssel ist

Wir experimentierten mit einer Paarung des Entwicklers mit einer QA Person mit recht guten Ergebnissen. Sie ‚gehalten sich ehrlich‘ im Allgemeinen und da die Entwickler Unit-Tests hatten den Code zu handhaben, er / sie mit den Veränderungen ganz intim war schon. Die QA Person war nicht aber kam es aus der Blackbox Seite. Beide waren verantwortlich für die Vollständigkeit gehalten. Ein Teil des laufenden Überprüfung Prozesses dazu beigetragen, Unit-Test Mängel zu fangen und so gab es nicht zu viele Vorfälle, dass ich weiß, wo jemand absichtlich vermied X Test zu schreiben, weil es wahrscheinlich beweisen, gäbe es ein Problem aufgetreten.

Ich mag die Idee Paarung in einigen Fällen und denke, es ist ziemlich gut funktioniert. Vielleicht nicht immer, aber die Spieler aus verschiedenen Bereichen, die interagieren half die Mentalität ‚es über die Mauer werfen‘ zu vermeiden, die oft passiert.

Wie auch immer, hoffen, dass Sie irgendwie nützlich ist.

Aus der Vergangenheit hatten wir ziemlich viel Glück Tests auf verschiedenen Ebenen definieren, leicht verschiedene Dinge zu testen:

1. Stufe: Bei der Code / Klasse Ebene sollten Entwickler Atom Unit-Tests schreiben. Der Zweck ist, einzelne Klassen und Methoden so weit wie möglich zu testen. Diese Tests sollten von den Entwicklern, wie sie Code ausgeführt werden, vermutlich vor Code Archivierung in die Quellcodeverwaltung, und durch eine kontinuierliche Integration Server (automatisiert), wenn man verwendet wird.

2. Stufe: Auf der Komponentenintegrationsebene, haben wieder Entwickler Unit-Tests schaffen, sondern dass Test der Integration zwischen den Komponenten. Der Zweck ist, nicht einzelne Klassen und Komponenten zu testen, aber zu testen, wie sie miteinander interagieren. Diese Tests sollten manuell durch eine Integration Ingenieur ausgeführt werden, oder automatisiert durch eine kontinuierliche Integration seerver, wenn man in Gebrauch ist.

3. Stufe: Auf der Anwendungsebene, haben das QA-Team ihre Systemtests ausgeführt werden. Diese Testfälle sollten die Unternehmen werden Annahmen oder Anforderungsdokumente zur Verfügung gestellt von einem Produktmanager basiert. Grundsätzlich Test, als ob Sie ein Endbenutzer, tun die Dinge, Endbenutzer sollten zu tun, wie dokumentiert int eh Anforderungen der Lage sein. Diese Testfälle sollten von der QA-Team und die Produktmanager geschrieben werden, die (vermutlich) wissen, was der Kunde will und wie sie die Anwendung verwenden erwartet.

Ich finde, dass das einen ziemlich guten Deckungsgrad bietet. Natürlich Stufe 1 und 2 im Idealfall vor dem Senden über eine integrierte Anwendung auf das QA-Team ausgeführt werden sollen. Natürlich können Sie diese anpassen, was auch immer Ihr Geschäftsmodell passt, aber das funktionierte ziemlich gut bei meinem letzten Job. Unser kontinuierliche Integration Server würde eine E-Mail an das Entwicklungsteam zu, wenn eine der Unit-Tests auch während des Build / Integrationsprozesses fehlgeschlagen ist, Incase jemand ihre Tests vergessen zu laufen und begangen gebrochen Code in das Quellarchiv.

„Entwickler, die denken, dass es eine Verschwendung ihrer Zeit ist, oder dass sie einfach nicht mögen, es zu tun“ belohnen Dann sie dafür. Welche Social Engineering ist notwendig, um sie Testfälle zu erstellen?

Kann QA Blick über den Code und Testfällen und sprechen Sie „Nicht genügend Deckung - benötigen Sie mehr Hüllen“. Wenn ja, dann wird der Programmierer, dass „genug“ Abdeckung hat sofort wird der Big Kahuna sein.

Also, meine Frage ist: Wenn die Aufgabe erledigt ist, der sollte das Ziel, „genug“ Testfälle für diese Aufgabe definieren? Sobald Sie wissen, „genug“, können Sie die Programmierer für das Ausfüllen „genug“ verantwortlich machen und QA dafür verantwortlich, dass „genug“ Tests durchgeführt wird.

Zu hart „genug“ zu definieren? Interessant. Wahrscheinlich ist dies die Ursache für den Konflikt mit den Programmierern an erster Stelle. Sie könnten das Gefühl, es ist eine Verschwendung ihrer Zeit ist, weil sie schon „genug“ tat und jetzt jemand sagt, es ist nicht „genug“.

die QA Menschen, in Verbindung mit der „Kunde“, sollte definieren die Testfälle für jede Aufgabe [wir wirklich Terminologie hier Mischen] und der Entwickler sollte sie schreiben. zuerst!

Der Grund Ich mag es nicht meine QA Menschen es tun haben, ist, weil Ich mag die Idee nicht von ihnen ihre eigene Arbeit zu schaffen. Zum Beispiel könnten sie Dinge weglassen, die einfach zu viel Arbeit zu testen sind, und sie können nicht die technischen Details wissen, die benötigt wird.

Huch, müssen Sie mehr Vertrauen in Ihrer QA-Abteilung haben, oder einen besseren. Ich meine, vorstellen, von euch gesagt hatte: „Ich nicht wie meine Entwickler-Software entwickeln zu müssen. Ich mag die Idee nicht von ihnen ihre eigene Arbeit zu schaffen.“

Als Entwickler, ich weiß, dass es Risiken in schriftlicher Form meine eigenen Tests beteiligt sind. Das ist nicht zu sagen, dass ich das nicht tun, dass (ich tun, vor allem, wenn ich TDD tue), aber ich habe keine Illusionen über die Testabdeckung. Entwickler werden Tests schreiben, die zeigen, dass ihr Code tut, was sie denken, es tut. Nicht zu viele werden Tests schreiben, die auf den tatsächlichen Business Case zur Hand gelten.

Das Testen ist eine Fertigkeit, und hoffentlich Ihre QA-Abteilung, oder zumindest, die Führer in dieser Abteilung, sind in dieser Fähigkeit versiert.

Wählen Sie (nicht nur wählen zufällig) ein oder zwei Tester, und lassen Sie sie die Testfälle schreiben. Rezension. Es könnte auch nützlich sein, wenn ein Entwickler mit einer Aufgabe arbeitet bei den Testfällen für die Aufgabe aussieht. Ermutigen Tester Verbesserungen und Ergänzungen Test-Sets vorschlagen - manchmal Menschen Angst haben, zu beheben, was der Chef tat. So kann man vielleicht jemanden, der bei Testdesign gut finden.

Lassen Sie die Tester wissen über die technischen Details - Ich denke, jeder in einem agilen Team soll Zugriff auf Code gelesen hat, und was auch immer Dokumentation zur Verfügung. Die meisten Tester kann ich wissen, lesen (und schreiben) Code, so könnten sie ihnen Unit-Tests nützlich, möglicherweise sogar verlängern finden. Stellen Sie sicher, dass die Testdesigner bekommen nützliche Antworten der Entwickler, wenn sie müssen etwas wissen.

würde Mein Vorschlag sein, dass jemand anderes die Testfälle durchsehen, bevor der Code zusammengeführt wird Qualität zu gewährleisten. Zugegeben kann dies bedeuten, dass ein Entwickler anderen Entwicklers Arbeit mit Blick aber, dass die zweite Reihe von Augen fangen kann etwas, das nicht von Anfang an gefangen wurde. Die ersten Testfälle können von jedem Entwickler, Analyst oder Manager erfolgen, kein Tester.

QA sollte die Testfälle nicht schreiben, wie sie Situationen geben kann, in denen das erwartete Ergebnis nicht definiert wurde und von diesem Punkt kann es schwierig sein, jemanden Schiedsrichter zwischen QA und Entwicklung zu haben, wenn jede Seite ihre Interpretation denkt, ist die Richtige. Es ist etwas, ich habe viele, viele Male gesehen und wollen es nicht so oft das passiert, wie es der Fall ist.

ich meine Tests lose brechen in „Entwickler“ Tests und „Kunde“ Tests, von denen die letztere wäre „Abnahmetests“. Erstere sind die Tests, die Entwickler schreiben, um zu überprüfen, dass ihr Code korrekt ausführt. Die später sind Tests, dass jemand andere als Entwickler schreibt, dass das Verhalten, um sicherzustellen, entspricht die Spezifikation. Die Entwickler müssen nie , schreiben die accepatance Tests, weil ihre Erstellung der Software, die sie Tests sind davon ausgegangen, dass sie das Richtige tat. So werden ihre Abnahmen wahrscheinlich gehen zu behaupten, was der Entwickler bereits wußte, um wahr zu sein.

Die Akzeptanztests sollten von der Spezifikation angetrieben werden, und wenn sie vom Entwickler geschrieben sind, werden sie durch den Code erhalten angetrieben und somit durch das aktuelle Verhalten, nicht das gewünschte Verhalten.

Die Agile Kanon ist, dass Sie (mindestens) sollten zwei Schichten von Tests: Entwicklertests und Kundentests.

Entwicklertests ist mit den gleichen Leuten geschrieben, die den Produktionscode schreiben, vorzugsweise unter Verwendung von Test Driven Development . Sie helfen, kommen mit einem gut entkoppelten Design auf, und stellen Sie sicher, dass der Code tut, was die Entwickler denken, es tut -. Auch nach einem Refactoring

Kundentests ist angegeben durch die Kunden oder Kunden-Proxy. Sie sind in der Tat, die Spezifikation des Systems, und sollte so geschrieben sein, dass sie sowohl ausführbar sind (vollautomatische) und verständlich durch die Geschäftsleute. Oft genug finden Teams Möglichkeiten für die Kunden auch schreiben sie mit Hilfe von QA Menschen. Dies soll während geschehen - oder sogar vor -. Die Funktionalität entwickelt wird

Idealerweise die einzigen Aufgaben für QA zu tun kurz vor der Zusammenführung, eine Taste drückt alle automatisierten Tests auszuführen, und einige zusätzliche Sondierungs (= unscripted) Tests. Sie wollen diese Tests wieder nach der Zusammenführung laufen, auch, um sicherzustellen, dass die Änderungen der Integration nicht etwas brechen hat.

Ein Testfall beginnt zunächst in der Geschichte Karte.

Der Zweck der Prüfung ist Defekte auf die linke Seite zu fahren (früher in dem Software-Entwicklungsprozess, wenn sie billiger und schneller zu beheben).

Jede Geschichte Karte soll Akzeptanzkriterien enthalten. Die Product Owner-Paare mit der Lösung Analyst die Akzeptanzkriterien für jede Geschichte zu definieren. Diese Kriterien werden verwendet, um festzustellen, ob eine Zweck Geschichte-Karte treffen gewesen.

Die Geschichte Kartenakzeptanzkriterien bestimmen, welche automatisierte Unit-Tests von den Entwicklern codiert werden müssen, da sie Test Driven Development tun. Es wird auch die automatische Funktionsprüfung durch den autoamted Tester (und vielleicht auch mit dem Entwickler-Support, wenn Tools wie FIT verwenden) implementiert fahren.

Ebenso wichtig ist, werden die Annahmekriterien der automatisierten Performance-Tests fahren und können verwendet werden, wenn sie von den Entwicklern, die Profilierung der Anwendung zu analysieren.

Schließlich wird die Benutzer Abnahmeprüfung durch die Akzeptanzkriterien in der Geschichte Karten bestimmt werden und soll durch den Geschäftspartner und oder Anwender gestaltet werden. Folgen Sie diesem Prozess, und Sie werden mit Null-Fehler wahrscheinlich lösen.

ich selten habe gehört haben oder gesehen Projektmanager schreiben Testfälle mit Ausnahme in den kleineren Teams. In jeder großen, komplexen Softwareanwendung hat einen Analysten haben, dass wirklich die Anwendung kennt. Ich arbeitete bei einer Hypothekenbank als PM - war ich Subprime-Kredite, die Zinsen zu verstehen, und das so? Vielleicht auf einer oberflächlichen Ebene, sondern echte Experten benötigt, um sicherzustellen, arbeitete diese Dinge. Meine Aufgabe war es, das Team gesund zu halten, schützt die agilen Prinzipien und sucht nach neuen Möglichkeiten für die Arbeit für mein Team.

Der Systemanalytiker sollte über alle Testfälle und seine korrekte Beziehung zu den Anwendungsfällen überprüfen. Plus die Analysten sollte die endgültige UAT durchführen, die auch auf Testfälle basieren könnte. So ist der Analytiker und die Qualität Kerl machen Art von Peer-Review.

Die Qualität wird die Überprüfung der Anwendungsfälle, während er Testfälle baut, und der Analyst prüft die Testfälle, nachdem sie geschrieben werden, und während er UAT ausführt.

Natürlich BA ist der Domain-Experte, nicht aus technischen Sicht. BA versteht die Anforderungen und die Testfälle sollten die Anforderungen zugeordnet werden. Entwickler sollten nicht die Personen sein, die Testfälle Schreiben gegen ihren Code zu testen. QA kann Detail Prüfschritte pro Anforderung schreiben. Aber die Person, die die Anforderung schreibt sollte diktieren, was getestet werden muss. Wer schreibt eigentlich die Testfälle, ich dont care zu viel, solange die Testfälle wieder auf Anforderungen zurückgeführt werden kann. Ich würde denken, es macht Sinn, dass BA die Prüfrichtung oder Umfang führt, und QA schreibt die granularen Prüfpläne.

Wir müssen entwickeln sich aus der „das ist, wie es gemacht wurde, oder sollte Mentalität getan werden,“ es versagt und versagt kontinuierlich. Der beste Weg, das Testplan / Fälle Schreiben Problem zu beheben ist, dass die Testfälle auf den Anforderungen doc in Wasserfall oder die User Story in agilen geschrieben werden sollten, da dieser reqs / User Storys geschrieben werden. Auf diese Weise gibt es keine Frage, was getestet werden muss und QA und UAT Teams können den Testfall (s) ausführen und die Zeit auf der eigentlichen Prüfung und Fehler Auflösung konzentrieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow