Was ist Testen in Produktion und wie sollte es durchgeführt werden?

Artikel von Marc van ’t Veer

Basierend auf der Erfahrung aus einem Projekt ohne TiP gibt es Gründe, warum das DTAP Model nicht für das Testen moderner öffentlicher Online-Services in der Cloud geeignet ist. Abgesehen von der Notwendigkeit des TiP erörtert dieses Dokument, dass TiP ein regulärer Testlevel sein sollte. Durch den Vergleich von Test- und Produktionsumgebungenwird ein Blick darauf gegeben, wie ein Test in Produktion als normal wahr genommen werden sollte. Zusätzlich dazu wird eine Definition von TiP gegeben. Das Dokument endet mit der Frage nach zukünftigen Entwicklungen.

Einführung

Würde man anders testen, wenn man den Test in Produktion (TiP) machen könnte? Würde man eine andere Strategie verfolgen? In einem Projekt wurde ein öffentlicher WebService ohne TiP erstellt. Basierend auf den in dem Projekt gewonnenen Erfahrungen gibt es Gründe, warum ein Test und eine Akzeptanzumgebung des DTAP Modells (Development, Test, Acceptance und Produktionsumgebung) nicht ausreichend sind (Alast, 2006), (Pol, 2000). Allgemein sind traditionelle Testumgebungen nicht für den Test moderner Onlineanwendungen, wie z. B. WebServices in der Cloud, geeignet (Grundy, 2012). Daneben ist TiP notwendig und argumentiert, dass TiP ein regulärer Testlevel sein sollte. Basierend auf dem Vergleich zwischen Test- und Produktionsumgebungen wird ein Blick darauf geworfen, wie normal ein Test in Produktion sein sollte. Zusätzlich wird eine Definition von TiP vorgeschlagen und das Dokument endet mit den Fragen nach der zukünftigen Entwicklung.

Die natürliche Umgebung eines neuen öffentlichen WebServices wird anhand eines Testprojektes bei einem großen niederländischen Mobilfunkanbieter dargestellt. Der Service ist eine API und wird in der Zukunft bei externen Apps und sozialen Netzwerken wie Facebook verwendet. Eine App ist typischer Weise ein kleines, spezialisiertes Programm, welches auf einem Mobilfunkgerät heruntergeladen wird. Mit der Veröffentlichung der App in der Cloud können verschiedene Plattformen unterstützt werden, ohne für jede einzelne eine App zu entwickeln. Mit der Nutzung einer App und den dahinterliegenden WebServices haben Benutzer über ihr Handy in Echtzeit Zugriff auf all ihre Internet Credits, Adressdaten und Rechnungen. Das Projekt muss gewährleisten, dass die API stabil, hochperformant und sicher ist, sowie wiederverwendbare Infrastrukturen nutzt und einfach mit neuen Funktionalitäten zurechtkommt. All diese Anforderungen bestimmen, wie die API als öffentlicher WebService für externe Nutzer arbeiten wird. Nutzer sind nicht nur Apps, sondern auch externe Entwickler. Ein paar der wahrgenommenen Risiken des Testmanagements sind: unbekannte Integrationen, eine unbekannte Vielfalt von Vertragsdaten und wie diese Daten präsentiert werden sollen. Die API hat keinen Einfluss auf die Darstellung beim Endbenutzer. Es ist möglich, die API unrechtmäßig zu verwenden, ob absichtlich oder unabsichtlich. Kann ein Tester für Mängel zwischen der API und einer externen App verantwortlich gemacht werden?

Ein Endbenutzer hat keine Ahnung von der Anzahl der Schritte zwischen der App auf seinem Handy, der API und anderen BackendSystemen. Für ihn ist alles hinter der App die Cloud. Der Endbenutzer entscheidet über die Qualität der API, in dem er über die Qualität der App entscheidet. Ohne eine frühe Integration zwischen App und API werden alle möglichen Integrationsmängel erst sichtbar, wenn die API in Produktion ist. Die Teststrategie für das API-Projekt war „früher Integrationstest mit der kompletten Infrastruktur“. Diese Strategie wurde während der Entwicklung sowie beim System- und Integrationstest schrittweise umgesetzt. Die API wurde unter der Nutzung von Prototypen der App entwickelt. Beispiele für das Prototyping von Apps sind SoapUI, Webbrowser, Windows Taskbar App und eine Entwicklungs-App, welche alle die API nutzen. Für die Akzeptanz wurde ein erster Prototyp der externen App im internen Netzwerk getestet. Die Integrationstests wurden komplettiert mit dem Test des DownloadProzesses, der Installation und dem Einloggen der App in einem privaten, produktiven Mobilfunknetzwerk.

In dem Moment, in dem die App produktiv ging und die API nutzte, wurden die ersten Störungen berichtet. Zum Beispiel hatte ein Benutzer einen Tarif, der zwei Bundle enthielt: Anruf und Textnachrichten. Aber für jeden Tarif konnte nur ein Nutzungsfortschrittsbalken (nur ein Bundle Typ) in der App angezeigt werden. Ein zweites Beispiel ist, dass es für viele Endbenutzer nicht klar war, wie sie sich in der App anmelden konnten. Benutzer verwendeten ihren existierenden Account statt eines speziellen Zugriffscodes. Ein drittes Beispiel ist, das ein Account eines Benutzers, der zu viele falsche Login-Versuche hatte, vorübergehend gesperrt wurde. In diesem Fall nutzte die API die Standard http-Fehlermeldung „401 – nicht autorisiert“, die einem Benutzer, der sich nicht anmelden kann, gezeigt wurde. Aber die App wollte unterschiedliche Fehlermeldungen in den Fällen „fehlerhafte Eingabe“ und „zu viele Anmeldeversuche“ zeigen. Leider kann dies durch den Fehlercode 401 nicht unterschieden werden. Jetzt ist die Standard Fehlermeldung durch spezifische Fehlermeldungen der API erweitert worden: 401 – nicht autorisiert + 1102 – falscher Nutzername oder Passwort sowie 401 – 1103 – Account ist vorübergehend gesperrt.

Die App und die API wurden zum ersten Mal in der Produktionsumgebung vollständig integriert. Vor Produktivsetzung wurde vorgeschlagen, eine Anzahl Tests in Produktion durchzuführen, weil erst dann eine repräsentative Testumgebung verfügbar ist. Die Menschen waren überrascht von der Idee und waren dagegen, weil „man nicht in Produktion testet“ (TestNet, 2012), (Groot, 2012). Innerhalb des Projektes und mit dem Mobilfunkprovider war es nicht möglich, in Produktion zu testen. Am Ende wurde für alle Tests ein Blick auf das Risiko geworfen und ein Weg gefunden, diese zu reduzieren. Durch das Hinzufügen von TiP als ein Testlevel konnten das Verhalten und mögliche Risiken für den Service in Produktion sichtbar gemacht werden.In der Einführung wurde eine Test- und Produktionsumgebung erwähnt, aber was sind genau die Unterschiede?

Umgebungen

Eine Testumgebung ist beschrieben als “eine Infrastruktur, welche für die Durchführung von Tests benötigt wird“ (Pol, 2000) und (Aalyst, 2006). Eine Testumgebung sollte stabil, kontrolliert und repräsentativ sein. Es gibt verschiedene Typen von Umgebungen mit unterschiedlichen Rollen. TMap und TMapNext definieren eine Testumgebung als „eine Kombination von Hard- und Software, Verbindungen, Umgebungsdaten, Administrationstools und Prozessen, in denen Tests ausgeführt werden“ (Pol, 2000) und (Aalyst, 2006).

Während der Entwicklungszyklen von Anwendungen wird jede Umgebung innerhalb des DTAP-Modells von unterschiedlichen Nutzern verwendet. White-Box-Tests werden in der Entwicklungsumgebung ausgeführt. Die ersten Anwendungstests werden in der Testumgebung durchgeführt und Akzeptanztests werden in der „wie in Produktion“Umgebung ausgeführt. Weil die Nutzung über diese unterschiedlichen Umgebungen verteilt ist, kann die Entwicklung – ohne die Akzeptanztests zu stören – fortgeführt werden. Der Instandhaltungsbetrieb hat die Verantwortung, die bestehenden Anwendungen in der Produktionsumgebung am Laufen zu halten (Aalyst, 2006). Mit jeder weiteren Stufe des DTAP-Modells werden weitere Systeme miteinander verbunden womit die Umgebung mehr und mehr vergleichbar mit der Produktionsumgebung wird. Ein Ergebnis davon ist, dass die Anwendung robuster und reifer wird. Die Produktionsumgebung ist somit vor geringer Qualität geschützt und bleibt stabil.

Wenn man den Zusammenhang betrachtet, in dem die API und die App operieren müssen – wie in der Einführung angegeben – ist eine Testumgebung nicht repräsentativ, wenn sie nicht stabil ist. Änderungen werden ständig durchgeführt, Verbindungen werden gekappt, Benutzer sind alle extern, die Geräte sind vielfältig und die Verbindungen, die sie benötigen, existieren nicht, wenn die API entwickelt wurde. Die natürliche Umgebung von APIs ist eine öffentlich kontrollierte Domain. In Blokland, 2012 und Whittaker, 2011 ist ein Überblick gegeben, wie dynamisch, komplex und vielfältig die Umgebung eines modernen öffentlichen Services ist. Wenn das Ziel ist, dass ein Test in einer repräsentativen Umgebung ausgeführt werden soll, dann kann dies nur in Produktion erfolgen (Blokland, 2012).

Eine Produktionsumgebung wird oft mit einer Testumgebung verglichen. Produktion ist nicht nur eine Umgebung, aber der Ort, an dem die Anwendung „in Wirklichkeit“ ausgeführt werden soll. Eine Test- und eine Produktionsumgebung miteinander zu vergleichen, ist wie der Vergleich zwischen einem Zoo und der Natur. Sie haben Gemeinsamkeiten, aber es gibt reichlich Unterschiede. Auch die Notation „Umgebung“ klingt nach einer klaren Herstellung des Zusammenhangs in dem die Anwendung genutzt werden soll. In Produktion läuft der Service „live“ und die API sowie die App unterstützen den Endbenutzer. Die Testumgebung ist eine Parallelwelt, in der Änderungen und neue Projekte ohne Einfluss auf den live Service entwickelt werden. Die Umgebung, in der der Service kritisch für die Gesamtqualität ausgeführt wird. Wenn sich die Test- und die Produktionsumgebung ähnlich sind, sagen die Tests mehr über die Qualität und die möglichen Risiken aus. Microsofts Seth Eliot machte eine klare Aussage, als er den „Google Staged Approach“ (Eliot, 2012, Frühlings STP) diskutierte. Der Ansatz folgt 4 Teststufen, davon 3 in Produktion. Die erste Stufe ist der traditionelle „offene Test“ in einer Testumgebung; die anderen 3 Stufen sind Benutzer-Szenario Ausführung, Dogfooding und Beta-Test in Produktion. Google geht schnell in Produktion, weil kein Mehrwert durch weitere „offene Tests“ entsteht. 10 Prozent mehr „offene Tests“ ergeben nicht 10 Prozent Verbesserung der Softwarequalität (Whittaker, 2012, (Eliot, 2011, Frühling QASIG).

Für einige ist es ein „no go“ in Produktion zu testen, aber was sind Testergebnisse wert, wenn die traditionelle Testumgebung nicht repräsentativ ist? Sollte TiP eine normale Teststufe werden?

Wie normal ist Testen in Produktion?

Wird Software mit einem „normalen“ Produkt oder Service verglichen, dann ist klar, das Testen in Produktion nicht neu ist. Für normale Produkte finden immer Tests in Produktion statt. Die niederländische Organisation für angewandte wissenschaftliche Forschung führt Produktionstests für die Einführung der 4G LTE Technologie für schnelles Internet in den Niederlanden (TNO), (TNO-Huawei) durch. Die Verbrauchervereinigung führt ebenfalls Produktionstests für alle Arten von Produkten und Services durch. Wirft man einen Blick auf Gesetze und Haftungsregeln, findet man mehr Argumente, warum es normal ist, in Produktion zu testen. Software ist mehr und mehr ein tägliches Gut für die Endanwender und sie erwarten, dass die Software zuverlässig ist. In dem Moment, in dem ein Fehlverhalten gefunden wird, ist der Lieferant verantwortlich. Levy und Bell haben Forschungen zur Produkthaftung angestellt und welche Aktionen bestehen, diese zu verringern, zu transferieren oder zu teilen (Bell, 1990). Mit einer Klage gegen einen Lieferanten gibt es die Möglichkeiten, die Rechte und Pflichten zwischen dem Lieferanten und dem Kunden zu verdeutlichen. Die Einsicht in mögliche Risiken und Haftungen trägt zu einer „positiven Beziehung zwischen dem Lieferanten und seinem Kunden“ bei (Bell, 1990). Durch die Schaffung der Gerichtsbarkeit von Rechten und Pflichten werden Erwartungen realistischer und die Chance, das mögliche Probleme in der Software entdeckt werden, wird größer, zugelassen und korrigiert, bevor jeglicher Verlust oder Schaden eintritt (Bell, 1990). Das Gesetz differenziert zwischen Produkten und Services. Der Verkauf von Produkten unter liegt vielen Schäden- und Gewährleistungsrechten (Bell, 1990). Diese Gesetze sind nicht anwendbar auf den Verkauf von Services. Die Webseite ICTRecht gibt Basisinformationen für Softwareentwickler. Diese Informationen beinhalten ebenfalls den Umgang mit Haftungsfällen. Ein Entwickler kann verantwortlich für Fehler sein, welche in Produktion auftreten (ICTRecht). Software wird zu einem „normalen“ Produkt und Anwender erwarten, dass die gleichen Rechte für Schäden und Garantie anwendbar sein werden. Bei der Betrachtung der Produktqualität sollte ein Produkt in Produktion wie spezifiziert arbeiten.

Die Fortsetzung der Kontrolle der Produktqualität hört nicht auf, wenn das Produkt in Produktion ist. Innerhalb des traditionellen VModells für Softwareentwicklung wird jede Phase durch eine Teststufe validiert, um die Qualität zu überwachen (Aalyst, 2006). Die letzte Teststufe im V-Modell ist der Produktions-Akzeptanz-Test (PAT), der im Allgemeinen durch die Instandhaltungsabteilung erfolgt. In dem Modell ist keine Teststufe nach der Abnahme der Software definiert. ISTQB fügt eine „Wartungs- und Betriebsphase“ hinzu, um Wartungstests durchzuführen. Wartungstests werden auch „in Betrieb Inspektionen und Tests“ genannt. Diese Tests fokussieren auf Regressionsmängel und sind vergleichbar mit der jährlichen Inspektion eines Autos. Wenn ein Auto die Inspektion nicht besteht, muss es repariert werden, will man es weiter benutzen. Rückblickend auf das V-Modell sollten diese „Inspektionen“ Teil des Modells werden. Fügt man diese Tests dem Modell hinzu, wird es ein Kreis, da die erwarteten und die tatsächlichen Verhaltensweisen in Produktion verglichen werden. Blickt man auf die Entwickler bei Google, stellt man fest, dass diese mehr direkten Kontakt mit dem Endanwender haben als der traditionelle Entwickler, da Google einem grundlegend anderen Entwicklungsmodell („Google Staged Approach“) für Cloud-Dienste folgt. Traditionell werden die Anforderungen des Endanwenders ständig zwischen dem Entwickler und dem Tester übersetzt, weil kein direkter Kontakt zwischen ihnen besteht. Nach Whittaker, 2011 wird es in Zukunft viel mehr Tests in Produktion geben und das gesamte Entwicklungsmodell wird sich verändern.

TiP ist notwendig, um gute Tests für modern öffentliche Online-Services, wie z. B. APIs, durchzuführen. Aber was genau ist TiP und was ist die Definition davon?

Definition des Tests in Produktion

Um ein besseres Verständnis dafür zu haben, was Test in Produktion ist, wird zuerst eine kleine Idee davon gegeben, was TiP ist und was nicht. TiP ist keine Ersetzung einer Teststufe wie System- oder Akzeptanztest. Das bedeutet, dass TiP nicht gemacht werden sollte, weil keine Zeit mehr vorhanden oder es billiger ist. Das Ziel von TiP ist nicht zu prüfen, ob eine Installation korrekt in der Produktion durchgeführt wurde. TiP ist kein produktiver Akzeptanztest, weil diese Tests bereits gemacht sind, bevor die Software produktiv geht. Und deren Ziele sind ebenfalls unterschiedlich. Ein PAT schaut eher, ob die Software einfacher zu warten ist als sie genutzt wird oder wie sie sich in Produktion verhält (Aalyst, 2006).

TiP beschreibt Testen von Software, welche auf der Hardware des Endbenutzers installiert und ausgeführt und für reale Dinge genutzt wird. Wiki definiert TiP wie folgt:

Produktionstest ist, wenn man auf einem realen Live-System testet, entweder um live zu gehen oder mit echten Nutzern. Es ist erforderlich, weil Software, die auf dem Computer des Entwicklers gelaufen ist, keine Garantie dafür ist, dass sie auf Computern von Benutzern arbeitet.“ (TiP)

Seth Eliot definiert TiP wie folgt:

Test in Produktion (TiP) ist ein Set von Softwaretest-Methoden, welche reale Anwender und Produktionsumgebungen in der Form nutzen, dass sich beide der Vielfalt der Produktion bedienen, um die Risiken für den Endanwender zu mildern.“ (Eliot, 2012).

Wichtige Elemente dieser Definition sind, dass Tests durch oder für den Endanwender auf realen Live-Systemen mit dem Fokus auf dessen Verhalten in deren unterschiedlichen Umgebungen gemacht wurden.

Mit der Einführung der TiP-Testmethoden und Techniken, die die Vielfalt der Produktionsumgebung nutzen, können die Risiken für den Endanwender minimiert werden. Die Vielfalt der Produktionsumgebung ist ein Hebel, um Fehler zu finden, die nur dort gefunden werden können. Gehen wir zurück auf die zentrale Frage: „Warum soll man in Produktion testen?“ Man sieht, das nichts in der Definition fehlt (für welche Arten von Anwendungen ist TiP anwendbar), aber man fokussiert zu sehr auf Methoden. Eliot erklärt, dass TiP gemeint ist für (Web) Services (Eliot, 2011) und definiert TiP als einen Testtyp, während die Begründung in diesem Dokument ist, das TiP eine Teststufe ist. Eine Teststufe ist eine Gruppe von Testaktivitäten, die kombiniert ausgeführt und überwacht sind (Aalyst, 2006). Ein Testtyp ist eine Gruppe von Testaktivitäten, die die Software oder Teile davon in einer Kombination von Qualitätsattributen testen (Aalyst, 2006).

Testen in Produktion kann verglichen werden mit Systemtest. Ein Systemtest erfolgt durch einen Lieferanten in einer Labor- oder Testumgebung mit dem Ziel, dass das entwickelte System mit den funktionalen und nicht funktionalen Spezifikationen sowie dem technischen Design übereinstimmt (Aalyst, 2006). Der Unterschied ist, dass TiP die Produktionsumgebung verwendet und das Verhalten auf mögliche Grenzfälle untersucht wird, die natürlich dort auftreten. Diese Grenzfälle sind undenkbar und unberechenbar. Durch die Verwendung der Produktionsumgebung mit realen Nutzern wird die Vielfalt des Testens genutzt. Beim Systemtest wird auf das erwartete Verhalten fokussiert und mit TiP auf das unerwartete Verhalten. Innerhalb dieser neuen Teststufe können und sollten alle Testmethoden von Eliot wie synthetische Tests in Produktion oder kontrollierte Testflüge verwendet werden.

Wenn man alle vorher genannten Punkte kombiniert, ergibt die Definition von TiP:

Testen in Produktion ist eine Kombination von Testaktivitäten, die die Vielfalt der Produktionsumgebung und realer Endanwenderdaten zum Testen des Verhaltens des entwickelten Services in der Live-Umgebung nutzen, um so das Risiko für den Endanwender zu minimieren.

Wenn TiP in einer Organisation eingeführt wird, änder sich das gesamte Entwicklungsmodell. Bevor TiP hinzugefügt wurde, war es hauptsächlich BUFT „big up-front testing“, das existierte. Das bedeutet, dass alle Tests abgeschlossen waren, bevor eine Software live ging (BUFT). Aber mit TiP haben die Entwickler mehr direkten Kontakt mit dem Endanwender und die Tester brauchen nicht wie Endanwender agieren. Die Testumgebung wird zu einer internen Produktionsumgebung, in der Tests mit Hilfe von „dogfooding“ erfolgen und eigene Device genutzt werden. Wenn die Software
stabil ist, ist der Test in Produktion mit Hilfe von Beta Tests erfolgt (Whittaker, 2012).

Zukünftige Entwicklungen

Eine der ersten Fragen, die zu beantworten sind, ist: Werden Tests in Produktion ausgeführt, wie kann das erfolgen, ohne die Kontinuität und die Stabilität für reale Endanwender zu beeinflussen? Andere Fragen sind: Wie können Regressionstests und Testumgebungen für die Überwachung genutzt werden und wie sieht das aus? (Riungu-Kalliosaari, 2012). Wenn eine Teststrategie vorgebracht wird für TiP, sollte mit der Betriebsabteilung diskutiert werden, weil das Monitoring aller Systeme durch TiP beeinflusst werden kann. Der Betrieb wird in der Produktionsumgebung konstant überwacht. Aber wenn Tester in der Produktionsumgebung testen, überwachen diese ebenfalls mit ihrem eigenen Ziel. Zwischen Test und Betrieb kann eine neue Rolle „Testops“ kreiert werden (Eliot, 2012). In dem Moment, in dem TiP zur Anwendung kommt, muss klar sein, welche Strategie zur Abdeckung der Risiken verwendet werden kann. Gibt es Unterschiede in der Verantwortlichkeit zwischen Fehlerbehebung in der Testumgebung und Fehlerfällen in der Produktionsumgebung? Was wird passieren, wenn man einen Fehler in der Produktion findet? Wer behebt diesen? Wer bezahlt dafür? Und wann sollte er behoben sein? Es sollte mehr Forschung durchgeführt werden, wie TiP in einer Organisation eingeführt werden kann und welche Techniken für das Finden unterschiedlicher Fehler genutzt werden können.

Fußnoten

Bücher

  • Aalst, L. van der, Baarda, R., Broekman, B., Koomen, T., Vroon, M., 2006. TMap® Next, voor resultaatgericht testen,Tutein Nolthenius. p. 44–51, p. 68, p. 82, p. 412, p. 419
  • Bell, S. Y., Levy, L. B., 1990. Software product liability: Understanding and minimizing the risks, Berkely Technology Law Journal, Boalt Hall School of Law, University of California at Berkeley, California. Vol. 5, issue 1, 2–3. Available at: http://www.law.berkeley.edu/journals/ btlj/articles/vol5/Levy.pdf
  • Blokland, K., Mengerink, J., 2012. Cloutest, Testen van cloudservices. Tutein Nolthenius. p. 162–170
  • Eliot, S., 2012. Testing in Production A to Z, TiP Methodologies, Techniques, and Examples, Software Test Professionals, p. 5, p. 55, p. 19, p. 20. Available at: http://www.setheliot.com/blog/a-to-z-testing-inproduction-tip-methodologies-techniquesand-examples-at-stpcon-2012/, http:// www.softwaretestpro.com/item/5477
  • Eliot, S., 2011. Testing in Production, Your Key to Engaging Customers, Quality Assurance Special Interest Group, p. 19–20. Available at: http://www.qasig.org/presentations/QASIG_Testing_in_ProductionEngaging_Customers.pdf
  • Groot, D. J. de, 2012. TiP and the iceberg, Professional Tester, June. Available at: professionaltester.com
  • Grundy, J., Kaefer, G., Keong, J., Liu, A., Guest Editors’ Introduction: Software Engineering for the Cloud. IEEE Software, March–April 2012, vol. 29, no. 2, p. 26-29, Available at: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
  • Riungu-Kalliosaari, L., Taipale, O., Smolander, K., Testing in the Cloud: Exploring the Practice. IEEE Software, March–April 2012, p. 46–51
  • Pol, M., Teunissen, R., Veenendaal, E. van, 2000. Testen volgens TMap®, Tutein Nolthenius, 5th edition, p. 495
  • Groot, D. J. de, Kramer, A., Loenhoud, H. van, Prins, A., Ro, J., Schoots, H., Vorst, P., 2012. Bepaal je koers!, Toekomst en trends in testen, TestNet, p. 75-81

Internetquellen

(API)

  • API definition: http://en.wikipedia. org/wiki/Application_programming_ interface#Use_of_APIs_to_share_content
  • Project API: https://capi.t-mobile.nl/
  • Customer API documentation: https:// capi.t-mobile.nl/documentation
  • My T-Mobile app: http://www.t-mobile.nl/ service-en-contact/apps/my-t-mobile-app

(app)

  • Definition of app: http://dictionary.reference.com/browse/app

(BUFT)

  • http://blogs.msdn.com/b/seliot/archive/2010/01/20/building-services-thedeath-of-big-up-front-testing-buft.aspx

(dogfooding)

  • http://harveynick.com/blog/2011/08/26/ dogfood-nom-nom-nom/
  • http:// en.wikipedia.org/wiki/Eating_your_own_ dog_food

(error codes)

  • http://en.wikipedia.org/wiki/List_of_ HTTP_status_codes

(environment)

  • Why are there so many environments? http://askville.amazon.com/environments-software-development/AnswerViewer.do?requestId=2956413

(forum)

  • Comment on the T-Mobile Forum (in Dutch): https://forum.t-mobile.nl/belstatus-398/de-online-belstatus-gadget-pedge-werkt-niet-meer-151973/

(consumentenbond)

  • http://www.consumentenbond.nl/over/ Onderzoek/onderzoek_en_verslagen

(ICTRecht)

  • http://ictrecht.nl/diensten/juridischeproducten/starterspakket/softwareontwikkelaars/and http://blog.iusmentis. com/2011/09/19/ben-ik-aansprakelijkvoor-de-fouten-in-mijn-software/

(Madagascar)

  • http://en.wikipedia.org/wiki/Madagascar_(2005_film), http://www.imdb.com/ title/tt0351283/

(maintenance testing)

  • http://en.wikipedia.org/wiki/Maintenance_testing

(production environment)

  • http://www.head-fi.org/t/167356/whatdoes-the-word-production-environmentmean and http:/www.techopedia.com/ definition/8989/production-environment

(TiP)

  • http://wiki.answers.com/Q/What_ is_production_testing_in_Software_ development#ixzz266VbdjZh

(TNO)

  • http://www.tno.nl/groep. cfm?context=thema&content=markt_pr oducten&laag1=897&laag2=191&it em_id=377

(TNO-Huawei)

  • http://www.nu.nl/internet/2601169/tnoen-huawei-testen-lte-in-nederland.html

(Whittaker, 2012)

  • http://www.computer.org/cms/Computer.org/dl/mags/so/2012/02/extras/ mso2012020004s.mp3

(Whittaker, 2011)

  • http://blog.utest.com/testing-the-limitswith-googles-james-whittaker-parti/2011/05/ and http://blog.utest.com/ james-whittaker-the-future-of-softwaretesting/2008/11/

Der Artikel wurde aus dem Englischen übersetzt und ist erstmals in Testing Experience Nr. 20, „Testing in the Cloud“ (Dezember 2012) erschienen.

Weitere Artikel vom testing experience Magazin

Automatisierung oder nicht – Lösen wir das richtige Problem? von Markus Gärtner

TMMi: Warum Reifebestimmung wichtig ist von Michiel van der Voort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts