本記事は株式会社ベリサーブに所属するメンバーによる ベリサーブ Advent Calendar 2023 の3日目の記事です。前日の記事は こちら から。
本日はいわゆるイベント登壇レポートをさせていただきます。（自身のメインセッションへの登壇のみがスコープです。時間の都合で、ぐんちゃさん による サブセッション への言及はまたの機会に…🙇♂️）
Encraft #9 にパネラー登壇してきました
タイトルのとおり、2023/11/29（水）に開催された 株式会社ナレッジワーク さま主催の技術イベント Encraft の 第9回目、サブタイトルを「QA Enablement -Practical Test Design-」としたテスト・QA技術を取り扱った回のメインセッションのパネルディスカッションに、いちパネラーとして参加してきました。メンバー構成は以下のとおり（敬称略）。
一定期間、テスト・QA業界に身を置いている方ならおわかりいただけるであろう、私以外のメンツが錚々たる感じで、河野さんからお話をいただいたときはわりとガチでヒヨりもしましたが、せっかくの機会ということで受けさせていただきました。
さて、今さらの自己紹介ではありますが、私は普段ベリサーブでは、テスト管理支援ツールの QualityForward や テスト開発支援ツールGIHOZ といったテスト支援ツール群の開発・デリバリーマネージャー、および、QualityForwardについてはプレイングマネージャーとして自らプロダクトオーナーをしていたりと、私自身はテスト・QAエンジニアではなく、プロセス領域としてはどちらかというと製品企画・開発側に身をおいております。ちなみに、くしくもこの日は、プロダクトマネージャー・プロダクトオーナー系人材にとっては年に一度の国内最大規模のイベント pmconf_2023 の開催日でもあり、そっちの懇親会とかぶっているのも悩みの要因でしたが、せっかくのお声かけということで登壇のほうをとりました。
そんなプロフィールの人間ですので、河野さんからはパネルでのポジションとしてもツールベンダーとしての立場的なものを期待していただいておりましたが、結果的にそういう立場要素は最後にテスト技法教育にGIHOZはいいぞ...と宣伝をさせていただいたぐらいで、あとは自身の経験ベースで好き勝手話していたように記憶しております。（結果的にそれでよかったようにも思いますが）
というわけで、本記事では私なりにパネルの内容を振り返ったり、当日の自身の発言の背景などを軽く細くできたり、なんて思っております。
パネルで扱った参加者からの質問の傾向
パネルディスカッションはいろいろなセッション設計の流派がありますが、今回はモデレーター・パネラー合意のうえ、あえてパネラー3名には事前に質問は公開せず、当日初見でぶっつけの議論スタイルとしました。これはあくまで私個人の意見ですが、おそらく事前にちゃんと質問を見て回答内容を整理・設計したほうが、イベントとしてはよりホスタビリティが高いのではとも思うのですが、無料イベントですし、正直最近結構忙しく、なかなか事前に時間をとる余裕もなかったため、やむなしといったところです。
当日、非常にたくさんの質問が用意されており、かつそれらはすべて当日参加者の皆さんから事前にエントリーのあったものということで、イベントへの関心度の高さも感じました。そんな質問群ですが、非常に乱暴には以下の2つの方向性に分類できるものが多かった印象です。
- テスト活動の効率化
- 1～2週間のスプリント・イテレーションで、どう効率的にテストを進めるか
- テスト技術の向上
- 個人としてテスト技術をどのように向上させていくか
- チームが拡大していくなかで、どうチームとしての技術力をあげていくか
ひと昔前に比べて、 アジャイル型開発案件で、かつ、ジュニア・ミドル層の一人目ないし少人数体制のテスト・QAエンジニア という感じの立場での質問が多いのかなと想像し、当日もそんなプラグマティックペルソナを脳内に浮かべながら話していました。
テスト活動の効率化
前者のトピックについては、以下の2点に集約されるような内容の議論になったかと思います。
- テストアーキテクチャの最適化
- テストプロセスの最適化
テストアーキテクチャの最適化
こちらは主に井芹さんからのお話が中心でしたね。質問者は立場的に、ある程度動くものができあがったあとに、 ストーリー・シナリオ的な側面でテスト をしている方が中心だったかと思います。そこで、全部自分たちで解決しようとするのではなく、自身が担当しているテストに加え、たとえば開発エンジニアによる サービス・コンポーネント内（たとえばpublicなメソッドなど）の単体テスト、開発エンジニアやSETによる サービス・コンポーレートのインターフェース（たとえばWeb APIなど）の結合テスト なども壇上に並べて責務を整理し、たとえば自動化しやすく実施リードタイムの短い単体・結合テストに少しずつ責務をよせていくことで、全体最適になり、結果的に自身らの活動もスリム化できるかもね、というような話がありました。
テストプロセスの最適化
私からは、たとえばテストをするうえでテストパターンの洗い出しなどを行うテスト設計活動もすべて自分たちでやろうとせず、軽量なモデルベースドテスト（ちょっと無理やり 昨日のAdvent Calendarネタ も絡めてみたり）的な考え方で、テスト設計に活用できる仕様モデルの一部を、開発時に仕様ドキュメントとして、プロダクトオーナーや開発エンジニアに要件定義・設計活動として担当いただく、というような最適化も提案しました。Web開発での鉄板例としては、複雑な入出力を持つ画面フォームやWeb API仕様は、 開発の役にもたつよね というコンセンサスのもと、入出力仕様を デシジョンテーブル を開発初期段階から作っている、というのを私はよく提案しています。また、画面遷移やデータエンティティのパターンの整理を状態遷移図として、ユーザの目的機能達成パターンをアクティビティ図として、書き方をパターン化しておくと、かなりテスト設計活動の助けになることも多いでしょう。
ただ、注意点としては、前述で協調したとおり、ただテスト活動を手伝ってくれ、よりかは開発時の仕様の認識齟齬がなくなるなどのメリットを訴求して、プロダクトチーム全体としての活動最適化になる旨をすりあわせることが重要ですね。
テスト技術の向上
一方、後者のトピックも、秋山さんから「HAYST法が難しいは心外ですね」「教育は無理ですね」「ナレッジ蓄積は無理ですね」など、場をなごませるあえての尖った発言が連発されるなどもありながら、議論も盛り上がりましたね（笑） またも乱暴に整理するとこんなところでしたかね。
- まずはプロダクトから
- テスト開発方法論は要テラーリング
- 実践と振り返り
- 仲間づくり
まずはプロダクトから
井芹さんからも秋山さんからもお話がありましたが、テストエンジニア・QAエンジニアとしてテスト技法、ひいてはテスト開発方法論をうまく活用して仕事を効率化・高度化したくなる、というのは非常によくわかるのですが、とはいえ、表面的なプロセスだけうまくやろうとするのは無理で、まずは目の前のプロダクト・ドメインについて勉強し、考え抜きましょう、というのが正攻法ですね。品質って市場の状況、会社の状況、ユーザの状況等、プロダクト自体の外側にもたくさんパラメータがありますからね、近道はなしですな。
テスト開発方法論は要テラーリング
テスト開発方法論、たとえば日本ではHAYST法、VSTeP、ゆもつよメソッドなどが挙げられますが、それらの活用について、みんな難しく考えすぎだよね、みたいな議論もありました。テスト開発方法論というのはテスト分析やテスト設計における様々な工夫を積み上げ、いろいろな現場での文脈でとおるように抽象化したものなので、たしかにぱっと見、仰々しいものに見えますが、方法論に含まれる各ステップや成果物の背景にある工夫要素に理解し、いきなり全部ではなく、少しずつ自身の仕事にあてはめていってみる、という スモールスタート・トライ＆エラー が重要ですね。
実践と振り返り
テストのナレッジ蓄積・テストの標準化のような文脈の質問にも、あまり大げさに考えずに、 やってみてよかったことをちょっとずつチーム内で共有・実践の幅を広げていく、ぐらいに考えるのがいいよねという議論がありました。アジャイル型の開発だからこそ、振り返りのタイミングというのも従来より設定しやすいかと思うので、継続的な改善を少しずつ積み上げていくのが地道ですが王道ですね。ナレッジ蓄積も標準化も、言葉の定義的には決して間違ってはいないのですが、けっこう強い言葉だったりもするので、言葉に引っ張られて手段の目的化というか、思ったより効果が得られない、というのはけっこう私も見てきたので...
仲間づくり
テスト設計技法より先はOJT・実践あるのみ、みたいな話もあがりました。「教育は無理」というのは若干言葉が強いですが、でも実際問題として、テストって開発のエンジニアリング領域と比べると教育が難しい、というか、「試す」ハードルが非常に高いと個人的に感じます。というのも、何をするにも テスト対象となるプロジェクト・プロダクト というのが必要になり、またそのシステムの在り方によってアプローチ自体が大きく変化するのがテストのため、汎用的、かつ、学習・教育に最適なテスト対象というのは用意が難しいのですよね...であるならば、 目の前の仕事で自身・もしくは同僚と実践あるのみ、でいくか、あとは 社外で近しい領域の仲間をつくって、ワークショップ的に議論を重ねる しかないのですよね。ちなみに、私は過去にまさに後者のための後押しとして WACATE というワークショップを運営していたので、セッション内でもWACATEをおすすめさせていただきましたが、今は他にも様々なテストのエンジニアリングのコミュニティができているので、そういうところへ赴いて、自身の具体的な仕事の悩みについて議論・ワークショップができるような仲間をつくっていくことが、自身の技術アップの有用な手段のひとつかなと思っております。
（宣伝）GIHOZをよろしく
というわけで、テスト・QA活動の効率化・高度化の道はとてもはてしないですが、その最初らへんの一歩のひとつとして、テスト設計技法の学習は有用というのはなんとなくコンセンサスがとれていたように思いました。ということで、皆さん、無料で活用できますので、テスト設計技法の学習の際は、ぜひ GIHOZ のご活用、よろしくお願いいたします！
おわりに
久々のオフラインイベント、大変楽しかったです！企画いただいたナレッジワークさま、お声かけいただいた河野さん、どうもありがとうございました。ご参加いただいた皆さんも、別のテストイベントでぜひまた！