日本語テスト自動化ツールの社内展開における「ルール整備」〜組織全体での安定運用に向けた検討事項の整理
こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。
テスト自動化ツールを導入したら、次は組織全体で活用できる状態にしていく必要があります。ただ、推進担当として旗振りをしていても、思うように利用が広がらなかったり、使う人が増えてきたら増えてきたで運用面の課題が出てきたり。そんな悩みを抱えている方もいらっしゃるのではないでしょうか。
ツールを導入することと、それを組織全体で活用できる状態にすることは、実は別の話です。特に複数のチームでツールを共有する場合、運用のためのルール整備が重要になります。
本記事では、テスト自動化ツールを社内で普及・展開する際に整備すべきルールについて、MagicPodを例に解説します。
なお、整備すべきルールには大きく2種類あると考えています。1つはツールの中の話、つまりテストケースや共有ステップの命名規則、フォルダ構成といった、ツール内での整理整頓に関するルールです。もう1つはツールの外の話、つまり利用開始の手続き、担当者の明確化、テストデータの管理といった、組織としての運用に関するルールです。
ツールの中の話については、MagicPodヘルプセンターの「複数人で使用する際の運用ルールについて」などで詳しく紹介していますので、ぜひ参考にしてみてください。本記事では、ツールの外の話にフォーカスしてお伝えします。
目次
なぜルール整備が必要なのか
テスト自動化ツールを導入して、最初のうちは順調に使えていたのに、気づいたらカオスな状態になっていた——そんな経験はないでしょうか。
ルールが曖昧なまま運用を続けると、いくつかの問題が起こります。たとえば、誰かが作ったテストを別の人が知らずに編集してしまったり、退職したメンバーが作ったテストの中身を誰も把握していなかったり。費用や契約の管理がはっきりしないまま、気づいたら想定外の出費になっていた、ということもあります。（金額面もそうですが、社内の申請や手続きなどの手間が発生するのは避けたいですよね。）
特にこうした問題は、複数のチームでツールを共有するようになると起こりやすいです。
ルールというと堅苦しく感じるかもしれませんが、ここでいうルールは「縛り」ではなく「共通認識」です。社内のユーザーが同じ認識を持つことで、無用なトラブルを防ぎ、スムーズに運用できるようになります。
ここからは、具体的にどのようなルールを設定すればいいのかについて見ていきましょう。
利用開始・体制に関するルール
テスト自動化ツールを使い始めるにあたって、まず整理しておきたいのが利用開始時の流れや担当者についてです。
利用開始時の手続き
新しいメンバーがツールを使い始めるとき、勝手に使い始めていいのでしょうか。それとも、誰かに申請が必要でしょうか。
1チームで使っている場合はあまり気にならないかもしれませんが、複数チームで共有している場合は明確にしておいた方がよいでしょう。特に、新しいプロジェクトを作成する場合は、既存のプロジェクトとの棲み分けや、命名規則との整合性を確認するためにも、事前に相談するフローがあると安心です。
「とりあえず触ってみたい」というトライアル的な利用についても、どこまでOKなのかを決めておくとよいでしょう。たとえば、テスト用のプロジェクトを用意しておいて、そこで自由に試せるようにする、といった方法があります。
関連して、
- 利用部門とは別に情報システム部門による半年や一年ごとの「ツール棚卸し」や「アカウント棚卸し」対応
- チーム単位で利用を終了する場合の手続き（作成済みのテストやデータの扱いなど）
なども考慮が必要となります。
管理・運用担当者の明確化
組織内での利用推進や適切な管理のためにも、「このツール、誰が管理してるんだっけ？」という状態は避けたいところです。
全体の管理者が誰なのか、つまり契約周りや課金設定、組織全体に影響する設定変更などを担当する人が誰なのかを明確にしておきましょう。複数チームで使っている場合は、全社の管理者と各チームの担当者を分けて設定することもあります。
担当者が休暇や異動で不在になったときの代理も決めておくと、いざというときに困りません。
問い合わせルートの整理
ツールを使っていて困ったとき、誰に聞けばいいのかがわからないと、結局使わなくなってしまいます。
問い合わせには大きく2種類あります。1つは社内で解決できるもの、たとえば「こういうテストを作りたいんだけど、どうすればいい？」といった使い方の質問や、社内のベストプラクティスに関する相談。もう1つはサービス提供者に確認が必要なもの、たとえば「これってバグじゃない？」といった障害報告や、機能の仕様確認などです。
どちらのルートで問い合わせるかの判断基準と、社内で集約して問い合わせる場合の窓口を決めておくと、スムーズに対応できます。よくある質問はFAQとしてまとめておくと、同じ質問に何度も答える手間も省けます。
実行に関するルール
テストを作るだけでなく、実行に関するルールも整理しておく必要があります。
実行時間帯とインフラメンテナンス
テストをいつ実行するか、というのは意外と重要なポイントです。
テスト対象の定期メンテナンスの時間帯やデプロイが走る時間帯にテストを実行すると、当然ながら失敗します。また、テスト環境に大きな負荷をかけるような大量のテストを業務時間中に実行すると、他の作業に影響が出ることもあります。
夜間や休日に自動実行する場合は、失敗したときに誰がどう対応するのかも決めておきましょう。翌営業日に確認すればOKなのか、それともオンコール対応が必要なのか。テストの重要度によって対応を変えることもあります。
複数チームで共有している場合は、他チームのテスト実行と時間帯が被らないように調整が必要なこともあります。
上限・費用の管理と周知
テスト自動化ツールによっては、テストケース数や実行回数、並列実行数などに上限が設けられていることがあります。また、上限を超えると追加費用が発生する場合もあります。
こうした上限や費用体系を、ツールを使うメンバー全員が把握するのはなかなか難しいものです。「知らないうちに上限に達していた」「想定外の費用が発生した」といった事態を防ぐためにも、現在の使用状況をユーザーが確認できる仕組みや、上限に近づいたときのアラートがあると安心です。
また、テストを細かく作りすぎたり、同じようなテストを大量に作ったりすると、テストケース数が膨れ上がって費用増につながることがあります。テスト作成のガイドラインとあわせて周知しておくとよいでしょう。
禁止事項・注意事項
やってはいけないこと、注意が必要なことを明確にしておくことも大切です。暗黙の了解ではなく、明文化しておきましょう。
触ってはいけないデータや設定
テスト自動化ツールの中には、触ってしまうと全体に影響が出る設定があります。組織全体の設定や課金に関する設定などがその例です。
また、他のチームも参照している共有リソースを勝手に変更すると、他のテストが壊れる可能性があります。「自分のテストでしか使っていないと思っていたら、実は他のチームも使っていた」ということもあり得ます。ツール内の共有リソースの扱いについては、MagicPodヘルプセンターの「複数人で使用する際の運用ルールについて」も参考にしてください。
「触っていいもの」と「触る前に確認が必要なもの」の線引きを明確にして、ドキュメントにまとめておきましょう。
他チーム・他メンバーへの影響
複数チームで共有している場合、自分の作業が他チームに影響を与える可能性があることを常に意識する必要があります。
共有リソースを編集する場合は、事前に関係者に連絡する、レビューを受けるといったルールを設けておくと安全です。また、誤って他チームのテストやリソースを壊してしまった場合の対応フローも決めておきましょう。履歴から復元できるツールであれば、復元手順を共有しておくと、いざというときに慌てずに済みます。
「自分だけの作業」と「他に影響する作業」の区別を意識することが大事です。
テストの運用・メンテナンスに関するルール
自動テストは作って終わりではありません。作った後の運用・メンテナンスに関するルールも整備しておきましょう。
失敗テストの対応方針
テストが失敗したとき、どう対応するかを決めていますか。
「失敗しているテストがあるけど、誰も対応していない」という状態が続くと、やがて失敗しているのが当たり前になってしまいます。そうなると、本当に問題がある失敗を見逃してしまうリスクが高まります。
失敗したテストは何日以内に対応する、対応できない場合は一時的に無効化してラベルを付ける、といったルールを設けておくとよいでしょう。無効化する場合は、期限を決めて定期的に見直すことも大切です。
原因調査や修正の担当者をどう決めるかも明確にしておきましょう。テストを作った人が対応するのか、テスト対象の機能を担当しているチームが対応するのか、ケースバイケースで決めるのか。たとえば週やスプリントの単位で「自動テストの結果確認・修正担当当番」のようなものを決めて、ローテーションしている会社もあります。
不要テストの整理
長く運用していると、使わなくなったテストが溜まってきます。機能が廃止されたのにテストだけ残っている、作りかけで放置されている、といったテストです。
こうした不要なテストは、テストケース数の上限を圧迫したり、一覧の視認性を下げたりします。「念のため残しておこう」という気持ちはわかりますが、定期的に棚卸しをして、不要なテストは整理する習慣をつけましょう。
削除の判断基準としては、「一定期間実行されていない」「対象の機能が存在しない」などが考えられます。いきなり削除するのが怖ければ、まずはDeprecated（非推奨）などのラベルを付けて一定期間様子を見てから削除する、という方法もあります。
テストデータの管理
テストで使用するパスワードやアカウント情報をどう管理するかも決めておきましょう。
テストコードの中に直接パスワードを書いてしまう（ハードコードする）のは避けた方がよいでしょう。変数や環境変数として管理し、テストコード自体には含めないようにするのが一般的です。
また、チーム全員で共有するテストアカウントと、個人ごとに用意するテストアカウントを使い分けることもあります。共有アカウントは便利ですが、誰かがパスワードを変更すると全員のテストが失敗する、といったリスクもあります。
機密性の高い情報を扱う場合は、アクセス権限の設定や、ログへの出力を抑制する設定なども検討してください。
命名規則
テストケースやフォルダ、一括実行設定などの命名規則も、運用を円滑にするためには欠かせません。統一されていないと、検索しても目的のテストが見つからない、似たような名前のテストが複数あってどれが正しいかわからない、といった問題が起こります。
ただし、これはツールの中の話なので、本記事では詳しく触れません。MagicPodを使っている場合は、ヘルプセンターの「複数人で使用する際の運用ルールについて」で命名規則の考え方や具体例を紹介していますので、そちらを参照してください。
アカウント管理
最後に、アカウント（ユーザー）の管理についてです。
アカウントの作成・削除ルール
誰がアカウントを作成できるのか、作成時に何を申請するのかを決めておきましょう。特に、メンバーの権限（管理者、編集者、閲覧者など）をどう設定するかは重要です。
見落としがちなのが、退職や異動時の対応です。アカウントが残ったままになっていると、セキュリティ上のリスクになりますし、ライセンス数を無駄に消費することにもなります。人事異動のタイミングでアカウントを棚卸しする仕組みを作っておくと安心です。
管理台帳を作ろう
アカウント情報を管理する台帳を作っておくと、棚卸しや引き継ぎが楽になります。
台帳に含める項目としては、ユーザー名、メールアドレス、権限、担当プロジェクト、作成日、最終ログイン日などがあります。スプレッドシートで十分なので、あまり凝ったものを作る必要はありません。
定期的に更新するルールも決めておきましょう。四半期ごとに棚卸しをする、といった形で運用しているチームもあります。
まとめ
本記事では、テスト自動化ツールを社内展開する際に整備すべきルールについて、ツールの外側の観点から解説しました。利用開始・体制、実行、禁止事項、運用・メンテナンス、アカウント管理といった、組織としての運用に関わる部分です。
もちろん、ここで挙げた内容がすべてではありません。組織の規模やツールの使い方によって、必要なルールは変わってきます。本記事の内容を参考にしつつ、自社の状況に合わせてアレンジしてみてください。
ルールは作ることよりも、運用することの方が大事です。最初から完璧なルールを作ろうとせず、まずは最低限のルールから始めて、運用しながら改善していくのがおすすめです。また、ルールを作ったら必ずドキュメント化して、新しいメンバーでも参照できるようにしておきましょう。
