本記事について
JaSST'21 Tokyo (JaSSTソフトウェアテストシンポジウム-JaSST'21 Tokyo)
A9）招待講演
「パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術」
鷲崎 弘宜 （早稲田大学 / NII / システム情報 / エクスモーション）
の聴講メモです。
講演メモ部分は講演資料と併せて読む前提でまとめています。講演資料が公開されましたら、ぜひ読んでみてください。
講演メモ
従来型の開発では顧客と開発者の距離感が離れる時期（特に開発の中盤）がある。また、開発開始から終了までの時間が長い。これらにより顧客と開発者の思い（価値観）がずれやすくなる。
一方でアジャイルは頻繁に打ち合わせ・リリースをすることで、顧客と開発者の距離がさほど離れず、価値観のずれが少なくて済む。
従来の品質保証は特定の段階（ゲート）でゲートキーパーとして機能していた。ある程度開発が完了した後に品質を確認する。
アジャイルではある程度動くソフトウェアを対象に確認する。
問題と解決を抽象化してまとめたものが「パターン」といえる。
品質とは行動ではなく習慣である。
テストをすればよい、レビューをすればよい、という行動ではなく、習慣である。
何でもかんでも自動化しない。めったにやらないこと、自動化するのが難しいこと（一貫性がないとか）はしない。繰り返すこと、人手でやるとミスしやすいこと、面倒なことを自動化する。
チェックリストは肥大化して形骸化しやすい。本当に必要な品質に絞ってかつ具体的（期待値）にリストする。
刺激源はユーザー・他システム・自然など。
刺激源「端末の利用者」
刺激「報告をWebで要求」
応答「報告を受理」
「1秒以内」とピンポイントに示すより、着陸ゾーンのように幅を持たせることをお勧めする。
C4モデルはコンテキスト(Context)・コンテナ(Container)・コンポーネント(Component)・コード(Code)で表現する。ハイレベルかつ具体的に記述できる。
定義ファイル動的読み込みは「変更を停止なしでの反映」に対してポジティブだが、処理スループットにはネガティブになる、といったトレードオフを表現できる。
Q & A
Q.
「品質スプリント」はとてもよさそうだと思いましたが、「テストフェーズと何が違うの？」と聞かれると答えられる自信がありません。混乱しない回答があればご教示いただきたいです。
A.
複数のスプリントによってフェーズが構成される。そのフェーズが品質に注目しているものを品質スプリントと呼ぶ。スプリントベースなのが従来との違いになる。
Q.
QAを全員で考えるとなると、開発も全員で考える、企画も全員で考える、スペシャリスト不在の烏合の衆になる恐れがあるとおもうのですが、この点に関してはどうお考えでしょうか？
A.
それぞれのスペシャリティが活かせる環境になるとなおよい。開発者がテスターと同じことをするのではなく、設計や実装でテストしやすさを心がける。テスター側としても同様となる。
それぞれの立場で品質を見て、スペシャリティを活かしながらフィーチャーを作り込む。
Q.
品質の中に機能性などもありますが、品質バックログの品質は、どちらかというと非機能に関する品質を意味するのでしょうか？
A.
ユーザーストーリーに織り込まれる品質であったり、全体に対する品質を指す。
開発者にしかわからないような品質（例えば保守性）なども品質バックログに含まれる。
Q.
QAを嫌がるような開発者がいますが、そのような人とワンチームを築く上でのコミュニケーションポイントがあれば教えてください。
A.
QAに早い段階で関わる。理想的には開発者とQAの協業をする。QAとしても成果物を単に見るのではなく、その途中段階から関わる。
開発者にとってQAが価値を出す妨げの存在ではなく、高め合う存在である、という協調関係を作る。
最初からQAが全チームに入るのは難しければ、QAが各チームをローテーションするというのもありかもしれない。
Q.
品質シナリオを抽出する方法は何か考えられてますでしょうか。着目しているシナリオに対して、品質特性をガイドワードとして発想するような形でしょうか。
A.
その通り。性能・可用性・典型的な入力などを押さえる。
Q.
一度チェックリストの項目に載ると、捨てるのは難しいです。例えば過去のバグ事例に基づく場合はなおさらです（それがめったに出ないとしても）。既存も含めて絞り込むためにどうすべきでしょうか？
A.
複雑さ（エントロピー）が増大するのは避けられない。リストの項目数の最大値（例えば20個）を決めておくのが一つの手だ。もしくはリストが膨れすぎたらゼロから再構築する。
Q.
「品質チェックリスト」問題が発生するたびに項目が増えがちなのですが、適切に項目を絞るためにはどうすればよいでしょうか？ 本当に削って大丈夫か、と自問自答してしまい、増やすとなかなか削ることができません。
A.
チェックリストの項目が何のためにあるのかをトレースできるようにしておく。数が決まっていると本当に何を残すべきかと見直すきっかけになる。
Q.
品質ストーリーはシステム全体を対象とするので、クローズするタイミングがなさそうです。各スプリントに同じ品質ストーリーが入って、毎回クローズするのでしょうか。
A.
定期的に出ることもあるし、品質チェックリストの項目とすることもある。
Q.
従来型のQAから徐々にステップアップしていくことを考えると、どのあたりから取り組んでいくのがおすすめでしょうか
A.
見える化・自動化・チームとして構成する。
繰り返しの中で扱えるように自動化する。
Q.
品質チェックリストのチェックは自動化しないのでしょうか？
A.
客観的かつ機械的に確認できることは早期に自動化したほうが良い。
全て自動化するということではなく、そうする意味があるところを自動化する。
Q.
1チームで進めると、経験の浅いQA担当者等は、第三者視点が損なわれたり、開発者の意見に流されたりする可能性が高くなるように思います。どのような対策が考えられますか？
A.
POと協業して顧客にとって何が重要かを意識合わせする。
組織内QAコミュニティを作ることも重要といえる。
Q.
Dashboard と Radiator の両パターンの境界線が難しいです。Dashboard を構築するとおのずと Radiator が達成されるのではないでしょうか？
A.
Dashboard もほっておくと肥大化していく。そうすると何を見て意思決定すべきかが見えなくなる。複雑化した Dashboard をサマライズした Radiator を作ることになる。
Q.
ハードチームとソフトチームは一緒にアジャイル開発をできるのでしょうか？
A.
工夫すればできる。ハード含めたシステム全体をアジャイルで取り組むという事例もある。
Q.
品質全体を考えるときなど、スプリントでは収まらないこともあると思います。そのようなタスクはどのように扱うべきでしょうか？例えば品質チェックリストの初版作成など。
A.
スプリント0と称されるようなベースを整える期間を設ける。
もしくは収まらないということは粒度や大きさが設定できていないのではないか？、ということを見直す。例えば、品質チェックリストが最初から巨大なものである必要があるのか？
Q.
QAの作業はチーム内で分散できると思いますが、逆に開発作業をQA出身のメンバーへ分散させることは難しいため、負荷が開発者に偏ってしまう問題があると思いますが、どのような解決策が考えられますでしょうか？
A.
テストの自動化のようなQAと開発者の接点において、QAも積極的にタスクを引き受ける。
