JaSST’18 Tokyo に行ってきました。
みなさんこんにちは！品質管理グループのs-24です。
先日、日本最大のテストイベント(たぶん・・)、JaSST’18 Tokyo に行ってきました。
高校野球の甲子園出場風に言うと、2年ぶり6回目の参加になります。
東京で開催される JaSST は2日間あり、それぞれ違うタイムテーブルが組まれています。
今回の開催場所は御茶ノ水にある日本大学。天気はあいにくの雨。前回も確か雨。日本大学での開催の時は、いつも雨の様な気がする・・(違ったらごめんなさい)
そんなことを思い出しながら会場に入りました。会場はこんな感じです。電車遅延もあり、ギリギリ到着だったので一番後ろの席。。
システムテストの段階で計画を超えるバグが出た場合どうするか？
今回参加したセッションは
- 「テストマネージャの決断」
- 「組織改善のためのPMOのあり方とPMOの育成に関して」
- 「私が経験したソフトウェアテストの変遷」
- 「アジャイル・自動化時代のテストの現場のリアル」
この中で今回は「テストマネージャの決断」を紹介したいと思います。このセッションは、あらかじめ用意された課題に対して、各パネラーさんならどういう決断をするかを話していくセッションでした。パネラーさんは3名。3名ともテスト業界では有名な方で、2名が組み込み系のテストマネージャでもう1名はWEBサービスのテストマネージャの方でした。
今回用意された話題は2つありました。
- システムテストの段階で計画を超えるバグが出た場合どうするか
- 基本設計書がなく、開発もそれぞれ別会社が担当していて、テストケースを作成する資料がない場合どうするか
この中で私が注目したのは、システムテストの段階で計画を超えるバグが出た場合どうするかでした。これは私もよくこの状況に遭遇するので、パネラーさんの決断に注目してみました。パネラーさんの決断は以下の通りです。全てではありません。もっとあった気がします。それと聞きながらのメモを載せているので認識違いがあるかもしれません。
- まずは騒がないw
- テストチームであげたバグが本当にバグなのかを確認する
- バグをなるべく早く開発者に共有する
- バグを解析して、まだ出そうな機能を重点的にテストを実行する
- バグに重みづけをする
- 現在の状況をプロジェクトリーダーに伝える
この課題に対して私が感じたポイントとしては、現在の状況を把握してしかるべき決断をする。そのために何をするべきかを考えることが大事なのかなと私は思いました。挙げていた決断のうち、1,2,3,5 について私になりに考察してみました。
1. まずは騒がない。(←会場では若干の笑いがおきる！)
予定よりバグが出ているの？スケジュール遅れるの？リリース遅れるのでは？こういう噂が立つと社内が異様な雰囲気になります。売上インパクトが大きい案件は特にです。
実際に騒がなければいけない(社内に共有する)状況はまだまだ先。本当にリリースを遅らせるかどうかの決断が必要な時までは、開発・テストチーム内で解決できるようにするべきということす。外野からワーワー騒がれるとやりにくくなりいいことはありません。
2. テストチームであげたバグが本当にバグなのかを確認する。
私も経験ありますが、テストチームでバグを出したが実際に確認してみるとバグではなかった。仕様だったということがよくあります。だいだい1割から2割ぐらいはバグではなかった経験があります。これも状況把握には必要なことです。
3. バグをなるべく早く開発者に共有する。
当たり前のことですが、これは絶対必要。開発とテスト担当が近いプロジェクトなら、ほとんどリアルタイムで伝えられるのですが、遠いプロジェクトも存在します。私もこの経験があり、組み込み系に多いと思います。リリースが近くなるとこの時差が命取りになる可能性もあり、直すべきバグなのかそうではないのか、もし直すならどれぐらいの期間、リスクがあるのかを話す必要があります。時差が出れば出るほどこの判断が遅くなりリリースに影響が出ます。また、開発者にバグを共有することで、今後どの機能をもう少し重点的にテストをすればいいかの材料にもなります。当たり前のことですが、意外とできていないプロジェクトを私も経験しました。
バグを解析して、まだ出そうな機能を重点的にテストを実行する。これはバグをなるべく早く開発者に共有するところでも少し書いた、今後どの機能をもう少し重点的にテストをすればいいかに似てます。バグが出そうなところの当たりをつけて、バグを出してしまおうという作戦です。
5. バグに重みづけをする。
私はこれを一番重要視しています。出たバグを3段階ぐらいで重みづけして、高いものから直して貰う様にします。例えば、このバグを直さないと次に進めない。ユーザーが知らない間にデータが書き変わってしまっている。データ復旧ができない。などは重要度をHighにして、逆に表示系や、要求とは異なっているが、違う方法、違う遷移で実現できるようなバグはLowにしたりして重みづけをします。限られた時間の中でどれを直すか直さないかを判断できないと、リスケが必要なのかこのまま進めていいのかも判断できません。これはとても重要だと思います。
上記のことを踏まえて、最後にプロジェクトリーダーに状況を伝えることになるかと思います。
まとめ
テストマネージャとしては、実際にリリースを遅らせるかどうかの決定をするのはテストマネージャの決断ではなく、あくまでも現在の状況を把握するための決断をする。それをプロジェクトリーダー、企画、営業、役員に伝えることが大切でそれが責任、仕事であると感じました。後はやっぱり開発チームと密にコミュニケーションを取ることが大事ですね。開発とテストチームが一体となっているプロジェクトを作ることが大切だなと感じました。
トライコーンの開発チームとテストチームは一体感がありますね。というかもう同じチームという感じです。一体感を作り上げてこれたのにはいろいろありますが、テストチームも機能開発や改修の上流工程から共有や議論を積極的に行う文化を作り上げてこれたからだと思います。また、開発チームとテストチームはミーティング、チャット、チケット管理システムなど様々な粒度で頻繁にコミュニケーションしていますので、計画外のことが生じてもどちらかのチームで長期間抱えるようなことも起きにくい環境になっています。今回セミナーに参加して得た一つ一つの気づきも興味深いものでしたが、トライコーンで培われてきた開発チームとテストチームの関係性もまた貴重なものであることを改めて感じました。
久しぶりにセミナーに参加しましたが、とっても有意義な1日になりました。
今後はまたセミナーに参加する機会を増やしていきたいと思います！