ヒンシツ大学 Evening Talk #01 ”高橋寿一氏とアジャイルとテストを語ろう に参加してきた
- プログラムの話じゃないですが、表題の勉強会に参加してきました。
- 初めてSHIFT社にお邪魔しましたが、キレイなスペースで素敵空間でした。
- 写真NGとのことなので残念。
ヒンシツ大学 » 先着50名様！【無料開催】高橋寿一氏とアジャイルとテストを語ろう！
自分の感想
探索的テスト、、、楽しそうだけど「上手にやる」のは難しそうだな。
探索的テストのスキルの伝達方法
- (探索的に関わらず)なんでその人は見つけるのか。本人も説明できない。
- 出来る人を育てる、増やす、に関しては時間が掛かりそうだし、何をもって「できる」とするのかも定義は難しい。
- 重要度の高いの不具合を多く見つけた人、とかかな。
- ある期間やってみて圧倒的に差がつくようであれば多分その人はできる人。
探索的テストの前に、開発者レベルでの「最低限の品質が担保できていること」が前提
以下、勉強会時のメモ
マイクロソフトの25年位前
- MSでは開発者：開発40%、テスト40%、UIとか20%だった
- そこから、よりスピードが求められた
- 上流工程のテストに移行＋探索的テストに移行
旧来のテスト
- 網羅的＝全機能ちゃんとチェック。かつ、機能の組合せ
- →網羅度が品質基準になる、を厳密にやる
- お金がかかる＝品質に関わる投資はどんなプロジェクトでも50%を超える
- →
- 時間がかかる＝最初のリリースから数ヶ月のテストしてませんか？
- →お金がある大企業ではお金がかかるより時間がかかるのがいや
軽いソフトウェア、重いソフトウェアで同じテストでいいのか？
- よくないよね。
クラウドアジャイルの新しいテストとは？
- 早い
- 安い
- そこそこの品質
ビジネスで勝たないと意味が無い。
- 旧来のやり方でメリットがあるのかどうか。
提案する新しいテストのスタイル
- TDD＋探索的テスト
- TDD：
- 開発者による網羅的テスト
- QAではなく開発スピードを上げるための手法
- 仕様変更に耐えながら「最低限の」品質を担保する
- 探索的テスト
- 探索的テストvsテストケースベーステスト
- →探索的テストは有効、なグラフ (開発品質によるよね？)
- 探索的テストは「スキルがあるテスターが」やらないと効果は低い
探索的テストとは？
- ソフトウェアテストの「スタイル」
- 個人に自由意志を持たせるとともに責任をより明確んする
- 一個人のテスト活動
- ↑メモが追いつかなかったので
- http://sssslide.com/www.slideshare.net/goyoki/ss-34292539 のP10から引用
- Cem Kanerによる探索的テストの定義
- ソフトウェアテストのスタイル
- テスター一人一人の自由意志と責務に基づく
- 各々の価値の合わせて洗練されていく
- テスト関係の学習、テスト設計、テスト実施、テスト結果の説明を扱う
- プロジェクトを通して並行実施される補完的な活動
やってることは
- ソフトウェアを理解する
- ケース設計
- ケースの\実施
- の3つを同時実行する → つまりこれらを説明、書き出すことができない人には探索的テストをやらせても効果は低い
同時実行なので一つ一つのテストケースは書かない
- 書いても見ない(実施者が自分だから)
- 何のために書くのか？
- そんな暇があったらテストしようぜ → テストケースを書く時間は全体の半分くらい？
過去はテストケース数に対していくつ消化したか、で品質を判断していた
- １０００ケースのうち、９９９ケースやったらから出荷していいのか？
- ケースは品質を代表する指標なのか？
- それよりは、スキルのあるテスターが「品質を担保するために」ユーザーケースを考えてテストする
- 仕様に変更があるたびにケースを修正する時間があるなら、テスターがそれも含めてテストする
- ソースコード量は増えている。コピペ。
- テスト実施者の生産性はそんなに上がらない
従来のテストケースベースのテストをネガティブに言うと
- ケースは時間がかかるしめんどうだから書かない、だったらテストする時間にしよう
- だいたいどこにバグが有るかななわからない 触ってみる
- 回帰テスト：スキルのあるテスターが変更箇所を考えてテストすることでバグが見つかる
要求仕様（ドキュメント）は間違いと言うより記述されていないものがバグになる
- エスカレータの例
- 靴を履いてください
- 犬を抱いてください ←犬を買ってこないとならない
テストケースがあるとテストケースしかやらない
- テスターはそれだけやることが自分の仕事、になる。
探索的テストの本
- 探索的テストのPass/Fail基準
- アドホックでもいいかげんでもランダムでもない
- ちゃんとストラテジックに行うもの
- マネージャが部下のテストアクティビティを理解する（何をやったか、ではなく）
- どのコンポーネントに対して、どの品質特性を担保するのか、を定義する
- 機能性｜○○したら合格｜○○したら不合格｜
- 安定性｜ ｜ユーザーが目的を達せられない
- 対象ソフトウェアはWindowsOSを不安定にさせない、とか
- ↑この辺りは↓この本に詳しく載ってそう
探索的テストのプロセス
- 製品の目的を明確にする
- 重要機能リストアップ
- 機能を明確にする（役割分担
- 弱いエリアを叩く ←わかりきってることはテストしない（誰かが気づく)
- 理論的には継続開発では７％のファイルからすべてのバグが見つかる (２０１０年くらいの情報)
- テスト実行およびバグを記録する
- 上記を継続して実行する
- ↑この辺りも↓この本に詳しく載ってそう
JamesWhittakerのアイディア
- ソフトウェア
- └入力処理
- └計算
- └出力処理
- └データ保存
- ソフトウェアは上記の4つしかしない。
- ケースを考えるときにはこれを考える
タスクシートを書く
- タスクの記述：なにをやろうとしているのか（何を担保するため？
- 探索アプローチガイド：どのように進めていくか。どんな値を入力するか、どんな操作をするか、どういう考えですすめるのか
- 結果：どういう品質のものがリリース可能か
- 終了基準：どのように終わらせるか。どうなったら終わりと判断するのか。
探索的テストとは「スタイル」。メソドロジーじゃない。
- 結果がきちんと報告できる必要がある
- この値は境界値。この値はディシジョンテーブルでやりました。
- 正常ステート、異常ステートを確認しました
- 入力データは正常、異常を確認しました
- こんなバグがでて、修正され、回帰テストを行い、問題なかったので出荷OKです。とか。
スキルのあるテスター
- ねらった品質を担保するために適切な手法が使えること
探索的テストの欠点
- 素人がやるのはダメ
デベロッパーとテスター
- が並んで、デベロッパーが実装の仕方、仕様を話しながら、隣でテスターがテストする
- こういうときにエラーハンドリングするから、やってみて
- とかは効果を発揮した。
注意点
- 100％探索的テスト頼っちゃだめ
- トレーニングを十分に受けたテスターがやる
- コードを書く人のできる人できない人差は26倍。
- テストの場合は10倍くらいと思ってる
- 非機能テストについては探索的テストの効果はビミョウ
マイクロソフトの実験
- 未経験者 １０％のバグを発見
- 教育を受けた人 ６５％のバグを発見
MS時代
- ファーストビルドが動くようになるまではみんなで遊ぼうよ
- (テストが無駄になるから開発者自身で使ってみる)
ファーストビルドが動くまでは開発者が担保する
現状はドキュメントも揃ってない、仕様変更も起こる、最新が何なのかわからない、、、
- これが「あたりまえ」の時代になってきている。それでもリリースしなければならない状況。
- その状況でも耐えうるテストが必要
質疑応答
- テストエンジニアの地位
- MSではコンピュータサイエンスを学んできた人じゃないとテストエンジニアになれない
- PM、開発者の１０％～２０％低いくらいの給与
- ポジションが明確に存在するので転職しやすい
- 日本はプロジェクトマネジメントエンジニア、テストエンジニアの地位が不明確
- ちゃんとスキルをもって労働市場にでれば、企業はほしい
現場で探索的テストを活用している例
ある会社の例
- 1スプリント2週間
- 1週目に開発
- 2週目の初日に探索的テストを全員で実施
1日時間をとるだけでも、継続開発を続けていった将来から見た時に検証時間は劇的に下がる
「チャーター(ガイドライン)」が重要になる
- チャーターについては↓これのP26以降に例
- プライマリファンクション（これがないと意味が無い、という機能）
- コントリビューションファンクション（あったりいいな）
を説明して、2時間くらいで切って実施
画一的なチャーターを導入してもだめ。
自分のチームにあったものを作って、他のチームのチャーターを見ながら良くしていく
ケースを書いて消化するときにバグに悩まされる、ではなくて、
今あるソフトウェアの状況を把握し、それをもとにディスカッションしながら進める
セッションベースドテスト
- http://www.nttdata.com/jp/ja/insights/trend_keyword/2014072401.html
- 終わった後にどんなことがあったか会話する
探索的テストの効果を説明できること
- リスクは存在する
- 成果が出なかったチームは無い
優秀なテスターの指標
- コミュニケーションスキル
- 開発者と仲がいい方がバグを見つける
- バグを見つけるスキル
- (高橋さんが)長年人間観察しているが答えが出ていない
- できる人にやったあとに聞くと、
- 前回の製品よりはいいですよ、とかコメントして、実際に市場評価もそんな感じになっている
意味のある探索的テストにするためには
- 前提知識をみにつける
- ドメイン知識
- テスト対象の理解(システムの目的や使われ方、ユーザー層など)
- ドキュメントレビューへの参加
- 過去の類似プロジェクトの不具合状況
- 知見を共有する
- 類似プロジェクトのバグの傾向、リスク
- 手順に書かれていないテストの必要性
- 書かれたことを消化するだけでやった気になってしまう
- 開発プロセス全体の中の1つのプロセスとして探索的テストを位置づける
品質で儲かるエリアの製品、スピードで儲かるエリアの製品がある
- エビデンスは残らないので、医療のような厳しい品質を求めるものには向かない
