どうも、年度初めの目標作成と面談が山のように積みあがっていて戦々恐々としているオムそばです。
今すぐにでも取り掛からなければ…。
さて、今回は、前記事に引き続きイベントのレポートになります。
国内で業界最大規模のソフトウェアテストに関するシンポジウム、JaSST '19 Tokyo の二日目に参加してきました。
今年も、日大理工学部の駿河台キャンパスの1号棟！
■JaSSTとは？
JaSSTは、NPO法人ASTERが運営しているシンポジウムで、ソフトウェア業界全体のテスト技術力の向上と普及を目指して全国各地(北海道、東北、新潟、北陸、東京、東海、関西、四国、九州)で開催されています。
■A5セッション テストマネジメントの鉄則
本セッションでは、テストマネージャーのスペシャリスト達が、テストマネジメントの各役割(テスト計画や、欠陥管理、進捗管理など)において、どのような鉄則をもって実現しているかを議論されていました。概要はこちら。
また、スライドはこちら。
以下メモ。(多少順番や言い回しなど、修正しています。もしかしたら講演者の意図しない形になっているかも…)
【テーマ:欠陥管理】
●鉄則(町田):欠陥管理がうまくいかないのはExcelのせいではない
- BTSを入れただけで、欠陥管理がうまくいくわけではない。それをどう回していくか、誰が責任を持つかなどのルール決めをして、使いこなせなければ意味がない
- ツールはメンバーみたいなもの。入れて、はい、活躍してください、はできない。
- テストマネージャーとしては、そもそもなぜ欠陥管理をやりたいのか、に答えられないといけない。
●鉄則(湯本):転がし続けろ
- テストチームと開発チームがわかれていたり、大きな規模になってくると、誰がやるのかお見合い状態になり、放置されるチケット(バグチケット)などがある。それらを滞留させず、ゴール(close)まで辿り着かせることが重要。
- 滞留させないために、欠陥の棚卸会議などを定期的に行い、滞留しているものをピックアップして転がす必要がある。
- テストマネージャの仕事は、期間内に目指した品質に落ち着かせることを目指す。障害が発生して、テストの進捗が止まったり、再テストのスケジュールが決まらなかったりするので、それをマネジメントすることが大事。
- 転がす人が第三者検証会社であれ、事業会社であれ、SIerであれ、どの立場だったとしても、大きな差はない。PRJとして与えられた役割があるはずで、その役割の人がコントロールできるようにすることが大切。
- 欠陥のボールを誰も取らなかったら、誰も取らないことに対して、誰が取るかをテストチーム主導でコントロールしてよい。
●鉄則(長谷川):欠陥レポートタイトルはすべて記憶しろ
- 暗記しろという話ではない。IDで話していると、周りに事象が理解、浸透しづらい。タイトルで呼ぶことで、チームやPRJに、今何が起きているのかを発信、浸透させることができる。
- 良いタイトルを書くための１つの施策として、"声に出して読みたいバグ票コンテスト"を開いたことがある。
- IDもIDで大事である。欠陥の事象だけで会話していると、BTSに登録されないまま修正される場合もあるため。
質問1：欠陥を分析する際、ウォーターフォールの場合、フェーズ単位で分析すると思うが、アジャイルの場合はどういった切り口で分析すればよいか？
回答：アジャイルだから、とかは関係ないと考える。ウォーターフォールは期間で工程を切っているが、アジャイルも別の切り口で必ず切っているはず。それらに分けて分析できるはず。まずはそこを見直すとよい。
【テーマ:テスト計画】
●鉄則(湯本):念入り、肝いりなものはNG
- テスト計画を、何かしらの標準(ISO29119など)のフルセットができるまで作ろうとすると、PRJが終わってしまう。また、テスト計画は変化するもの。早く出して、皆で合意していくことが大事。
- JSTQBのテストマネージャシラバスで、1.2.1の冒頭に書いてあることで、テスト計画が継続する、とある。
●鉄則(長谷川):安心しろ！奇跡は起こらない
- 計画を立てる際、スケジュールにはまるように、「これ、10分で終わるところが8分になるんじゃないか？」「バグはこんなに起きないんじゃないか？」という計画を作り、リスクを見ないようにしてしまうことがある。合わせるなら合わせるで、それによりどんなリスクを持つかを紐づけておくことが大事。
- テスト計画はコミュニケーションツールとして使うとよい。開発と、少なくともこれだけは押さえなきゃいけない(テストスタートできない)点を、少しずつコミュニケーションを取りながら決めていくとよい。
●鉄則(町田):テスト計画はみんなのために
- 各所に合意をとらなきゃいけなかったり、テストチームの進める方針になったり、会社の経営層に報告しなきゃいけなかったり、と色々な人に見せ、合意を取る必要があるので、そういった人たちに向けてテスト計画は作らなくてはならない。日本の開発スタイルとして、多重下請け構造があるが、その場合、計画を末端のところまで伝えなきゃいけない。そこが難しいところ。
- 全員に八方美人な計画書を作ると、ダメになる。ある程度バランスを取る必要がある。うまく色分けして、伝えるべき人に伝えることを気を付けている。
【テーマ:進捗管理】
●鉄則(長谷川):ツールとパトロール
- パトロール(巡回すること、事故や欠陥のために見回ること)する、テストチームを見て回る。何で困っているか、どんな顔してテストしているか、同じようなデータを作ってないか、同じ欠陥を書こうとしていないかなど、ツールで集計しているだけでは見えない部分を見回る。
- ツールなどを使って数字を管理し、パトロールでやっている内容を見る。
- 進捗管理していると、全部自分が回答できるようにする。回答できなかったら(誰かに聞きに行きますとか)、テストマネージャとして最悪(PRJの規模にもよるが)。
- ツールをちゃんと使わせるのが大事。それがないと、大きなPRJでは数字合わせに奔走することが発生してしまう。数字の聞き取り調査が発生する。
●鉄則(湯本):親身になるな
- 進捗を妨げる要因。PRJの末期になると、皆が心配になる。例えばシステム統合テストの中に、心配だからといって他のテストを入れるなどはしてはいけない。もしやるなら、別フェーズを設けてやるべき。
●鉄則(町田):見えている数字に騙されるな
- テスト消化数というメトリクスで、グラフ作ったりして管理することが多いと思うが、テスト消化数で何をイメージしたか？テスト実行した数か？テストを合格した数か？(会場で意見がわかれる)
- リグレッションテストなどで、合格が不合格に戻ったりするが、出てくる数字の定義や意味を正しくとらえないと、間違ったことになる。
- 進捗は9割くらい進んだところが実質5割だと思っている。大体やりやすいところから始めて、難しいところを残しがち。そういうことではないらしい。
- 進捗を1日6時間で計算しないと間違える(これは私も前に記事を書いたので、リンクを載せておきます)
- ビジネスライクの人には数字を見せなければいけないが、ソフトウェアテスト293の鉄則の198番に、数字しか見ない経営陣ほど危険なものはない、とある。この数字をどうやってだせばいいか。
⇒数字はあくまでも目安。必ず定量的なものと定性的なものがある。説明しきれることが大事。
質問2：PRJリスクはどのように出すか？
回答：PRJリスク、プロダクトリスクに分けて管理するべき。発生確率と発生影響、何に影響するかを識別し、それらをどう管理するとよいか。
PRJリスクはPRJ運営にかかわること、プロダクトリスクはテスト設計にかかわること。
質問3：PRJリスクの具体例はどこを見れば出ているか？
回答：自分がPRJに対して、影響を与えそうなものすべて。ただ、リスクを全部摘む必要はない。
濃密なセッションで、時間があっという間に過ぎてしまったし、聞きたいことはたくさんありましたが、自分でも考えていこうと思いました。
他のセッションのまとめは、他の方のブログや、toggetterなどを見るとよいでしょう。ではまた。
