Sollten Entwickler, Tester und Geschäftsanwender ein einheitliches Testskript haben?

In der Entwicklung hätte ich normalerweise meine eigenen Testskripte, die die Daten, Szenarien und Ausführungsschritte dokumentieren, die ich testen möchte. Das ist mein Entwickler-Testplan. Wenn die Funktionalität für Test bereitgestellt wurde, testen Tester sie mit ihrem eigenen Testskript, das sie geschrieben haben. In UAT testet der Geschäftsbenutzer dann mit seinem eigenen Testplan.

Rückblickend sieht es so aus, als würde dies eine bessere Abdeckung bieten, da Entwicklertests eine Mischung aus Black- und White-Box-Tests aufweisen, während sich Tester und Geschäftsanwender auf Black-Box-Tests konzentrieren. Auf der anderen Seite werden jedoch unterschiedliche Testfälle angezeigt, die nur pro Stufe ausgeführt werden (dh einige Fälle, an die Tester gedacht haben, werden nur auf der Teststufe ausgeführt), und es möchte, dass der Entwickler sie verpasst, was sie zu einem Befund / Fehler macht .

Lohnt es sich, die Testskripte von Anfang an zu konsolidieren? Verwenden Sie also ein einheitliches Testskript, oder ist es schwierig, dies im Voraus zu tun?

Erstens ist QS kein Test. Wenn Ihre QS-Abteilung nicht in den gesamten Entwicklungsprozess involviert ist, handelt es sich um Test und nicht um QA. Die Qualitätssicherung bei der Arbeit bietet Qualitätssicherung, im besten Fall zeigt der Test die mangelnde Qualität, kann aber nicht nachweisen, dass Qualität vorhanden ist - dh der Test zeigt, dass die Qualitätssicherung fehlgeschlagen ist, aber nicht nachweisen kann, dass sie erfolgreich war. Daher sollten Test und Qualitätssicherung nicht dieselbe Abteilung sein.

Ich glaube, der beste Weg ist, dass jede Gruppe ihre eigenen Tests verwaltet, da dies eine bessere Abdeckung bietet. Jedes Team sollte jedoch so schnell wie möglich mit dem Testen beginnen. Dies bedeutet, dass UAT gestartet wird, sobald Benutzer etwas verwenden können. Der Test wird gestartet, sobald ein Teil, für das sie einen Test haben, bereit ist usw. Dies verhindert das späte Auffinden bestimmter Testfälle. Dies kann eine Neuausrichtung Ihrer Arbeitsmodelle bedeuten, da UAT und Test häufig davon ausgehen, dass sie an einem vollständigen Produkt arbeiten und eine Schulung zum Testen teilweise vollständiger Ausgaben benötigen. Es kann teurer sein, wenn der Workflow nicht diszipliniert ist und ein Entwickler "Vollständig" "Vollständig" bedeutet.

Die Qualitätssicherung sollte dies zusammen mit anderen Qualitätsmaßnahmen überwachen, um sicherzustellen, dass der Prozess nicht nur die gewünschte Qualitätsleistung liefert, sondern auch ein angemessenes Effizienzniveau aufweist.

Bearbeiten: Der ursprüngliche Verweis auf QA wurde entfernt, daher erscheint diese Antwort jetzt als OT.

Wir verwenden von Anfang an UATs.

Es dient als universelle Referenz und ich denke, es funktioniert gut. Während es möglicherweise Testskripte gibt, die nur von den Entwicklern oder Testern für kleinere Komponenten verwendet werden, ist die Richtung des Tests immer auf ein einheitliches Ziel gerichtet. Am Ende des Tages zählt nur die UAT, sodass Sie sie am Anfang genauso gut in den Mittelpunkt stellen können.

UATs von Anfang an durchzuführen hat auch einen zusätzlichen Vorteil. Es klärt wirklich jede Unklarheit zwischen den Kundenerwartungen und Ihren eigenen.

Sie benötigen kein einheitliches Testskript, da die Dinge, die sie testen, und die Art und Weise, wie sie Tests durchführen, oft unterschiedlich sein sollen. Sie benötigen eine einheitliche Anforderung, an der alle Parteien arbeiten. Wenn UAT und QA Dinge testen, an die der Entwickler nie gedacht hat, ist es Zeit, sich mit den Anforderungen zu befassen.

Ich stimme zu, dass es schön wäre, ein einheitliches Testskript für Entwickler, Tester und Geschäftsanwender zu haben, aber ich glaube, dass dies nicht ohne großen Aufwand möglich ist, wenn die Kosten den Nutzen übersteigen.

Der Grund für die Schwierigkeit ist, dass der Datenbankinhalt in jedem System unterschiedlich ist und Tests normalerweise stark vom Datenbankinhalt abhängen. Unser Ansatz für "einheitliche Tests" war, dass jedes System auch eine zusätzliche Testdatenbank erhält und es Skripte gibt, um diese Datenbank von Grund auf neu zu erstellen. Die Testskripte werden für die Testdatenbank ausgeführt, in der der Inhalt standardisiert ist.

In einer perfekten Welt müssen Entwickler Unit-Tests (xUnit), Tester - automatisierte Integrationstests (Selen) und Geschäftsanwender - Akzeptanztests (FIT) haben. Sie können auf Tests zugreifen.

Es kommt wirklich auf das Projekt an. In einigen Fällen kann ein einheitliches Test-, QS- und UAT-Team, das sich zur Erörterung der Ergebnisse trifft, von großem Nutzen sein. Dies erspart Doppelarbeit beim Testaufwand und stellt sicher, dass alle Parteien über UAT-Skripte ein klareres Verständnis der Geschäftsanforderungen haben. Andererseits kann es je nach Komplexität des Projekts sinnvoller sein, die Ein- und Ausgaben vor dem Testen von Geschäftsbeispielen gründlich zu überprüfen. Für die Systementwicklung im eigenen Land ist eine anfängliche Qualitätssicherung ein Muss, bevor der Benutzer sie akzeptiert. Für sofort einsatzbereite Implementierungen wäre ein einheitliches Testteam am sinnvollsten.