こんにちは。freee申告でQAエンジニアをしている金子です。
freee QA Advent Calendar2023 の4日目です。
freeeには謎解き部があり、謎解き公演に一緒に行ったり、社内イベント用に謎解き制作を行なったりしています。 この記事は、普段はWebサービスに対してfreeeのQAプロセスを回している人が、謎解き制作に対してfreeeのQAプロセスを試したらどうなるのかというネタ投稿となっております。 もしかしたらfreeeのQAプロセスを他業種に活かすときの参考になるかもしれません。
Abstract
近年、謎解きの人気が伸びており、謎の需要が高まっている。しかし謎の品質を保証するための確立された手法は存在しないのが現状である。本稿では、既にプロダクト開発において一定の効果を発揮しているfreeeQAプロセスを謎解き制作に用いたときの品質改善効果について検証した。その結果、謎の品質が向上することが確認できた。また特定の条件下で謎解き制作の速度を高める効果も確認できた。
はじめに
謎解きとは
謎解きとは、
言葉遊びを用いたクイズの一つ。いわゆる「ひらめき問題」の総称。（Wikipedia「謎」より一部抜粋）
である。
近年、謎解きの人気が伸びてきており、謎の需要が高まってきている。
謎の品質
謎解きにおいて謎が破綻していると謎解き体験の著しい損壊に繋がってしまう。 下は破綻した問題である。
この問題では、きつねを狐やFoxに読み替えても答えを満たさず破綻している。 謎解きでは絶対に解けない問題はもちろん、意図しない別解なども存在してはならない。
この謎は「たぬき」から「た抜き」と考え、答えが「かき」と出るので成立している。また例えばたぬきの英語「Racoon dog」などで解けないようになっている。
その他、クオリティという言葉で難易度や美しさを指すこともあるが、あくまでここでいう品質とは実装が破綻していないことを指すこととする。 よって謎の品質とは「解が制作者の想定したものに定まり、実装が破綻していないこと」と定義する。
謎解き界のテストの現状
謎解き界において、謎の品質は全て制作後にテストプレイ等を行なうことで保証していることが多い。しかし制作中にQAすることはなく、最後にバグが見つかったときには最初から制作し直しになることも少なくない。また、品質の保証方法としても確立された手法が存在しないのが現状である。 今後、謎解き界でも破綻や別解をテストして品質を守ったり、早期発見による無駄な実装を削減する専門職が現れるだろう（希望）。
freeeQAのテストプロセスの適用
freeeのQAではバグ流出を防ぐことはもちろん、早期発見で無駄な実装を削減することも目的としている。このとき限られた時間と人員で最大限のテスト効果を発揮するために、危険なところから優先して潰すリスクベースドテストの手法を取っている。
これらを謎解き制作に適用することにより、実装の手戻りや別解・破綻を防げるのか実験を行なった。
開発情報キャッチ
解説
案件に対して初動で出遅れないためになるべく早く開発情報をキャッチする必要がある。今回は運良く制作者とQAが同一人物であったため遅れなしで開発情報をキャッチできた。なお、本来であれば制作者とQAが別人なので、制作者（または企画者）は制作することを開示し、QAは制作が行われそうか気にかけることが重要である。
適用結果
この記事に一枚謎を載せる開発情報を迅速にキャッチし、初動から対応することに繋がった。
開発内容の理解
解説
このステップは制作者が制作計画を書いた段階で行なう。制作計画の内容を理解するとともに考慮漏れや不安な箇所を指摘する。
製作計画
絵が入った一枚謎を制作する 文字列に対していらすとやの絵を文字に読み替えたものを足し、答えとして「金」が出力される謎を制作する。 具体的には、文字列と動物を足してワード「まいぞう」を導くようにする。その後、関連するものを選ばせる選択肢から「金」に確定させる。ダミーの選択肢も用意する。 ↑QA「いらすとやの絵の著作権は大丈夫ですか？」 ↑ 制作者「利用規定に則り制作しますmm」 ↑QA「答えが金である必要はありますか？」 ↑ 制作者「私が金子なので必須です」
適用結果
制作に入る前に法律面でのリスクを止めることができ、制作手戻りの可能性を減らすことに繋がった。
リスク洗い出し
解説
考慮漏れを未然に防ぐ、注力してテストする部分を明らかにするため、あらゆる観点・視点で不明点やリスクを洗い出す。プロダクトマネージャー、デザイナー、制作者に加え、必要に応じてビジネスチームやカスタマーサポートチームも招集する。
実施
- （こんなふざけた記事を書いていいのか）
slack確認 - OK
- そもそも問題が成立していないことはないか
- テストに追加する
- 言い換えたときに別解が存在しないか
- テストに追加する
- 逆から読んだときに別解が存在しないか
- テストに追加する
- ヒント・お問い合わせ対応は必要か？
- 問題は簡単なものにする。その他質問に対しては本記事コメント欄等を活用する。よって不要。
適用結果
謎の別解について考えていなかったパターンを捕捉することができた。また記事公開やサポート体制についても考慮できた。
テスト計画
解説
これまでの情報をもとに大まかなテスト計画を立案しチームに共有する。特に注力してテストするところを決めるとともに、テストすることだけでなくテストしないことを明確にする。
実施
[重要]文字列と絵から推測ワードとして「まいぞう」が導けて、選択肢のうち「金」が答えになることを確認する 謎の答えとして「金」以外にならないことを確認する 謎内の文字と絵について日本語と英語で意図しない解釈が存在しないことを確認する 謎内の文字と絵について日本語と英語以外の言語で意図しない解釈が存在しないことの確認は行わない
適用結果
基準要件かつテスト実行のクリティカルパスになる点を重要とし警戒することができた。 テスト対象範囲を明確にしてテスト実行数を大幅に削減できた。
テスト設計
解説
これまでの情報をもとにテストチャーターを作成する。テストチャーターとはテストの方向性を示すものでチェックリストではない点に注意する。テストチャーターを使うことで、リスクが多いところを重点的かつ自由度をもたせたテストにできる。 詳細設計：入力や条件（P-V）の組み合わせが複雑で設計が必要な場合にはチェックパターンを作成する。
設計（一部抜粋）
文字列と動物から推測ワードとして「まいぞう」が導けること 「まいぞう」から推測したときに答えが選択肢のうちの「金」となること 謎内の全ての文字と絵に対して日本語と英語の言い換えを全て挙げる→全組み合わせで想定しない答えにならないこと 区切り、逆読み、漢字、ひらがな、カタカナ、ローマ字等に注意する
適用結果
リスク洗い出しで出た観点も取り込み、リスクベースでテストする計画ができた。また自由度を持たせてテストできるので、自由度が高い謎解きと相性がよさそうに思える。
テスト実行
解説
これまで作成したテストケースに従ってテストしていく
実行
まずVer.1として制作者から提供された謎に対しテストを行なった。
文字列＋動物が“まいぞう”ではなく“しんぞう”となり推測されるワードは心となるのでNGである。修正を依頼した。 引き続きVer.2として制作者から提供された謎に対しテストを行なった。
文字列＋動物が“まいぞう”ではなく“まいわし”となり推測されるワードは魚となるのでNGである。修正を依頼した。急遽仕様が変わってワシをEagleと読むことで成立させるのかとも考えたが、単純に画像の差し替えミスだったらしい。 引き続きVer.3として制作者から提供された謎に対しテストを行なった。
文字列＋動物が“まいぞう”となり推測されるワードは金となるので最低要件は満たしている。ここからこの謎内の全ての文字と絵に対して日本語と英語の一般的な言い換えを挙げ、全組み合わせで想定しない答えにならないことをテストする。 “まい”をいまと読んで英語に変換、象を“elephant”と読んで解けないことを確認。それぞれの選択肢を別解釈したときに”まいぞう”から推測対象にならないことを確認。 全てのテストが完了したのでリリースOKとなった。
適用結果
普通は制作者やテストプレイヤーが正解目的でプレイした結果、偶然に別解が見つかることが多い。今回はNGパターンを作成し別解の考慮漏れが無いようにテストできた。
品質分析
解説
活動をふりかえり、PDCAサイクルを回す
振り返り
今回の開発では謎制作に入ってからの作り直しが多く見られた。制作者自身で解けることを確認したうえでテストに回すようにする。
まとめ
謎制作にfreeeのQAプロセスを適用することにより、謎の破綻を初期に防ぐことができた。また別解についてもランダムテストプレイより網羅的にパターンをテストできた。さらに記事公開やサポート体制についても事前に考慮することができた。以上のことから手戻りを減らすことができていると考えられる。 また、制作を振り返り次の制作に活かすサイクルを取り入れたことも、今までにない習慣なので大きな進歩だと考えられる。
よって謎制作のテスト手法にfreeeのQAプロセスを適用することは総合的に見て制作時間の短縮に繋がると言える。
最後に
明日は、freee人事労務のQAエンジニアのtin-san が「A novice to API testing」（意訳：初めてAPIテストやってみた）について記事を書いてくれます。 これからAPIテストを始める人、進め方に悩んでいる人はぜひ読んでみてください！ お楽しみに〜！
よい品質を〜
