MasaoApril's Library.

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

JaSST15東京(4) クロージングパネル「これからの時代、テストエンジニアとデベロッパとの幸せな関係」

JaSST Conference

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

　前回は、セッションF4 「アジャイル開発成功の鍵となるQA・テストエンジニアを目指そう」について書きました。

　今回は、クロージングパネル「これからの時代、テストエンジニアとデベロッパとの幸せな関係」です。

クロージングパネル「これからの時代、テストエンジニアとデベロッパとの幸せな関係」

(1)テストエンジニアとデベロッパとの幸せな関係はどう変わったか？

(1-1)平鍋氏

(1-1-1)「キャンディの話」

　2003年ユタ州にあるアジャイル宣言の場所で、テスターのワークショップ(アジャイルとテストのセッション)での話。
　開発者がテスターに質問しに来た。テスターが開発者からの質問に答えた後、テスターがキャンディを渡し、信頼関係を構築した。

(1-1-2)上着のシッパーの写真

　上着のシッパーの写真をV字モデルに例えると、開発の早い段階でジッパーを閉じると開発者とテスターが融合するような関係。つまり、テストの観点と開発の観点の融合。

(1-2)松木氏

(1-2-1)WebとmobileのTesting

　テストエンジニアのアドバンステクノロジとして、テスト自動化があった。

(1-2-2)過去
  • 品質保証の中にテストの役割
  • バグ票でコミュニケーション
(1-2-3)現在とこれから
(1-2-3-1)QA(Quality Assurance)とEngineering Productivityを繋ぐ役割
  • 効果的なテスト自動化
  • 開発生産性の向上
(1-2-3-2)探索的テスト

　バグを早く見つける。

(1-2-3-3)仮想化

　テストのターンアラウンドタイムを短縮。

(1-2-3-4)ペネテーションテスト

　オープンソースソフトウェアで存在する。

(1-2-3-5)エンジニアが使う環境、ツール
(1-2-4)DevQUT
(1-2-4-1)コンセプト
  • Developer/User/Tool ⇔ QA(Quality Assurance)
  • QAを中心にテストを選択する
  • Communitcatization(※松木氏の造語)

(1-3)八田氏

(1-3-1)バグが無い＋ゲームのおもしろさ
(1-3-2)取り組み その1

　社内、社外でゲーム仕様決めの時にミーティングへ積極的に参加する。

(1-3-3)取り組み その2

　過去バグ経験からの実装チェックリストを開発者と共有し、バグを潰す作業を減らすことにより、過去バグ未然防止な実装が可能になる。

(1-3-4)開発者と上手くコミュニケーションを取りながら、開発情報の共有
(1-3-5)ビジネス構造の違い
  • 工数で委託
  • 早い段階での関わり
  • しかし、ゲーム業界全体というわけでは無い
  • これまで、テストはバイトで一気にテストしたが、ノウハウの蓄積はないのはよくないと思ったので、開発者からQAとミーティング出席依頼が来るようになった

(1-4)Bolton氏

(1-4-1)開発者とテスターの信頼

　御礼の気持ち。

(1-4-2)定量化に関し、引っかかるところが...
  • 数字そのものが意味をなさない
  • 厳しい内容の話の対話を持つことの価値
(1-4-3)2004年のインドの会議

　完璧なコードを期待するのではなく、「○○な機能を確認していること」に対し期待している。

(1-4-4)テストとチェック

　違いを考えることが大切。

(1-4-5)テストエンジニア

　プログラマに事細かに指示するのは、テストエンジニアの仕事ではない。

(1-4-6)「QAの言葉を使うことに反対」

　品質保証は、プログラマやQA、マネージャといったメンバー共通の目標だから。

(2)QAと開発者の距離を縮めるには？

(2-1)平鍋氏

(2-1-1)自社開発

　１つのチーム

(2-1-2)委託開発
  • V字の左側
  • 開発者がテスター
  • ユーザサポートチームがQA

(2-2)松木氏

(2-2-1)上流におけるQAの取り組み

　コミュニケーション

(2-2-2)下流におけるQAの取り組み

　ターンアラウンドタイムの短縮がカギ。
→バグが見つかるまでの時間が長いと、仕事が終わらない。
→ユースケーステストやシナリオテスト、機能テストを自動化することで、ターンアラウンドタイム短縮に貢献する。

(2-2-3)平鍋氏の話を聞いて

　QAと開発者の距離があるのは、品質を神格化しているのが原因かなと思う。
→自組織では、開発チームでわかるようにしていて、みんなで検討して定量化している。

(2-2-4)開発とテストを分けることについて

　作りたい製品によるが、会社のビジョンの表現が「チームの外」や「メーカの品質保証」の場合は、社会的な信頼や社会への責任を価値に置いているのであれば、開発とテストでロールを分けるべき。

(2-3)八田氏

(2-3-1)βテストのフィードバック
(2-3-1-1)ゲームを早くリリースするためには？

　ゲームの場合は早くはならない。理由は、発売日が決まっているため。

(2-3-1-1)短期間でデバッグするには？

　リリースまでに多くの要素を入れている状況で、競合他社に優位に立つためにはどうすればよいか？
→βテストで様々な人(開発チーム以外)に触っている。

(2-4)Bolton氏

(2-4-1)プログラマとテスターを物理的に近い場所に配置すべし

　もし、テスターとプログラマが別の階にいるなら、プログラマとテスターが一緒に仕事できるようにしよう！また、会社の設備でできない状況でも、設備関係者がプログラマをコントロールしなくなったら、距離が縮まるように進めよう。

(2-4-2)非機能

　コードの中で明示的に示されていない。

(2-4-3)中には定量的にできるもの

　例えば、トランザクション。しかし、トランザクションのスピードが向上することでhappyになるかは疑問である。

(2-4-4)プログラマは時間との闘い

　よく分かっているのはゲーム系開発。
→クリスマスシーズンで苦しむ。

(2-4-4)ミスを犯す要因

　自然なことであり、短い時間で学ぶ必要がある。
→新しいことや誰もやっていないことをやってみよう！

(2-4-5)非機能要求の品質保証
  • コミュニケーションを通じ、理解を深める。そのため、ツールを活用しよう。
  • 八田氏のゲーム業界のβテストのような楽しいといった質問をすることはいいことだと思う。
(2-4-6)参加者からの質問「テストと開発を分けたいのは何故か？」

　ウォータフォール開発の文献(40年前)によると、
ドイツ人曰く「悪い考えだねと。非常にロジカルだけど、上手くいかないね。」と。

　そこで私は、"Critical Distance(※)"を提案している。

※ http://jasst.jp/symposium/jasst15tokyo/pdf/H1.pdf の55ページ上部を参照

  • 浅いテストは、プログラマができるテスト。
  • 同じ事を繰り返すと、深い問題を見つけられなくなる。
    →別の人がある程度の距離で実施するテスターが必要。テスタは、実はプログラマだったりするが。
  • 敵対関係になる必要が無い
(2-5)テスターの権限
  • スケジュールを変えることもできない
  • 上手く出荷していると言う権限はない
  • 制限の中で品質を保証することはできるか？
    →開発者やマネージャがQA。

所感

　テスターがテストを実施するだけの役割だと、(サービスも含めた)製品作りに寄与しにくいと実感している。第3者検証の組織内では、テスト実施時に製品に関する不味いことや改善提案できるが、仕様書が完成したものをコーディングしているので、ソフトウェア内部の大きな変更はできないことが多く、次期開発時に検討することになります。しかし、次期開発時に検討することがお客様からのクレームという形で市場不具合が発生することもあり、市場不具合対応で本来やるべき事が実施できない悪循環に陥り、製品力が色あせることになります。
　本当に実現したい機能を実装し、市場に投入するためには、妨げになっているものを「安く」「上手く」「早く」取り除く必要があるので、様々なステークホルダに対し、適切な時期にフィードバックするための工夫や知恵が必要になってくる時代だなと思う。
　テスターの価値(存在意義)について、再考する時期に来ているかもしれない。