Wie kann ich meinen Web-Service testen, anstatt mich dazu zu zwingen, seinen Web-Service-Client zu testen?

Question

Ich arbeite an einer Reihe von Web-Services und praktisch jedes Mal, wenn ich einen größeren Build produziere, beginnt QA, Bugs auszulösen, die ich oft nicht mit dem serverseitigen Code, sondern mit ihrer Mist-Client-Bibliothek zu tun habe. Ich habe versucht, es zumindest so zu machen, dass sie keine Fehler ohne den XML-Code, den sie auf den Server schieben, einreichen, aber sie ignorieren diese Anforderung häufig.

Answer 1

Aufzeichnen, dokumentieren, Fall vorbereiten. Sie halten eine Aufzeichnung über die Anzahl der Zeit, die sie falsch waren, die Zeit, die Sie brauchten, um das Problem zu diagnostizieren, und die Zeit, die es brauchte, um es zu beheben. Dann eskalieren Sie das Problem zum Management: In den letzten 5 Arbeitstagen musste ich insgesamt 15 Stunden zuweisen, um die Probleme X, Y und Z zu diagnostizieren, die ohne Berücksichtigung durch QA geöffnet wurden. Sie mussten A, B und C in ihren Tests überprüfen, um die Probleme zu mildern. Hier ist das XML, das sie vorher gesendet haben, hier ist das XML nach. Wie bei jedem Unternehmensdschungel, dokumentieren Sie Ihre Beschwerde: steht das tägliche Einkommen einer Person auf dem Spiel und er wird Sie zurück kämpfen. QA-Person hat mehr zu verlieren als du, also wird er härter kämpfen. Sie müssen Ihre Ansprüche nachweisen können. Entweder passt die QA ihre Einstellung an, oder Sie bekommen zusätzliche Zeit, um ihr Durcheinander zu beheben, oder nichts ändert sich und Sie wissen zumindest, wo Sie stehen und ... wohin Sie als Nächstes schauen.

Answer 2

Diese Frage wahrscheinlich unter der breiteren Verallgemeinerung von

eingereicht werden könnte: „Wie kann ich meine Mitarbeiter ihre Arbeit richtig zu tun?“

Answer 3

Dies hat wahrscheinlich mehr mit Ihren Arbeitsrichtlinien und -prozeduren zu tun als mit der Programmierung.

Aber in der einfachsten Form, ist die Beweislast auf QA, und Sie sind unschuldig, bis bewiesen, schuldig. Wenn die QA einen Fehler bei Ihnen auslöst, sollten sie dies mit den maximal verfügbaren Daten tun, was beweist, dass es tatsächlich einen Fehler gibt und nicht nur ein falsches Negativ auf ihrer Seite. Alles andere ist Mangel an Professionalität auf ihrer Seite.

Sie sollten Richtlinien festlegen und einhalten, um möglichst wenig Zeit zu verschwenden. Sie debuggen ihre Tests ist NICHT akzeptabel, noch ist es Ihre Aufgabe.

Answer 4

Vielleicht können sie nur über den Client auf Ihren Web Service zugreifen. Was, wenn Sie ihnen Werkzeuge wie soapUI gezeigt haben und sie diese Werkzeuge benutzen lassen, um Ihre Dienstleistung direkt zu prüfen?

Answer 5

Der Standard Weg, um mit einem solchen Problem umzugehen ist Eskalation. Melden Sie das Problem in der Hierarchie an jemanden, der deren überlegen ist. Stellen Sie sicher, dass Sie gut geschriebene Fallbeschreibungen und Argumente haben, warum sie ihre Vorgehensweise ändern müssen.

Da die Menschen auf der Eskalationsstufe wird höchstwahrscheinlich Manager mit wenig/keine Erfahrung in der Programmierung sein, schreiben Sie Ihre Argumente in ‚Geschäftssprache‘: Wert, Umsatzverlust, Einsparpotential (mein Favorit !) usw.

Answer 6

Markieren Sie es als "nicht reparieren - kein Fehler" und werfen Sie es zurück bei QA.

Answer 7

Zwei verschiedene Dinge.
Firs QA sollte XML in Fehlerbericht enthalten. JEDE relevante Information, die sie kennen, sollte im Fehlerbericht sein. Falls erforderlich, eskalieren Sie dies, wie andere vorgeschlagen haben.

Zweitens, wenn es Problem mit ihrem Client ist, überprüfen Sie, ob der Benutzer die gleiche Bibliothek verwenden wird. Wenn Sie die QA nicht bitten, den Client/die Bibliothek/den Weg zu ändern, prüfen sie den Dienst. Wenn Fragen nicht helfen, eskalieren zu zeigen, wie viel Zeit und Geld es kostet. Wenn ja, müssen Sie herausfinden, wie Sie Ihren Service mit dieser Bibliothek arbeiten lassen können.

Diese oder eine andere Eskalation kann erforderlich sein.