登壇者
- 鈴木三紀夫
- 松木晋祐
- 山崎崇
- 藤原洋平
- 長谷川聡
モデレータ
- 江澤宏和
アジェンダ
- オープニングとポジショントーク
- ディスカッションパート1
- ディスカッションパート2
オープニングとポジショントーク
- 炎上しているプロジェクトに入る場合、みなさんはまず最初に何をしますか?
鈴木
- 入るときにはPMとして入るが、表と裏の技がある。
- 表の技…全てのタスクを洗い出すこと。お客さんのクレームとかも全てタスクにする
- 裏の技…入ってすぐ、メンバーに「平日のある1日休め」と言う。お客さんの交渉力があるPMだと信頼してもらう
松木
- テストリーダーの立場として入ったら、情報の流通経路を確認し、詰まっているところが無いか確認する。情報を今後共有する時は、その経路を使う。それが無かったらまず構築する
- どうなったら炎上が終わるか確認する
山崎
- 支援とする立場が多い。
- 欠陥管理ツールがあるならば、それを見る。WBSがあれば見る。あとはヒアリング。
藤原
- 体制図を作って可視化する。
- お客さんもいるときは、窓口だけではなく、お客さん先の開発陣や子会社なども確認する。
- 仕様決めの人は?予算決めは?Goサインは誰が?を見る
長谷川
- 現場のテストをしている人と話をする。
- 上の人と現場の人の認識のズレがあるはずなので、そこをまずは解決する。
アンケート
ディスカッションパート1「仕様書が神様ではない状況」
鈴木
- テスト設計ではなく、QA形式のものを構築する
長谷川
- 実態として、連絡経路とかではなくもうテストしなくてはいけない場合は?
松木
- 私の場合はテストケースのレビューも行う
- 機能仕様書やユーザーマニュアルを作ってからテストする。
- クラッシュなどを中心にテストする。
- 類似製品のテスト設計を当ててみる。
- 質の低い仕様に対してテスト設計をしても効率が悪い
長谷川
- 全部の質が悪いことはあまり無いのでは?
山崎
- 特定のところだけ良いところはあまり無いイメージ
松木
- 機能仕様が無くても要求が無いわけではない
鈴木
- エンプラの場合は、区分コードや種別コードの組み合わせを考えて、ビジネスルールをあたりをつける。
- もしくは画面からビジネスルールのあたりをつける
山崎
- 期待結果に着目して話すが、テストオラクルが無い場合、そもそも期待結果を定義出来ないと思うが、起きたことのリスクを合わせて報告できるようにする。
- 結果がFailだけでなく、影響度からのリスクも示す
松木
- 確かに、これって開発側も分かるようにする
山崎
- 上流側から行うのが王道ですが、テスト側からアプローチする。
- 利用時の品質を訴求して示す。
松木
- テストチームが仕様を書く。そのフェーズはきついが、次フェーズでアドバンテージになる。次フェーズでかならずテストチームに関わることになる
松木
- 分かっている人が限られて属人化しやすい範囲かなと
ディスカッションパート2「結合テストが終わってないのにシステムテストが開始される」
藤原
- 実際に経験あり。結合テストどころか、機能実装が終わってない段階でできるところからやってと言われる。
- PMとの事前合意が大事。
- こういう状況になってしまったら、立て直す方にフォーカスする
山崎
- 決定権がPMにあるように見えるので、無茶ぶりに対するリスクを示してあげることが重要。
- 新しいバグを見つけることも価値があるが、それによるリスクを説明することも価値がある
長谷川
- PMにリスクを説明して聞いてもらえるコツはあるか?
松木
- この段階になると聞いてくれない。
鈴木
- これって手遅れなんだよね。
- 何が問題なのかよくわからなかった。
- 今回の対処なのか、もう一回起こさないためにはなのか。
- おそらく、契約時などでこの状態になる予兆があるはず。
- 隠して第三者検証に発注しようとしてもダダ漏れになるはず。
長谷川
- その意見はAgreeだが、こういうことってよくあるべきでは?
鈴木
- いくつかの握りができるはずなので、システムテストが1ヶ月あったら最初の3日でこれだけバグが出たら相談しませんか?とか
長谷川
- 核心疲れるとへそ曲げちゃうPMは多いハズ。人情派で行きたい
山崎
- 責任を負うあなたに向けてリスクを示したい。それでも行くんだというならばそのPMは責任を負うべき。都度都度ジャッジする情報を示したい。
長谷川
- 数値を出すのって大変だと思うが、すごいと思う
鈴木
- テストチームとリーダーではなく、PMの立場に寄り添っているように感じた
長谷川
- いやらしい言い方をするとそうかもしれない。私はテストのプロなので、その部分については信じてくれと
鈴木
- ということはPMOではなく、テストのアドバイザの立場と。
松木
- 本来、どの段階で出るべきバグかというような数値を出す。
- 次のプロジェクトもある場合はね。
- 単発の場合は優先度を付けて、優先度の高い部分からやって、7割できるけど、3割できない部分をやりますかやりませんか?と伝える
- (「冊」の字の話)
鈴木
山崎
鈴木
- そういうこと。
- 場合によって、結合テストが開発者中心になっているならば、そこにテストチームが入る
ディスカッションパート3「影響範囲を適切にテストする方法は?」
鈴木
- テストコンサルタントとして入るとめっちゃ多いが、これはテストの範囲ではない。
- 影響範囲分析をしてくださいと言うしか無い。
- 対象システムによって違うかもしれないが、リソース共有をしている場合、そこのプログラムにリソースに影響を及ぶ可能性がある場合(1次波及)と、そのリソース先も影響を及ぶ場合(2次波及)がある
山崎
- ソリューションの1つはテスト自動化。もう影響範囲を考えない方法。
松木
- 自動化を進める時は、冊の1画目をまずは行う。テストの人が知っておくこととして、開発者は影響範囲を断定するのがすごい怖い。
- 「言ったじゃん」と言われるから。開発者に丸投げするのではなく、テスト担当者もテクニカルレビューに参加する。開発者1人に丸投げしない。
鈴木
- 自動化しようとすると、保守フェーズなので自動化のコストを捻出できなくて断念する。
- そういう場合はデータパトロールを導入する。
- システムテストが終わったら簡単なプログラムバッチを流す。
- テストの自動化というと負荷がかかるが、数値の単純な足し算を作っておく。
山崎
- 自動化というと重いものを考えがちだが、チェッキングの部分だけでも自動化する
質問
Q. システムテストをやっている途中に結合テストやっているということについてどのように交渉するのか?
鈴木
江澤
- やはりPMとネゴるべき?
鈴木
- ケースバイケース
江澤
- PMとネゴると裏という感じではなくなる
Q. 候補1に関連して、藤原さんが言ったように製造が終わってないのにテストしてくれと言われる。製造が終わってないので受け入れテストが始まる場合は?(作りかけのビルドが提出されてるとか)
藤原
- 仕様書のレビューとか出来ないのでは?
山崎
- そこまでいくと、政治で解決しないといけない
松木
- お客さんに「本当にやりたかったことはこれですか?」と要求の方からアプローチする
鈴木
- 質の高いテストケースを書くようにする
長谷川
- これが全部通ったら嬉しいですか?というテストケースを作る
Q. 松木さんが、仕様をテストチームが書いてしまうと言ったが、設計チームも書いているので、2つ出来ると思ってしまうが?
松木
- システムチームが書いている権限を乗っ取ったほうが良い。
鈴木
- 派生開発は差分だが、テストで欲しいのは全体なのでそれをこっちで書く
江澤
- 仕様書を書く技術はテストチームが持っているのか?
松木
- 期待結果を元に作れば仕様書に出来ると思う
山崎
- 状態遷移テストとかデシジョンテーブルとかは本来設計段階で書くべき
江澤
- 動かないと仕様が確定できないものがある
山崎
- それはテストオラクル問題で、実際に今後出てくる。分からないものに対してはかなり煮詰めておく必要がある
Q. コンシューマに所属しているのですが、設計との交渉になる。どこまでだったら直さなくても良いよというような知見があれば教えてほしい
山崎
- バグレポートに対して直す直さないのかの判断はPMが行うべき。なのでPMにエスカレーションすべき。
松木
- それはチームが目指すべき品質レベルの共有が出来てない。
- 優先度高中低とその都度考えて付けているチームはきっと合意できていないはず。
- パフォーマンスを重要とするのか、セキュリティを重要するのか。
山崎
- いくつ以上のものはすぐに直すなどの判断をする
Q.探索的テストと記述テストをやったあと、スーパーテスターがバグをいっぱい出した結果、バグが収束しなかった。どのように記述テストにフィードバックさせるのか?
長谷川
- 探索的テストを欠陥ベースにやっているはずなので、欠陥と見つけ方を管理するのが1つのアプローチ。何のバグを想定してテストを行おうとしているのかを共有する。
松木
- 共有すべきなのは思考過程やテスト観点。探索的テスターが語りだした最初の10秒が重要
長谷川
- 感覚派のテスターもいるのでは?
山崎
- 説明が出来ないテスターは探索的テストではなくアドホック。
鈴木
- 感覚派の感性に合わせられる説明をすることも大事。