この記事はDee Ann Pizzicaによるゲスト投稿です。

会社の大きな新システムで問題が報告されています。この技術的に高度なプロジェクトには、実績のある開発者からなるDevOpsチームが携わり、チームのトップクラスの頭脳が参加しています。プロジェクトのあらゆることをインフラを活用して進めるいっぽうで、他のソフトウェアプロジェクトと同様に、バグやサービスの中断や停止もあります。マネジメントチームはより高い品質を望み、QAチームを指名して関与を求めました。

このような状況でテスターが遭遇する課題は数多くあります。この記事では、まずこのようなプロジェクトで何から手を付けるべきかを明らかにし、その後、大きなプレッシャーの下にあるDevOpsチームにどのような提案をできるかについて説明します。

学びはじめる

チームに提案したり価値を提供するには、まずプロジェクトや関係者全員について、もっとよく知る必要があります。

概要を把握する

できるだけ早くチームリードまたはプロダクトマネージャーと話をする時間を設けます。このディスカッションでは、成功に必要な知識の範囲をしっかりと把握する必要があります。理想的には、プロジェクトだけでなく、各チームメンバーとその役割についても基本的な情報を得られるとよいでしょう。

チームとともに働く前に、答えを必要とする質問は多数あるでしょう。直近のマイルストーンも含め、プロジェクトのゴールを明らかにします。チームが具体的にどのような懸念を持っているかも明確にすべきです。サービスの停止、遅延、データの誤りがあるのでしょうか？特にパフォーマンスを懸念しているかもしれません。チームが直面している課題について、できるだけ多くの例を収集しましょう。

また、あなたがチームに関わることで何を期待しているかを尋ねましょう。システムやチームの中で、特に力を注いでほしい部分があるかどうか、あるいはまったく手を付けなくてよい部分があるかどうかも知る必要があります。

ドキュメントを読む

始めるにあたって、手に入るドキュメントをすべて読むことも役に立ちます。詳細をすべて理解できなくとも、プロジェクトで使われている用語について学べるでしょう。ドキュメントを読むうちに、概要ミーティングで聞いたエピソードが具体的にわかるような詳細を発見するかもしれません。

なじみのない概念にも多数ぶつかるかもしれません。聞いたことのない用語をやツールを検索し、何がわかるか試してみましょう。特に、重要と思われるが、どれだけ調べてもよくわからなかったことをメモしておきます。後でメモや疑問点が必要になるでしょう。

チームのディスカッションやミーティングに参加する

ドキュメントを読んだときと同様に、最初にミーティングに参加したときは、議論に完全についていくことはできないかもしれません。進行をあまり邪魔しない範囲で、できるだけの情報を取り入れましょう。耳を傾けメモを取ることから始めると、それまでチームがどのように働いてきたかについて、多くを学ぶことができるでしょう。

プロジェクトに新たに参加したときは、初めからどれくらい質問していいのか、それとなく探る必要があるのが普通でしょう。途中からミーティングに参加した場合、チームを脱線させないよう、ゴールとアジェンダを把握しておくべきです。学びながら信頼を築いているところなのですから、挑戦的な質問ではなく、確認するための質問にとどめるようにしましょう。

開発者の話を聞く

たとえすでに相手を知っている場合でも、すべてのチームメンバーと１on１のミーティングを設定します。概要ミーティングで質問して、すでに各メンバーの役割についてある程度知っているかもしれませんが、各自が見る自分の役割と、他人から見たその人の役割がかけ離れていることも珍しくはありません。各人が日常的に行っていることや、プロジェクトとの関わりについて尋ねる機会を逃さないようにしましょう。

このようなミーティングは、プロジェクトについて学ぶ中でメモしておいた質問を尋ねる良い機会でもあります。画面を共有してシステムがどのように動作するか、またどのようなツールを使って情報を得ているかを見せてくれるよう依頼しましょう。複雑な概念については、いったん止めて繰り返すことも重要です。繰り返しは理解に役立つだけでなく、仕事について学び、参加することへの興味を強化するのにも役立ちます。

会話をリードし、どのようなリスクや問題に時間が取られているかを明らかにするべきです。開発者たちは、あなたが詳しく調べる価値がある問題について、懸念やアイデアを持っている可能性が高いでしょう。また、各開発者に現在はどのように成果物をテストしているかを尋ねるまたとない機会です。テストの対象や方法についての開発者の考え方を知ることで、提案の材料となる情報をいろいろと得られるでしょう。どうすればテスターがチームを支援できるか、またチームに最大の価値を提供できると考えているかを各人に尋ねることもできます。

提案する

学習に時間をかけて、プロジェクトのゴールを把握したり、どんな役割が期待されているかを尋ねたり、チームの各メンバーと話をして現在のやり方を理解したら、仕事に取り掛かる時です。あなたはプロジェクトに「品質」を組み込むために招かれたのですから、チームが対処しなければならない問題が存在するはずです。

モニタリングの実装

顧客が問題に気付く前にチームが問題の存在に気付く必要があります。安定性に近づくための最大の一歩は、システムのどこが不安定で何がその理由なのかを理解することです。その際にモニタリングが役に立ちます。

DevOpsチーム向けのツールが多数あります。API のパフォーマンスをモニターする場合はRunscopeを検討しましょう。特定のAPIがダウンしたときに警告を受け取れるよう、稼働時間のモニタリングから始めるとよいでしょう。データの完全性のチェックをセットアップすることもできます。これは、エラーを示唆する不正なデータを検出するためのネガティブテストについてチームの検討を促す良い機会です。

もう1つ注目すべきツールがGrafanaです。Grafanaには、データベースを監視するモニタリングツールがあります。CPUの使用率やAPIのレスポンス時間に基づくアラートを設定できます。あなたのテストスキルで開発者を支援し、複雑な手順をテストする方法を判断するのと同様に、重要度に基づいてアラートのしきい値を決定します。

テストの場合と同様に、モニタリングにおいても、最も重要な情報を最初に見つける必要があります。また、すべてのバグが同じレベルの注目に価するわけではないため、見つけたバグの重要度を評価する必要があります。アラートを構築する際、そのような観点を適用します。真夜中に誰かをベッドから引きずり出すに価するアラートはどれで、24時間待っても構わないものはどれか、また単にノイズに過ぎないものはどれかについて、見解を一致させる必要があります。過剰な通知はチームを疲弊させ、ツールの有効性を低下させます。テストが安定して有意義であり、適切な時にアラートを発するよう、賢くテストを選択します。

チェックリストを利用する

テスターの最大のツールの1つがチェックリストです。チェックリストは、非常に複雑だったり、非常に重要だったりするために忘れないようにしたい一連の情報の備忘録の役割をします。さらにチェックリスト愛を高めたいと考えているなら、Atul Gawandeの著書『The Checklist Manifesto』をチェックしてみてください。

DevOpsチームに対して提案を行うとき、あなた自身のチェックリストを持っていきます。DevOpsチームは、このチェックリストをまとめたものをランブックと呼ぶかもしれません。良くできたランブックには、スムーズな運用を維持するために必要なすべての手順に関する情報が載っています。

チームは不測の事態に対応するのに忙しく、エラーを修正するための手順を書き留める時間がとれないため、ランブックをおろそかにして自分の頭に情報をとどめがちです。それがさまざまなリスクの原因になります――メンバーは会社を辞めてあらゆる知識を持って行ってしまうかもしれませんし、バケーションや休暇を取るかもしれませんし、大きな利害やプレッシャーがあるために、疲労やストレスによって、明白だが重要なステップを抜かしてしまうかもしれません。

もしチームにランブックがあるとわかったら、それは良いことです。ランブックを精査し、正確で最新の状態であり、漏れがないことを確認しましょう。ランブックがなければ、チームを支援して作成に着手しましょう。プロセスを文書化するのは時間がかかりますが、適切なチェックリストのおかげで大きな失敗から救われるかもしれません。

自動化

できるだけ多くのテストとプロセスを自動化することで、ヒューマンエラーのリスクを低減し、リーチを広げます。たとえあなたが自動化テスターではなくても、この領域で価値をもたらすことはできます。テストのためのコードを書くことはできなくても、どうすればテストを効果的にできるかを考える方法は知っているはずです。

開発チームと協働し、プロジェクトの各フェーズで役に立つテストを選択しましょう。DevOpsチームは継続的デリバリーを意識しているでしょうから、コア機能すべてをカバーし、変更がマージされるたびに実行されるテストスイートが必要です。また、特定の機能だけを対象とし、ただちに大きな価値をもたらすが、あまりにも特殊であるためにメンテナンスの労力に見合わないような特別なテストを検討することもできます。自動テストスイートをこまめに取捨選択し、顧客の懸念やサービス停止によって浮上した重大な問題を考慮してテストを追加します。

前に進んで能力を発揮する

DevOpsチームにおけるテスターの役割について、最も重要なメッセージを忘れないでください。あなたはチームに所属し、プロジェクトに違いをもたらすことができます。険しい学習カーブにしり込みするのは簡単ですが、自分を励まして飛び込みましょう。

テスターであるあなたには、すでに十分なスキルがあります。あなたは傾聴し、探索し、学習し、質問することができます。あなたはコラボレーターとして、また考える人としてのスキルを持っており、ソフトウェアがどのように壊れるかを知っています。これらのスキルを強みとし、どうすれば最大の価値を提供できるかを知るために、チームと話をしてください。DevOpsについてもっと知りたい方は私たちのブログを参照してください。 

Dee Annは熱心で好奇心にあふれたソフトウェアテスターです。15年以上にわたって、さまざまな業界の顧客向けに、小規模からエンタープライズ規模まで、きわめて複雑なビジネスロジックを持つカスタムモバイルおよびWebアプリケーションをサポートしてきた経験があります。現在、Dee AnnはBRDのDirector of Engineeringとして勤務し、iOSおよびAndroid向け暗号通貨ウォレットに取り組む才能あるチームとコラボレートしています。

（この記事は、開発元Gurock社の Blog 「DevOps Test Strategy for Successful Testers」2021年2月4日の翻訳記事です。）