こんにちは。QAグループ所属のQAエンジニア松谷（まつや）です。
LIFULLでは新卒エンジニアに27日間の研修を行なっています。
その研修の中で、丸一日を使ったテストワークショップも行われています。
今回はそのテストワークショップについてご紹介します。
キーワードは「テストを考えられる」です。
LIFULLの開発体制とQAグループについて
まずは認識を合わせるためにLIFULLの開発体制とQAグループの業務について説明します。
LIFULLでは月に200件ほどの施策がリリースされています。
それら施策は、主に企画者、開発者、デザイナーの三職種のメンバーで構成されています。
ここでお伝えしたいことは、テスト専門のメンバーは基本的にはいないということです。
リリースする施策については、施策のメンバーが責任を持ってテスト計画〜実行までを行っています。
数年前は第三者検証が主流だったため珍しい形でしたが、昨今のスクラムの形ではよくある形かと考えます。
ここでテスト=QAと思われている方は、QAグループが何を行なっているか疑問に思われるかもしれません。
QAグループは社内横断組織であり、各所の品質保証活動のサポートを行なっています。
例えば、施策のテスト計画の手伝い、品質保証についての相談などです。
以下のQMファンネルというモデルの「QAコーチ」「QAコンサルタント」にあたります。
（テスト=QAの認識の方は、このモデルの「フェーズゲートQA」部分のみにフォーカスしていそうです）
（出典 : 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版) Yasuharu Nishi)
テストワークショップについて
テストの考え方を伝えている
エンジニア志望の方々は、学校やプライベートで開発については深く学んできています。
ですが、テストについて体系立てて学んできた方は多くないのが現状です。
結果、実装したものが実装した通り動くかチェックすることのみがテストの全てであるという認識の方もいます。
Unit Testの責任範囲ではそのように言えるかもしれませんが、企業が提供するシステム全体に対するテストとしてはそれでは不十分です。
テストワークショップでは全体を通してのテストをどのように考えていけばよいかという「考え方」を中心に説明しています。
教える内容はJSTQBに（基本的には）準拠
教える内容は基本的にはJSTQB(国際的なテスト技術者認定資格ISTQBの日本版)に準拠しています。
わかりやすくするためにそのままの定義を伝えるのではなく、例などを用いてわかりやすい言葉に噛み砕いて説明を行います。
またJSTQBの全項目を教えているわけでもありません。大事なところをピックアップして伝えています。
（参考：JSTQB Foundation Level version2018V3.1.J03 )
JSTQBに沿ってお伝えしている理由は以下です。
- 正しいテストの知識
- 世界中のどこでも通用するテストの考え方
これらを身につけてから業務に入っていただきたいと考えています。
それにより「JSTQBではこのように言われていることが、LIFULLではこう実践されているのか」とわかりやすくなるためです。
テストプロセスを伝えている
テストをあまり知らない方の場合、テスト実行することだけがテストだと思っていることもあります。
また新卒研修の場合、最初にテスト実行をやってもらうのだから実行工程のやり方を細かく教えよう、という会社もあります。
LIFULLのエンジニアとしては、与えられたことを与えられた通りやれるだけではなく、テストを考えられるエンジニアになって欲しいのです。
よってテスト実行のやり方だけではなく、「何をどうテストするのかを考える」ということを伝えるため、テスト分析からテスト実装の流れ、つまりテストプロセスを使ってお伝えしています。
テストプロセスを知ることで、テストについて何をどう考えていけばよいかの道筋がわかるためです。
(テストプロセスについては JSTQB Foundation Level version2018V3.1.J03 P19〜参照)
各項目ごとに（ほぼ）ワークがある
教えている項目は多岐に渡りますが、それぞれの項目でワークがあります。
そこで実際に考えてみて手を動かしてもらいます。
個人ワークを行ってもらった後に、少人数グループでのディスカッションを行ってもらいます。
これは、個人でしっかりと考えた後に周りのメンバーと話し合うことで、他者の意見から新しい気づきを得たり理解を深めやすくなるからです。
ワークの一例を記載します。
以下は「マイヤーズの三角形」と呼ばれる問題です。
（出典：ソフトウェア・テストの技法第２版 Glenford J. Myers）
テストワークショップで、テストの考え方を伝える前に行っているワークです。
このワークは一見すると簡単そうです。
ですが「テストは仕様通り動くことを確認すればOK」と考える方がひっかかる問題です。
またグループディスカッションでは、入力値以外にも動作環境の観点も挙がりました。
こういった話も踏まえ、テストで考えるべきことは意外と多いことをお伝えしています。
最終ワーク
テストワークショップの最後にはおおよそ３時間ほどの本格的なテストの実習があります。
QAグループが作ったテスト用プロダクトに対して、少人数のグループで実際に以下のことを行なってもらいます。
- 仕様把握、テスト分析
- テスト設計
- テスト実装
- テスト実行 / 不具合起票
- グループ発表
これらは学んだことを総動員しなければいけません。
とはいえ、ただ「やってください」といっても皆さん不慣れですので動けません。
そこで各プロセスをどう考えていけばよいかのヒントは出しています。
ただ大まかなヒントなので、グループ内で考え、話し合い、協力しながらでなければ決められた時間での進行は難しいようになっています。
グループ発表では以下の内容で発表してもらっています。
- 何を重要と考えたか
- なぜ重要と考えたか
- どうテストをしたのか
- 発見したバグ
- 良かった点
- 悪かった点
最後に、最終ワークの私の所感を記載して終わります。
３時間という限られた時間でしたが、作成されたテストケースでは重要なポイントの確認は押さえられており、仕様をなぞったテストだけでは見つけられない問題も見つけられるものとなっていました。
また「◯◯を確認したいから、このように確認する」といったテストの意図が第三者にも伝わるテストケースです。
そういったテストケースを書けていますので、発表でも「こういった理由でここが重要なので、このようにテストを考えていった」と自分たちの考えと実施したテストについて説明ができていました。
もちろん全体的には荒削りなところも多いですが、最初の「実装したものが実装した通り動けばいいのではないか」の状態から、テストを考えられるようになっていることを感じ取ることができました。
まとめ
何をテストすればよいのか、それらをどのようにテストをするのか。
これらが考えられなければ、思考を放棄し仕様をなぞるだけのテスト実施になり、抜け漏れが多かったり非効率なテストになってしまうことでしょう。
それにより企業として信頼を失ってしまうような大問題を発生させてしまうかもしれません。
「テストは仕様通り動くかだけを確認すればいい」という考えから、何をどうテストしていけばよいか考えられるようになるためのテストワークショップの話でした。
LIFULLでは、何をどうすればよいか自ら考えられるエンジニアを育成していきたいのです。
このブログの話はLIFULL主催のLtech#19でもお話しさせていただきました。
ご興味がある方はスライドをご覧ください。
最後に教えている項目を列挙します。ご参考になりましたら幸いです。
- なぜテストをするのか
- マイヤーズの三角形問題
- テストプロセス
- テストレベル / テストタイプ
- レビュー
- コードレビュー
- テスト技法
- ホワイトボックステスト
- C0カバレッジ
- C1カバレッジ
- ブラックボックステスト
- 同値分割
- 境界値分析
- デシジョンテーブル
- オールペア
- リスク
- バグ管理
- テストケースの書き方
- テスト実習
