MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST15東京(3) 「アジャイル開発成功の鍵となるQA・テストエンジニアを目指そう」

 2015/2/20(金)~21(土)に開催されたソフトウェアテストシンポジウム'15東京(JaSST'15 Tokyo)で私が参加したセッションの内容を数回に分けて書いています。
(※おことわり(再掲):チュートリアルは有料セッションですのでblogに書けません。予めご了承下さい。)

 前回は、セッションB2 テスト開発方法論「解決!テストアーキテクチャ設計」について書きました。

 今回は、セッションF4 「アジャイル開発成功の鍵となるQA・テストエンジニアを目指そう」です。

セッションF4 「アジャイル開発成功の鍵となるQA・テストエンジニアを目指そう」

(1)お題 その1

 「今度からはアジャイル開発していくから」と言われ、

  • テストはどうするのか
  • プロセスはどうなるのか
  • 品質保証はどうなるのか?

 懸念、課題を付箋に書いて下さい(所要時間2分)。
→書いた後、付箋でポジショニングマップ(横軸:個人⇔組織、縦軸:テストプロセス⇔テスト技法(テスト手法))を作って下さい。

(1-1)私が書いたこと

  1. 体制はどう変えていくか?
  2. テストのライフサイクルは、ウォータフォール開発とどう違うのか?

 チームでアジャイル開発を進めることを想像したとき、ポジショニングマップで言うと、プロセス寄りかつ組織的な面で不安だなと思いました。

(1-2)同じグループ内での傾向

 ポジショニングマップの傾向は、プロセス寄りかつ組織的な面な事が多い印象がありました。推測ですが、他のメンバーがアジャイル開発がどのようなイメージなのか、認識がずれることに対し不安を抱えているのではないかと思います。

(2)お題 その2

 「スクラムで、複数イテレーションを経てシステムテストを実施する現場とする。各イテレーションでスプリントバックログが増大したとき、システムテストが開始できない、もしくは出荷に間に合わないリスクがある。設計チーム内の朝会などに参入するにはどうすればよいか?」
→上記設問は、ニュアンスとして書いた。

(2-1)私が書いたこと

 開発側で発生した問題(バグやリスク)をQA側で情報を掴み、問題(バグやリスク)を検出するためのテストを考えることがQA側から開発側へのフィードバックの1つと考えていました。

(2-2)同じグループ内での傾向

  • テストのスコープ決め
  • システム全体の把握とI/Fの整理
  • バグのモニタリング

 大まかに、上記3点に集約されました。特に、バグのモニタリングすることが重要との認識がありました。

(3)お題 その3

「QAから設計に対し、何をフィードバックすることができるか?」

(3-1)私が書いたこと

  • 仕様について不明なところを質問すること。
  • QAチームが感じたリスクをPOやPMに報告。

(3-2)同じグループ内での傾向

 「欠陥を見つけること」と「チーム文化の土壌作り」に集約されました。QAが「欠陥を見つけること」で設計者との信頼関係を築き、「チーム文化の土壌作り」が促進されると思いました。

所感

 本セッションを通じ、開発組織での役割によって、「できること」/「できないこと」や「得意なこと」/「不得意なこと」があり、各々が補完できると開発組織としてのチーム力が発揮できると思う。まずは、自分が「誰に対し、何ができるか」を模索するところから進めていこうと思う。