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

14

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.

Kein Greifen
quelle
3
Wenn ein Fehler so klein ist, dass es den Benutzern selbst egal zu sein scheint, ob er behoben wurde oder nicht, warum bestehen Sie darauf?
Kamilk
2
@kamilk - die kurze Antwort ist, dass ich in meinen Kunden investiert bin, der es gut macht, produktiv ist usw. Fehlende Funktionsimplementierung usw. Wenn ich nichts davon weiß, kann ich es nicht beheben. Außerdem sind die "Workarounds", mit denen sie aufwarten, oft eine enorme Zeitverschwendung oder sogar eine Beibehaltung früherer Versionen der Software.
Kein Grabbing
18
Wenn Sie in Ihren Kunden investiert sind, geht es Ihnen gut. Sie sollten sehr solide Tests durchführen, bevor Sie sie freigeben. Clients sind keine Tester. Mieten Sie einen Tester oder führen Sie Ihre eigenen Tests durch oder schreiben Sie codierte Tests. Wenn Sie jedoch absolut sicher sein möchten, dass Ihre Produkte für Ihre Kunden funktionieren, testen Sie sie, bevor Sie sie ihnen geben.
Jimmy Hoffa
4
@djechlin - es geht überhaupt um Testen (und Berichten). Und ein Entwickler kann nur so viel testen: Ich benutze es nicht wie die Benutzer.
Kein Grabbing

Antworten:

18

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.

MetaFight
quelle
4
+1, wenn Sie versuchen, die internen Abläufe eines ganz anderen Unternehmens zu ändern, weil es Ihnen nicht richtig erscheint, wird normalerweise eine Beziehung abgebrochen. Ein Fachmann sollte beraten, wenn er ernsthafte Probleme vorhersehen kann, insbesondere, wenn er auch beraten kann, wie sie gemildert werden können. Wenn die Probleme jedoch so klein sind, dass sich das Unternehmen nicht einmal darum kümmert, sie zu melden, ist das Beste, was Sie tun können, hin und wieder eine freundliche Erinnerung zu senden, dass möglicherweise Zeit gespart wurde, wenn X oder Y nicht darauf bestanden haben.
Ordentliche
-1 wie, obwohl dies ein gut geschriebener Beitrag ist, wird hier nicht wirklich die Frage angesprochen, wie Sie vorgehen würden, um es zu tun. Die Antwort ist, dass Sie es auf eine sehr ähnliche Weise tun, die Sie reguläre Entwickler zum Testen überreden: Zeigen Sie, dass das Testen das Risiko verringert. Weniger Risiko == weniger Produktionsprobleme in der Mitte einer Kundendemo.
David sagt Reinstate Monica
Nein, aber danke für die Antwort.
Kein Grabbing
@DavidGrinberg Das ist alles schön und gut, es sei denn, die Anzahl der Produktionsprobleme zu reduzieren, ist den Aufwand / die Kosten / die Zeit für den Kunden nicht wert. In diesem Fall wird sie keine Menge Entwicklerlogik davon überzeugen, ihren ROI zu opfern, nur um Sie zufrieden zu stellen. Und deshalb habe ich das Wie der Frage nicht beantwortet und mich stattdessen auf einen möglichen Fehler in der Prämisse konzentriert.
MetaFight
Handwerker :-)
Toni Leigh
10

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). .

amon
quelle
1
Geld ist nicht das Problem (ich habe einen monatlichen Selbstbehalt - ich werde bezahlt, ob ich codiere oder nicht). So können Sie ihre Bürokultur fördern ... oder etwas, das ich nicht verstehe.
Kein Grabbing
2

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.

Brian
quelle
Diese Antwort bringt es auf den Punkt. Sie möchten, dass sie strenge Testprotokolle implementieren. Dies ist sehr unwahrscheinlich, insbesondere wenn sie von außerhalb der Organisation stammen (z. B. von Ihnen). Das Beste, was Sie in diesem Fall tun können, ist, es so schmerzlos wie möglich zu machen, Ihnen Fehler zu melden, da Sie ohnehin bezahlt werden. Wenn Sie wirklich tot Satz auf einer gründlichen Prüfung, tun es sich, und erfahren Sie mehr über die Geschäftsprozesse , wenn Sie benötigen ... Es ist eine bedauerliche Tatsache , dass viele Unternehmen nie priorisieren Tests.
DrewJordan
1

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.

Doc Brown
quelle
Ich stimme dem ersten Absatz nicht wirklich zu. Oft merken die Leute wirklich, dass etwas wichtig ist, tun es aber nicht (zum Beispiel, wenn sie mit dem Rauchen aufhören). Testen ist ein klassisches Beispiel für so etwas: Auch wenn Sie erkennen, dass es wirklich wichtig ist, erfordert es viel Disziplin, bei Terminen usw. keine Abkürzungen zu treffen. Die Idee der Beta ist jedoch gut Der erklärte Wunsch des Kunden, beim Testen besser zu werden.
Ich würde dies auch als Gelegenheit nutzen, um Punkt 1 anzusprechen. Schlagen Sie dem Kunden einen vollständigen Prozess vor, in dem neue Anforderungen niedergeschrieben, vereinbart, in einer nicht produktiven Umgebung getestet und dann freigegeben werden.
Ich tagge neue Releases als "Alpha" oder "Pre-Release - nicht für die Produktion" und mache den ganzen Github "Meilenstein" mit Problemen (Bugs, zu testende neue Features, etc.), aber es hat keinen Fehler gemacht Unterschied. Die ganze Situation verwirrt mich irgendwie. Ich habe Dinge wie ein monatliches "Pizzatag" vorgeschlagen, um das Testteam (2-3 Personen) auf "Stimmen für Ihre Lieblings- / nervtötendste Angelegenheit" zu konzentrieren. Es ist komisch, aber sie verwenden meine Software die ganze Zeit für wichtige Präsentationen, sodass ich nicht verstehe, warum es nicht mehr Pushback gibt. Ich nehme an, es fällt in "eine andere Sache zu tun / nicht meine Arbeit"
No Grabbing
@TOMATO: Verweigern Sie strikt die Übertragung von Funktionen aus der Vorabversion in die Produktionsversion, bis der Kunde Ihnen mitteilt, dass er die Funktion getestet hat? Versucht Ihr Kunde, diese Ablehnung zu umgehen?
Doc Brown
2
+1 für die deutlich gekennzeichnete Beta-Version: Wenn Sie die Testversion in grellem Lila verteilen, wird oben auf dem Hauptbildschirm ein riesiges grün blinkendes Banner mit der Aufschrift "TESTVERSION - NICHT ZUR PRODUKTION GEBRAUCHT - UNSICHER - UNGEFÄHRDET! msgstr "" "verwenden sie nicht für Präsentationen oder irgendwo, wo ein Kunde sie sehen könnte. Sie können die saubere Produktionsversion zurückhalten (wenn Sie so wollen, nehmen Sie sie als Geisel), bis sie eine Art nützliches Feedback geben.
Christian Severin