テストの属人化を防ぐには

【はじめに】

属人化という言葉はご存知ですか？属人化と聞くと、プログラミングの工程で多く発生するイメージがあるかもしれません。

例えば、1人の人がある機能を単独でプログラミングし、詳細な資料を作成していないような場合

その本人でないと、どの様な内容が記載されているのか、どの様な構造になっているのかが理解できないなど、その人が居ないとプロジェクトが進まなくなる状況がそれに当たると思います。

このような状況は、多くの現場で発生のリスクがあるのではないでしょうか。

一般的に属人化を回避するためには、個人しか持たない情報を無くし、作業を標準化していく事が重要だと考えられています。そのためには仕様書の作成や、複数人でのコードレビューなどを、ルールとして運用し、情報共有をチーム全体として徹底して行く事が必要になってきます。

【テストフェーズでの属人化】

では、テストフェーズで属人化が発生するリスクがあるのはどの辺でしょうか？

よく耳にするのは、単体テストや結合テストのテストレベルです。

このテストレベルは開発者自身がテストを実施することが多く、検証チームで管理することが少ない部分になります。

そのため、検証方法や検証項目、検証の粒度などは開発者自身が考えて作業するため、属人的になってしまい、機能ごとに品質が均一化しない状況が発生しがちです。

これを回避するためにはやはり、テストをテストエンジニアが一元管理し、テスト計画において各テストレベルでの終了基準や使用ツールを規定して管理して行く必要があるかと考えます。

が、それだけで完全にテストフェーズでの属人化を防げるかと言うとそんなはずはありません。それは、その他の各テスト工程においても属人的になってしまうリスクがあるからです。

例えば、テストベース（仕様書などの資料）を要件分析してテスト計画を作成していきますが、要件分析の段階で潜在的な要件やリスクが高そうな条件などを抽出するには作業者のスキルや経験に依存してしまいます。

また、テスト設計、テスト実施の工程でも同様に、作業者の経験/スキルに依存し、発見できる観点やバグが多くあります。

そして、それらの知識は個人に蓄積されていくだけで、共有がされていないのではないでしょうか。

その個人に蓄積された知識や経験が属人化の要因になります。

私はテストフェーズでの属人化は致命的では無いかと考えます。担当者が変わる度にプロダクトの品質が変動するようでは、製品を安心して世の中へ送り出すことが出来ません。

【テストフェーズでの属人化を防ぐには】

では、テストフェーズでの属人化をどの様に予防していくか。

前述したように、各作業工程を標準化していくことは重要ですが、それにプラスして個人に貯まってしまう知識や経験をナレッジ化し、いつでも閲覧可能な状態にしておく事で予防できるのではないかと考えます。

例えば、プロダクト・機能・画面などの単位で以下の情報を紐づけたファイルを作成して管理することでナレッジを蓄積し、チーム全体に共有しておく。

• テスト観点（テストケース）
• テスト環境
• バグ

そして、新たな検証がスタートした時にそのファイルから必要な情報を検索し確認していくことで、属人化は予防していくことができるのではないのでしょうか。

【ナレッジ蓄積の難しいところ】

「ナレッジを蓄積する」とだけ書くと、簡単なように思えますが、実際に実行しようとすると、とても大変だと感じます。

それは、何か記録が必要な状況が発生した場合に、作業者は能動的にナレッジ蓄積用のファイルを開いて、分類し、記載する。この作業をその都度実施していく必要が出て来るからです。

こんれは作業者の自己判断により実施する作業になるため、『面倒だから記載をしない人』・『記載を忘れてしまう人』・『記載が必要だと気づかない人』、などが出てきてしまうことが想像できます。そうなると、この方法でのナレッジ蓄積を運用していくことが難しくなってきます。

【ツールを利用してナレッジを蓄積する】

前述のようなナレッジ蓄積における運用の不安定な要素も、テスト管理ツールを利用することで払拭することができると考えます。

テスト管理ツールの多くは、テスト実施からバグチケットの登録までが同一ツール上で管理・蓄積していくことができるため、ナレッジ蓄積のために別ファイルを作成しメンテナンスしていく必要が無くなります。

また、作業者は能動的に行動する必要は無く、通常の検証業務を遂行していくだけでナレッジはツール上に自動的に蓄積されて行きます。

ツールは常に関係者へ共有されているため、情報が必要な時に検索し、参照することができるため効率的に運用することができます。

【PractiTestでのナレッジの蓄積・参照方法】

では、総合テスト管理ツールであるPractiTestを使ってのナレッジの蓄積方法・参照方法など、その活用例をご紹介いたします。

PractiTestは、要件・テストケース・テスト実行結果・バグチケットをそれぞれ紐づけて管理する事が出来る総合テスト管理ツールです。

• [要件 – テストケース – 実行結果 – バグ]　の関連性はレポートとしてExcel形式で出力し、一覧として確認できます。また各項目はPractiTestへのリンクとなっているため、選択することで詳細内容を確認できるようになっています。

• 同様にPractiTest上の要件モジュールにおいても紐付きの関係性は一覧で確認することが出来ます。

また、カスタムフィールドという機能があり、それぞれのデータに必要に応じた情報をタグ付けすることができます。

• カスタムフィールドは[要件]、[テストケース(テストライブラリ)]、[テスト実行(テストセット)]、[バグ票(課題)]それぞれのモジュールで個別に設定できます。
• 必須項目やパラメータの値などを規定できるため、データの揺らぎが無くなり作業を標準化することが出来きます。 

これらにより、作業を標準化することができ、欲しい情報の検索や表示が容易になります。

ナレッジを蓄積する！

ツール運用前に「どのような情報が欲しいのか？」「その情報をどの様に活用するのか」を検討し、ツールをカスタマイズしておくことで、作業者はナレッジの蓄積を意識して作業する必要がなくなり、

ツールで指定されている内容を選択/記載するだけで、整理可能なデータがナレッジとしてツール上に蓄積されていきます。

必要な情報を参照する！

各モジュールにはフィルター機能があるため、データを任意のタグにより絞り込み表示させることが可能です。また、フィルターは階層構造で管理することができるため、効率よくデータを整理・検索することが出来ます。

データを活用する！

このようにPractiTest上のデータは[要件]-[テストケース]-[実行結果]-[バグ]のそれぞれが紐づいた状態で蓄積され、それらはフィルタリングして管理することができるため、必要な時に必要な情報を容易に確認することが出来ます。そして、それら情報はツールのルールに則り、作業することで蓄積されていくため、作業者への負担も軽減されます。

では、それら情報をナレッジとしてどの様に活用するか。

例えば以下の様な判断基準の材料として活用が出来ます。

• 要件の内容からどの様なテストケースを作ったか（観点や粒度）
• テスト結果からテストケースの有効性（観点や粒度）
• 発生したバグの内容や操作手順から不足している観点の発見
• 類似機能・製品における弱点部分の傾向

【おわりに】

最近はソフトウェア開発の工期がどんどん短くなっきています。

そのような状況では、開発工程全体で属人的になるリスクがあり、それはテスト工程においても例外ではありません。

適切にテスト管理ツールを利用することでそのリスクを軽減できると思いますので、ツールの導入を検討している方は、是非ナレッジの蓄積の観点でツールを選択する事も考えてください。

特にPractiTestは自由度が高いツールですのでユーザーのやりたい事を実現する手助けが出来ると思います。