始めに
WACATE2025 夏〜動かすだけじゃだめですか？〜というイベントに参加してきました。
このWACATEというイベントは、テストエンジニアに向けのイベントではありますが、自分と同じようなWebアプリケーションエンジニアの方も参加していました。
イベント参加の切っ掛けとしては、社内で参加したことがある人達による紹介と、ログラス内の開発フローの一環としてどこでもテストするという文化があります。
TDDを実践的に活用しつつ、良い品質のプロダクトを作りたくてログラスに入ったわけですが、このどこでもテストするという活動の一環に「テスト分析」があります。
このテスト分析が非常に難しく、チーム内である程度のテスト分析を作った後にQAのコタツさんにレビューしてもらうと、観点漏れが出てきてしまうということがありました。
「観点漏れがないような考え方を身に付けるぞ」という思いで参加しました。
全体的にはWACATEというイベントの雰囲気や当時の感想まとめていきます。
ポジションペーパーを使いながらの自己紹介とチームガイドライン作成ワーク
イベント全体として、考えて手を動かしすワークが中心です。
そこでこの2日間一緒に活動するメンバーと自己紹介をしていくのですが、ここで参加申し込み時に作成したポジションペーパーを利用します。
このポジションペーパーとは、自己紹介やイベント参加に対する意気込みを書いておきます。
イベント参加には必須の物となるため、すべての参加者はポジションペーパーをまとめた冊子が参加賞として渡されます。
ちなみに、私のポジションペーパーは以下のような物です。
このポジションペーパーを利用して、チーム内で自己紹介をしていきます。
ポジションペーパーを作りこんでいると話のネタにもなりますし、後述する素敵な特典があるため何回も参加されている方のポジションペーパーはおもしろい物がいくつもあります。
自己紹介後は、チームビルディングの一環として、2日間一緒にワークするメンバーとチームガイドラインを作成しました。
このガイドラインは「どんな雰囲気で進めたい」と「そのためにどんな行動を取るか」という観点でふせんを挙げていき、特に重要な物を上半分に貼るという物です。
「楽しくやっていこう！」というのが伝わる良いガイドラインになりました。
進めたい雰囲気に「パッション」があることから、自分達で「パッションの8班」などと呼んでいました。
BPPセッション: 新卒でQAになった人のLT
Best Position Paperの略で、前回の2024冬のWACATE参加者で、ほかの参加者から参加時のポジションペーパーが良かったと投票してもらうと、次のWACATEに無料で招待される特典があります。
こういう特典があるから、おもしろいポジションペーパーを作り、イベントのリピート参加の方が多いのだと思いました。
今回登壇された方のスライドは公開されていないので、話を聞きながら印象に残った部分を書いていきます。
この発表で最も印象に残ったのは、最初はQAと開発の関係性が敵対的だった状況から、1on1や実際のリリースを乗り越える中で考え方が変わっていくストーリーでした。
特に、リリース後の打ち上げ飲み会で開発チームから感謝の言葉をもらったという話は、QAの仕事がバグを見つけることだけではなく、チーム全体で価値提供するための重要な役割であることを物語っている素敵なエピソードだと感じました。
また、「品質について考えるプロになる」という発想や、slackのリアクションを複数付けたり、ファシリを積極的に実施するといった開発者との信頼関係構築のアプローチにも驚きました。
ただ目の前の作業をしていくだけではなく、チームビルディングで信頼関係を築いていくのは、かなりすごいチャレンジだと感じます。
新卒9ヵ月という短い期間でありながら、自分の付加価値や品質への意識が高く、自分の目標に対して一生懸命な姿勢がとても素敵に感じました。
セッション1: テストプロセスについて
スライドについてはこちら。
セッション全体はとしては、何かワークを実施するとかではなく、スピーカーセッションの内容を聞く座学がメインでした。
この後のワークのための事前座学的な内容ではあるが、普段の開発の一環としてのテストというよりもテストを実施していく上で必要なプロセスについての解説でした。
ISTQBのシラバスに示されている内容をベースにした内容ではあるが、実際の開発現場で起こりうる可能性についての話もありました。
詳しくはスライドを見てもらえると、テストについて形式的な知識を得られると思います。
このセッションを聞いて思っていたのは、ログラスは開発の各フェーズでテストするという開発フローになっていると同時に、テストのことも常に考える文化が醸成されています。
シラバスによって定義されている各テストプロセスを形式的にインプットしながら、文化や環境を構築できていることの偉大さを再認識することになりました。
テストプロセスを体験するワーク
このワークでは、ヘアスタイリスト予約システムというWebアプリケーションを対象に、実際のテストプロセスを体験しました。
ワーク全体の構成として、まず個人で考える時間があり、その後チーム内で発表し合いながら意見をまとめていくという流れになっていました。
ワークで実践したテストプロセスは以下の4つです。
- テスト分析：初日午後から実施
- テスト設計：初日午後から実施、2日目の最初に1時間ほど追加で実施
- テスト実装：2日目のメイン作業
- テスト実行：2日目のメイン作業
テスト分析
テスト計画書やアプリケーションの仕様書といった資料を元に、この後のテスト設計のために考えられるテストケースや考慮すべき観点を挙げていく作業をしました。
この段階では「三色ボールペン活用術」という手法を使いました。
赤・青・緑のペンを使い分けて、一番大事なところに「赤」、そこそこ大事なところに「青」、おもしろいと思ったところに「緑」で線を引きながら資料を読み込んでいきます。
普段はデジタルツールに慣れてしまっているため、正直面倒に思いながらも印を付けていきました。
漠然とテスト分析と呼ばれる作業を開発フローの一環で実施していたログラスでの経験はありましたが、このワークを通じてテスト分析で考えるべきことが明確になりました。
知らないアプリケーションをいきなりテストするよりも、テストプロセスを使うことで効率よく論理的にプロダクトを客観視できるため、テストケースが考えやすくなることを実感しました。
テスト設計
テスト分析で考えた観点を元に、以下の作業をしました。
- 状態遷移図の作成：画面遷移についての期待挙動を明確にする
- ペアワイズ法の適用：入力項目のパターンの組み合わせを効率的に考慮する
- ディシジョンテーブルの作成：スタイリストの選択要素を整理する
- テストスコープの決定：1時間で実施できる範囲の決定
実はこのテスト設計と呼ばれる作業ですが、私は勘違いしてテスト分析の作業の一環として実施していました。
今回のワークでこの作業自体は『テスト設計』という別のプロセスであることが理解できました。
修正前
公開後に指摘があり、こちらは修正前の内容になります。
自分は画面の状態遷移図を作成していましたが、これも手書きでやっていたので、ちょいちょい汚い図や間違いがあってきれいにしたい気持ちを抑えながら作図していました。
ちなみに、このテスト設計のワークは初日の最後と2日目の最初に実施をしたわけですが、初日も2日目の終わりの時間になるとどのチームでも心残りがあり、こっそり作業を続ける人達もいました。
テスト実装
テスト設計で作成した状態遷移図、ペアワイズ法による組み合わせデータパターン、ディシジョンテーブルから、実際のテストケースを列挙していく作業です。
ここで特に苦労したのが、スプレッドシートやExcelが使えず、大きな紙にテストケースを書いていく必要があったことです。
手書き文化から離れているため、誤字や文字の大きさに苦戦しながらテストケースを列挙しました。
途中、手書きでの作業が面倒すぎて、心からExcelを欲っしていました。
人類が生み出したコピー&ペーストは偉大です…はい。
テスト実行
テスト実装で列挙したテストケースを元に、実際のヘアスタイリスト予約アプリケーションを操作しながらテストを実施しました。
テストケースが前の作業で列挙できなかった部分については、モンキーテスト的に作業を実施しました。
そして、想定外のバグを発見することになります。
スタイリストの勤務時間を超過しているにもかかわらず、ユーザーが予約できてしまうという挙動を発見し、テストでバグを見つけることの喜びのような感情を覚えました。
「業務時間外まで仕事させられてしまうスタイリストって…えぇ…」なんて言いながらチーム内でバグを発見したときは、ワイワイしていました。
ワークを通じての学びと気付き
ログラスという会社ではプロダクト開発組織の全員がプロダクトの品質について第一に考えているのですが、この視座の高さをほかの参加者から褒めてもらえたことはうれしい驚きでした。
普段当たり前だと思っていた品質への取り組みが、実は特別なことだったのだと気付かされました。
短時間で自分が考える時間とチームで考える時間があり、脳がフル回転する感覚でとてもたいへんでした。しかし、ワーク全体を通して学びと再発見があり、非常に有意義な体験となりました。
イベントの設計として「自分で考えて手を動かすことを大事にしている」とのことで、全体を通して紙とペンの手書きによる作業がメインでした。この物理的な制約があることで、より深く考える必要があり、結果として学びが深まったのだと思います。
2日目:招待講演
当日のスライドや資料に関しては、参加者限定で公開されていて、ここで共有はできませんが当日に聞きながら思ったことを書きだしておきます。
この招待講演で最も印象に残ったのは、今回のワークで学んだテストプロセスが実は日本で生まれたものだったということです。
てっきりISTQBで定義された海外発祥のものだと思い込んでいましたが、最初は「テストアーキテクチャ」と呼ばれていて、現在のようなテストプロセスは後から整備されたものだったというのは大きな驚きでした。
しかも日本発祥だったということを知って、なんだか誇らしい気持ちになりました。
また、「バグのにおい」という概念についての話も非常に興味深かったです。
仕様書を読んでいると、論理的な説明はできないけれど「なんとなく不自然な何か」を感じ取ってバグを見つけるという技術で、まるで警察官の勘で犯人を見つけるような雰囲気を感じました。
この直感的な技術に対して、実際に「コードスメル」という研究分野が存在していることも知り、テストエンジニアの専門性の深さを実感しました。
特に組込み系をやられている講演者の方は、実際のコードから物理的な「におい」を感じ取ることもあるという話には思わず笑ってしまいました。
ISO 9000認証が1990年後半に日本のソフトウェア業界に入ってきた当時の話も印象的でした。
海外や官公庁案件で必要になったことから話題になり、このころから「一人QA」という言葉が生まれたそうです。
「やるべきことをやっていれば、たいへんではない」という言葉を聞いて、「その当たり前が一番たいへんなのでは…」と思いながら聞いていました。
JSTQBシラバスの翻訳裏話では、標準の翻訳という責任の重さを感じました。
解釈や翻訳を間違えると間違った標準になってしまうというプレッシャーの中で、カタカナ表記にするか日本語に和訳するかといった細かい表現まで悩まれていたそうです。
「テストレベル・テストベース・インシデント・テストアイテム」といった今では当たり前に使っている用語が、当時の日本には存在しなかったということも知りました。
現在翻訳に関わっている方が「今はAI時代だからね～」と言いながら、最強の翻訳プロンプトが存在するという話は時代の変化を感じさせておもしろかったです。
「レビューはテストに入りますか？」という議論も技術的に興味深い内容でした。
一般的にレビューは静的テストに該当しますが、ISO29119/IEC/IEEEの標準ではテスト技法として扱われていないなど、標準によって解釈が分かれることを知りました。
また、TDDについても「テストではなく開発技法である」という明確な位置付けや、最近のlinterのような静的解析も一種のテストと言える、という現代的な視点も学びになりました。
質問コーナーでは、AIの振る舞いに対するテストを扱うQA4AIというコンソーシアムの存在を知り、テスト業界もAI時代に対応していく必要があるのだと実感しました。
最後に
現職以外でQAエンジニアの方々と交流するのは初めての体験でしたが、皆さんがプロダクト品質と真摯に向き合っている姿がとても印象的でした。
プロダクト品質を第一に考える人たちと語り合う時間は、普段の業務では得られない貴重な体験となりました。
また、テストプロセスという概念を実際のワークを通じて体験することで、これまで苦手意識を持っていた打鍵によるテストに対する見方が変わりました。
テストコード自体の考え方も重要ですが、プロダクト全体のデリバリを考えると、打鍵によるテストの重要性もあらためて認識できたと思います。
テストに関連する規模の大きなイベント自体の参加も初めてでしたが、イベント名のWACATEからも想像できるように、
初心者と若手の人は大歓迎という設計のイベントのため、興味を持った方は参加してみるのはいかがでしょうか？
Discussion