この記事はPeter G Walenによるゲスト投稿です。

2013年の6月、私は一日を始める前にコーヒーを飲みながらTwitterをチェックしていました。大統領選の年を除けば、私はよくTwitterのポストをざっと見て、友人や同僚がテクノロジー、特にソフトウェア開発周りで興味深いことをポストしていないか探します。

その日の朝は、Jim Holmesの新しい本がLeanPub(こちら)で公開されたという本人のツイートを見ました。残念なことに、この本はもう入手できません。Jimのメッセージは明瞭簡潔でした。「ベストプラクティスが1つある。思考だ。」

2013年以降、テストを支援し、情報フローを改善するツールが成長を遂げたいま、改めてJimのメッセージを検討してみるのも有意義ではないかと私は考えました。

プラクティスとツール

標準と標準化の需要は増大し続けています。少なくともUSでは「急増」とまでは言えませんが、目立った存在感はあります。管理ツールやコントロールはいたるところにあり、数を増やしているように見えます。みなあらゆる問題を解決してくれる魔法のメトリクスを探し続けています。

プラクティスが発見、あるいは再発見されています。「新しい」プラクティスが前面に押し出されるいっぽうで、うまくいっていても、「役に立たない」として捨て去られるプラクティスもあります。

ソフトウェアの開発、テスト、デリバリーの問題を解決するテクノロジー駆動型のツールを求める旅は終わりません。テストをガイドする「テンプレート」の人気がかげるいっぽうで、他のアイデアがとってかわろうとしています。

「コードレス」が増える中で、テスト「自動化」ツールが躍進しています。そういったツールは、テスト自動化を「始める」方法として「技術的でない」メンバーをターゲットとしていることがよくあります。よいテストプラクティスとはどんなものかに関する適切な教育があるなら、このようなアプローチも妥当でしょう。

多くの組織にとっての課題は、ツールを重視するいっぽう、ツールを使う理由についてはそれほど重視しないことから生じます。テスターあるいは自動化テスターにある程度のコーディングを要求するツールの場合も、「コードレス」テストツールの場合も、多くの組織ではツールの使用経験あるいは必要とされる言語でコードを書いた経験が重視されるという偏りがあります。

Jimの本で説明された問題にはほとんど注意が払われない傾向があります。当時から何年も経っていますが、実際、同じ問題に出会ったことは何度もあります。みなツールを適用することにばかり注力しています。企業はツール、言語、あるいは「フレームワーク」の経験を重視しています。これが別の、もっと深い問題につながります。

これは「テスト」が「自動化」されていようと「手動」だろうと変わりません。

すべての「テスト」は開発チームとプロジェクトチーム全体に価値を届ける必要があります。それができなければ時間の無駄であり、プロジェクトの状況に誤った印象を与えます。

ツールの性能の問題ではない

どんなテスト管理ツールも、使い方次第です。テスト自動化ツールが不適切に使われる可能性はありますし、組織に「優先的」ツールがある場合、そうなることも珍しくありません。ツールが意図されたとおりに適切に使われた場合、非常に強力で、開発チームにより良く、より速く仕事をする力を与えるでしょう。

意図されていない不適切な方法でツールが使われた場合は、チームの効率に影響を与え、デリバリーをスローダウンさせます。

あることに気付くことが重要です。ツールの営業担当者は「成約を取る」ために必要だと思ったことをなんでも約束するでしょう。「もちろん{X}はできます」と言うかもしれません。自分自身で調べましょう。

目の前のツールは確かに{X}できるツールなのかもしれません。横目でちらりと、特定の角度から見ればなんとなく{X}できるという可能性もあります。ツールを使っている他のユーザーの体験を調べましょう。これはツールの購入を決めたマネージャーではなく、ツールを使用させられる人たちのことです。

技術的な情報に注目しましょう。{X}はキー機能として設計されているか？動作させるために「修正」は必要か？{X}機能を「有効化」するための追加ライセンスはどうなっているか？

実行する必要があることを本当に実行できるか？それとも実行する必要があることをなんとなく実行するだけか？

ベンダーから発信されたものではないレビューやコメントを調べるとよいでしょう。みながそのツールをどのように受け止めているか、ツールを利用してあなたがやりたいことをどれほどできているかを調べましょう。

つまり、ベンダーが主張することとソフトウェアのユーザーの経験を比較して検証します。成功に必要な適切なツールを選択するには、できるだけ確信を持てるようにすべきです。

優れたツールも、導入後に棚ざらしになるようでは役に立ちません。意図された目的のために使用されないなら、どんなツールも力を発揮できません。

ニーズを把握する

そんな事態になる理由の1つは、何をする必要があるのかがほとんど、あるいはまったく理解されていないからではないでしょうか。「ぜんぶ自動化する」、あるいは「ぜんぶ追跡する」なども必要性を理解できていないうちに入ります。これらは答えになっていない単なる要点です。指示のように聞こえますが、実際的な意味やコンテキストはありません。

利用するツールを決める前にニーズを検討することは組織の利益になるでしょう。多くの組織にはすでに既存のツールがあるのは私も承知しています。ツールの入れ替えはコストのかかる提案かもしれません。

しかしそのコストは、作業の質を損なうようなやりかたを強制するコストに比べたら小さなものではないでしょうか？

この問いは、折に触れ繰り返し検討するべきです。  組織のニーズが移り変わるのと同様に、チームのニーズも移り変わる可能性があります。ニーズの変化に合わせて利用するツールも変化する必要があります。  

ニーズには、たとえば複雑な回帰シナリオを実行することから、API 呼び出し、UI、可変関数のテストやインテグレーションテストなど多岐にわたります。単体テストが必要な場合もあれば、CI/CD環境のテストが必要な場合もあります。

選択されたツールは、チームが開発およびデプロイメント作業を行ううえでのニーズを満たす必要があります。そこで課題になるのは、さまざまなチームがツールに対して大きく異なるニーズを持っている可能性があるのを理解することです。

学習

チームが利用するツールまたはツールのセットをインストールした後は、組織にとって初めてのツールであれば、トレーニングを行う必要があります。トレーニングには、ツールに慣れることができるよう支援することも含まれます。

一般的によく使われているツールであれば、トレーニングは少しか、なしで済むでしょう。それでも、推奨される利用方法についてのトレーニングを検討する価値はあるでしょう。私がいろいろな会社で見てきたのは、みなツールを使った経験はあるが、使い方がばらばらだという問題です。ツールをどのように最適化するかに関して、チームの間で明確に統一された見解がありません。  

トレーニングには、チームでツールを使ってみることも含めるべきです。ツールに慣れるとともに、機能をひととおり使うことは、早い段階で小さな成功を経験するのに役立ちます。

小さな成功体験が新しいツールやプラクティスを受け入れやすくすることもよくあります。消極的な受け入れから始まって、改善可能性の実現に向かいます。個人レベル、またチームレベルでの学習があるかないかは、新しいツールセットやプラクティスが進んで受け入れられるかどうかに大きな違いをもたらします。

どんなツールを選択した場合でも、忘れずに採用しなければならないツールが1つあります。

最も重要なツールとは

どんなツールを選んだ場合でも、他のツールの効果を最大化できるツールが1つあります。そのツールは、可能な限り優れたソフトウェアを構築するために従うべきプラクティスを判断するのに役立ちます。

そのツールは、この記事で一貫してほのめかされています。それは成功の原動力となります。それは意思決定の中心にあります。

私たちは私たちの頭脳を働かせて思考する必要があります。私たちの精神が創造的なひらめきのもとになり、そのひらめきが問題の解決策を見出し、答えが必要な疑問に答えるのに役立ちます。

忘れられがちな最も重要なツールとは、抽象的な言葉で思考する人間の能力です。盲目的にスクリプトに従うように言えば、そのとおりのことしか起きません。思考して探索することを許せば、素晴らしい結果が生まれるかもしれません。

Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。

（この記事は、開発元Gurock社の Blog 「The Most Important Tool for Software and System Testing」2020年5月21日の翻訳記事です。）