# タイトルコール ようこそ、世界が広がるソフトウェア品質。 このチャンネルでは、Qエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # テスト実行工数の見積もりでの工夫 キューエンジニアのサミーです。 皆様いかがお過ごしでしょうか。 今回はテスト実行放送を見積もる時に工夫していることを3つお話ししようと思います。 1つ目が最初はざっくり大中小。 2つ目がストーリーの数とか複雑さが見えてきたらテスト期間が1週間なのか2週間なのか。 3つ目がテスト設計後に詳細な見積もりをするです。 キルナ空港で収録をしているので、他の周りの雑音が聞こえているかと思いますがご了承ください。 まず1つ目ですね。最初はざっくり大中小。 最初はどこかという話なんですけれど、一番遠いと半期の目標を立てる時とかですね。 キューエンチームのメンバーがまだにいるという状態で、 例えばロードマップ。この半年ではこの辺を作っていきますというロードマップがあります。 大体はその全部の案件に入ることはできないので、 エンジニアリングマネージャーの方だったり開発チームのリーダーの方と話をしながら、 どの案件にキューエンチームのメンバーをアサインするのかを決めます。 その際にざっくり開発規模を1ヶ月なのか3ヶ月なのかとか、 大中小というものを決めておいて、7月のこの案件には大大さんをアサインするということをざっくり決めます。 キューエンチームとしてやりたいことは、その案件の品質保証、品質リードだけではなくて、 他にも例えば不害の分析だったりとか改善のタスクとか、 リグレッションテストだったりとか、自動化だったりとかいろいろやることがあるので、 この目標を立てるタイミングではそのメンバーの最大でも 構数の3割で収まりそうなボリュームでアサインをします。 ここまでの話をまとめると、ロードマップ案件を大中小に分けて、 それの大きさを基にキューエンチームのメンバーをアサインしていきます。 テスト実行構成の見積もりの精度という意味だと、間隔ですけど精度は10%ぐらいです。 ちなみにその大中小がどのくらいの期間なのかという話なんですけど、 これはもう開発、会社によって違っていて、 例えば、昔10年ぐらい前に勤めていたウォーターホールで開発していたときで言うと、 大は6ヶ月ぐらい、3ヶ月以上かな、3ヶ月以上の開発期間とか、 中が3ヶ月とか、小が1ヶ月になったかなと思います。 ここ数年のアジャイル開発を進めている場合だと、 大が3ヶ月、中が1ヶ月、小が1ヶ月未満みたいな感じかな。 大中小がテスト実行コースを見積もるときに工夫していること、最初の1つ目のポイント。 最初はざっくり大中小でした。 2つ目ですね、ストーリーの数とか複雑さが見えてきたら、 テスト期間は1週間か2週間かです。 PRDが作成された後、開発の見積もりが出てくると、 そのくらいストーリーの数が多そうだとか、 どのくらい複雑な実装が必要かというのが見えてきます。 特にテスト期間は1週間なのか2週間なのかぐらいのざっくりな感じで見積もりをします。 これまでの経験だと、開発の見積もりの中に 手動でのテストというものが含まれていないこともあったりしますので、 見積もりをした方にテストのコースって含まれてますか、 どのくらいの期間ですかというところを聞いて、 自分の感覚値と大きくずれていたらディスカッションをするようにしています。 もちろん見積もりをするタイミングで声をかけてもらうか、 ディスカッションをしてテストコースってこのくらいですよねって見積もれるのが一番ではあるんですけれど、 場合によっては気づいたら見積もりまで終わっていて、後でレビューするということもあります。 テスト実行コースの見積もり方法ですが、ストーリーの重さを見ながらざっくり テスト実行は1時間、3時間、6時間というふうに数字を入れて足し算をすることが多いです。 このテスト実行の時間に何が含まれているか、どういうテストが含まれているかというのは 案件だったり会社によっても違って、一概にこれとは言えないんですけれど、 例えばイメージとしては機能テストが一番近くて、新機能と後リグレッションのテストをさせていることが多いです。 場合によってはクロスブラウザーテストも含まれていることもあります。 ここまでがテスト実行コースを見積もるときに工夫していること2つ目のストーリーの数とか複雑さが見えてきたら テスト期間は1週間か2週間かという話でした。 3つ目です。3つ目がテスト設計後に詳細な見積もりをするです。 テスト設計が終わるとテストケース数が全体の量が数が分かります。 その後に自分のそれまでのテスト実行、テストケースの実行の速度、1分間でどのくらいのケースを消化できるか、 あるいは1ケースを消化するのにどのくらいの時間がかかるかという情報を持って見積もりをします。 テストデータの用意が必要だったり何かテスト実行の前の準備が必要な場合はちょっと多めに時間をとります。 今の自分のスピードが分からない場合は1時間やってみる、あるいは1日やってみる、1ストーリー分やってみる、その結果のデータを使って見積もりをします。 認知ケースあたりの実行時間を例えば1分、4分というのが出てきたら、それかけるケース数というところで時間を見積もることができます。 1つ注意点があって、不具合の報告時間についてです。 見積もりの時間に不具合報告時間を入れるか入れないかはどちらでもいいと思っているんですけれど、 もし不具合の検出数の見積もりも出しているのであればその時間を足せばいいと思いますし、そうじゃない場合はテスト実行のタスク以外に不具合報告プラス修正確認というタスクを足して見積もる必要があります。 8年くらい前は不具合報告の時間もテスト実行の時間に混ぜて見積もりをして、ちょっとパッパーと思ってテスト実行の時間を見積もれるようにしていました。 最近はテスト実行は純粋にテストデータを作って実行して結果を書くまでの範囲にしていて、 不具合報告と修正確認は別のタスクで、ざっくり2時間とか4時間というふうにタスクを登録しています。 ここまでが3つ目、テスト設計後に詳細な見積もりをするでした。 最後に1つメッセージがあって、最初から完璧な見積もりができる人はいないと思っています。 ですけど何回か繰り返して見積もってみて実行してみる。 その差分を埋めていくと言いますか、どこかもう恒例が盛れているところがあって見積もりの方が少なかったらその分を次回は足せばいいと。 このトライアンドエラーを何回か繰り返すと見積もりの精度というのが上がっていき、 結果としてこのくらいの規模感だったらこのくらいの個数になるかなという見積もりができるようになります。 最後に言っちゃったんですけど、もう1つQAリーダーとしてよくやっているチップスみたいなものがありますので紹介します。 自分なりの見積もりの方法を持っていないメンバーに対しては、 今日の放送で話した内容を説明をして見積もりをしてもらっています。 あとはその見積もりをリーダーである自分がやる場合、メンバー自身ではなくてリーダーがやる場合は、 私だったらこのくらいかかるという個数×2倍で見積もりをしています。 そしてメンバーにも私の2倍くらいの個数で収まるように頑張ってみてねなんて話をしています。 以上、テスト実行個数の見積もりで工夫していること3点でした。 こういう工夫しているよというものがあればぜひコメント欄で教えてください。 # #17のコメント返し それでは17話目のコメント返しです。 17話は、仕事を英語で一番恥ずかしかったスペルミスのお話でした。 みる9999さんから、涙を流しながら笑っている大笑いの絵文字をいただいております。ありがとうございます。 いつもコメントだったりリアクションいただいて、とても嬉しいですし励みになっております。 これからもよろしくお願いします。 以上、17話のコメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はVoicyのトークテーマですね。 私のリフレッシュ方法についてお話ししようと思います。 この放送のいいねとSNSでのシェア、ぜひよろしくお願いいたします。 それではまたお会いしましょう。 ごきげんよう。