Testen

Nun, Sie wollen keine offensichtlichen Fehler. Schnell veröffentlichen bedeutet nicht, dass wir Dinge veröffentlichen müssen, die die Anwendung brechen oder schlecht aussehen lassen.

Etwas vor der Veröffentlichung zu testen, ist eine gute Idee. Testen ist, wie alles andere auch, ein großes Thema und es gibt verschiedene Schulen, wie man es macht. Wir sprechen hier offensichtlich nicht von einer "Testphase" im alten Stil des Projektmanagements.

Es mag heute lächerlich erscheinen, auf das Testen von allem am Ende eines Projekts zu warten, aber es war eine gängige Praxis und ist es in vielen Wasserfall-Projekten immer noch. Glücklicherweise haben sich die meisten weiterentwickelt. Bei der Entwicklung wird mit dem Testen gewartet und die Entwickler sind weitergegangen und haben vergessen, und es ist fast ein neues Projekt, um alle kleinen Dinge zu beheben.

Heutzutage verwenden Unternehmen kontinuierliches Testen, das in einem Testumgebung stattfinden muss, bevor das Ticket/Geschichten/Fehlerbehebung in die Produktion geht (veröffentlicht wird).

Auf diese Weise können wir Funktionen codieren, sie testen, Feedback geben, wieder codieren und das Testen fortsetzen, bis wir mit dem Ergebnis zufrieden sind. Wir können Features veröffentlichen, sobald sie fertig sind, auf einer Feature-basierten Basis.

In vielen Entwicklungsprozessen codiert der Entwickler etwas, testet es dann ein wenig auf seinem lokalen Computer und commitet den Code, macht dann einen Pull Request für die Peer-Review (im besten Fall). Dann ist es in der Testumgebung.

Hier geben einige Entwickler den Test an ein QA (Qualitätsicherung) Team weiter, das die Testverantwortung übernimmt und "sicherstellt", dass es "die richtige Qualität" hat. Das sieht auf dem Papier gut aus. Tun Sie das nicht! Zumindest nicht so.

Lesen Sie mehr in "The CTO Playbook" verfügbar auf Amazon/Kindle.