こんにちわ。プラットフォーム開発部 QA の hark です。
QA チームでは、昨年より QA プロセスを改善する取り組みを継続的に行っています。その一環で、今年 3 月、JaSSTソフトウェアテストシンポジウム-JaSST'22 Tokyo に参加する機会をもらい、色々なセッションを聴講してきました。それぞれの現場で、QA 担当者が感じている生の声をたくさん聞くことができたこともあり、「○○できたらいいな」と漠然と思っている状況をやめて、「○○するには、弊社の場合は何から始めたらいいのかな」と具体的な一歩目について考えるようになりました。
今回は、興味深かったセッションを数例ピックアップして共有したいと思います。合わせて、まだネタにも種子にもなっていないですが（いずれ芽が出たら改めてレポートしたいと思います。）、JaSST 2022 をきっかけとして、自分の中で燻り続けている「QA とは」についても紹介します。
- [JaSST'22 聴講レポート 1] QA と Verification と Validation
- [JaSST'22 聴講レポート 2] QA と フィードバック
- [JaSST'22 聴講レポート 3] QA と Vision
なお、Mirai Translator開発チームでは、「5分だけ勉強会」というエンジニアメンバーの勉強会を毎朝開催しています。（以下のWantedlyの記事参照）
当記事は、この「5分だけ勉強会」で 4 月に発表したものです。社内で共有してから既に３ヶ月が経ち、改めて自分の書いた記事を読み直して、自分の理解が少し進んだかなと思ったので、下記の項目を追加しました。
- [３ヶ月経って振り返る] Verification と Validation と フィードバック
[JaSST'22 聴講レポート 1] QA と Verification と Validation
（出典：品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World - Speaker Deck スライド30より）
自動テストのコードを書いているときに、「validateXXX()」や「verifyXXX()」といった関数を作ったことは何度もありますが、自分は両者を気分で使い分けていたなぁと反省しました。ともあれ、自分は以下のように理解しています。
最終成果物が事前に取り決めたルール（仕様）を遵守しているべきであり、その当たり前を保証（確認）する観点が、いわゆる Verification 視点だと理解しました。開発プロセスの位置によっては、機能テストだったり、E2Eテストだったりしますが、いずれにせよ、仕様が明確に定義されている Verification は、いつ、誰が、テスト仕様書に沿ってテストを実施しても、マル・バツは一意に決まります（基本的に再現性あり）。「テスト」と言われた時に一般的に誰もが抱くイメージが、この Verification ではないでしょうか。
振り返ってみると、現在の QA チームに配属されるまでは、「仕様書という名の正解データ（正例）」と「実際の動作」を比較して、マル・バツをつけることがテストの全てだと思い込んでいました。以前、 TE（テストエンジニア）として別現場で働いていた際、『神の手』と称される同僚がいて、というのも、その人にテストさせるとなぜかバグが発掘されるのでそのように呼ばれていたのですが、「自分もそうありたい」と飲み会で上司に語っていたことをついでに思い出しました。（今でも、その気持ちはありますけど。）
対して、Validation 観点は、（乱暴に言ってしまえば）Verification という囲いの中から踏み出して、その外側から全体を観ているように理解しています。「ユーザが何に不満を感じていて、この機能を追加することでそれは解消するのか？」「ユーザの要望に対して正しい解決策を提示できたのか？」「そもそもユーザにとって、この仕様はありなのか？」といった根源的な問いに向き合うために、さまざまな物差し（評価軸）を使って多角的に評価することが Validation 視点だと思います。
Verification は自動化しやすい領域であり、「QA がやるべきこと」ではあるものの、例えば SaaS 型のテスト自動化ツールなどを利用することによって、「QA の属人的な業務」からは少しずつ外れていくのかもしれません。だからこそ、「ユーザの要望に対して正しい解決策を提示できたのか？」を追求する Validation について、QA として取り組む必要があるのではないか、と感じました。
しかし、実際は、Verification に加えて Validation も QA が専任で行うパターンがベースとなると思われます。結局、QA のやるべきタスク、やりたい業務は山積みとなり、それを開発プロセス終盤の QA フェーズで全部消化しようとしても無理なので、できる限りシフトレフトして、開発フェーズのより前の段階でタスクを消化して効率化を図り、その結果として生まれた余力で、開発サイクル全体として品質維持する旗振り（ファシリテータ）をやるのが、QA の Next Stage なのかなと、自分はそのように考えています。
[JaSST'22 聴講レポート 2] QA とフィードバック
（出典：従来型QAからアジャイルQAへの進化方法 - Speaker Deck スライド20より）
（出典：品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World - Speaker Deck スライド33より）
アジャイルな開発において、「フィードバックのループ」は必要不可欠な要素です。 このループにより、日々の開発プロセス、行動、そして、プロダクトの品質が絶え間なく改善されていきます。
上記セッションを聞いて、QA が {送る、受け取る} フィードバックって何かを整理しているのですが、未だに納得のいく整理ができていません。（下記は整理中のたたき台であり、実在の組織や事実とは異なるケースを含んでいます。）
そんな状況ですが、下記の 2 点について、まずは個人として改善したいと考えています。
- ユーザの気持ちになってテストを行うこと
- 自動テストの声を聞くこと（自動テスト実施結果からのフィードバック）
- ユーザの気持ちになってテストを行うこと
まず、1 についてですが、QA には「開発プロセス終盤で行う E2E テストなど通して、出来上がったプロダクトを最初に触るユーザである」という側面があると考えます。だから、テストが完了したのであれば、その製品（機能）に対するユーザ観点の意見をフィードバックできるよなあ、そういう意識を持ってテストを実施しないといけないよな、そう再認識しました。
あと、これは別に本件に限定したことではないのですが、「（言葉は適切ではないかもしれませんが）徹底して粗探しして問題が検出されないことを確認する」ことが（改善のネタ出しとして役に立っているので）フィードバックだと思い込んでいたように感じます。
「今回の○○機能ですが、こういう点が使いやすかったです。」「■■がめちゃ改善しましたね。」みたいに、もっとポジティブなフィードバックもしよう、と言うことが、今、自分が最も強く意識していることです。
- 自動テストの声を聞くこと
次に、２についてですが、テスト結果（失敗頻度、各種処理時間、、、）が蓄積したものも立派なデータです。そのデータ（テスト結果）を入力として、見える化（インサイト）して分析を行い、継続的にモニタリングすることによって、気づきが得られるのではないか。PASS すれば無問題、バグが検出できれば万々歳で、みるのはそこだけだ、そんな認識でいたかなぁと反省しました。
上記セッションを受け、振り返ってみて、以下のような端緒に気づきました。重要度的に今すぐ手はつけられないかもしれませんが、いわゆる「20%ルール」の範囲で考えてみる、などしているところです。
- 追試したら PASS するので「{たまに、まれに、ごくまれに} 失敗するテストケース」だとは認識していたが、自分はそれ以上の調査は行なっていなかった。
- 機能が追加される度に RegressionTest の実施時間総計が右肩上がりに増えているけど、例えば半年前に比べてどれくらい増えたのか。そもそも、今どれくらい時間かかるのか、自分は把握できていなかった。（都度、調べて回りたいわけでなく、それらが勝手に蓄積されてその情報に気軽にアクセスできるような仕組みを入れておきたい。）
[JaSST'22 聴講レポート 3] QA と Vision
「PdMと考えるQAとプロダクトマネジメント」の中で紹介されていたのですが、これまでの変遷とこれからの未来をビジュアライズした資料で表現し、それを社内で共有しているとのことでした。
調べてみたら、pmconf 2021 でも発表されていたので、既にご存知の方も多いかと思います。
このセッションで、ホワイトボードや大きめの模造紙にイラストや図を使って会議の内容を見える化するファシリテーターや板書係の手法「グラフィックレコーディング（グラレコ）」を初めて知りました。
ロードマップやビジョンという硬派なものを、このようにビジュアル化（抽象化、見える化）することで、誰もがイメージしやすく、訴求度が高まっているのではないかな、と自分は感じました。
あと、蜂須賀氏は以下のように述べておられました（と記憶しています）。
「このロードマップは、年代別に並べると一枚の絵になるようにしている。ドラゴンボールの単行本の背表紙みたいな。そして、何十年後か後に、これを合体させて、どんな風景が描かれるのか、楽しみだ。」
上記テーマは、PMという大きな枠組みに限ったものではなく、どのドメインでも通用する身近な話だと私は捉えており、だからこそ、強烈に印象に残りました。そこで、試みに、2022年度の個人的なロードマップを同じように絵にしてみようと 2 回ほどチャレンジしてみたのですが、いずれも早々に断念しました。グラレコについて書かれたブログを漁って、グラレコについてわかったつもりになったのですが、そもそも図で描こうにも、描き慣れていないとそこでつまづいてしまい、全く立ち上がれません。例えば、ヒトを書こうとするだけでも、「自分はセンスないなぁ」と滅入る始末です。ただ、グラレコはとても興味があるので、長期的に取り組んでいこうと考えています。
[３ヶ月経って振り返る] Verification と Validation と フィードバック
新機能開発ともなると、開発プロセスには多くの関係者が存在しており、議論と手渡しと修正を繰り返しながら、要求定義、要件定義、各種設計、仕様書を FIX していきます。別の言い方をすると、「お客様の要望」は多くの関係者の手を渡りながら「各種仕様」を生成して、それを参照して実装を行い「サービス（もの）」を生み出しています。
とどのつまり、多種多様なコミュニケーションがそこに介在している以上は、その過程で、情報が欠落したり、誤った解釈により誤情報が追加されたりするリスクがあります。
ソフトウェア開発やシステム開発が「壮大な伝言ゲーム」に喩えられることが多いのは、その辺りに深く由来しているのではないでしょうか。
「壮大な伝言ゲーム」において、「ユーザが本当に求めているもの」に近づけるためにできることは、各フェーズで検証と確認を行うことではないか、と思います。
- 「前フェーズから聞いた内容」と「次フェーズに伝える内容（≒担当者の認識）」が合致していることを検証（Verification）する
- 最初に与えられたお題「ユーザの元々の要求」と「次フェーズに伝える内容（≒担当者の認識）」が合致していることを妥当性確認（Validation）する
QA はリリース水際の最終行程に近い位置にあり、またテストに紐づくあらゆる要素がタスク領域に含まれているため、検証（Verification）と妥当性確認（Validation）が強く求められます。なので、検証（Verification）と妥当性確認（Validation）は QA が気にしていればいい話なのかなと思っていましたが、開発プロセス全体で各々が意識することで、より効率的にことが運ぶのではないか、そう感じました。
この喩えを踏襲すると、「ユーザの元々の要求」と合致しているのかを確認（Validation）するとは、物理的にも遠く離れたエンドユーザ（または、導入先の情報システム部門、または、代理店など）とのフィードバック経路を確立するという意味なので、そもそも高コストで高負荷なアクションとなります。さらには、端まで到達してから評価して、やっと、ずれを把握できたとしても、引き返せないところまで来てから判明しても打つ手はほとんど残りません。だから、せめて、隣接する２者間（２社間）で検証（verification）して結果をフィードバックする仕組みの方が、両者のずれを都度補正できて効率的です。
また、アジャイル開発であれば、（理想的には）スプリント毎にユーザフィードバックを得られるので、お手を煩わせるとはいえ、ズレが小さいうちに確認してもらって、フィードバックをこまめに得ることで効率的に補正することになります。
ということで、３ヶ月間に書いた自分の記事を振り返って見ると、妥当性確認（Validation）が大事だ、QA でも取り組みたい、と３ヶ月前に簡単に口にしていましたが、自分が考えているほど容易に始められるものではありませんでした。やることは山積みであり、掲げた目標も遥か遠くにあり霞んで見えませんが、できることから、匍匐前進でもいいから進んでいきたいです。
※
ちなみに、グラレコは自分には高すぎる壁だと反省したので、まずはヒトが描けるようになろうと考えています。当初、本記事中では棒人間を描いていたのですが、あまりにも殺風景だったので、自分でもできそうなものを探しました。色々彷徨って、「イラストプレゼン研究所」というサイトを見ながら日々練習しています。まだ１ヶ月にも満たず、へたっぴなままですが、毎日最低でも10人書くようにしています。
最後に
みらい翻訳では、品質向上に一緒に取り組んでくださるQAエンジニアを募集しています。ご興味のある方は下記リンクからお問い合わせください。
