「変更を加えるには、人々が抵抗する理由を理解する」：ジム・ホームズのテスト文化

軍隊はテスターに​​何を教えることができますか？ テストアプローチの両極端は何ですか？ 技術的な負債が支払いによって赤くなっていることを説明するにはどうすればよいですか？ 前の質問に共通することは何ですか？



一般的なことは、彼らのすべての違いのために、彼らはすべて一人に近いということです。 Jim Holmesの背後には、米国空軍で80年代に始まった数十年のIT経験があります。多くのことを話す準備ができていることは驚くことではありません。 「テスト文化」の概念は彼にとって重要であり、私たちは彼に非常に多様な質問を尋ねましたが、最終的にはテスト文化に何らかの形で関連しています。



-はじめの質問：自分について教えてください。



-私の名前はジムホームズです。私は独立コンサルタントであり、自分の会社であるGuidepost Systemsの所有者です。 私はソフトウェア配信の品質を専門としており、軍隊に長い間勤務する前に、合計約20年間プログラミングを行ってきました。 私は15年ほど前に品質に真剣に興味を持ち、あまり成功していないプロジェクトに取り組んでいます。 一般的に、私は多くのテスト自動化、単体テスト、統合テスト、特に機能テスト、UIテストを行いました。 特に、素晴らしいTelerik Test Studioツールを書いた会社で働いていました。 そして、過去5〜8年で、純粋に技術的な側面だけでなく、供給全体の品質、つまり供給チームとビジネスの関係がどれだけうまくいくかを扱い始めました。 しかし、同時に、私はまだWebDriverスクリプトを長時間デバッグし、不正確な非同期アクションによる定期的な障害などの問題を解決しています。 私はオレゴン州のアッシュランド市に住んでいます。ポートランドではなく、心に留めてください（アメリカで「オレゴン」と言うとき、誰もが「ポートランド」と考えます）。



-おそらく、テスターに​​とって、伝記の最も珍しい部分は兵役です。 そこで何をしていましたか？



-私は常に飛行機に触発され、父はパイロットだったので、アメリカ空軍に勤務しました。 私がわずか4歳のとき、彼は私の最初のフライトで連れて行ってくれました。 空軍では、私は非常に幸運だった、私はE-3チームに勤めた-これは巨大なディスクが上にある非常に大きな飛行機であり、レーダーといくつかの通信システムの操作を担当した。 11年間、私はこの大きな電子システムの管理とデバッグを行ってきました。 そして、フライトのない時間に、私は自分の飛行隊にコンピューターを管理しました。 その後、職場でネットワークを作成することが可能になりました。 さらに、私は兵士だったので、教育を受けていたので、ソフトウェアを開発するために夜の学校に行きました。



あなたの質問に関しては、軍隊での奉仕の経験はテスターだけでなく、他の多くの分野でも珍しいです。 少なくとも私はそこで規律を教えられたと言えます。



-はい、軍隊の場合、最初に頭に浮かぶのは規律です。 これにより、多くのテスターと開発者に問題が発生します。 彼らは軍隊から学ぶべき何かを持っていると思いますか？



-これは非常に興味深い質問です。 事実、私が教えられた規律は、たとえば空para部隊とは多少異なっていた、つまり、絶え間ない叫びや罰はなかったということです。 私はテストへの、そして一般的には問題解決への規律あるアプローチを教えられました。 職場の規律も重要でした—階層とは何かを理解しました。 その中で働く方法を学ぶためには、上司とコミュニケーションをとることができなければなりません。 この種の規律は私を大いに助けてくれました。



私は25年前に軍を辞めました-はい、私は老人です-民間部門での仕事は、その優先順位のために私の以前の経験と非常に興味深い対照をなしました。 軍隊で、私は飛行機に乗りました。飛行機は広い領域にわたって敵を監視し、自分の安全を確保することになっていた。 間違いは、兵士の命を危険にさらすことを意味しました。 誇張したくはありませんが、本当にそうでした。 IT部門の誰かがパニックに陥り、課題をすぐに解決するよう要求するようになったとき、私の規律と経験のおかげで、私はいつでも人々を安心させることができます-誰かが死ぬという脅威はなく、負けません毎分数十万ドル（そして、私はそのような状況にありました）。 私たちは非常にしばしばパニックに陥り、ビジネスや株主が不必要に私たちを脅迫し、誰にとっても役に立たない不当な緊張を生み出します。 おそらく、軍が私に教えた最も良いことは、冷静を求め、状況をしっかりと評価し、事前に行動を計画し、人為的に作成されたパニックのために考えずに仕事に突入しないことです。



-つまり、戦略を練るために時間をかける必要があります。



-はい、IT部門ではこの問題は長い間ありました。この2番目にプロジェクトを正しく実行するための一定の要件です。 主なことは迅速に行うことであり、正確に行われていることは二次的に重要です。 ほとんどの場合、対話が正しく行われていれば、この圧力を制御できます。 しかし、このためには、もう少し時間をかけて問題に合理的にアプローチすれば、より多くの価値を創造できると言うことができることが重要です。



-現在の活動に移りましょう。 職場では、さまざまな企業でさまざまな方法でテストにアプローチする方法に精通しています。 このアプローチは、たとえば会社の規模に依存する可能性があることは明らかです。 しかし、おそらくあまり明らかではない多くの違いがあります-それらについて話してもらえますか？



-これは素晴らしい質問です。 私は独立した仕事に加えて、オハイオ州コロンバスのPillar Technologyとも仕事をしています。 私はこの会社の人たちを長い間知っていました。 現在、約250人がそこで働いており、そのほとんどがエクストリームプログラミング（XP）の原則に基づいて働いています。彼らは多くのユニットテストを行っており、開発は非常によく考えられています。 3年前にそこで雇われたとき、私は唯一のテスターであり、彼らは非常に高品質の製品を作成しました。 彼らは、XPの立場から、テスト駆動開発の立場から、テストにアプローチしました。 これは素晴らしいアプローチであり、彼らはそれをうまく適用しており、私は他の従業員と一緒にソフトウェア配信のいくつかの側面を変更することができました。



そして、この経験を、私が過去3年間コンサルティングを行ってきた別の会社と比較できます。 これは工業会社であり、フォーチュンのトップ10リストにあり、世界中で約20万人を雇用しています。 企業の内部ニーズに対応する非常に大規模なIT部門があります。 そこには多くの優秀な人々がいますが、彼らのテストは1980年代または1990年代の慣行にとどまりました。 同社はまったく同じ製品の巨大なバッチを生産しており、多くは、たとえばボールベアリングの生産において、予想される欠陥の数を推定することができるという事実に慣れています。 しかし、問題は、この種の考え方をITに転送することです。



一般に、いくつかのプロジェクトから欠陥レポートを収集し、将来起こりうる欠陥の数を予測しようとする4人の非常に優秀な従業員と会話しました。 業界でこれを行うのは非常に合理的だと彼らに話しましたが、モバイルアプリケーション用に計算された指標を、たとえばWebサービスの指標とどのように区別しますか？ 彼らは違いはないと答えた。 幸運にも、さまざまなアプローチとテスト文化のスペクトルでまったく反対の点を見ることができました。



加えて、私はスタートアップの段階から抜け出すことができなかったいくつかの会社と仕事をしました。 そして、数年後、複雑なプロジェクトでは、この段階で生じた問題が鋭く感じられ始めます。そして、このアプローチが間違っていること、そして今私は自分の行動を止めて適切に考える必要があることを人々に納得させなければなりません。 一般的に、私の答えはいくぶん広範でしたが、あなたの質問との接触を完全に失っていないことを願っています。



-そして、あなたのカウンセリングの実践において、会社との仕事を終えた後、彼らは「何も良くならない」と言ったことがありますか？



-それは人々にとって難しいこと、私たちは非常に難しい生き物であるという秘密をあなたに伝えます。 これは私が白髪をたくさん持っている理由の1つです（2番目は私の娘です）。 1人の人を変えることは難しく、組織内の人を変えることはさらに困難です。 そうです、私はこのような状況を頻繁に抱えています。



一部のコンサルタントについても、彼は「燃え尽きた」と言っています。 これは、組織で発達した文化を変えるために多くの努力をしているという事実によるものであり、私たちは個人レベルで多くの問題に取り組む必要があります-人々は変化を恐れ、彼らは常にこれが必要であると確信しなければなりません、それらに合ったパスを探します。 私がどんなに強くて騒々しくても、私はただ来て言うことはできません。 合意に達する必要があります。 この作業は何かを達成するために何年にもわたって実行する必要があり、問題を解決したと思われ、別の組織と相談するために去ると、以前とまったく同じ問題が発生します。 繰り返しますが、膨大な時間と労力を費やすと、最初の会社ではすべてが以前の状態に戻っていることがわかります。



人々はとても整理されており、私たちと一緒にいるのは難しいです。私たちはしばしば昔の習慣に戻ります。 しかし、それにもかかわらず、本当に成功した仕事の例があります。 あなたと達成した結果を統合するために管理する組織があります。 一般的に、私は一方が他方のバランスをとると言います。 これらの成功事例は非常に満足のいくものであるため、私はこの仕事を続けています。



-あなたのブログでは、あなたの職業上の原則について書きました。そこで、あなたはオープンであり、常に新しいことを学び、話よりも耳を傾け、適応し、同時に人々を親切に扱う必要性について話しました。 親切が本当にITの人々に役立つかどうか疑問に思っていますか？



-はい、役立ちます。 私は軍隊に勤めており、厳しい規律があったと言いましたが、規律と構造化は他の人々との良好な関係と共感を妨げないことを理解する必要があります。 スコットランドのシェフ、ゴードン・ラムゼイを知っていますか？ 彼はヘルズキッチンショーをリードしています。 高価なレストランのシェフは従業員に対して嫌悪感を抱くことがよくあります-彼らは叫び、in辱します。 私は人々に対するこの態度が嫌いです。 私にとっては、お互いに対する良い態度が重要です。 変化を達成したい場合、人々がなぜ変化に抵抗するのかを理解する必要があります。つまり、共感が必要です。 そして、それはあなた自身を変えたいと思う人を作ることを可能にします。 そのようなアプローチは、人々に叫び、彼らが従い、質問をしないことを要求するよりもはるかに効果的です。 それぞれの人は、自分の心、自分の魂、自分の経験を持っています。 哲学を掘り下げたくはありませんが、長い目で見れば、良い態度と共感により、素晴らしい結果が得られると思います。 はい、彼らは助けます。



-セミナーを実施し、そのうちの1つで、プログラミングの方法がわからないプログラミング担当者に教えます。 2つの質問があります。 まず、どのような問題が最も頻繁に人々がセルフプログラミングを妨げるのですか？ 第二に-来年、自動テストが手動テストに勝ると思いますか？



-私の経験では、人々は多くの場合、技術的な困難ではなく、恐怖に悩まされています。 すでにお話ししたFortune 10の会社での経験から例を挙げることができます。 私は手動テストを行うテスターのチームと協力しましたが、WebDriverを使用して自動化を行う必要がありました。 これらのうち、ほとんどがEclipseを開いてコードの作成を開始することさえできませんでした。 彼らは、自動化のためのスクリプトを書くことを恐れていました。なぜなら、彼らの理解では、これは、スケーラブルなWebサービスまたはデータベースをマルチスレッドで書くこと、つまり開発者が長年にわたって学んできたことと大差ないからです。 この恐怖は、彼らが一般的に簡単なことをすることを妨げました。



現在、Java、C＃、またはRubyスクリプトを開いて読み、一般的な構造を理解する、または書くために何年も練習する必要がないことを説明するワークショップに基づいて、試験省向けのコースを開発していますWebDriverでの簡単なテスト。 さらに、コードで発生しているすべてのことを完全に理解していない場合でも、たとえば、1つのメソッドが3つの画面を占有してはならず、4つのネストされたifステートメントがないことを知っているため、一般的な評価を行うことができます-それらは困難ですテストするために、変数に1文字の名前などを付けることはできません。 私の意見では、初期段階での主な困難は、信じられないほど複雑なタスクを解決しなければならないという恐怖を克服することです。 そして、私はいつも私のクライアントがこの恐怖をどれだけ早く取り除くかを知りたいと思っていました-あなたはその人に簡単なユニットテストを与え、彼にアレンジ、行動、主張を書くよう頼むだけです。 この人間の要素は非常に重要だと思います。



私たちが使用している技術のほとんどはそれほど複雑ではなく、無人車両などに関係するものはほとんどありません。 私はかつてインドで1人のクライアントを対象にセミナーを開催しましたが、プログラミング経験のないマネージャーが1人いました。 このマネージャーは最初は非常に怒っていたので、その理由はまさに私が話したばかりの恐怖であり、この恐怖は馬鹿げているように思わないことに重なっていた。 しかし、最初のレッスンの終わりまでに、彼はテストを書くことに夢中になり、レッスンが終わってから1時間後に聴衆から彼を追い出さなければなりませんでした。ボード。 そして、ここでのポイントは私の指導スキルではまったくありません。それは、この恐怖やその欠席がいかに重要であるかを示しているだけです。 ここで私たちは人間の本質に固有のものについて話している。



手動テストから自動テストへの移行に関する2番目の質問。 ここでいくつかの経験があり、テスト自動化に携わる会社で3年間働いていました。 質問は別の方法で提起されるべきであり、テストの自動化ではなく、テスターの開発と多くの技術的スキルの習得のために努力すべきであると考えています。 ユーザーストーリー、仕様、および要件を持ち、開発者とかなり専門的なことについて自由に対話を行い、コードで具体化されるソリューションを共同で探すことができるテスターに​​会いたいと思います。 これは、テスターがプログラミングを教えるアプローチとは若干異なり、WebDriverスクリプトを作成できるだけです。 もちろん、このスキルも重要ですが、私の意見では、それは最も重要ではありません。 私の意見では、スーパータスクとは、開発者と対話を行い、開発者がコードを記述する際にテストプロセスを念頭に置くことを保証する能力です。 TDDでもすでに大きな成果が得られます。すべての組織がこの方法で記述できるはずです。



一番下の行は、正しく配信されたテストが単体テストまたは統合テストに縮小されるにはほど遠いということです。 多くの場合、人々は典型的なコード実行パスのテストに満足しています-すべてのテストに合格し、チェックボックスはどこにでもあり、100％のコードカバレッジが達成されます。 しかし、これはコードの品質を保証するものではありませんよね？ もちろん、これらも必要な手順です。 したがって、私の理解では、テスターはいくつかの機能テストまたはWebDriverでのテストを書くだけでなく、開発者であるビジネスアナリストとの緊密な協力関係をどのように確立できるかを考えるべきです。 たとえば、 mobプログラミングを試すことができます 。 一般に、自動化はツールであり、目標ではないと考えています。



-「開発者との緊密な協力」という言葉は、ハイゼンバグの主催者として私たちに非常に近いです-会議のスローガンでさえ「テストについてですが、テスターだけのためではありません」。 そして、この協力に関連して、次の質問をしたいと思います。広範なテスト経験を持つ人として、読者やプログラマーに何を伝えたいですか？



「私たちはみんな悪じゃない！」 テスターは自分の行動で悪評を獲得しています。 彼らは会議で最も細かい詳細で障害を見つけ、しばしば言葉ではなくバグ報告を伝えます。 開発者は午前中に働きに来て、文法エラーと整列されていないページについて報告する50のバグレポートを見ます。 私は両方の役割を担ってきましたが、プログラマーがこれにどのように反応するかを知っています。 これは古いテストの一部であり、私自身もかつてこのように振る舞っていました。 しかし、最新のアプローチに慣れているテスターは、プログラマーにバグレポートを提出するよりも、彼と話すだけの方が簡単で良いことを理解しています。



私の意見では、開発者にとって、優れたテスターは非常に貴重なものになる可能性があることを理解することが重要です。事前にテスターと話をすれば、多くの時間と神経を節約できます。 これは、制約の理論が言っていることです。 私が開発者で、テスターが何らかの問題を検出したと思います。 TFSや他の場所でそれについてテキストメッセージを送る代わりに、私は彼に近づいて直接話をする場合、この会話は私が書いているコードの欠陥の数を減らすのに役立ちます。 さらに、個人的なコミュニケーションでは、ほとんどのテスターは原則として怖くはありません。 , , , , — , , , .



, . , , , , — , . , .

, , : 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), , . , , . , « », , , , . , , . , , - .



— . .



— , . , : , .