Wie kann die Rolle der QA die Abstimmung zwischen Business und IT aufrechterhalten?

In meiner vorherigen Organisation gab es eine Trennung zwischen dem Geschäftsbetrieb und der IT, die sich immer auf die endgültige Ableitung auswirkte.

Aus irgendeinem Grund wurde die Geschäftsabsicht im Endprodukt nicht genau dargestellt. Obwohl wir den Business Case immer wieder überprüft haben, fehlte immer eine Funktion oder funktionierte nicht wie erwartet. Wir hatten QA-Tester im Entwicklungsteam, aber auf der operativen Seite wurde kein UAT durchgeführt. Ich habe also einige Fragen, bei denen ich Ihre Unterstützung erbitte, um dieses Problem in Zukunft zu vermeiden.

  1. Sollten wir QAs an beiden Enden benötigen?
  2. Wer sollte eigentlich die UAT durchführen?
  3. Wer sollte die Testfälle schreiben?

Antworten (2)

Dies ist ein häufiges Problem, auf das ich in mehreren Organisationen gestoßen bin.

  1. Unternehmen erwarten möglicherweise, dass QA sicherstellen kann, dass das System ihre Anforderungen erfüllt. Die QA wird jedoch mit den gleichen Anforderungsspezifikationen wie die Entwicklung arbeiten. Die QA kann sicherstellen, dass das System den Spezifikationen entspricht. Dies ist nicht dasselbe wie sicherzustellen, dass die Anforderungen den geschäftlichen Anforderungen entsprechen.

    UAT sollte ein ganz anderer Prozess sein. Es wird überprüft, ob die implementierten Anforderungen den Geschäftsanforderungen entsprechen. Wenn Sie dies als QA-Aktivität betrachten, benötigen Sie zwei QAs mit zwei verschiedenen Teams. Nach der Lieferung ist nicht der Zeitpunkt, um Abweichungen zwischen den Spezifikationen und den Geschäftsanforderungen zu identifizieren.

    Usability-Tests können in die Grauzone zwischen UAT und QA fallen. QA sollte die Tests handhaben, die jedes Mal einen neuen Benutzer (externe Ressource) erfordern. UAT kann Fälle handhaben, in denen Geschäftsanwender das System für den angegebenen Zweck einsetzen. Benutzer in UAT-Tests können an mehr als einem Testzyklus beteiligt sein.

  2. UAT ist eine Geschäftsrolle, um sicherzustellen, dass das System wie gebaut wirklich die Geschäftsanforderungen erfüllt. Je früher Sie das Geschäftsteam dazu bringen können, zu testen, ob die Anwendung ihre Anforderungen erfüllt, desto besser. Je früher das Unternehmen das System überprüft, desto früher können Probleme identifiziert werden.

    Es ist in der Regel schwierig, Unternehmen in UAT einzubeziehen. Ich habe festgestellt, dass dies ein ziemlich häufiges Problem ist. Dadurch wird die Erkennung von Abweichungen zwischen den Spezifikationen und den Geschäftsanforderungen verzögert. Die Beteiligung des Unternehmens während des gesamten Entwicklungsprozesses sollte zu einer früheren Erkennung führen.

    Unternehmen möchten möglicherweise auch die Schuld abwälzen, indem sie sich aus dem Projekt zurückziehen, nachdem sie die Anforderungen erfüllt haben. Es kann hilfreich sein, Schuldzuweisungen zu vermeiden und Unternehmen einzubeziehen, um den Erfolg des Projekts sicherzustellen.

  3. Das QA-Team sollte die Anforderungstestfälle schreiben. Wenn sie am Anforderungserfassungsprozess beteiligt sind, haben sie ein besseres Verständnis der Anforderungen. Dadurch können Abweichungen zwischen den dokumentierten Anforderungen und Testspezifikationen frühzeitig erkannt werden.

    Es kann eine beträchtliche Anzahl von Unit-Testfällen geben, die für den Code entwickelt wurden. Dies sollte in der Verantwortung des Entwicklungsteams liegen. In Unit-Testfällen getestete Anforderungen sind möglicherweise nicht Teil der Systemanforderungen. Das QA-Team kann die Entwickler möglicherweise beim Entwerfen von Unit-Testfällen unterstützen.

Ich denke, dieses Zitat fasst eines der Probleme beim Sammeln von Anforderungen zusammen:

„Ich weiß, dass Sie glauben, dass Sie verstehen, was ich Ihrer Meinung nach gesagt habe, aber ich bin mir nicht sicher, ob Sie erkennen, dass das, was Sie gehört haben, nicht das ist, was ich gemeint habe.“ Robert McClosky

Es liest sich für mich wie ein grundlegender Mangel an anständigen Anforderungen, die von Anfang an erhoben wurden. War das Unternehmen an der Entdeckung oder anfänglichen Diskussion beteiligt?

Das klingt nach dem perfekten Szenario, um einen agilen, iterativen Plan auszuprobieren. Die Konzentration auf kleinere, häufigere Lieferungen (ein Sprint, wenn Sie es vorziehen) mit einem Vertreter der Geschäftseinheit, um Feedback zu geben, sollte zu einem Produkt führen, das den Zielen aller näher kommt. Oder wenn nicht, sollten sie früher wissen, warum.

Um Ihre Fragen zu beantworten:

  1. 1 QA sollte ausreichen, wenn die Anforderungen genau definiert sind. 2 klingt nach bürokratischer Hölle.

  2. In diesem Fall würde ich empfehlen, dass UAT von Business durchgeführt wird.

  3. Werden Anforderungen erhoben, sollten sich Testfälle quasi von selbst schreiben.