この記事はレコチョク Advent Calendar 2021の23日目の記事です。
自己紹介
株式会社レコチョクでQAを担当している清崎（きよさき）と申します。
社内では独立したQAチームが組織横断として存在しており、自社サービス、toB向け、toC向けと展開しているサービスに対して、ビジネスチーム/開発チームとQAチームが協力しながらテストを実施しております。
はじめに
とあるアプリのスクラム開発へQAとして参画したとき、どのようなテストを実施したのかその経験を紹介いたします。
本投稿ではGherkin記法を中心に説明しており、自動テストに関する部分は割愛してます。
状況
自身はスクラム開発やアジャイルQAとしての経験もなく、どのようなテストを行えばいいのか正直ゼロから考えるという状況。
今まで経験した伝統的なプロジェクト開発手法とは異なり未知の部分も多く、短期間で品質保証をどう取りかかればいいか検討することになった。
これまでのQAはいわゆる開発後半のテストフェーズで実施を行っており、開発がアジャイルであっても後半にQAが入るということしか経験がない。
プロセス
- 1スプリント1週間のスクラム開発
- POが作成したプロダクトバックログをもとに、開発チームがスプリント期間内の計画を立てスプリントバックログを作成する QAは開発と並走してテストシナリオを作成してテストを実行する
- 各スプリントのスプリントレビューで、実際の動くアプリを触って受入基準を満たしているか確認する
取りかかる前に整理したこと
プロダクトバックログの内容は理解したが、どう設計して、いつテストすればいい？
1. どう設計する？
プロダクトバックログの内容をもとに、システムの振る舞いや期待値を予測してテストの設計を実施したいため、ビヘイビア駆動開発 (BDD)の考え方を取り入れることにしました。
参考にしたのは「ISTQBシラバス アジャイルテスト担当者」のP.28の「ビヘイビア駆動開発」です。
2. いつテストする？
開発と同タイミングでQAも動かないとスクラムの意味がないため、コーディングと同時にテスト設計を実施して、スプリント内でテスト実行を取り組めるようプロセスを整理。
テスト設計について
テスト設計は「Gherkin記法」を採用
Gherkin記法とはCucumberやTurnipで採用されているテスト記述言語フォーマットの1つで「こういう状態のとき、こういう動作を行えば、こうなることが期待される」という形式で記述していくものであり、構文がとにかくシンプルで平易な書き方になるので、技術者以外でも理解しやすくコミュニケーションが取りやすくなります。
Gherkin Steps：
- As：〜として
- Given：前提条件
- When：どの様な操作や入力
- Then：操作や入力の後に期待すべき結果は
- And：かつ
- But：しかし
Gherkinの書式：
Feature：<some terse yet descriptive test of what is desired>
As a <role>
I want <feature>
So that <business value>
Scenario：<some determinable business situation>
Given <some precondition>
And <some other precondition>
When <some action by actor>
And <some other action>
Then <some testable outcome is achieved>
And <something else we can check happens too>
参考：テスト駆動開発(著者Kent Beck 著／和田 卓人 訳)
例）次に例を示します。
-
満足条件
- 再生プレイヤーにて再生中にシャッフルボタンを押下した際、再生中の楽曲を再生リストの1曲目としてリストが生成される
- 再度シャッフルボタンを押下すると元に戻る
Feature：○○音楽プレイヤー(シャッフル再生)
Scenario Outline：シャッフル再生
AS ○○音楽プレイヤーのプレイリスト利用者として
GIVEN 3曲以上のプレイリストがあり、リスト２曲目を再生中
AND 再生中にシャッフルボタンを押下して＜ボタンの状態＞にする
WHEN 再生リストをタップして、リストの状態を確認する
THEN 再生中の楽曲が＜再生リスト位置＞にある
Examples:
|ボタンの状態 |再生リスト位置|
|活性(ON) | １曲目|
|非活性(OFF) | 2曲目|
例ではScenario Outlineという複数のパターンをまとめる方法になっており、入力データと期待される出力データを表形式で指定できます。
同じ動作の異なる値を繰り返しテストしたい場合に有効です。
カッコ＜＞でかこまれている単語は可変データのプレースホルダで、テーブルの期待値と結果を比較します。
1行目にはScenario Outlineの見出しが含まれ、その下からはデータ行で行単位で組み合わせパターンを表します。
この例ではGIVENステップの＜ボタンの状態＞変数は「再生中にシャッフルボタンを押下して＜活性(ON)＞にする」が割り当てられ、THENステップの期待すべき結果＜再生リスト位置＞は「再生中の楽曲が＜１曲目＞にある」という値が割り当てられます。
「プレイリストが３曲だった場合に１曲目と３曲目がシャッフルされたことをどうやって確認するのか？」という部分をツッコミたくなるのがQAですが、毎回期待値がランダムであり何をもってOKかNGか出しにくいことや、シナリオに複数のことを詰め込みたくないので別で確認したほうが良いという判断しました。
まとめ
テスト設計で気をつけた点
- いろんな観点を入れすぎず1つのことに着目してシンプルにまとめ上げる。
- 複数のシナリオをまたがないと実行できないようにすると後で使えなくなるので、各シナリオは独立して細かく実行できるように注意する。
よかった点
- 受入基準をパスすることを優先に進めたため、短いスプリントでテスト設計と実行までは回すことはできた。
- 前提条件からインプット/アウトプットを整理するため、仕様の整理や認識を合わせることができ曖昧さや抜け漏れが整理できるという効果を感じられた。
- シナリオで達成したいことに目的を1つに絞るようになるので、前提条件の考慮漏れや複数の前提条件に分けられるなど、設計時点で早めに気付くことができた。
- 必要なテストデータを整理することになるので、後続の作業を予測しながら進めることできる。
今後の改善点
短いスプリントでテスト設計と実行を行えた一方で、毎回余裕がなく一週間ギリギリであった。
- 先回りしてプロダクトバックログを確認してキャッチアップを早くする。
- 不明点があれば早めにPOへ確認する。
明日の レコチョク Advent Calendar 2021は24日目「データ分析未経験の新卒エンジニアがレコメンド機能を実装した話」です。お楽しみに！
参考ドキュメント
この記事はレコチョクのエンジニアブログの記事を転載したものとなります。