Wann sollte die Entwicklung aufhören und die Qualitätssicherung beginnen?

Wir schreiben eine vollständige Funktionsspezifikation für unser zweiköpfiges Entwicklungsteam. Wir haben keine professionellen Tester, haben jedoch mithilfe unseres verfügbaren Helpdesk-Personals einen Entwurf für die Durchführung von QS-Tests erstellt.

Wir hatten in der Vergangenheit Probleme, bei denen vollständige Funktionsblöcke nicht funktionieren oder der gelieferte Code einfach nicht der Spezifikation entspricht.

Meine Fragen sind: Ab wann sollten Entwickler aufhören, dem QA-Team die Codierung zu übergeben? Ist es zu viel, die Entwickler zu bitten, ihren Code anhand der Spezifikation zu überprüfen, bevor sie an das QA-Team übergeben werden?

Es sollte nicht!

Es ist sehr schwierig, die ganze Arbeit zu erledigen, anzuhalten und dann alle Probleme zu beheben. Wenn Sie ein Problem beheben, das Sie während des QS-Prozesses festgestellt haben, werden Sie möglicherweise feststellen, dass es besser ist, etwas anders zu machen.

Versuchen Sie, alles zyklischer zu gestalten, anstatt alles als Lock-Step-Prozess zu betrachten. Codieren Sie einige Funktionen und testen Sie sie. Codieren Sie noch etwas und testen Sie es (und die alten Dinge funktionieren immer noch). Dieser flüssigere Prozess erleichtert das harte Schiff, alles von vorne zu laden. Sie können immer noch das Konzept eines Code-Freeze haben (nur Fehler beheben), wenn Sie sich der Frist nähern, aber es geht darum, früh und häufig zu testen.

Wenn ganze Codeabschnitte in einem nicht funktionierenden Zustand an die Qualitätssicherung übergeben werden, sollten Sie möglicherweise versuchen, Ihrem Prozess eine Art Unit- / Integrationstest hinzuzufügen. Missbrauche deine QS-Mitarbeiter nicht, indem du sie herausfindest, dass du deinen Code nicht auf Einheit oder Integrationstest getestet hast.

Es ist eine feine Linie, denn wenn der Code gemäß den Spezifikationen geliefert wird, bedeutet dies für mich, dass es keine Fehler gibt (und keine QS erforderlich ist!). Die Tatsache, dass Code routinemäßig nicht gemäß Spezifikation geliefert wird, ist der Grund, warum wir überhaupt QS durchführen.

Aber ich glaube nicht, dass Sie darüber sprechen. Was Sie damit meinen, ist, dass das Entwicklerteam mit seiner Codierung etwas zu faul zu sein scheint und es große offensichtliche Dinge gibt, die nicht zu funktionieren scheinen. Wenn Sie vorab festlegen, dass Unit-Tests für jedes der Merkmale A, B und C (in der Spezifikation) vorhanden sein müssen, und dann Code und Tests unabhängig voneinander (von einem Team-Lean oder Manager) überprüfen lassen, kann dies helfen, diese Art von Problem zu lösen .

Ich würde argumentieren, dass die Entwickler zumindest den "glücklichen Weg" hätten testen sollen. Wenn sie erwartete Daten eingeben, tut dies genau das, was die Spezifikation vorschreibt. Entwickler, die nicht so viel tun, sollten befragt werden.

Ich bin auch enttäuscht, wenn ein Entwickler die offensichtlichen Randfälle nicht getestet hat: eine für die Datenbank zu lange Zeichenfolge, offensichtlich ungültiger Text, wenn Sie Buchstaben eingeben, in denen eine Zahl stehen soll usw. Wenn dies häufig vorkommt, sollten erneut Fragen gestellt werden .

Angenommen, es wird in der Spezifikation nicht ausdrücklich erwähnt, wenn ein Entwickler einen Namen nur auf Groß- und Kleinbuchstaben beschränkt, aber vergisst, dass einige Namen Apostrophe haben oder ein Datum vom 29. Februar 2011 zulässt - das ist etwas verständlicher . Es sei denn, sie machen immer wieder den gleichen Fehler.

Das QS-Team sollte die extremen Randfälle aufgreifen. Ich bevorzuge die Qualitätssicherung als Affentester: Geben Sie einfach zufälligen Müll ein und prüfen Sie, ob sie die App auf diese Weise beschädigen können.

In der Webentwicklung sollte die Qualitätssicherung verschiedene Browser ausprobieren und versuchen, Plugins zu finden, die sich auf den Code auswirken könnten. Sie sollten Javascript und CSS ausschalten und sehen, womit sie dann durchkommen können. So was. Wenn Sie erwarten, dass die Entwickler dies tun, geben Sie zu viel Geld dafür aus.

Wenn Funktionen bereitgestellt werden, die nicht funktionieren, liegt das Problem nicht zwischen Entwicklung und Qualitätssicherung, sondern zwischen Entwicklung und Produktbesitzern.

Produktbesitzer und Entwickler sollten Teil desselben Teams sein und zusammenarbeiten, um zu definieren, was funktionieren muss, um eine Funktion als "erledigt" zu betrachten, und um sicherzustellen, dass der Code diese Anforderungen erfüllt.

Wenn Code geliefert wird, sollte das Testen lediglich eine Formalität sein, da die Produktbesitzer auf dem Weg mit den Entwicklern zusammengearbeitet haben sollten, um sicherzustellen, dass alle Anwendungsfälle abgedeckt sind.

(Wenn Sie professionelle Tester haben, sollten diese Teil des Teams sein und in jeder Phase einbezogen werden.)

Wir haben einen Überprüfungsprozess für Projekte, bei dem wir die Entwickler bitten, eine exemplarische Vorgehensweise / Demo ihres Codes zu geben, bevor er in die Qualitätssicherung eintritt. Wir schließen nicht nur die QS-Tester ein, sondern auch die Geschäftsinhaber des Codes, den Kundenservice und das Marketing / Design. Dies konzentriert sich in der Regel auf die Entwickler, zumindest in Bezug auf die einfachen Anwendungsfälle, und manchmal führt die daraus resultierende Diskussion zwischen den verschiedenen Teams zu Änderungen der Spezifikationen und einer Verzögerung beim Eintritt in die Qualitätssicherung. Wenn wir können, beziehen wir die Qualitätssicherung viel früher in den Prozess ein, wodurch Fehler behoben werden, während der Code noch warm ist. Wir führen jedoch die exemplarische Vorgehensweise durch, bevor die "offizielle" Qualitätssicherung beginnt.

Ich habe manchmal gesagt, dass Code nicht an die Qualitätssicherung gesendet werden sollte, wenn Sie verärgert wären, wenn er versehentlich anstelle der Qualitätssicherung in die Produktion ging. Code mit schwerwiegenden Funktionsstörungen gehört nicht zur Qualitätssicherung (außer unter bestimmten Umständen).