Wie kann man den Kunden ermutigen, einige interne QS-Tests durchzuführen?

Update / Klarstellung Mein Kunde versteht die Notwendigkeit seiner internen Tests und er / sie schwört immer, dass er / sie es "besser" machen wird (dh etwas tun wird), aber es passiert einfach nicht. Sie haben nicht das Budget für externe Tests. Ich schätze, ich frage (undeutlich, ich gebe zu), was einen "Test früh, Test oft, Test auf dem Ethos der Zielmaschinen" auslösen könnte.

Frage: Wie können Benutzer dazu ermutigt werden, sich die Zeit zu nehmen, Probleme mit neuen Releases explizit zu testen und zu melden, und nicht in Produktionsprojekten "Test-as-they-go".

Hintergrund: Ich habe einen kleinen Kunden, für den ich eine Reihe von Multimedia-Präsentationstools geschrieben habe. Sie sind ein netter Kunde und wir haben eine gute Beziehung. Das Projekt ist im Gange und fügt im weiteren Verlauf Funktionen hinzu.

Ich habe zwei Probleme:

1. Die Definition der Funktionen erfolgt im Handumdrehen, häufig telefonisch, vorbehaltlich Änderungen, Überarbeitungen und Umkehrungen. (ein bisschen wie Kennedys "Wir werden zum Mond gehen und die anderen Dinge tun" - ich war immer amüsiert über den Teil "andere Dinge" davon)

2. Es werden praktisch keine QS-Tests durchgeführt.

Ich kann mehr oder weniger mit Nummer 1 umgehen. Dies ist kein Kunde, der eine Spezifikation vor einem Meeting lesen würde, geschweige denn eine aufschreiben würde. Ich bin daran gewöhnt. Es ist Punkt 2, mit dem ich ein Problem habe: Sie testen keine neuen Versionen oder werden sie nicht testen. Was sie tun, ist, sie für die Produktion zu verwenden. Wenn also Fehler auftreten, finden sie entweder eine Problemumgehung und melden sie nicht, oder sie haben es so eilig, mit dem Projekt fortzufahren, dass Fehlerberichte vage sind.

Wir haben viele Diskussionen darüber geführt, aber ich konnte sie nur ein wenig anstupsen (z. B. verwenden wir Github zum Verfolgen von Problemen - obwohl ich es meistens benutze). Es gibt zwei Gründe: Sie sind ein kleines Beratungsunternehmen und haben nicht die Ressourcen zum Testen (oder das Budget, um es auszulagern). Und kulturell: Obwohl sie sich als "Entwickler" verstehen, sind sie eigentlich nur Benutzer eines Multimedia-Softwarepakets. (ZB haben sie nicht die obsessive Aufmerksamkeit der Neurose für Details von "echten" Entwicklern).

Dies betrifft mich, wie Sie es erwarten würden: Ohne Feedback kann ich nicht sagen, ob eine Funktion vollständig ist (siehe Nr. 1) oder ob es andere Konsequenzen gibt. Es macht mich auch ein bisschen faul.

Sie haben nicht die obsessive Aufmerksamkeit für Details von "echten" Entwicklern

Vorwort : Die Art der Sprache, die Sie hier verwendeten, ist für mich normalerweise eine rote Fahne. Wenn ich Leute über "echte" Entwickler oder die (einzige) "richtige" Vorgehensweise sprechen höre, denke ich an Frachtkult-Entwickler mit Tunnelblick .

Nun, ich sage nicht, dass Sie definitiv einer dieser Entwickler sind (ich habe nicht genügend Beweise, um das zu behaupten), aber wenn ja, dann könnten Sie von dieser Antwort profitieren.

Antworten

Es hört sich so an, als würden Sie und Ihr Kunde für verschiedene Dinge optimieren. Es ist eine bedauerliche Tatsache in der Softwareentwicklung, dass die Anforderungen des Unternehmens und die Wünsche der Entwickler oft nicht unbedingt übereinstimmen.

Softwareentwickler sind oft leidenschaftliche Menschen mit einem Fokus auf Verbesserung. Sie möchten die Softwareleistung, den Entwicklungsprozess, Geschäftsprozesse, Kommunikationsmethoden usw. verbessern. Und das ist großartig. Sich auf diese Dinge zu konzentrieren, ist das, was die Handwerker und Handwerkerinnen von den geistlosen Tastern unterscheidet.

Ihr Kunde ist jedoch kein Software-Handwerker. Ihr Kunde ist ein Unternehmen mit ganz anderen Prioritäten. Und manchmal sehen diese Prioritäten für uns Software-Handwerker lächerlich aus ... aber das liegt nur daran, dass wir für verschiedene Dinge optimieren.

Unternehmen möchten häufig Optimierungen für die vorzeitige Markteinführung und kurzfristige Kosteneinsparungen vornehmen. Dabei müssen sie möglicherweise auf Qualitätssicherung, Benutzererfahrung, langfristige Kosteneinsparungen und andere Faktoren verzichten, die Entwickler zum Ticken bringen.

Ist das etwas schlechtes? Na ja, nicht unbedingt. Ich kann nicht für alle Unternehmen sprechen, aber meiner Erfahrung nach tun meine Kunden diese Dinge, um ihren eigenen ROI (Return on Investment) zu steigern. Dinge wie Qualitätssicherung, UX-Verfeinerung und langfristige Planung bieten ihnen einen niedrigeren ROI. Schlimmer noch, viele Unternehmen haben Investmentstrukturen, die nur kurzfristige Gewinne belohnen, im Gegensatz zu nachhaltigen Ansätzen und langfristigen Gewinnen.

Während Sie also versuchen könnten , die Idee der Qualitätssicherung an Ihren Kunden zu verkaufen, verschwenden Sie möglicherweise Ihre Zeit und belasten Ihre Beziehung zu ihm. Im besten Fall werden Sie jemanden dazu bringen, Ihre Ideen auszuprobieren (unwahrscheinlich). Im schlimmsten Fall müssen Sie das gesamte Unternehmen davon überzeugen, seine Anreizstrukturen zu überarbeiten, damit sich langfristige Investitionen wie die Qualitätssicherung auszahlen. In beiden Fällen sind Ihre Erfolgsaussichten gering.

Die interessante Frage ist, wann Sie bezahlt werden und nicht, ob Ihr Kunde selbst Tests durchführt.

• Wenn Sie aufgrund Ihrer Zeit bezahlt werden, ist das kein Problem.
• Wenn Sie im Voraus bezahlt werden, ist das kein Problem.
• Wenn Sie bezahlt werden, wenn der Kunde das Projekt für „erledigt“ erklärt, ist das ein großes Problem.

Das Problem ist, wie Sie wissen können, wann der Kunde die Software akzeptiert und Sie bezahlt. Dies funktioniert offensichtlich nicht, wenn der Kunde das Projekt kontinuierlich mit vage definierten neuen Anforderungen ändert. Wenn dies bedeutet, dass der Zahltag immer verschoben wird - und dies bei jeder Anforderung unwahrscheinlicher wird - wird dies für Sie unhaltbar.

Ein fester Vertrag, der sorgfältig alle Funktionen festlegt und definiert, unter welchen Bedingungen der Kunde diese Funktionen akzeptiert, ist eindeutig sehr unangenehm streng, ermöglicht Ihnen jedoch, das Projekt im Voraus zu planen (auch das nächste Projekt). Es garantiert auch, dass Sie Ihr Geld für die von Ihnen gelieferte Software erhalten, wenn sie den Spezifikationen entspricht. In einem solchen Szenario liegt die einzige Verantwortung eines Kunden in der Phase der Vertragsdefinition und am Ende der Abnahmetests .

Diese von einem Kunden durchgeführten Abnahmetests unterscheiden sich von anderen Testformen:

• Unit-Tests
• Systemintegrationstests
• Usability-Tests
• Belastungstests
• Pre-Release-Tests

Sie sollten die Abnahmetests so weit wie möglich vorwegnehmen und selbst durchführen, bevor Sie die Funktionalität bereitstellen, um Verlegenheiten zu vermeiden. Abgesehen von Abnahmetests (die nur die Vertragserfüllung messen , nicht die Softwarequalität ) liegt die gesamte Qualitätssicherung in Ihrer Verantwortung. Insbesondere verfügt Ihr Kunde nicht unbedingt über eine QS-Einstellung, den erforderlichen technischen Hintergrund oder die vertragliche Verpflichtung, eine QS durchzuführen. Außerdem finde ich das Outsourcing der Fehlersuche an den Kunden ziemlich unprofessionell.

Das heißt nicht, dass Bugs nicht passieren würden. Angenommen, Sie haben eine projektbasierte Beziehung zu Ihrem Kunden, dann möchten Sie die Grenze zwischen Höflichkeit und schnellem Bereitstellen von Korrekturen ziehen und erklären, dass er die aktuelle Version als ausreichend für seine Anforderungen akzeptiert hat - große Änderungen erfordern einen neuen Vertrag. Wenn Sie einen laufenden Supportvertrag haben, müssen Sie sich natürlich an Ihren vereinbarten Servicelevel halten.

In einer agilen Umgebung ist es wichtiger, auf Kundenbedürfnisse zu reagieren, als sich an den Vertrag zu halten, aber Sie möchten trotzdem bezahlt werden. Aus diesem Grund legen viele agil ausgerichtete Projektmethoden Wert auf eine enge Kundeninteraktion, sodass der Kunde möglicherweise Teil des Teams wird. Sie können dann jederzeit mit diesem „Product Owner“ sprechen, um alle erforderlichen Punkte zu klären. Da die PO befugt ist, Ihnen die Zeit zu gewähren, an allen Funktionen zu arbeiten, die sie für wertvoll halten, kann dies auch dann funktionieren, wenn Sie mit vagen Kundenanforderungen beginnen. Wenn Sie keine so enge Kommunikation haben, müssen Sie einen formaleren Ansatz verfolgen.

• Wenn Sie von neuen Kundenbedürfnissen erfahren, arbeiten Sie mit dem Kunden zusammen, um diese in Anforderungen umzusetzen. Dies hilft dem Kunden, das zu bekommen, was er eigentlich will.
• Anforderungen sind objektiv messbar - sie sind entweder erfüllt oder nicht. Dies erspart dem Kunden halbe Lösungen, die nur eine Art von Arbeit sind.

• Alle Kundenanfragen müssen schriftlich gestellt werden, damit Sie sie in Rechnung stellen können. Dies schützt sie davor, dass ihnen Dinge in Rechnung gestellt werden, an denen Sie gerade arbeiten wollten - beispielsweise das Umschreiben der gesamten Benutzeroberfläche, wenn Sie gefragt werden, ob eine Schaltfläche anders ausgerichtet werden soll.

  Viel Kommunikation kann persönlich oder über das Telefon erfolgen, aber am Ende möchten Sie ein Stück Papier, um zu dokumentieren, dass der Kunde Sie an diesen Anforderungen arbeiten lassen möchte . In einfachen Fällen kann es ausreichen, ein Telefongespräch erneut zu führen und ihnen eine E-Mail zu senden, um zu überprüfen, wozu sie Sie aufgefordert haben.

Fehlerberichte sind immer schwierig. Wenn Ihre Kunden selbst Entwickler sind, sollte dies helfen, da sie Ihre Bedürfnisse verstehen können: klare Schritte zur Reproduktion. Eine einfache Möglichkeit, einen umfassenden Einblick zu erhalten, besteht darin, die Protokollierung in der bereitgestellten Software zu aktivieren. Vorausgesetzt, die Datenschutzprobleme können geklärt werden, und jeder Fehlerbericht muss mit dem aktuellen Protokoll versehen sein. Dies garantiert nicht nur eine schriftliche Kommunikation, sondern gibt auch Aufschluss darüber, was der Benutzer tatsächlich getan hat (im Gegensatz zu dem, was er zu tun versucht hat). .

Der Weg, die Kommunikation von Fehlern zu fördern, besteht darin, die häufige, differenzierte Kommunikation von Funktionen zu fördern. Wenn Sie eine Firma ausbilden, die ohne Zeremonie um alles bitten kann , wird diese Funktion auch für kleinere Fehler verwendet. Geben Sie es auf, den Workflow Ihres Kunden zu ändern, es sei denn, diese Änderungen erleichtern ihm das Leben.

Es ist schwierig, Ihren Kunden dazu zu bringen, interne Tests durchzuführen, aber Fehler zu melden, ist nicht so schwierig, wie es sich anhört. Die Möglichkeit, mehr Feedback zu erhalten, besteht darin, die Reibung der Benutzer zu verringern ... auch wenn dies bedeutet, dass Sie einen Teil dieser Reibung auf sich selbst übertragen.

1. Verwenden Sie einfachere Tools, auch wenn diese Tools nicht ausreichend und ungeeignet sind. Zum Beispiel ist BaseCamp ein ziemlich schrecklicher Bug-Tracker (weil er für das Projektmanagement gedacht ist), aber die Leute sind tatsächlich bereit, ihn zu verwenden.

2. Da die von uns verwendeten Bug-Tracker das Kopieren und Einfügen von Bildern nicht unterstützten, habe ich ein einfaches Programm geschrieben, das das aktuelle Bild der Zwischenablage (als Guid) auf die Festplatte kopiert und dann die Guid in die Zwischenablage kopiert. Nach einer minimalen Schulung konnte ein Benutzer Bilder aus der Zwischenablage an Probleme anhängen, indem er nur den Druckbildschirm drückte, auf eine Schaltfläche klickte und sie dann in den Dateiauswahldialog des Fehlerübermittlungstools einfügte.

Ein Screenshot (möglicherweise in MS Paint mit Anmerkungen bearbeitet) und 1-2 Sätze reichen aus, um die meisten Funktionen / Fehler zu lokalisieren.

Beide Vorschläge zielen auf Reibungspunkte ab, die ich erlebt habe, und beide Vorschläge haben die Berichterstellung um einen Faktor von mehr als 10 erhöht. Sie müssen jedoch Ihre eigenen Reibungspunkte als Ziel festlegen.

Vereinfachen Sie das Testen für Ihren Kunden, aber erschweren Sie es Ihrem Kunden wirklich, neue Funktionen in einer nicht getesteten Version in der Produktion zu verwenden. Dies kann folgendermaßen erreicht werden:

Wann immer Sie eine neue Funktion ausliefern, implementieren Sie diese zuerst in einer "Beta-Version", die deutlich mit dem Zeichen "Nicht für die Produktion" gekennzeichnet ist. Sie stellen diese Beta-Version dem Client zum Testen zur Verfügung. Sie stellen auch die neueste "Produktionsversion" zur Verfügung, die er für die reale Produktion verwenden soll (ohne die neuen Funktionen, aber mit den neuesten Fehlerkorrekturen), und Sie lehnen es ab, die neuen Betafunktionen in die Produktionsversion zu übertragen, bis Sie ein Feedback von jemandem von erhalten Die Kundenseite hat es zumindest zuerst ausprobiert.

Wenn der Kunde damit beginnt, die Beta-Version für seine realen Produktionsdaten zu verwenden, obwohl beim Starten des Programms immer die große Meldung "Not for production use" angezeigt wird, können Sie ihm nicht helfen, aber Sie haben zumindest klargestellt, dass die Produktion bei jedem Produktionsausfall eingestellt wird arbeiten, weil er die Beta für falsche Zwecke verwendet, dass es eindeutig seine Schuld ist. Wenn der Client daraus nicht lernt, können Sie in Erwägung ziehen, die Fähigkeit Ihres Clients zur Verwendung der "Beta" in der Produktion zu deaktivieren, indem Sie einige wichtige Funktionen deaktivieren, z. B. das Speichern der Ergebnisse auf der Festplatte in der "Beta", falls dies erforderlich ist.

Wenn Sie eine separate Beta-Version bereitstellen, müssen Sie eine ordnungsgemäße Versionskontrolle / Konfigurationsverwaltung einrichten, damit Sie einen Produktionszweig und einen Beta-Testzweig problemlos nebeneinander verwalten können. Aber da Sie mit Github arbeiten, verwenden Sie vermutlich bereits so etwas wie GIT, was diese Art der Verwaltung sehr einfach macht.