テストプロセス改善技術を身につけ、実践することの意味と意義
はじめに
本記事は「テストプロセス改善技術」を身につけ、実践する意味と意義について記載しようと思います。
テストプロセス改善技術の概要としては以下を参照してください。
https://www.aster.or.jp/business/testprocess_sg/pdf/ASTER_TPIGuide_v1.0.0.pdf
この記事のコンテキスト
私は「TPI」という、江戸時代に作られたテストプロセス改善技術を取り扱うギリ専門家です。
それを私の強みの一つとして取り扱っていたのですが、アジャイルQAのカジュアル面接を進める中で、「アジャイルではテストプロセス改善技術は必要ない」、「トップダウンのプロセスモデルは合わない」、「ウチは現場で起こった問題にきちんと向き合って対処しているから必要ない」といった意見が結構見かけられました。
「現場によっては必要がない」はテストプロセス改善技術に限らず、全てに当てはまるものですが、「どうせプロとして試してもないし上辺くらいしか理解してないのによくそんなこと言えんな」と思ってないこともないです。
そのため、本記事ではテストプロセス改善技術を少しでも学んだ人間として、少しだけ言い訳をしたいです。
本記事の意図
本記事は以下を意図しています。
テストプロセス改善技術について、偏見を持っている人に当事者として伝えたい
テストプロセス改善技術について、その現場にとって適切な使い方をしなかったために嫌な思い出を持ってる人に弁明したい
伸び悩んでるテストエンジニアの解決手段の一つの手段として、テストプロセス改善技術というものを知ってほしい
決して全ての現場にテストプロセス改善技術を取り入れて欲しいという趣旨ではありません。
テストプロセス改善技術の弁明
全てがトップダウンアプローチという印象について
テストプロセス改善技術の導入方法として、そのテストプロセス改善技術に習熟した人が主導して行うことが、今のところ最も有用なアプローチの一つだと考えます。
テストプロセス改善技術がトップダウンアプローチであるということはある種否定できません。
テストプロセス改善技術のアプローチは、大雑把に言えば以下の工程で実施されます。
現状を知る
現状を評価する
改善策を計画する
改善策を実行する
以下ループ
そのため、コンサル的な人が突然降りてきて、第三者的に現状をチェックして、改善策を押し付けてくるみたいな印象を持ってしまいます。それはテストプロセス改善コンサルが得意とする働き方によって異なります。だって上の工程をよく見てください、OODAループそっくりじゃないですか。
例えばTPI NEXTという手法では、セルフアセスメントモデルとしての位置付けが強調され、有識者によるガイドの必要性を記述しながらも、チーム自身で自己認識して改善していくことが推奨されています。
テストプロセス改善技術の有識者が「コンサル的アプローチ」を選択しなければ、トップダウンなテストプロセス改善は回避できると考えます。
そして、私は多くのアジャイル開発では「コンサル的アプローチ」ではなく、「コーチング的アプローチ」を行うことでテストプロセス改善技術を使った効率的なテストプロセス改善ができると考えています。これは後ほど述べます。
テストプロセス改善技術のダメ適用パターン
テストプロセス改善技術はものによっては「あるべき姿のテストプロセスモデル」が存在して、それに向かうための段階を表現されたものと思われています。
それは正しいと思っていいです。
過去の蓄積された経験知から「Goodなテストプロセス」を定義して、そこに向かうのが基本的なテストプロセス改善技術です。
一方で、その現場のコンテキストや開発プロセスをきちんと理解せずに、「あるべき姿のテストプロセスモデル」にひたすら邁進するテストプロセス改善コンサルとしたら、それはダメコンサルです。
本来、テストプロセス改善コンサルは、テストプロセス改善技術の段階モデルだけでなく、「あるべき姿のテストプロセスモデル」についてそれらの存在意義をきちんと納得できる形で説明できるか、コンテキストによって取捨選択するかなどの柔軟な対応ができるべきです。
標準に従うのではなく、標準について本質的な理解を深め、そのプロセスを実施しないことによる問題やリスクをきちんと理解して説明できる状態でなければなりません。
ふりかえりだけでよくならない場合もある
「ふりかえりだけでテストプロセス改善はいいんです」といってる人もいます。
一応それにも別の意見を提示します。
第一に、概してテストはリスクを予防するという目的を持つ活動であるため、「問題が起こる前に対処する必要がある」という性質があります。そのため、「問題が起こってから対処する」ではなく、なるべく様々な不確実性を排除した方が良く回るということがあります。
第二に、多くのふりかえり手法はその分野でのGoodプラクティスを提供することはなく、自己の認識の範囲内での改善に留まるという点です。チームの納得感としてはそれでもいいかもしれませんが、あくまで「道しるべ」として使う用途として、何かしらの方向性がある方が有用だと考えます。
ていうか、テストプロセス改善技法をアレンジして「テスト活動」というテーマにしたふりかえり技法と仕立ててもいいと思います。
テストプロセス改善技術を「道しるべ」として使う
テストプロセス改善技術を適用することによって得られる改善策というものは、「経験的にこの優先度や順番でやったらいい感じになるで」といったものです。
テストプロセス改善技術によって示される改善策はあくまでプロジェクトのいく末を判断するための「道しるべ」であるべきだと考えています。
例えば、「バグ分析を行うこと」は有用なプラクティスと言われたりしますが、それ以前に「テストの専門家がいること」や「テスト設計が適切に行われていること」などが満たされていないとあまり意味のある対策にはならないと多くのテストプロセス改善技術では定義されています(多分)。
そうしたテストプロジェクトの全体像を把握して、テストプロセスの改善の1歩目として何をすべきかの「道しるべ」を提供するのがテストプロセス改善技術と考えています。
※ちなみに「テストの専門家がいること」「テスト設計が適切に行われていること」が「バグ分析を行うこと」より優先する理由としては、テストの専門家によるテスト設計がきちんと行われていない場合、バグがきちんと出せていない状態であったり、バグ分析に必要な情報がテストの観点で得られない、バグ分析の結果がテストに反映されないなど、いろんな理由があります。もっとあるかも。
テストエンジニアがテストプロセス改善技術を学ぶ意義
「テストプロセス改善技術の弁明」の章では、テストプロセス改善技術を取り入れるモチベーションについてなんとなく書きました。
私はその程度でいいです。取り入れるかどうかはプロジェクトで決めたらいいと思います。
ここからはテストエンジニアがテストプロセス改善技術を学ぶ意義について記載します。
ここからが本当に言いたいことです。
徹底的な言語化
テストプロセス改善技術の大まかな流れについては上記で記載しました。
全ての流れで、テストプロセス改善エンジニアは徹底的な言語化が求められます。
全ての評価項目でそのテストプロセスがどういう状態かを文書化する技術、知識、知恵、アセスメントモデルの場合は聞き取るための説明、コミュニケーション能力とかが求められます。他にも求められるかも。
それらは単純にJSTQBとか元のプロセスモデルを学ぶだけでは得られない、「プロセスをインスタンス化する力」を得られます。
これらは実務で他のテストエンジニアと一緒に働くだけでなく、開発者やその他のロールと納得感を持って進めるための大いなる力となるでしょう。
テストプロセスへの深い理解
半端なテストプロセス改善技術者になるならいらないですが、真面目に適用しようと思ったらこう思うはずです。「なんでこのプロセスはこうあるべきなんだ？」と。
テストプロセスを構成する何百というプラクティスは全て導入する理由や目的があります。それらを理解する機会を強制的に与えられるようになるわけです。
「JSTQBがベストプラクティスって言ってるからそうなんだ」という思考停止した人がいるならそれはダメコンサルです。
きちんと現状を言語化して、その現状に適したGoodなプラクティスを提示するのがGoodなテストプロセスコンサルです。
「テストの技術を学んでもアジャイルでは通用しない」と言ってる人もいますが、一部はYESですが、概ね間違っています。
2024年現在、アジャイルテストの技法のほとんどは既存のテストの技術の応用でできていると見ています。基本的には早くなっただけです。
そのため、本質的な理解をするためにも既存のテストプロセスモデルのGoodプラクティスや技術を学ぶことは有用だと考えています。
コンサルじゃなくても使えるテストプロセス改善技術
テストプロセス改善技術はコンサルじゃなくても使えます。
テストプロセス全体を客観的に判断して改善に向かうことができる技術としてです。
自身もテスト実行を行い、テストの業務に忙殺されているアジャイルテストエンジニアは少なくないと思います。
そんな中で、目の前のテストケースの修正だけを改善としてもいいですが、一度立ち止まって、「全体はどうなんだろう？」と考えることができるようになります。
これからのテストプロセス改善技術
これは日本人である私が日本語で得られた情報のみを考えて発信するものですので、世界的には違うかも、、でも記載しますね。
テストプロセス改善技術の足りないところ
多くのテストプロセス改善技術、フレームワークはアジャイル開発を前提としていません。そのため、元となったテストプロセスモデルがアジャイルに適していないと、不要なプラクティスを適用してしまう場合があります。
また、アジャイルフレームワークも一部存在しますが、それらには具体的に評価するための項目やプラクティスが用意されているもを見たことありません。
なので、セルフアセスメントの道具としては使えるとは思いますが、技術として再現性のあるものではないのではないかと思っています。
(私の実力がないだけかも)
テストプロセスコンサルのこれから
アジャイル開発において、テストプロセスコンサルは「コンサル的アプローチ」から「コーチンング的アプローチ」に変更した方がうまく働けると思っています。
「コンサル的アプローチ」とは、第三者として評価して、レポートを出して、改善策を渡して、その後見守るといった形を想定しています。
「コーチング的アプローチ」では、(テストエンジニアを含む)エンジニアとの対話を重視して、問いをベースに評価の段階から納得感を醸成しながら進んでいく手法をイメージしています。アウトプットとして何かのレポートがなくても、チームと伴走していくことで成長した組織を作ることがゴールと想定しています。
ただ、老害の意見としてはこれからテストプロセス改善技術を学ぶ人がレポーティングをしなくていいかというと、そうでもない気がしています。
レポーティングは上記で示したように言語化の機会となるので、する機会がなくてもきちんと武器としていつでもできる状態でいた方がいいと思います。
おわりに
ここまで読んでもらって本当にありがとうございます。
あんまり自信がないので、私の心を傷つけない範囲で批判やコメントは大歓迎ですのでよろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？