「はじめに」の前に
・JSTQBとは？
ソフトウェアテストの資格のひとつ。
https://jstqb.jp/committee.html
・アジャイルテスト担当者とは？
JSTQBは専門分野ごとにカテゴライズされております。
「JSTQB FL(Foundation Level) アジャイルテスト担当者」もその中の一つです。
https://jstqb.jp/syllabus.html
・「JSTQB FL アジャイルテスト担当者」のシラバスはこちら
https://jstqb.jp/syllabus.html#syllabus_foundation_extension
・君は誰？
QA組織のマネージメントをやっています。
はじめに
スクラム開発に組み込まれたQAエンジニアが「スクラムのなかでQAとしてどう振る舞うのが良いのか」と、戸惑っている姿をたびたび目にします。スクラムの中にQAフェーズ(設計/実行の期間)を設けてみたりするものの(俗に言う(？)なんちゃってスクラム(=ちっちゃいウォーターフォール))、これでいいのかなと自問自答し、色々試行錯誤が続いている印象です。
試行錯誤は良いことですが、スクラムもそこそこ歴史がありますし、まずは先人の知恵を借りようじゃないか。ということで、JSTQBのアジャイルテスト担当者のシラバスを読んでみることにしました。内容を自分なりに咀嚼した上で、「アジャイル開発で、QAは何をすればよいのか？」を考えてみたいと思います。
なおタイトルにもあるように、当記事は読書感想文 であり、シラバスのサマリーではありません。あしからず。
1章 アジャイルソフトウェア開発の基本
ウォーターフォールの時代は「入念な計画」が重要視されていました。
しかし、昨今は市場(=ユーザの要望)の変化が激しい時代になってしまったため、長期にわたる計画的な開発は、効果的ではないシーンが増えてきています。なるべく早くリリースし、ユーザの反応を見て、修正をなるべく早く行うことが重要です(=変化とスピードが大切)。
アジャイル開発は、「ユーザが求めているもの」を「なるべく素早くリリースする」ための考え方といえます。
2章 アジャイルテストの基本的な原則、プラクティスおよびプロセス
アジャイルテストにおいては、(ユーザとプロジェクトにとって利益となる)仕様の変化は歓迎しなければなりません。かつ、どのような状況でも、なるべく早くテストを終わらせる必要があります(「動くビルド」を素早く提供する)。
そのためのキーワードが「シフトレフト」「探索的テスト」「テスト自動化」になります。
ちなみに、これまでのQA組織は、仕様や計画の変化を避けたがる傾向にありますね。「仕様変更」と聞いて喜ぶQAを見たことがありません。しかし、このマインドセットはアジャイル開発では不利に働く可能性が高いです。変化を歓迎出来なければ、アジャイルQAとして成果を出すのは難しいかもしれません。
準備をどれだけ減らせるか。「テスト設計」というものを考え直す
これまでのテストとの大きな違いは「テスト設計」の扱いにあるかなと思います。ウォーターフォールではテスト設計の品質がプロダクトの品質に大きく関連していました。また、テスト設計に費やされる時間は、テスト工数全体の50%近くになるプロジェクトも見かけます。
しかし、一つ認識しておくべきことがあります。それは「テスト設計している時間は、サービスの品質向上に貢献していない」という点です。サービスの品質が向上するのは「テスト設計で作成した成果物をもとに、サービスを触った時」です。テスト設計は、あくまで準備なのです。
料理でいえば、テスト設計はレシピを考えている時間です。レシピをどれだけ考えても、味はしませんし腹は膨れません。
つまり、「テスト設計の時間をなるべく減らす。しかし、充分にテスト設計した状態と変わらない内容でテスト実行を行う」が理想的な状態といえるでしょう。
シフトレフト
テスト設計をするな！というわけではありません。ただ、仮にテスト設計するのであれば、その内容は開発者にも共有するべきです。コーディングの段階でバグを潰すことができるでしょう。QAエンジニアは「品質のコーチ」としての役割も求められます。
探索的テスト
入念なテスト設計をせずとも、テスト実行の質を落とさない。そのために、探索的テストのスキルを向上させる必要があります。なお、本ドキュメントでは特に触れませんが、シラバスの第3章に探索的テストのノウハウが記されています。
テスト自動化
細かい改修を重ねるアジャイル開発では、回帰テストは大切です。追加した機能や、改修した機能が、既存機能に影響を与えていないことを確認してこそ、安心してリリースが出来ます。
回帰テストは、システムの機能が増えるほテストケースの項目数が膨らんでいきます。また、リリースの頻度に比例して工数が増えていきます。品質を担保し、回帰テストの時間と工数を減らし、テスト担当者が探索的テストや開発者との対話の時間を確保するために必要なことが、「テスト自動化」です。
3章 アジャイルテストの方法、技法、およびツール
アジャイル開発で大切なことは、安定したビルド(品質が一定以上のビルド)を、継続的に迅速にデリバリーすることです。
そのためには、各セクション間(エンジニアとかQAとかPMとか)で、対話、協調、合意をベースにして、業務を進めていくことが求められます。適切なコミュニケーションによって業務を効率化し、それと同時に、可視化により不要な(というか過剰な)コミュニケーション(ドキュメンテーション含む)を減らすことを目指しましょう。
QAに求められること
QAのタスクをブラックボックス化してはなりません。ツールを活用して、テストの観点、見積もり、テスト範囲、テスト結果、リスクを誰もが見えるようにしておくとよさそうです。
また、アジャイル開発のQAは、テストレベルによって求められる役割が異なります。具体的な一例は下記。
・対話やレビューを通して、関係者の品質意識を高めること
・開発者が作成するユニットテストのテスト観点の共有
・E2Eテストの自動化
・マニュアルテスト
上記のプロセスで成果を出すためには、コミュニケーションスキル(ペアワーク等の技法含む)、自動テストスキル、マニュアルテストスキル、開発プロセスへの理解、が必要となるでしょう。
おわりに
私はアジャイル開発ではQAというロールに、幅広いスキル・素養が求められてるな、という感想を持ちました。
それは「難しい」という側面もあります。これまでのように「ドメイン知識が最低限あれば良し」という間口の広さは失われるかもしれません。一方で「いろんな長所を活かせる」とも言えると思います。開発が得意なら自動テストに寄せれば良いし、コミュニケーションを活かしたいなら対話で価値を出すこともできるでしょうし、マニュアルテストが得意なら爆速でハイクオリティなテストを提供することで価値が出せるかもしれません。
QAというお仕事は、システムと人間という複雑で曖昧なものと向き合う、とても奥が深いお仕事だと思うのでした。