Welche Tests gibt es neben Komponententests und kontinuierlicher Integrationsentscheidung?

Question

Einige DO Fakten:

• zwei Entwickler in einem Team
• wir Unit-Tests (Autofahrt mit jedem Build)
• wir verwenden Quelle Versionierung Steuersystem (SVN)
• wir schreiben (die beiden Entwickler) sind auch Produktmanager (eine klassische Situation mit hohem Risiko von Produkt-Over-Engineering)

Einige NICHT Fakten

• wir nicht jede Nacht haben baut
• wir haben keine kontinuierliche Integration
• wir Integrationstests
• wir haben keine Regressionstests haben keine
• haben wir die Annahme/Kundentests nicht
• wir noch

keinen dedizierten Tester haben

Ich lese viel über alle diese verschiedenen Arten von Tests, aber ich sehe keinen Grund, sie im Moment zu schreiben. Jetzt sieht es aus wie ein Plain Overhead ohne Wert (bearbeiten: Arbeit, die im Moment scheint nicht viel Wert hinzufügen).

Frage: Was sind die Ursachen wird Kraft uns eine der Don'ts zu entscheiden, zu implementieren und welche können/sollen mit welchen Tools automatisiert werden/libs?

Answer 1

„Was uns verursacht, wird der Grund dafür eine der Don'ts zu implementieren“

Nichts.

Nichts zwingt Sie, Ihre Qualität zu verbessern. Viele Leute schreiben Code, der meist die meiste Zeit funktioniert, erfordert viel sorgfältige Wartung und ihre Benutzer sind meistens zufrieden.

Das ist in Ordnung. Manche Leute mögen es so. Da Sie Praktiken charakterisiert haben, die zu hoher Qualität als "einfacher Overhead ohne jeden Wert" führen, brauchen Sie dieses Qualitätsniveau natürlich nicht und können nicht voraussehen, dass Sie jemals dieses Qualitätsniveau benötigen.

Das ist in Ordnung.

Ich weiß nicht, wie Sie liefern, ohne Abnahmetests durchzuführen, aber Sie haben klar gesagt, dass Sie nicht tun. Ich kann nicht verstehen, wie das funktioniert, aber du scheinst damit glücklich zu sein.

None "die diejenigen, kann/soll automatisiert werden". Das ist ziemlich triviales Zeug. Sie verwenden bereits den Unit-Test von C#. Unit-Tests, im Wesentlichen ist Regressionstest. Bis zu einem gewissen Grad können Sie dieselben Werkzeuge und dasselbe Framework für die Integration und Elemente der Akzeptanzprüfung verwenden.

Es gibt zahlreiche make-like (ameiseähnliche, mavenähnliche, scons-ähnliche) Werkzeuge für nächtliche Builds.

Sie brauchen keine Automatisierung mehr als Sie haben.

"kontinuierliche Integration" erfordert keine Werkzeuge, nur die "Plain Overhead ohne jeden Wert" der Überprüfung Zeug oft genug, dass der Build nie gebrochen wird.

Soweit es mich interessiert, ist jeder Entwickler ein Tester, also sind Sie alle engagierte Tester. Viele Menschen debattieren über die Rolle des "engagierten Testers". Ich weiß nicht mehr, was das bedeutet. Es scheint eine Person zu sein, die keinen lieferbaren Code produziert. Ich weiß nicht, warum du jemanden so einstellen würdest. Es macht mehr Sinn, einfach alle für alle Tests verantwortlich zu machen.

Ein "engagierter Tester" - der als Ersatz für den Benutzer fungiert - stellt immer fest, dass er eng mit dem Business Analyst zusammenarbeitet. Da dies normalerweise der Fall ist, handelt es sich normalerweise um Junior-Business-Analysten, die sich auf den Abnahmetest konzentrieren. Dies ist eine gute Sache, weil sie ein Ergebnis haben: ein gelöstes Geschäftsproblem.

Ich bin nie sicher, was Tester liefern. Mehr Tests? Mehr Bugs? Wie wäre es damit, sie den Nutzern zur Rechenschaft zu ziehen, um sicherzustellen, dass das Geschäftsproblem gelöst ist?

Nichts Kräfte Sie etwas davon zu tun.

Answer 2

Ich bin mir nicht ganz sicher, ob diese Antwort würdig ist, aber hier sind ein paar Dinge zu beachten:

• Wenn Ihre Unit-Tests gut sind und up-to-date (ein Bericht Fehler führt zu Einheit Tests, die den Fehler bestätigen), Unit-Tests können als Regressionstests fungieren.
• Wenn Ihre Komponententests mit jedem Check-in ausgeführt werden, klingt das sehr nah an meinem Verständnis von nächtlichen Builds, aber mit einer anderen Frequenz.
• Wenn Sie keine Abnahmetests haben, wissen Sie, dass das, was Sie bauen, den Anforderungen Ihrer Kunden entspricht? Ein Abnahmetest kann so einfach sein, wie sicherzustellen, dass die Anforderungen erfüllt werden, wie dokumentiert.

Answer 3

Irgendwann kann die Qualität zu einem größeren Profittreiber werden, der dann noch schneller auf den Markt kommt. Dann müssen Sie darüber nachdenken, bessere Qualität zu haben.

Bis das passiert, sollten Sie an nächtliche Builds, automatisierte Regressionstests, usw. denken, um Ihnen Zeit und Mühe bei der Entwicklung zu sparen. Also verbringe alle paar Monate etwas Zeit (etwa 1 Woche), um deine Entwicklung (und Veröffentlichung) produktiver zu machen (und Spaß).

Gehen Sie zuerst für die großen Gewinne, z. B. automatisieren das Setup für einen manuellen Regressionstest kann oft viel kostengünstiger die Automatisierung der UI-Test ist es selbst.

(Beachten Sie auch, was Sie Spaß finden, wenn Sie automatisierte UI-Tests Code-Tests mehr als manuelle Regressions gerne schreiben, können Sie mit dem automatisierten UI-Testcode einen besseren Job machen.)

Answer 4

Wenn Sie keine (oder nicht zu viel) Beschwerden über Ihre Produktqualität - nehmen Sie es leicht und versuchen Sie nicht, das Niveau zu verlieren, das Sie bereits haben. Team von zwei Leuten kann es sich leisten, denke ich.

Aber wenn Sie nach QA Verbesserungen fragen, denke ich, dass Sie einige Zweifel an der Produktqualität haben. In diesem Fall empfehle ich, eine Bewertung durch Dritte vorzunehmen, um sicherzustellen, dass Ihre Qualitätsschätzungen korrekt sind.

Sind Sie schon auf dem Markt? Oder ist es ein "für einen Kunden" -Projekt?