# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、Qエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # テスト計画で苦労していること こんにちは。Qエンジニアのサミーです。 連休を明けてお仕事に慣れてきた頃でしょうか。 私は日曜日の夕方に帰国、日本に帰ってきたんですけれど、 意外にもしかして今週ちょっと疲れちゃうかなぁなんて思ってたんですけど、 意外に大丈夫で元気に仕事をしております。 はい、ということで今回はテスト計画で苦労していることについてお話しします。 これまでだと工夫していることみたいな感じでお話ししてたんですけど、 今回は苦労していることなので、こうやってうまくいったよという話ではなくて、 こういうことをやっているんだけど、なかなかうまくいってないんだよねという話になります。 皆さんの職場ではテスト計画って作られてますか。 本題に入る前にテスト計画とは何かの認識を合わせておきたいと思います。 おなじみのISDQBグローサリーから引用しますね。 英語だとテストプランなんですけど、 急に英語でびっくりした方もいるかもしれませんので、日本語でも説明します。 テスト計画書とは、達成すべきテスト目的、 およびそれらを達成するための手段やスケジュールを示し、 調整したテスト活動を体系化したドキュメントです。 要は、何のためにテストするのか、今回のテストするのかというテストの目的と、 その目的を達成するためにはこういうことが必要ですよねというやり方だったり、 スケジュールだったり、手段だったりのスケジュールを書いたドキュメントのことを テスト計画書と呼びます。 本題に入っていくんですけど、これまでの自分の経験として、 テスト計画書を書くとき、大体大きめな案件と言っているんですけど、 会社によって大きめな案件って異なるんですけど、 大体これまでの経験だと、3ヶ月くらい、3ヶ月以上の開発期間、 全体を設計をしてからリリースするまで、全体公開するまでが3ヶ月、 あるいはそれ以上あるような案件を大きめな案件と呼んでいて、 そういう大きめな案件に対してはテスト計画書を書いていることが多いです。 そのテスト計画書を書くときは、ISOはIEEEの29119の規約に沿った テンプレートっていうのがISOで出していて、 それをベースにこれまでやってきていることが多いです。 少し話それちゃうんですけど、昔というかテストエンジニアというか、 一番最初ってこういう規約の存在とかは知らずに、 こういうことを事前に考えなきゃいけないねみたいなのを なんとなく自分のドキュメントにまとめていたんですけど、 あるタイミングでこの存在、テンプレートという存在をして、 規約の存在をして、なるほど確かにこういうことを考えなきゃいけないな というものが網羅されていて、とても助かったみたいな経験が昔ありました。 本題に戻ってくるんですけれど、昔10年ぐらい前ですかね、 ウォーターフォール開発でやっているときは、 このテンプレートに沿って案件の最初の時期のほうで、 テスト計画のフェーズといいますか、テスト計画書を作っていたんですけれど、 最近はアジャイル開発、スクラム開発というところで、 今日やることが多くて、このテスト計画書をどう適用させればいいのか というところをとても苦労しております。 過去にやってみたことと、今やってみていることの共有をしようと思っています。 過去1回やってみたのが、マスターテスト計画書とイテレーションスプリントごとの テスト計画書を2つに分けて、それぞれ作るということをやってみました。 マスターテスト計画書というのが言葉が正しいかは自信ないんですけれど、 要はその案件3ヶ月ぐらいかかるであろうという案件全体に対してのテスト計画書をまず作りました。 それに対して、それぞれのイテレーションでやること、開発するものに対してのプチ、 プチという名前は付けてないですけど、イテレーションテスト計画みたいなテスト計画書というものを メンバーに作ってもらうみたいなことをやってみました。 やってみたんですけど、ちょっと今一つでして、何かというと1週間イテレーションあるいは2週間イテレーションの中で テスト計画を作るのに1、2営業日かかってしまって、ちょっとコストが高すぎるみたいな感じになって うまく運用がその時はありませんでした。 今やってみてることなんですけれど、今は大体キックオフぐらいのタイミングで テスト計画書を作るようにしています。 キックオフだったり、PRDの内容が共有されたりとか、プロジェクト計画作ったりっていうようなタイミング、 開発の全体の見積もりをするぐらいのタイミングでテスト計画というものを作っています。 ISOのテンプレート見たことある方は分かると思うんですけど、結構ボリュームがあるんですよね。 なので、必要そうな項目のみをピックアップして記載しているという感じに今はしています。 やってみての感想なんですけれど、なんかしっくりきていなくて、 でも何がしっくりきていないのかが、今はまだちょっと言語化できていないという状況であります。 一つ思うのは、作りっぱなしになっちゃってるのはちょっともやっとしてるんですけど、 でもそれはウォーターフォールとか、アジャイル開発とかっていう開発のスタイルとは関係ないことなのかな、 なんて思ってたりはしてます。 じゃあテスト計画っていらないんだっけって思うと、そんなことはなくて、 やっぱり結局、じゃあいざ自分がテスト設計をするとか、スクラムに入るっていうなったときに、 結局そのテスト計画書に書いてあるような内容のことは確認してるんですよね。 例えばコミュニケーションってどのチャンネルで行いますかとか、 不具合の管理は報告ってどこでしたらいいですか、管理ってどこでしますかとか、 そういうのって自分が最初にチームにジョインするときに絶対に聞くことだったりするので、 やっぱり必要なんですね。 あとテスト計画で一番大事なテストの目的っていうところ、 今回の案件で一番何を気にしているのか、何が一番リスクなのか、 どういう状態を一番防ぎたいのか、そのためのそのリスクを減らすためのテスト活動だと考えているので、 そこの何を一番守りたいか、保証したいのかっていうポイントを認識合わせるっていうのはすごく大事だと思うんですよね。 その認識合わせるいいタイミングとしてテスト計画書っていうものがあるとは思っています。 なのでいろいろヒアリングする今回一番防ぎたいポイントってこういうことですよねみたいなのを確認をして認識を合わせたりして、 その結果がテスト計画書に記載されている。 いろいろ聞いた内容、コミュニケーションを取るスラッグはこのチャンネルですよねとか、 あとテストの種類ですかね。 昨日テスト以外に今回ってパフォーマンステストやったほうがいいですよねみたいな話とかを決めた、 合意した内容、ディスカッションした内容をまとめる成果物としてテスト計画書っていうものを使うのも、 もしかしたらアリなのかななんていうのはもやもや考えてたりします。 ということで今回はテスト計画で苦労していることのお話でした。 ぜひコメント欄にテスト計画でこういうことを工夫してるよとか、こういうふうにやってるよということを取り組み、 工夫、Tipsあればぜひぜひコメント欄で教えてください。 # 今日のほっこり話🎬🟥 今日のほっこり話です。今日は映画の話をします。 先日ですね、ちょっとクリスマス開けた後にはなるんですけれど、 レッドワンという映画をネットフリックスかな、アマゾンかな、アマプラかちょっと忘れましたが、家でレッドワンという映画を見ました。 その舞台がですね、フィンランドっぽいところ、CGとかも入ってたのでわかんないですけど、サンタさんのお話なのでフィンランドが舞台っぽくて、 オーロラとかも見れて、この間見れたね、みたいな話をしながら夫と見れたりしました。 すごいいい映画だったのでオススメです。ストーリー性というか世界観と、あとギャグ要素がとても笑えるというかコメディ要素がとても面白い映画でした。 以上、今日のほっこり話でした。 # 次回の放送は、#旅行積立やってません 今回も最後までお聞きいただきありがとうございました。 ぜひコメント欄を書いていただけると嬉しいです。 引き続き勝手にコメント強化期間をやっております。 また、放送のいいねとSNSでのシェアをしていただけるととても励みになります。 いつも藤原さんとかmel999さんがXでいいねしていただいているのもとても励みになっております。 ありがとうございます。 次回の放送はVoicyのトークテーマ、旅行積み立てというテーマについてお話ししようと思います。 私は旅行積み立てやっていませんので、やっていませんというお話しをしようかなと思っております。 それではまたお会いしましょう。ごきげんよう。