ごきげんよう、とのの（@tonono2587）です。
お久しぶりでございます。 元気です。
今回のテーマ：アジャイル開発におけるQAエンジニアの関わり方 参加したのでメモ
こちらに参加しました
自身が最近アジャイル開発チームのメンバーになったので
わたし向けだ！と思って参加しました。
聴講メモ
話の流れ
アジャイル開発とテスト
■前提として、「上手いテストをする」というのは「テストの活動をクリティカルパスにしないこと」
どゆこと？
- 「テスト」は品質マネジメントの一手段だから
- テストと、他の品質マネジメント手段との住み分けをしてスコープは明らかに
- テスト技術次第になるよ
- テスト設計、テスト戦略：テスト対象の確認をより少ない量で確実に行う技術
- 開発ライフサイクル次第になるよ
- テストの成熟度を高めようとすればするほど開発の状況が前提条件になるから
■ソフトウェアテストの7つの原則 からみたとき
- 欠陥があることは示せるが…とか全数テストは不可能、とかはいつの時代でもアジャイルでもそうじゃなくても変わらない
- 「網羅して！」って言われたらちゃんと言い返せないとだめ
- 言い返す/説明する/納得してもらうためにモデリング能力とかが必要
- テストは状況（context）次第：開発トレンドとテストへの影響どんなのあるか
■テストは状況（context）次第：開発トレンドとテストへの影響
□オープンソース中心の開発
- 開発に合わせたテストツール
- 組み合わせの変更をテスト
- 自分で責任が取れるようテスト
□クラウド
- 本番環境でのテスト（コスト削減のため）
- 機能トグルを使ったテスト（フラグの切り替え）
- 性能や信頼性をモニタリング
□アジャイル
- 意識合わせしながらテスト
- リグレッションテストが主役
- メトリクスが変わる：フル機能じゃないけどリリースしちゃう。1回リリースしたら終わり、という開発はなくなる
- 継続的にメトリクスをとるほうが価値のあるテストになる
□マイクロサービスアーキテクチャ
- ユニット→サービス→E2E
- 結合点の保証方法をテスト
- 適応度関数で保証する
■そしたら、テストをどう変えるか
- QAがチームに内在するアプローチにする
→チーム自身が品質に対する判断をする - いまどきの品質リスク許容度合いにする
→すぐに修正/リリースできる欠陥は許容する
10分でリバートできます！とか、技術とあわせて - 逐次テストにする
→リリース直前のテスト量を減らすために早期から少しづつテストをする
”ログイン”など一部分だけ先につくってもらいテストするとか
反対は「ビッグバンテスト」
機能が揃ってからのほうが効率よく思えるが、それだとバグがいっぱい出たらリリースまで1ヶ月かかってしまう、とかになるので - 継続的品質改善をしていく
→リリースとは関係なく常にチーム全員が品質をよくしていく(メトリクスを変える)
■メトリクスについて
□開発規模と予想欠陥数
□テスト実行カバレッジ
欠陥対応状況とテスト合格率
- リスクを合意してテスト数を変える
- 機能がドロップすることがあるのでテスト数は可変する
- 重篤度で修正するか判断し、修正しない欠陥が多くなることがある
- 欠陥は複数のリリースをまたいで対処していく
DRE（欠陥除去率）
毎月の エンジニアが出した 欠陥の数
QAが出した欠陥の数
顧客から出された欠陥の数
→「顧客から出された欠陥の数」が下がっていってるか？
QAのアジャイル開発への貢献事例
※※※※※※※打つのめんどくなった；；；；；；
QAエンジニアに求めること
開発チームの一員として価値がある行動をしよう！
テストするだけじゃなく、品質がよくなることはコード以外なんでもやる
QAは鏡みたいなもの、お出かけ前に整ってるかみる的な
重症な場合は、やばい顔をそのまま写してあげないと
きれいだったらそれもちゃんとそういってあげる
QAだけが品質をよくするわけではない。チームみんなでやることを考えるリリースされる前に、ユーザーと同じ目線でプロダクトに最も触れているのは自分なんだ、と自負できるようにしよう
競合製品使う
上辺だけでなく、システム構造を理解する
ユーザーとしてリリースされたプロダクトを使うチームのみんなに、思っていることを言葉で伝えるように
仕様はどうなりますか？はやめよう
仕様はこうだと思っているけど、想定と違う 理由はこう という発言の仕方をする
どうだかわからないんだけど、の場合も意思を伝えるテストの"変えないでほしいこと"、”変わらないこと” →テストプロセス
プロセス自体は変わらない
変わらないからちゃんとやる。具体的にやることは、コンテキストによって変わるので変える- 技術者として、やらないといけないことを効率よくやる
- アジャイル開発でのQAでいちばん変わるのはコミュニケーションかも
■質問らへんのメモ
感想
- テストプロセス自体は変わらない。状況によって変わるところに対して技術でよくしてく
- 様子みてたせいか遠慮してたかも 特に「仕様どうなりますか？」って発言してたかも、前までそんなこと言ってなかったのに〜
- 前のほうがよっぽどアジャイルチームのQAぽい動きしてた気がしてきた、戻そとおもった
- アジャイル開発ってはやいことに意味があるから考え方で足りてないのはそのへんかもしれない
- どうテストプロセス踏むか的な考え方になってしまっていたかも？はやいことよりそっちが重くなってたかもしれない
- 考え方がちょっと変わった気がした
- 受け入れ要件を自分で書くのよさそう！すぐできそう
おつかれさまでした！
