QA best practices
1.0.0
Dies ist eine Zusammenfassung der Futurice -Verwendungen von QA Practices und empfiehlt, verwendet zu werden. Es soll keine detaillierte Beschreibung sein und manchmal nicht vollständig von allen Aufgaben verwendet werden, sondern als Überblick über die wichtigsten QA -Prozesse und eine Liste guter Praktiken, die verwendet werden sollten.
Für die Klarheit beschreibt dieses Dokument keinen Fehler oder einen Vorfallprozess (dh ein neuer Fehler wird aus der Produktion festgestellt).
Jeder im Futurice -Team hat QA -Verantwortlichkeiten, auch wenn es einen benannten QA -Manager oder QA -Spezialisten gibt. Zu Futurice QA bedeutet drei Dinge.
Auf hoher Ebene können QA -Arbeiten und Praktiken in zwei Prozesse unterteilt werden.
Darüber hinaus gibt es andere QA -Aktionen.
Futurice verwendet gegebenenfalls TDD- und ATDD -Methoden (Acceptance Test Driven Development).
Die Methode erzwingt die Implementierung, der Architektur zu folgen und Module zu berücksichtigen, die verwendet werden. Die Implementierung beginnt damit, zuerst den automatisierten Test zu schreiben und dann die Funktionalität zu implementieren, um den Test zu bestehen.
Futurice verwendet gegebenenfalls die Paarprogrammiermethode. Dies ist eine sehr bequeme Möglichkeit, Wissen und Erfahrungen über das in der Entwicklung befindliche Projekt und Software auszutauschen.
Durch die Überprüfung des Codes hilft es anderen Teammitgliedern, Informationen über bestimmte Funktionen zu erhalten, und gibt die Möglichkeit, der verantwortlichen Person Feedback zu geben und auch die Verteilung des Wissens zwischen den Teammitgliedern zu gewährleisten.
Manuelle Tests werden hauptsächlich mit der Erkundungstestmethode durchgeführt, und es werden festgestellt, dass Fehler sofort behoben oder priorisiert und im Tool für Aufgaben-/Story/Fehler -Management aufgezeichnet werden. Die Erkundung der App oder des Dienstes kann gleich nach dem „Bereit“ von etwas Funktionalem gestartet werden.
Erkundungstests sind ein sehr leistungsstarkes Werkzeug bei End -to -End -Tests, bei denen das gesamte System durch Tests abgedeckt wird. Im Methode-Tester geht über das hinaus, was in einem Testfall definiert werden kann, das benutzerähnliche Denken anwendet und versucht, das System durch verschiedene Fehlerszenarien zu brechen, und wird niemals mit Tests „durchgeführt“.
Um die funktionalen Anforderungen und Tests gibt es normalerweise nicht funktionale Anforderungen, die bei Lokalisierung, Benutzerfreundlichkeit, Leistung und Lastprüfung getestet werden können. Die Bedürfnisse und die Tools sind Projekte spezifisch. Für Usability Testing hat Futurice ein mobiles Usability -Labor für den Einsatz. Für Leistungstests hat Futurice webbasierte Dienste wie Browsmob verwendet, um einen zu nennen. Für Lasttests werden Lastui und J -Messgeräte aktiv verwendet, um die Servicefunktionen im hohen Verkehr zu validieren und mögliche Service -Engpässe zu finden.
Die gefundenen Probleme werden in einem bestimmten Tool oder einer bestimmten Tafel mit Informationen wie Priorität, Umgebung (Software- und Geräteinformationen), Schritten zur Reproduktion, erwarteten Ergebnis, Zeit und Datum und einem Screenshot aufgezeichnet. Tools wie Jira, Trello, PivotAlTracker, Request Tracker werden auch aktiv für die Fehlerverfolgung verwendet.
Eines der Prinzipien von Agile ist, dass der Master -Code -Zweig immer potenziell versendbar sein sollte. Das heißt, es sollte immer Produktionsqualität sein. Dies wird mit folgenden Mitteln erreicht:
Jede Benutzergeschichte (oder Funktion) wird einzeln in ihrer eigenen Feature -Filiale entwickelt. Dies ist der Zweck, sicherzustellen, dass jedes Update auf den Master -Zweig gleichzeitig 1) so klein wie möglich und 2) potenziell versendbare, vollständige Geschichte ist.
Bevor der Feature -Zweig mit dem Master -Zweig zusammengeführt werden kann, muss sie eine Liste von Aktionen, Anforderungen und Praktiken übergeben, die als Definition von Done (DOD) bezeichnet werden. Dies wird zusammen mit dem Kundenpo und dem Entwicklungsteam definiert und kann während des Projekts geändert werden, wenn sich die Anforderungen an die Projekte ändern.
Die folgenden Elemente in den vorgeschlagenen DOD wurden fett gezogen
Der Bereitstellungsprozess ist ein Prozess, wie eine neue Version (oder eine Version in Master Branch) für die Produktion bereitgestellt wird. Für diesen Prozess gibt es drei relevante Umgebungen.
Der CI -Server (Continuous Integration) wird für automatisierte Tests und Bereitstellung von Code für Umgebungen verwendet. Automatisierte Tests werden immer durchgeführt, wenn eine dieser Umgebungen aktualisiert wird.
Die Testumgebung wird automatisch von CI aktualisiert, wenn die Master -Filiale aktualisiert wurde. Dies bedeutet, dass automatisierte Testfälle auch automatisch ausgeführt werden, wenn die Master -Filiale aktualisiert wird.
Die Testumgebung ist der Haupt -Testserver für Futurice. Es wird erwartet, dass jede hier getestete Veröffentlichung bereit ist, auf QA oder Produktion gedrängt zu werden (abhängig von der Terminologie und Integrationen im Projekt).
Bei der Aktualisierung von Tests ist nicht erforderlich, um manuelle Regressionstestfälle auszuführen. Sehr oft ist die Zeit, die für Erkundungstests aufgewendet wird, vorteilhafter. Es ist jedoch eine gute Praxis, diese Tests mindestens einmal pro Sprint durchzuführen.
Die QA -Umgebung sollte als Umgebung für Akzeptanztests, Demos oder Tests oder Audits der Drittanbieter (Sicherheit, Lokalisierung, Last, Benutzerfreundlichkeit usw.) verwendet werden. Dies ist kein Primärprüfserver von Futurice (Test ist). Das Update zu QA wird immer zwischen den PMs des Kunden und Futurice vereinbart.
Der Hauptgrund für zwei Testumgebungen (Test und QA) ist die Einhaltung der Sicherheits- und Integrationsanforderungen. Test ermöglicht Futurice, den Dienst mit agilen Prinzipien zu entwickeln. Die QA ermöglicht es Zeit und Kontrolle, dass der Kunde seine aktuellen QA -Prozesse ausführt.
Die QA sollte nicht aktualisiert werden, es sei denn, die Veröffentlichung hat Tests in der Testumgebung bestanden.
Die Produktumgebung ist die Umgebung für die Live -Website (Produktion).
Eine gute Praxis besteht darin, zumindest automatisierte Tests in der QA bereitzustellen und auszuführen, bevor Sie das Update auf ProD weitergeben. Bei prod muss jedoch nach jeder Bereitstellung die Hauptfunktionalität überprüft werden.
Es wird empfohlen, dass die PO auch das Recht hat, ein Update auf Prod zu bringen, ohne dass die QA getestet wird (wenn die Version im Test übergeben wird). Dies ist relevant, wenn das Update sehr klein oder einfach ist.
Letztendlich in der agilen Entwicklung, wenn sich der Dienst in einer kontinuierlichen Entwicklung befindet, ist es das Ziel, viele kleine Updates auch zu produzieren. Dh es ist wichtiger, dass der Bereitstellungsprozess schlank und schnell als kugelsicher ist. Es wird als wichtiger angesehen, schnell Korrekturen vorzunehmen, als einen fehlerfreien Service zu haben (offensichtlich sollte DOD und automatisierte Tests auch hoch sein). Futurice empfiehlt nicht sofort mit diesem Ansatz. Dies sollte jedoch die Richtung sein, in die beide Organisationen gehen wollen.
Jede mobile Plattform verfügt über ihre spezifischen SDK, Toolsets und Futurice -Best Practices.
Für Android https://github.com/futurice/android-best-practices
Für iOS https://github.com/futurice/ios-good-practices
Für Windows Phone https://github.com/futurice/windows-app-development-best-Practices
Mobile Plattformen bieten Emulatoren in ihrem SDK.
Während der Implementierungsphase kann der Entwickler simulierte / emulierte Geräte verwenden, um Änderungen zu validieren, aber nichts kann die tatsächlichen Gerätetests übertreffen, bei denen das gesamte System vom Touchscreen und integriertem Speicher an mobile Prozessoren berücksichtigt wird.
Mobile Browser können auch von Cloud -basierten Diensten wie BrowsStack getestet werden.
Futurice verfügt über eine gute Vielfalt verschiedener Geräte und Betriebssystemversionen in der Gerätebibliothek, von grundlegenden Telefonen bis hin zu fortgeschrittenen Tablets.
Für die testen und leistungsstarke Datenverkehrs -Test- und Leistungsvalidierungs -Futurice wurden das ELISA -Testlabor verwendet (ELISA ist ein finnischer Mobilfunkanbieter). In der Laborumgebung können verschiedene Lasten und Geschwindigkeiten in kontrollierter / isolierter Umgebung getestet werden, ohne dass teure und nicht wirksame Feldtest -Sitzungen erforderlich sind.
Normalerweise stellt die mobile App eine Verbindung zu einem Backend -Dienst über Mobilfunknetz her. Um das Beste aus dem Testen herauszuholen, muss der Tester eine vollständige Kontrolle über das Backend haben, mit dem die mobile Anwendung angeschlossen ist, um sich auf verschiedene End -to -Tester -Szenarien vorzubereiten und auszuführen.
In mobilen Geräten kann die Installation von Testbuilds durchgeführt werden: lokal über Kabel mit Entwicklungs -SDK -Tools, die drahtlos über Build -Distribution -Tools wie Testflug oder HockeyApp gesteuert werden. Die Freigabe von Frameworks unterstützen normalerweise die Absturzprotokolle und Versionsdaten. Dev, Alpha und Beta -Releases können ebenfalls bereitgestellt werden, um Feedback zu sammeln, bevor die Anwendung an Geschäfte veröffentlicht wird. Der Google Play Store hat die Möglichkeit, Alpha- und Beta -Testgruppen einzurichten, in denen die spezifische App nur für Gruppenmitglieder verfügbar ist
In modernen mobilen Anwendungen stellen Analytics und Datenerfassung eine kritische Funktionalität dar, die ebenfalls getestet werden muss. Futurice betrachtet dies als wichtiger Bestandteil des Funktionstests.
Aufgrund der Tatsache, dass sich der Prozess der mobilen App -Aktualisierung von den Web -Apps eins unterscheidet, muss das Analytics -Setup vom ersten Versuch richtig abrufen oder dann werden wertvolle Daten übersehen. Der Aktualisierungsprozess erfolgt über Anwendungsspeicherverfahren. Ob das Update durchgeführt wird oder nicht, liegt bei den Benutzereinstellungen und -aktivitäten. Wenn also die erste Version eine kritische Analysefunktion verfehlt und einige Benutzer die Anwendung nie aktualisieren, werden diese Daten dann übersehen. Die Lösung kann ein Upgrade erzwingen, wobei die App unbrauchbar wird, bis die Benutzer auf die neueste verfügbare Version aktualisiert werden, aber dies könnte zu spät sein.
