2024.10.15
バルテスで第三者検証の計画・設計を担当している小谷です。
今回は、ソフトウェア開発の仕事をしていた私が、バルテスに入社して気付いた、テストの質を高める「テスト観点リスト」の大切さについて、実際の経験をもとにご紹介します。
1．開発者時代に苦労していた「テスト設計」
私はバルテスに来るまで3年間、ソフトウェア開発をしていました。
要件定義からシステムテストまで一通り担当したのですが、いつも悩みの種は「テスト設計」でした。
開発者というのは、意外とテストのことを知りませんし、テストの重要さを認識している人も多くはありません。私は以前の会社ではお客様企業に常駐して開発をしていました。
複数の企業で業務を行いましたが、どの会社もコーディングと単体テストまでが仕事でした。後の結合テストとシステムテストは消化試合。いかに早く終わらせるかが勝負です。
私は社会人一年目の時点でJSTQB認定テスト技術者資格のFoundation Levelを持っており、テストの知識も大切さもある程度理解しておりました。でも、開発現場ではなかなか納得いくテストは作れませんでした。
いつも敵は「時間」と「網羅性」です。
一年のプロジェクトなら、要件定義～実装が11ヵ月。テストは1ヵ月だけです。実装に４ヵ月かかるシステムに対して、１ヶ月で結合テストとシステムテストと改修と改修確認まで行おうとするのです。正直、テスト設計をする時間なんかありません。「思いついたテストをやれ。今すぐやれ。考えずにまずは手を動かせ」というのが上司の口癖でした。
また、JSTQB-FLでは、テスト技法の使い方までは詳しくは教えてくれません。テストに長けた上司がいないので、私が選んだテスト技法が今開発しているシステムに合っているのか、誰も教えてくれません。誰も分かりません。上司は、私のテストケースを見て、いつも「カバレッジは100%？」と聞くけれど、網羅的にテストする方法が分かりません。
2．バルテスで「テスト観点リスト」を学ぶ
バルテスに入社し、中途採用者研修で、私は「テスト観点リスト」に出会いました。
研修内容はテスト設計。課題はテスト観点リストから適切な観点を選び、テストケースを作ること。
私の感想は、感動の一言に尽きました。
今まであったモヤモヤ感、「分かる範囲ではテストを作ったけど、絶対網羅してないよね？」というモヤモヤ感を、テスト観点リストが拭い去ってくれました。
以下の表は、バルテスのテスト観点リストの一部です。
私は開発の三年間、境界値分析を多用しました。処理の境目にバグがたくさんあるというJSTQB-FLの知識です。開発のチームでは随分と喜ばれました。
しかし、この表を見ると、私が活用した境界値分析は、「分類1の「入力」の部分だけを確認する手法です。
他の部分のテストは作っていませんでしたし、観点として見えてもいませんでした。
このテスト観点リストのもう一つの特徴は、一目で観点を俯瞰できることです。
時間がないときほど、視野は狭まりがちです。余裕があるときには絶対に気付けたテストの要点が、忙しく慌ただしいときは見えなかったりします。そんなとき、観点リストは視野が狭まるのを防いでくれます。
3．テストの専門家として実務へ
テスト設計の研修が終わり、私はテストの専門家としてバルテスのプロジェクトに加わりました。
このプロジェクトは、社内の会議室を予約するシステムを開発するプロジェクトであり、以下のような工数・体制でした。
開発期間は１０ヶ月。2ヵ月で要件定義・基本設計を行い、2ヵ月で詳細設計、3ヵ月で実装と単体テストを行い、残りの3ヵ月で結合テスト・シナリオテスト・ユーザー受入テストをします。
私が第三者検証として携わったのは、最後のユーザー受入テストでした。期間は1ヵ月。途中からの参画だった私は、テスト設計・テスト実施・テスト結果報告を担当しました。一週間で設計し、二週間と3日でテスト、2日でサマリレポートです。
蓋を開けてみると、実装はユーザー受入テストまでずれ込み、テスト開始が2日遅れで進みました。
時間がないので上司と相談して優先的にテストする項目を実施した結果、64件のインシデントが検出され、うち機能に関するインシデントは42件でした。
ユーザー受入テストで、機能のインシデントが2/3を占めているのは、開発側のテストが不適切だった可能性を示唆しています。実施結果を分析してサマリレポートを作成する期間は2日しかありません。
私は迅速に観点を俯瞰するため、テスト観点リストを利用して機能のインシデントを分析しました。
結果、機能インシデント42件のうち18件は「未入力チェック」という一つの観点で見つけることが出来るインシデントでした。開発チームから提供されていた基本設計書・詳細設計書・単体テストケース・結合テストケース・システムテストケースを確認すると、設計書にもテストケースにも未入力チェックに関する記載はありませんでした。
未入力のチェックのように、丸ごと設計書からもテストケースからも漏れてしまった観点は4つもありました。
サマリレポートで「今後は未入力など抜けているチェックを設計にも結合テストにも入れるべき」と提案すると、依頼元のお客様は「弊社に足りないテスト観点を提案してくれた」と、とても喜んでくださいました。
会社の経営指針発表会にも呼んでいただき、他の会社の人がいる前で「バルテスが今回のシステムの品質を高めてくれたおかげでリリースから今日まで1件の障害も発生していない。しかもバルテスは今後の弊社の品質を上げてくれる提案をいくつもしてくれた」と紹介してくださったのは、とても嬉しかったです。
4．テスト観点リストの大切さ
テスト観点リストが大切だと思うのは、以下の2つのメリットがあるからです。
- テスト経験が浅い人が作るテストの質を上げる（若手の成長に繋がる）
- テスト設計に必要な時間を短縮することでコストを削減する
まず、テスト観点リストは観点が網羅的に記載されているので、テストの知識が浅い若手がテスト観点リストを使うと、今まで知らなかった観点の理解に繋がり、品質を保証するために必要な視点の知識が増えます。結果的に、その若手のテストの質が上がります。
また、テスト観点リストは観点全体を俯瞰できるので、急いでいるときも、視野が狭まってしまうのを防ぎ、短時間で網羅的なテストのベースになってくれます。
まとめ
今回は、開発者時代に苦労していた「テスト設計」についての悩みを解消する「テスト観点リスト」についてご紹介しました。
システムの品質を支えているのはテストです。そのテストの品質を支えているのがテスト設計であり、テスト設計の品質を支えている要素の一つがテスト観点リストです。
Excelを一枚作るだけで導入できるテスト観点リスト。
テスト設計がうまくいかないとお悩みの方は、ぜひ実践してみてください。
