この記事は NTTコムウェア Advent Calendar 2024 13日目 の記事です。
こんにちは、NTTコムウェアの 吉村 優 です。
社内の開発プロジェクト向けに技術支援を行うチームに所属しており、現在は探索的テストを活用した機能性や使用性の改善・向上の支援を中心に取り組んでいます。
昨年も探索的テストに関する記事「マインドから始める探索的テスト」を書きましたが、引き続きホットなこの技法について私たちのチームの取り組みを書いていきます。
はじめに
さて、みなさんは探索的テストしていますでしょうか？
探索的テストは、事前に詳細なテストケースを用意するのではなく、その場その場でテスター自身の発想や気づきを活かしてテスト設計と実行を同時に進めていく手法です。
ここ数年で様々な第三者検証会社が探索的テストサービスを開始しており、かなり普及してきていると感じています。
自分のアイデアを盛り込めるのでやってみると楽しかったり、品質向上にはとても役立つのですが難しい面もあります。
- 学習や実践の場が限られる
- 経験を積むだけでは探索の質を高めにくい
- 質を上げるにも個人の暗黙知を活用するためノウハウの共有やスキルアップが難しい
私たちは第三者的な位置づけで探索的テストを行っていますので、新しくチームに加わった経験の少ないメンバにもしっかり探索してもらう必要がありますし、様々な状況にもきちんと対応していく必要があります。
そんな背景から「探索力を効率よく高められる方法はないかなぁ」とずっと考えています。
学べる場が少ないという点に関しては、実践力を鍛える探索的テストセミナーを開発したの（JaSST nano vol.38）でも発表させていただいた習熟セミナーを開発し、社内向けに開催しています。
今回はさらに一歩進めて、SECI モデルを参考に探索的テストで用いる暗黙知を形式知化し、チーム全体でノウハウを共有する仕組みを考えた取り組みについて紹介します。
探索的テストに SECI モデルを取り込んでみる
SECI モデルとは
SECI モデルは、個人が持つ「暗黙知（言語化しづらい経験やノウハウ）」を「形式知（文章などで説明できる知識）」に変換し、全体に共有するフレームワークです。
詳細は割愛しますが、大きく以下の４つのプロセスから構成されています。
- 共同化（Socialization）
- 経験を通して暗黙知を他者と共有する
- 表出化（Externalization）
- 得られた暗黙知を文章等で表現（形式知化）する
- 結合化（Combination）
- 形式知を統合して新たな知識やアイデアを生む
- 内面化（Internalization）
- 形式知をもとに実践し自身の暗黙知に落とし込む
この流れに沿って探索力を高められる仕組みができないかと考え、以下に取り組んでみました。
共同化：探索する際の暗黙知を共有する
最初のステップは「共同化（Socialization）」です。
探索的テストにおける暗黙知を他者へ共有するためにペアでの探索的テスト（モブテスト） を取り入れました。
任意のテストチャーター消化時に経験豊富なテスターと経験の浅いテスターなどが一緒に探索的テストを行います。
テスト対象を操作するドライバーと指示を出すナビゲータに役割を分けて進めることで、相手の思考の特徴や無意識に気にしている確認観点などを知ることができます。
役割を入れ替えてみたりペアを変えてみたりしながら、色々な人のスキルを見て・聞いて・学んでいくのはレベルアップ感があって面白い体験です。
また、仕様に強い人と組むとテスト対象の理解も加速度的に進むという効果もあります。
表出化：気づきを言語化する
次に「表出化（Externalization）」を行います。
テスト中に得られた気づきや発見を形式知に変換していきます。
ここでは大きく二つの取り組みをしています。
一つは実施した概要を記録することです。
とはいえ、記録に時間がかかりすぎると探索的テストのメリットの一つであるスピード感が崩れてしまうので簡易な方法をとっています。
手間がかかりすぎないようにテストチャーターにおける確認内容の概要とそこで見つけた故障を記録していきます。
ここは一般的な探索的テストのやり方かと思います。
もう一つは、見つけた故障について口頭で共有することです。
チーム全員に対してどんなことを考えて、どんな流れでこの故障を発見したかを説明します。
その場では「こういうパターンは試した？」、「似ているこっちの機能は大丈夫？」といった感じでちょっとした議論も行います。
その中で担当者が気付いていなかった真の要因を見つけられたり、関連する別の事象を発見できることもあります。
結合化：探索観点として整理する
そして「結合化（Combination）」を行います。
ここでは、記述式テスト（Scripted Testing）では確認しにくい内容や探索的テストだからこそ確認した手順と見つけられた故障情報を再利用可能な形で整理していきます。
具体的には、確認手順と見つけた故障の情報からテスト対象システム固有の情報（画面名、フォーム名、事前条件など）を除き、別システムに対しても活用できるレベルで抽象化を行います。
併せて、過去に別システムで見つけた類似する事象がある場合は結合させたり、新たな観点があれば要素を付け足したりして、一つの知識体系としてまとめていきます。
探索的テストを行うたびにこのような情報を蓄積していくことで、故障を見つけられた実績を持つ探索観点表ができ上がっていきます。
一例ですが以下のようなリストを作っています。
- 複数の入力フォームが存在する場合、データの投入順序を変えたり（下から入力する等）、一部のフォームを空欄にしたりしても処理が正しく行われるかを確認する
- 検索結果が「0件 → 1件以上」または「1件以上 → 0件」となるように条件を変えて、複数回検索処理を実行した場合に処理や画面表示が正しいことを確認する
内面化：知識を実戦で活用する
最後に「内面化（Internalization）」を行います。
作成した知識体系を新たな武器に、探索的テストへ挑戦します。
経験の浅いテスターは、作成した知識体系を参考にすることで「何から手を付けたらいいかわからない」ということになりにくくなります。
また、ただテスト対象をノーアイデアで徘徊するのではなく、効果の高そうなテストケースを優先的に使って探索することができるようになります。
経験豊富なテスターは、知識体系の内容に自身のアイデアを掛け合わせることによってさらなる発想の飛躍を狙うことができます。
今までの自分にはないテストケースを思いつくことができるため、探索的テスターとしてスキルアップが見込めると考えています。
工夫してみた結果
この取り組みによって、探索的テストの質と効率を向上させることができたと考えています。
また、形式知化した知識体系が状況に応じた柔軟な思考をサポートしてくれるため、チーム全体の成長を加速させてくれています。
探索的テストを単なる個人技にとどめず、どのような人でもアイデアを出しやすく＆実行しやすい環境を整えることができたのではないかなと思います。
留意点
ただし、注意点もあります。
探索的テストは個々の経験やスキルを活用する方法ですので、形式知化することで思考がそれに引っ張られ発想の幅が狭まったり、せっかくの個人の特性が薄まってしまう可能性があります。
あくまで手札の一つとして持っておくことが重要で、思考を支配されないように留意することが必要です。
そのため、探索のプロセスや手順を明文化・ルール化することではなく、状況に応じて豊富な発想が生まれるように個人の手札を増やすことを目的にしています。
おわりに
探索的テストって「テストチャーターを使ってテストをする」という一見シンプルな取り組みですが、やればやるほど奥深いなぁと思います。
今回ご紹介した取り組みも「これで完成！」というわけではありませんが、試行錯誤を続ける中で「こういうやり方もよさそう！」とチームが盛り上がる瞬間も増えましたし、今後もより良い探索のために進化させ続けていこうと思います。
この記事を通じて少しでも探索的テストに新たな可能性を感じていただけたら幸いです。
※ 記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。