Was könnte eine Armee einem Tester beibringen? Was sind die beiden Extreme bei Testansätzen? Wie kann man erklären, dass technische Schulden durch Zahlung rot sind? Was haben die vorherigen Fragen gemeinsam?
Die allgemeine Sache ist, dass sie trotz aller Unterschiede alle einer Person nahe stehen.
Jim Holmes verfügt über mehrere Jahrzehnte IT-Erfahrung, die in den 80er Jahren bei der US Air Force begann - es ist nicht verwunderlich, dass er bereit ist, viel zu erzählen. Das Konzept der „Testkultur“ ist für ihn wichtig, und wir haben ihm Fragen gestellt, die sehr unterschiedlich sein können, aber letztendlich irgendwie mit der Testkultur zusammenhängen.
- Einführungsfrage: Erzählen Sie uns von sich.- Mein Name ist Jim Holmes, ich bin ein unabhängiger Berater und Inhaber meiner eigenen Firma, Guidepost Systems. Ich habe mich auf die Qualität der Softwarebereitstellung spezialisiert und programmiere seit ungefähr 20 Jahren, bevor ich lange Zeit in der Armee gedient habe. Ich habe mich vor ungefähr 15 Jahren ernsthaft für Qualität interessiert, als ich an mehreren nicht sehr erfolgreichen Projekten gearbeitet habe. Im Allgemeinen habe ich viel Testautomatisierung, Komponententests, Integrationstests und insbesondere Funktionstests, UI-Tests, durchgeführt. Insbesondere habe ich für eine Firma gearbeitet, die das wunderbare Telerik Test Studio-Tool geschrieben hat. Und in den letzten 5 bis 8 Jahren habe ich angefangen, mich nicht nur mit rein technischen Aspekten, sondern auch mit der Qualität der Versorgung insgesamt zu befassen - das heißt, wie gut ist die Beziehung zwischen dem Versorgungsteam und dem Unternehmen. Gleichzeitig debugge ich WebDriver-Skripte noch lange und löse Probleme wie periodische Fehler aufgrund falscher asynchroner Aktionen. Ich lebe in der Stadt Ashland in Oregon - wohlgemerkt, nicht in Portland (wenn Sie in den USA „Oregon“ sagen, denken normalerweise alle an „Portland“).
- Für den Tester ist der Militärdienst wahrscheinlich der ungewöhnlichste Teil Ihrer Biografie. Was genau hast du dort gemacht?- Ich habe bei der US Air Force gedient, weil ich immer von Flugzeugen inspiriert war und mein Vater Pilot war. Er nahm mich mit auf meinen ersten Flug, als ich erst 4 Jahre alt war. In der Luftwaffe hatte ich großes Glück, ich habe im E-3-Team gedient - dies ist ein so großes Flugzeug mit einer riesigen Scheibe oben, wo ich für den Betrieb des Radars und einiger Kommunikationssysteme verantwortlich war. Seit elf Jahren verwalte und debugge ich dieses große elektronische System. Und während der flugfreien Zeit verwaltete ich die Computer unserer Staffel. Um diese Zeit wurde es möglich, Netzwerke am Arbeitsplatz aufzubauen. Da ich Soldat war, wurde ich außerdem für die Ausbildung bezahlt und besuchte eine Abendschule, um Software zu entwickeln.
Was Ihre Frage betrifft, so ist die Erfahrung des Militärdienstes nicht nur für Tester, sondern auch für viele andere Bereiche ungewöhnlich. Ich kann sagen, dass mir dort zumindest Disziplin beigebracht wurde.
- Ja, im Fall der Armee fällt mir als erstes Disziplin ein. Und damit haben viele Tester und Entwickler Probleme. Glaubst du, sie haben etwas vom Militär zu lernen?- Dies ist eine sehr interessante Frage. Tatsache ist, dass die Disziplin, die mir beigebracht wurde, etwas anders war als beispielsweise die Fallschirmjäger, das heißt, es gab keine ständigen Schreie und Bestrafungen. Mir wurde ein disziplinierter Ansatz zum Testen und allgemein zum Lösen von Problemen beigebracht. Die Disziplin am Arbeitsplatz war ebenfalls wichtig - zu verstehen, was eine Hierarchie ist; Um zu lernen, wie man darin arbeitet, müssen Sie in der Lage sein, mit Vorgesetzten zu kommunizieren. Diese Art von Disziplin hat mir sehr geholfen.
Ich habe die Armee vor 25 Jahren verlassen - ja, ich bin ein alter Mann - und die Arbeit im zivilen Sektor stand aufgrund der dortigen Prioritäten sehr interessant im Gegensatz zu meinen früheren Erfahrungen. In der Armee diente ich in einem Flugzeug, das den Feind über ein großes Gebiet überwachen und meine eigene Sicherheit gewährleisten sollte. Jeder Fehler bedeutete ein Risiko für das Leben unserer Soldaten. Ich möchte nicht übertreiben, aber es war wirklich so. Wenn also jemand in der IT in Panik gerät und verlangt, dass eine Aufgabe dank meiner Disziplin und meiner Erfahrung sofort gelöst wird, kann ich die Menschen immer beruhigen - wir sind nicht bedroht, dass jemand stirbt, und wir verlieren nicht Hunderttausende von Dollar pro Minute (und ich war in solchen Situationen). Wir geraten sehr oft in Panik und lassen uns vom Geschäft oder den Aktionären unnötig einschüchtern und schaffen unvernünftige Spannungen, die niemandem nützen. Vielleicht ist das Beste, was mir die Armee beigebracht hat, die Fähigkeit, Ruhe zu fordern, die Situation gründlich einzuschätzen und unsere Aktionen im Voraus zu planen, und nicht aufgrund einer künstlich erzeugten Panik gedankenlos in eine Aufgabe zu stürzen.
- Das heißt, Sie müssen sich Zeit nehmen, um eine Strategie zu überdenken.- Ja, und in der IT war dieses Problem lange Zeit: Konstante Anforderungen, um das Projekt in dieser Sekunde richtig umzusetzen. Die Hauptsache ist, schnell zu tun, und was genau getan wird, ist von untergeordneter Bedeutung. Meistens kann dieser Druck gesteuert werden, wenn der Dialog korrekt geführt wird. Dafür ist es jedoch wichtig zu sagen, dass wir mehr Wert schaffen, wenn wir etwas mehr Zeit verbringen und das Problem rational angehen.
- Kommen wir zu Ihren aktuellen Aktivitäten. Bei der Arbeit kennen Sie die Vorgehensweise beim Testen in verschiedenen Unternehmen auf unterschiedliche Weise. Es ist klar, dass der Ansatz beispielsweise von der Größe des Unternehmens abhängen kann. Aber es gibt wahrscheinlich viele weniger offensichtliche Unterschiede - können Sie darüber sprechen?- Das ist eine wunderbare Frage. Neben meiner selbständigen Arbeit arbeite ich auch mit Pillar Technology aus Columbus, Ohio. Ich kenne Leute aus dieser Firma schon lange. Mittlerweile arbeiten dort etwa 250 Menschen, und fast alle arbeiten nach dem Prinzip der extremen Programmierung (XP): Sie haben viele Unit-Tests und die Entwicklung ist sehr gut durchdacht. Als ich dort vor drei Jahren eingestellt wurde, war ich der einzige Tester, und sie haben ein sehr hochwertiges Produkt entwickelt. Sie näherten sich dem Testen ausschließlich von der Position von XP aus, von der Position der testgetriebenen Entwicklung aus. Dies ist ein großartiger Ansatz, den sie erfolgreich angewendet haben, und ich habe es zusammen mit einigen anderen Mitarbeitern geschafft, einige Aspekte der Softwarebereitstellung zu ändern.
Und Sie können diese Erfahrung mit einem anderen Unternehmen vergleichen, in dem ich seit drei Jahren berate. Dies ist ein Industrieunternehmen, es gehört zu den Top Ten der Fortune-Liste und beschäftigt weltweit rund 200.000 Mitarbeiter. Sie haben eine sehr große IT-Abteilung für die internen Bedürfnisse des Unternehmens. Es gibt viele gute Leute dort, aber ihre Tests haben sich auf die Praktiken der 1980er oder 1990er Jahre beschränkt. Das Unternehmen produziert große Mengen genau derselben Produkte, und viele sind daran gewöhnt, dass es bei der Herstellung von beispielsweise Kugellagern durchaus möglich ist, die Anzahl der erwarteten Fehler abzuschätzen. Das Problem ist jedoch, dass sie diese Art des Denkens auf die IT übertragen.
Ich hatte ein Gespräch mit vier im Allgemeinen sehr intelligenten Mitarbeitern, die daran beteiligt waren, Fehlerberichte aus mehreren Projekten zu sammeln und die Anzahl möglicher Fehler in der Zukunft vorherzusagen. Ich habe ihnen gesagt, dass dies in der Branche durchaus sinnvoll ist, aber wie werden sie die für eine mobile Anwendung berechneten Indikatoren von den Indikatoren beispielsweise für Webdienste unterscheiden? Sie antworteten, dass es keinen Unterschied gibt. Ich hatte das Glück, völlig entgegengesetzte Punkte im Spektrum verschiedener Testansätze und -kulturen zu sehen.
Außerdem habe ich mit einigen Unternehmen zusammengearbeitet, die es nicht geschafft haben, aus der Startphase herauszukommen, wenn sie die ganze Zeit ohne Rückblick arbeiten und nicht versuchen, die gesamte Situation abzudecken. Und dann, nach einigen Jahren, in komplexen Projekten, werden die Probleme, die in dieser Phase aufgetreten sind, deutlich spürbar, und ich muss die Leute davon überzeugen, dass dieser Ansatz falsch ist und dass ich jetzt aufhören und meine Handlungen richtig durchdenken muss. Im Allgemeinen war meine Antwort etwas umfangreich, ich hoffe, ich habe den Kontakt zu Ihrer Frage nicht vollständig verloren.
- Und in Ihrer Beratungspraxis gab es Zeiten, in denen Ihnen nach Abschluss der Arbeit im Unternehmen gesagt wurde, dass „nichts besser geworden ist“?- Ich werde dir ein Geheimnis verraten, dass es schwer mit Menschen ist, wir sind sehr schwierige Wesen. Dies ist einer der Gründe, warum ich so viele graue Haare habe (der zweite ist meine Tochter). Das Ändern einer Person ist schwierig, das Ändern von Personen in einer Organisation ist noch schwieriger. Also ja, ich habe diese Situation ziemlich oft.
Über einige Berater sagen wir sogar, dass er "ausgebrannt" ist. Dies liegt an der Tatsache, dass wir große Anstrengungen unternehmen, um die Kultur zu verändern, die sich in der Organisation entwickelt hat, und wir müssen viel mit Problemen auf persönlicher Ebene arbeiten - die Menschen haben Angst vor Veränderungen, sie müssen sich ständig davon überzeugen, dass dies notwendig ist und suchen Sie nach dem Weg, der zu ihnen passt. Egal wie stark und laut ich bin, ich kann nicht einfach kommen und sagen: Tu so und so. Wir müssen zu einem Konsens kommen. Diese Arbeit muss jahrelang durchgeführt werden, um etwas zu erreichen, und wenn es den Anschein hat, dass Sie das Problem gelöst haben und eine andere Organisation konsultieren, werden Sie dort genau auf die gleichen Probleme stoßen wie am vorherigen Ort. Wieder einmal verbringen Sie viel Zeit und Mühe, und dann stellt sich heraus, dass in dieser ersten Firma alles bereits in seinen vorherigen Zustand zurückgekehrt ist.
Die Leute sind so arrangiert, es ist schwer für uns, wir kehren oft zu unseren alten Gewohnheiten zurück. Trotzdem gibt es Beispiele für wirklich erfolgreiche Arbeit. Es gibt Organisationen, die es schaffen, das mit Ihnen erzielte Ergebnis zu konsolidieren. Im Allgemeinen würde ich sagen, dass einer den anderen ausbalanciert. Ich mache diese Arbeit weiter, weil diese Erfolgsfälle immens befriedigend sind.
- In Ihrem Blog haben Sie über Ihre beruflichen Grundsätze geschrieben und dort über die Notwendigkeit gesprochen, offen zu sein, immer neue Dinge zu lernen, mehr zuzuhören als zu reden, sich anzupassen und freundlich zu Menschen zu sein. Ich frage mich, ob IT wirklich zu einer guten Einstellung gegenüber Menschen beiträgt.- Ja, es hilft. Ich sagte, dass ich in der Armee gedient habe, wo wir strenge Disziplin hatten - aber wir müssen verstehen, dass Disziplin und Struktur in keiner Weise gute Beziehungen und Empathie mit anderen Menschen beeinträchtigen. Kennen Sie den schottischen Koch Gordon Ramsay? Er leitet die Hell's Kitchen Show. Ich erwähne ihn, weil Köche in teuren Restaurants sich sehr oft ekelhaft gegenüber Mitarbeitern verhalten - sie schreien und beleidigen. Ich hasse diese Einstellung gegenüber Menschen. Für mich ist eine gute Einstellung zueinander wichtig. Wenn Sie Veränderungen erreichen wollen, müssen Sie verstehen, warum Menschen sich ihnen widersetzen, das heißt, Sie brauchen Empathie. Und es wird Ihnen ermöglichen, die Person selbst dazu zu bringen, sich ändern zu wollen. Ein solcher Ansatz ist viel effektiver, als Menschen anzuschreien und zu fordern, dass sie gehorchen und keine Fragen stellen. Jeder Mensch hat seinen eigenen Verstand, seine eigene Seele, seine eigene Erfahrung. Ich möchte nicht tief in die Philosophie eintauchen, aber ich glaube, dass eine gute Einstellung und Empathie es Ihnen auf lange Sicht ermöglichen werden, großartige Ergebnisse zu erzielen. Also ja, sie helfen.
- Sie führen Seminare durch und unterrichten in einem von ihnen Programmierer, die nicht programmieren können. Ich habe zwei Fragen. Erstens: Welche Probleme hindern die Menschen am häufigsten daran, sich selbst zu programmieren? Zweitens: Glauben Sie, dass sich im nächsten Jahr automatisierte Tests gegenüber manuellen Tests durchsetzen werden?- Nach meiner Erfahrung werden Menschen oft nicht durch technische Schwierigkeiten, sondern durch Angst gestört. Ich kann ein Beispiel aus meiner Erfahrung in einem Unternehmen aus Fortune 10 geben, über das ich bereits gesprochen habe. Ich habe mit einem Team von Testern zusammengearbeitet, die manuelle Tests durchgeführt haben, und wir mussten die Automatisierung mit WebDriver durchführen. Von diesen konnten die meisten Eclipse nicht einmal öffnen, um mit dem Schreiben von Code zu beginnen. Sie hatten Angst, ein Skript für die Automatisierung zu schreiben, da dies nach ihrem Verständnis nicht viel anders war als das Schreiben eines skalierbaren Webdienstes oder einer Datenbank mit Multithreading, dh Dinge, die Entwickler seit Jahren gelernt haben. Diese Angst hinderte sie daran, allgemein einfache Dinge zu tun.
Ich entwickle derzeit einen Kurs für das Testministerium, der auf einem Workshop basiert, in dem ich erkläre, dass Sie keine jahrelange Übung benötigen, um einfach eine Java-Datei, C # oder ein Ruby-Skript zu öffnen, sie zu lesen und die allgemeine Struktur zu verstehen oder zu schreiben einfacher Test auf WebDriver. Selbst wenn Sie nicht alles verstehen, was im Code geschieht, können Sie eine allgemeine Einschätzung abgeben, da Sie beispielsweise wissen, dass eine Methode nicht drei Bildschirme belegen sollte und es keine vier verschachtelten if-Anweisungen geben sollte - sie werden schwierig sein Zum Testen können Sie Variablen keine Ein-Buchstaben-Namen usw. geben. Meiner Meinung nach besteht die Hauptschwierigkeit im Anfangsstadium darin, die Angst zu überwinden, dass Sie unglaublich komplexe Aufgaben lösen müssen. Und ich war immer daran interessiert zu sehen, wie schnell meine Kunden diese Angst loswerden - Sie müssen der Person nur einen einfachen Komponententest geben und sie bitten, schriftlich zu arrangieren, zu handeln und zu behaupten. Ich denke, diese menschliche Komponente ist sehr wichtig.
Die meisten Technologien, mit denen wir arbeiten, sind nicht so kompliziert, nur wenige befassen sich mit unbemannten Fahrzeugen. Ich habe einmal ein Seminar für einen Kunden in Indien abgehalten, und es gab einen Manager ohne Programmiererfahrung. Dieser Manager war anfangs sehr wütend, und der Grund war genau die Angst, über die ich gerade gesprochen habe, und diese Angst überlagerte die Zurückhaltung, dumm zu wirken. Aber am Ende der ersten Lektion stürzte er sich so sehr in das Schreiben von Tests, dass ich ihn eine Stunde nach Ende des Unterrichts aus dem Publikum verbannen musste - er saß da, vergrub sich auf dem Monitor, paarte sich mit einem anderen Teilnehmer des Seminars und schrieb einfache Tests für den Gehaltsalgorithmus Bretter. Und der Punkt hier ist überhaupt nicht in meinen Lehrfähigkeiten - es zeigt nur, wie wichtig diese Angst oder ihre Abwesenheit spielt. Hier sprechen wir über Dinge, die der menschlichen Natur innewohnen.
Ihre zweite Frage bezog sich auf den Übergang vom manuellen zum automatisierten Testen. Ich habe einige Erfahrung hier, ich habe drei Jahre in einem Unternehmen gearbeitet, das sich mit Testautomatisierung beschäftigt. Ich glaube, dass die Frage anders gestellt werden sollte und nicht nach Testautomatisierung streben sollte, sondern nach der Entwicklung von Testern und deren Erwerb vieler technischer Fähigkeiten, von denen eine automatisierte Tests sein sollten. Ich würde gerne solche Tester sehen, die mit einer User Story, Spezifikation und Anforderungen frei einen Dialog mit Entwicklern über ziemlich spezielle Dinge führen und gemeinsam nach Lösungen suchen können, die dann im Code enthalten sind. Dies unterscheidet sich etwas von dem Ansatz, bei dem der Tester das Programmieren lehrt, nur um WebDriver-Skripte schreiben zu können. Diese Fähigkeit ist natürlich auch wichtig, aber meiner Meinung nach ist sie nicht die wichtigste. Die Supertask ist meiner Meinung nach die Fähigkeit, einen Dialog mit dem Entwickler zu führen und sicherzustellen, dass er den Testprozess beim Schreiben des Codes berücksichtigt. Sogar TDD wird bereits ein bedeutendes Ergebnis sein - ich glaube, dass alle Organisationen in der Lage sein sollten, so zu schreiben.
Das Fazit ist, dass korrekt gelieferte Tests keineswegs auf Komponententests oder Integrationstests reduziert werden. Sehr oft sind die Leute mit dem Testen eines typischen Codeausführungspfads zufrieden - alle Tests sind bestanden, Kontrollkästchen sind überall, 100% Codeabdeckung wird erreicht. Aber nichts davon garantiert die Qualität des Codes, oder? Obwohl dies natürlich auch notwendige Verfahren sind. Nach meinem Verständnis sollte der Tester nicht nur einige Funktionstests oder Tests in WebDriver schreiben, sondern darüber nachdenken, wie er eine engere Zusammenarbeit mit Entwicklern und Geschäftsanalysten herstellen kann. Sie können beispielsweise die
Mob-Programmierung ausprobieren. Im Allgemeinen glaube ich, dass Automatisierung ein Werkzeug ist, kein Ziel.
- Die Worte „enge Zusammenarbeit mit Entwicklern“ stehen uns als Heisenbug-Organisatoren sehr nahe - selbst der Slogan der Konferenz lautet „Testen, aber nicht nur für Tester“. Und im Zusammenhang mit dieser Zusammenarbeit möchte ich folgende Frage stellen: Was möchten Sie als Person mit umfassender Testerfahrung unseren Lesern und Programmierern sagen?"Dass wir nicht alle böse sind!" Tester haben ihre Bekanntheit mit ihren eigenen Handlungen verdient. Sie bemängeln die kleinsten Details bei Besprechungen, kommunizieren häufig Fehlerberichte, keine Worte. Der Entwickler kommt morgens zur Arbeit und sieht 50 Fehlerberichte, die über Grammatikfehler und nicht ausgerichtete Seiten berichten. Ich war in beiden Rollen und weiß, wie Programmierer darauf reagieren. Dies ist Teil der alten Testschule, und ich selbst habe mich auch einmal so verhalten. Tester, die eher an den modernen Ansatz gewöhnt sind, wissen jedoch, dass es einfacher und besser ist, nur mit ihm zu sprechen, als einen Programmierer mit Fehlerberichten zu bombardieren.
Meiner Meinung nach ist es für Entwickler wichtig zu verstehen, dass ein guter Tester sehr wertvoll sein kann. Wenn Sie im Voraus mit ihm sprechen, können Sie sich viel Zeit und Nerven sparen. Dies ist, was die Theorie der Zwänge sagt. Angenommen, ich bin Entwickler und sehe, dass der Tester ein Problem festgestellt hat. Wenn ich nicht in TFS oder anderswo darüber schreibe, sondern einfach zu ihm gehe und persönlich spreche, hilft mir dieses Gespräch, die Anzahl der Fehler im Code, den ich schreibe, zu verringern. Darüber hinaus sind die meisten Tester in der persönlichen Kommunikation in der Regel alles andere als beängstigend. , , , , — , , , .
, . , , , , — , . , .
, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .
— . «The leadership journey» . , : , , — . ?— , , IT: , , , , . , , , , . , , , . , , .
, . , , , . , : , , . , , , . , , , . . , , . , , - , . , , . , — .
— , . : , , , . — ?— 18 , , 13 14. . , — , , . , , . , .
, . , , . DevOps. , , . , . , Skype - , Skype for Business Google Hangouts, . . , . , , , Xbox — , .
, — . , . hangout Slack — . , , .
20 , , — . . , , , . , , , . . , — , . , , .
— «Technical debt: payment plan». « » , « » , . , , , , ?— . , , IT - , . (Trish Khoo), Twitter hogfish. — , . , , «Technical debt: payment plan». , , , , -, .
, , , , - . -, , , . , , . - X , Y , . , - . , , 30 - , . , -, . , , : - .
, 10 3 . 3 . , . . , , , , . , , , - , . , . , , IT, , . , . , . . , , - , , , .
, , . , , . , , , . , .
— , , , . , , , .— . , . , , , . , , — , . , , - . .
, . , , , , . , , , , , , . , , , .
— , — . , .— Fortune 10, , . , . , , , . , , , , , Acceptance Testing.
, , . , (, Sonar Cube), , . , , . , « », , , , . , , . , , - .
— . .— , . , : , .