アジャイル開発におけるQAエンジニアの関わり方/湯本剛氏【豆寄席】 聴講

https://mamezou.connpass.com/event/288071/

アジャイル開発のQAということで、インプロセスQAとしての役割が多いのかなと思いつつ、チーム外からどのようにアプローチをしていくか、開発チームにしてほしいことが何かを自分の中でまとめようと聞いていました。

湯本さんのQA歴史から始まりました。

最初はアジャイルって駄目ぽのような思いという意識を持っちゃうプロジェクトに入っていた話からです。(いろいろと大変なプロジェクトを担当されていたんですね。。。)

今回は、アジャイル開発という題材でしたが、別にアジャイル開発じゃなくても通じるのではないかという思いでした。

一貫して「テスト活動をクリティカルパスにしない」ということ

テスト7原則を基準に以下の事を話していました。

テストは品質マネジメントの一手段

・品質マネジメント手段とのすみわけとしてスコープを明らかにする

・関係する人たちへの迅速、正しい情報提供

テスト技術次第

・テスト対象の確認を少ない量で確実に行う

・作業スピードをあげる技術

・アウトプットを再利用する技術(構成管理、メンテナンス)

開発ライフサイクル次第

・テストの成熟度を高めようとするほど、開発状況が前提条件となる

→インテグレーション戦略

早期テスト

まぁ、当たり前

欠陥の偏在

テストは状況次第

条件次第ではなく状況次第。オープンソースだったり、いろんなプロダクトの状況だったりするのでどのようなテストをするのかを考えよってこと。

今後のテストをどう考えるか

テストをどう考えるか

開発とQAが別チーム → QAがチーム内に内在するアプローチ

トラでぃっしょなるな品質リスク　→　今どきの品質リスク(許容度合)

ビッグバンテスト→逐次テスト(リリース直前のテスト量を減らす)

品質保証的判断→継続的品質改善

うーん、やはりインプロセスQAが中心ですか。。。

チーム外部からこのインプロセスQAに対してアクションしていく方法も聞いてみたかった。

メトリクスを変える

開発規模と予想欠陥数　　→　　欠陥対応状況とテスト合格率

テスト実行カバレッジ

欠陥除去率 (DRE)を考えてリリース計画を考える。

メトリクスがあまりとれていないし、とっているメトリクスっもまだうまく使えていないしで、QAコーチとかの立ち位置で参考にしていこうかと思ったしだい。

QA としてテストを中心にチームにやくにたつために

・スクラムチームの一員になる

・チケットの運用を変えていく

・テスト環境の割り振りをリード

・できるところからテスト

・テスト実行のスピードを高速にする

→プランニングとリファインメント

→ストーリーチケットの受け入れ基準

→開発順序の期待 (リスクが高いところ)

デイリー朝会

→テスト設計、テスト実施での疑問・課題

毎週1on1

テスト実行のスピードアップで自動化APIを用意したことなど。

最後にQAとしてチームに役立つようにするためにはという教訓みたいなもの

開発チームの一員として価値がある行動

・テストするだけではなく品質がよくなること(プロダクトコード以外)

・チームみんなでやること

リリースされる前にプロダクトに最も触れている人

・プロダクトについて詳しくなること

→競合製品を使う

→システム構造を理解する

(品質について)考えたことをチームに話す

品質を考えた仕様としてどうであるかを話す、理由付きで

→リアクティブな動きはよくない

重篤な問題を見つける、リスクをさげるテストを考える