ウイングアーク１ｓｔが取り組んでいるアジャイル開発のQA
ウイングアーク１ｓｔのアドベントカレンダーブログ2019を始めます！
本日（2019/12/2）は第一回目。担当は伊藤潤平（ @sadonosake）です。よろしくお願いします。
では、早速張り切って行きましょう！
初日はウイングアーク１ｓｔが取り組んでいるアジャイル開発のQAについて語りたいと思います。
段階的な品質の積み上げ
以前、自己紹介を兼ねて自分の取り組みをブログで紹介しました。
このブログで、アジャイル開発の中でQAの取り組みをトピックにしたので、ここで詳細を説明したいと思います。
因みにSQiP研究会でこの取り組みを研究し、ソフトウェア品質シンポジウム 2019でも発表しているので、論文やプレゼン資料を参考にするとわかりやすいかもしれません。（上の写真はプレゼン資料の自己紹介スライドに「趣味：日本酒（新潟限定）」にしているので、一部ご紹介！）
アジャイル開発で品質保証？
これはもう永遠のテーマだと思っています。たぶん苦労されている人も多いのではないかと予想します。実際にSQiP研究会でも参加された研究員の方の苦労話で盛り上がりました。
アジャイルマニフェストを見ると「動くソフトウェア」が重要な尺度とされています。他の文献を見てもアジャイル開発やアジャイルテストに関する資料は世の中にたくさんありますが、品質保証に対する定義は見つかりません。
「そもそもアジャイル開発において品質保証の定義って必要？」
この問に対して、少なくともウイングアーク１ｓｔにおいてはYESになります。
ウイングアーク１ｓｔでは製販一体となってパッケージソフトウェアを開発及び販売をしています。開発したパッケージソフトウェアはOEMやパートナー販売も行っているため、自社で定めた品質基準を作り、いつでも第三者に対して提出可能な品質ドキュメントを作成しています。
つまり開発プロジェクトがウォーターフォールでもアジャイルでも品質基準をクリアする必要があるため、ある程度の品質保証の定義が必要になります。
スクラムにおける理想とするQAフレームワーク
ウイングアーク１ｓｔの製品でSPAという製品があります。
この製品の開発プロジェクトはスクラムでやっていました（現在はスクラムではないですがアジャイル開発を継続しています）
5年前はSPA製品開発はウォーターフォールだったのですが、開発プロセスはスクラムに変えた経緯があります。その辺の話は以下の発表資料にて詳しく書いてあります。
上の資料にある通り、スプリント毎にSETメンバーがクオリティーゲートを設置して単体テストや結合テストがDoneしていることを確認します。QAはというと、テスト実施したエビデンスを基にスプリント毎に品質データを提示できる状態にしていました。
ただし、そこには2点ほど、どうしてもスプリント毎に品質データを提示できない問題がありました。
- 例えばバックエンドのエンジン開発は実装とテストに時間をかけて徐々に作り上げていくものですが、スプリント毎に品質データを提示できる状態にすることが難しい。
- 非機能面のパフォーマンス検証は長時間ロードテストするパターンもあり、スプリントの時間軸で品質データを提示することが難しい。
スクラムの定義に沿った場合のQAをするためには、スプリント毎に品質データを提示することが理想です。
ただし、上記のような問題があり、半分諦めていました。
そこでスクラムの定義に沿った場合のQAという縛りを外し、現実に沿ったQAプロセスのフレームワークを作ってみました。
実施しているQAフレームワーク
開発チームはスクラムなので、スプリント単位でプロジェクトを進行しますが、QAは「フェーズ」という単位を用いてプロジェクトを進めます。
このフェーズという単位は品質が確保されて製品がリリース可能状態である単位という定義付けをしました。
例えば機能Aを実装＆テストして、リリース可能である品質の判断と品質データの提示が出来るまでの期間が3スプリントだった場合、その期間を1つのフェーズと位置付けます。
SPAはパッケージ製品なので実際に機能Aを開発しただけの状態で製品をリリースすることはありませんが、開発プロジェクト内ではフェーズという単位で製品が「リリース可能状態」である、つまり「いつでもリリースできる状態」と考えるとわかりやすいです。
なおフェーズは1つの機能に絞るわけではなく、複数機能でも、もしくは機能ではなく非機能等の時間のかかる検証期間の単位でも良いことにしています。このフェーズをDoneすることを繰り返す（Increment）ことにより品質が徐々に確保されて、最終的には計画した通りの目標品質を達成するようなイメージです。
戦略的テスト計画の作成
アジャイル開発は計画が頻繁に変化するので、テスト計画は戦略的でなければいけません。
ウイングアーク１ｓｔの開発プロジェクトは全ての製品でマスターテストプラン（以下、MTP）を作成します。このMTPではテストプロジェクトにおける色々な必要事項を記載しますが、特に重要なのはプロダクトを最終リリースする際の品質目標を定義します。品質目標はISO25000シリーズの品質特性を指標として利用します。品質目標を品質特性別に定義して、その目標に対してどのようなテストを実施したら目標が満たされるかをテストタイプで定義します。つまり定義したテストタイプを全て実施すれば目標が達成され、最終的にリリースが可能になるという仕組みです。
MTPの次はフェーズ毎の計画であるフェーズテストプラン（以下、PTP）を作成します。このPTPでは主にフェーズ内で実施するテストタイプを定義し、実装される機能に対してどのテストタイプを実施すればフェーズがクリアできるかの計画を立てます。
つまりこのPTPはスクラムで運用しているプロダクトバックログ（以下、PBL）と同じようなものでフェーズのバックログのイメージです。単一もしくは複数のプロダクトバックログアイテム（以下、PBI）が1つのフェーズにあり、PBIのDoneと、PBIに対するテストタイプ実施のDoneでフェーズをクリアし、フェーズ内で確保した品質データを提示するための計画書になります。
品質ゲート設置と品質の積み上げ
各フェーズには品質ゲートが設置され、「ピックアップテスト」と言うサンプリング検証が実施されます。
※フェーズ内で実施されたそれぞれのテストタイプからテストケースをピックアップするので「ピックアップテスト」と呼びます。
ピックアップテストを実施して問題がなければ、フェーズ内の実施したテストの定性分析や定量分析を行い、他にリスクがないかを確認して、最終的に問題がなければ品質ゲート通過とします。
因みに「品質ゲート」と連呼して書いてますが、この「品質ゲート」という言葉はそのうち違う用語に変える予定でいます。なぜならば「品質ゲート」という言葉は厳しいイメージがあるからです。
もし品質ゲートを通過できない場合は開発チームにモジュールをお返しし、「もっとしっかりした品質のモジュール持ってこい」みたいなイメージあります。実際ウォーターフォール開発はそうかもしれませんが、アジャイル開発ではそれはもうレガシーです。
もしピックアップテストでバグが出る場合、そしてリリースする際のリスクが見つかった場合は、もちろんチーム全員でコミュニケーションです。そして落としどころを一緒に考えます。最小限の修正で良いか、修正せずに回避策を提示するかを決めてリリースします。
ですので品質ゲートを通らないからと言って、リリースできないと勘違いすることは一番の不幸となります。
話を戻して、この品質ゲートを各フェーズに設置し、これを繰り返すことにより、プロダクト自体の品質は徐々に積み上がり、最終的にMTPで計画した総合的な品質目標が達成できる。という仕組みです。
実際の各プロジェクトにおいて、このフレームワークを実施した結果は、担当するメンバーにブログに書いてもらうことにしよう！
おまけ
「戦略的テスト計画の作成」で、「アジャイル開発は計画が頻繁に変化する」と書いたのでその説明を！
PBLは優先順位でPBIが積まれています。上部に位置するPBIは優先順位が高く、下部に位置するPBIは優先順位が低いです。そしてPBIの内容は優先順位が高いものは明確であり、直近で作業しているため、そこまで計画が変化することはありません。ただ、優先順位が低いPBIの場合は、内容は曖昧性があり、しょっちゅう並び替えられます。
ということはPTPも同じで直近のフェーズはテスト内容が明確ですが、後半のフェーズはPBIに曖昧性があるため、テスト計画も曖昧です。
MTPの内容は戦略性のある品質目標を定義し、PTPは直近フェーズは明確な計画にする必要がありますが、後半のフェーズは曖昧で良いです。ただしMTPに書かれる戦略がブレるとプロジェクトは厳しいものになると思うので戦略はしっかりと立てると良いでしょう。
では！
