# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # テストスケジュールの定義 こんにちは、救援陣にあなさみです。 今日もワクワクしていますか? 今回はですね、ISTQBのGISPARTレベル テストマネジメントの調査を読んでいきます。 今回取り扱う章は、6.2プロジェクトマネジメントタスクの中の 6.2.2リファイリング・テスティングスケジュールを 中心にお話をしていきます。 時間がありそうだったら、6.2.3の バジェッティング&リソースアノペーションも 少し触れようかなと思っております。 6.2.2はリファイリング・テスティングスケジュール ということで、テストスケジュールの定義について書かれています。 最初読んでいきます。 前回のテストの見積もりの話だったんですけど、 一旦見積もりが終わると、今度テストマネージャーは テストスケジュールを定義することができます。 そして、そのスケジュールに含まれていないと いけないものは以下のものですということで、 Measurable Milestones、計測可能なマイルストーン、 タッチポイント、ディペンデンシス依存関係、 そして、デリバリー・オブ・ウォーク・プロダクトなんて、 成果物っていうんですかね、そのプロダクトだったりとか、 そして、Work Within the Overall Project Planなんで、 全体のプロジェクトの計画に沿って動かないといけないんですよ、 テストのスケジュールを作らないといけないんですよ、 という風に書かれています。 次、読んでいきます。 Suppose testing schedules are highly dependent on smooth handoffs with all expectations met. A list of objectively very fearful criteria should be defined for each dependency and work product delivery. テストのスケジュールはかなり依存している、円滑な引き継ぎに依存していると、 かつ、全ての期待が基準に沿っているという状態で、 ハンドオフされるかどうかにかなり依存されているということなので、 Very fearful criteria、検証可能な条件、クライテリアをちゃんと定義しておきましょうね、という風に書かれています。 確かに、特に複数チーム、複数の拠点、複数の企業が関わるような場合、 そして成果物がこっちのチーム、次はこっちのチーム、 こっちは次のテストチーム、みたいな感じに渡っていく場合は、 そこの引き継ぎというのがスムーズ、どのくらいスムーズにいくかというのは結構大事になってきますよね。 一文飛ばして、次のセクションというのかな、パラグラフに、段落に移っていきます。 For example, if the testing schedule is based on an assumption that the unit testing done by the developers will have achieved 100% statement coverage, that assumption should be clearly stated and a method of measurement defined. というところで、具体の話が書いてあるだけなんですけども、 もしテストスケジュールというのが想定ですね、ユニットテストが行われるということを想定しているなら、 ユニットテストといっているのが、デベロッパーが100%のステートメントカバレッジをやると完了したら、 テストを始めるとかね、そんな感じで基準にするのであれば、テストスケジュールの基準にするのであれば、 その想定というものは should be clearly stated なので、しっかり明確に書いておくべきだし、 どのように計測するのかもしっかり明記しておきましょうというところですね。 次読みます。 If the code arrives and the testing has only achieved 20% coverage, the testing schedule will need to be adjusted to increase the testing time due to the increased number of undetected defects that will be delivered with the code. ということで、ここなんか表現めちゃくちゃ面白いなと思ったんですけど、 もしカバレッジが20%しかない状態で引き渡しテストが始まるというか、 場合はそのテストのスケジュールは調整しないといけないですよと。 なんでかというと、どういうふうに合わせてかというと、 increase the testing time due to なので、テストの時間を増やす必要がありますと、 due to the increased number of undetected defects から、 そのコードと一緒に運び込まれてしまった未検知の欠陥があるので、 テストの時間というところを増やす方に調整しないといけないですねと書かれています。 次が、 Alternatively, the test manager might decide to keep the original estimate and reject the code delivery due to the failure to meet the entry criteria. ということで、それかテストの時間を増やすのか、 その代わりにテストマネージャーは、 予定のもともとの見積もりというのをキープと持つために、 コードのデリバリーというものを拒否するという選択肢もありますよと。 なぜなら、 エントリークライテリアなんで、テストの開始基準に満たしていないので、 このコードは受け取れませんと。 カバリティ100%が基準なのに20%しか通っていないのであれば、 受け取れませんというふうに拒否をすると。 次のパラグラフは飛ばして、その次のパラグラフに入っていきます。 Deliverables between the project team members aren't the only items that needs to be defined on the schedule. There may be times when input or participation by other stakeholders is required before testing can progress. というところで、最初何書いてあるかというと、成果物ですね。 プロジェクトチームのメンバー間でやり取りする成果物というものは、 だけじゃなくて、他にもスケジュールの中でいろいろ定義すべきものがありますよというふうに書かれているんですけど、 次の文に書いてあったのは、 When input or participation by other stakeholders is required. 他のステークホルダーのインプット情報だったり、 何かしらの参加というものがテストを始める前に、進める前に必要になってくる場合がありますと書かれています。 その次に、具体例が書いてあるので読んでいきます。 ちょっとこの文章分かりにくいんですけど、 ユーザビリティの分析というものが必要になるかもよという話なんですけど、 どのタイミングかというと、 After initial functional testing だから最初の機能テストの後、 かつBefore non-functional testing is started 非機能テストが開始される前に、 使用性、ユーザビリティの分析が必要になる可能性がありますというふうに書かれていますね。 この例は、ちょっとこの後英語はすとばして日本語で説明をするんですけど、 他のグループとの依存関係があるよという例なんですよね。 なので、ユーザビリティの分析というのは、 ユーザビリティチームだったり、他のチームがやる可能性も高いかなと思うんですけど、 そういう人たちと成果物のやりとりが発生すると。 なので、どういう活動が必要でというものは、 プロジェクトのプランにスケジュールも含めて書かれている必要がありますよという話でした。 そして、最後の段落パラグラフには、アジャイルのことがちょっと書かれているので、 2文目から見ていきます。 In agile environment, the schedule is based on what is planned for an iteration, but during the work in the iteration, the schedule may need to adjust as items are added or deletedというところで、 アジャイルの環境においては、スケジュールが基準にするのは何を作るか、何を作る予定なのか、 そのイテレーションで何を作る予定なのかという部分でスケジュールが決まるんだけれども、 during the work in the iteration、イテレーションの中の仕事によってはスケジュールが調整される、 スケジュール、may need to adjustか、違いますね。 アイテムが追加されたり消されたりするので、 それに合わせてスケジュールを調整する必要がありますというふうに書かれています。 次を見ます。 Schedules that are established at the beginning of a project rarely remain unchanged throughout the life of the projectというところで、 スケジュール、一番最初に立てられたプロジェクトのスケジュールというのが、 そのまま変わらないで終わるというのは滅多にないですという話ですね。 最後の一文です。 This manager must keep a realistic view of the elasticity of the schedule and must monitor to detect when changes, adjustments may be warrantedというところで、 テストマネージャーというのは、スケジュールの柔軟性というのを現実的に把握をして、 変更とか調整が必要なタイミングを見極めるためにモニターをし続けなければなりませんよというふうに最後を書いてあります。 # 予算とリソースの配分 続いて6.2.3のBudgeting and Resource Allocationについて、 ちょっとサクッと読んでいきたいと思います。 この6.2.3のBudgeting and Resource Allocationというのは、 予算とあとリソースの配分ですね。 最初のパラグラフは前提のような話なので、 日本語でサクッとお話をしていきます。 このリソースの配分とか予算取りというのが 何でスケジュールに大事かというところが書かれているんですけれど、 このリソースの制約というものがかなり デストスケジュールに影響を与えるからという話です。 リソースに制約があるとですね、 複数のプロジェクトをテストマネージャーは管理をしているんですけど、 こっちのプロジェクトでたくさん使っちゃったら、 もう片方のプロジェクトであまり使えないみたいなことになってしまう。 それが結果としてテストスケジュールに かなり影響を与えてしまうので、 予算取りだったりとか、リソース費と時間、コストというところに、 どのプロジェクトに配分するのかというのが とても重要ですというふうに書かれています。 二つ目のパラグラフを読んでいきます。 バジェット予算についてそれを使うときに 考えるべきことというのが何個書いてあるのかな。 1,2,3,4,5,6,7,10個あるんですけど、いくつかピックアップします。 その1個目と2個目は人権被害注意のことが書いてあります。 コンティンジェントって予備のスタッフとかかな、 業務委託とか給与とかそういうところが絡んできます。 3つ目がバケーションアロケーションなんで、 休暇の予定も考えないといけません。 4つ目が、5つ目がエクイプメントなんで、 装備設備の話なんですけど、 テストに必要、テストされる、 テスト対象の設備だったりとか、 あと、エクイプメントユースインテスティングなんで、 テストで使われる設備、サーバーとかネットワークとかプリンター、 そのハードウェアも含めてですね、というものを バジェットに考える、バジェットで考慮する必要があります。 あとは、もちろんソフトウェアユースインテスティングなんで、 テストで使用するソフトウェア、OSだったり、 データベースなどなどというところも 考慮する必要があります。 次の段落に入っていきます。 その他にもですね、考えるべきことがあるよって書いてあって、 There may be other considerations depending on how the organization is structured and how resources may be used across the organization ということで、 どのように組織が構成されていて、 どのようにリソースが使われるのか、 組織内でいろいろ横断してというか、 組織内でどういう風にリソースが使われるのかというところも大事ですよと考えています。 例えば、specific mix of permanent employees, contractors, offshores and outsourced team members and also the skill levels of each member of the team というところで、 例えば、permanent employeesは普通の一般社員ですね、 正社員で、contractorsは業務委託とか、 offshoreはアウトソースの人たち、いろんな人たちがいるので、 どういう配置だったり能力、スキルというのがあるのかもしっかり考えないといけないですねという話です。 最後の段落です。 最後の段落ではテストマネージャーが バージェッティングはオンゴインプロセスであることを ちゃんと気にしなきゃダメよというふうに書いてあって、 バージェッティングというのは予算取りとか予算管理みたいなところが オンゴインプロセスなので、 継続的なプロセスであるというところを ちゃんと覚えていかないといけないですよ。 例えば、adding resources to the project, switching from onshore to offshore resources, finding a higher number of defects than was anticipated, or reassessing the risk on a project can all affect the budget requirements. 例えば、リソースをプロジェクトに足すという時だったり、 オンショアからオフィシャルに変えたりとか、 何か予想していたよりも多くの不具合が見つかってしまった場合とか、 リスクの再アセスメント、再強化が必要になったり、 これらのものが全部バジェットの要件にかなり影響を与えるから、 継続的に見ていかなきゃいけないですよというところが最後書いてあります。 これまでの経験を振り返ってみて、 予算取りとかリソースの配分ってどうしたかなと思うと、 例えば、1人目っきりで入った時は自分しかいないので、 全部のプロダクトのテストとか変数保証は全然できないとお話をしていて、 とはいえ新しい新規プロダクト、 新しくプロダクトを作るよというタイミングだったので、 その時に必要だとテストの設計実行を 一緒にやってくれる必要があるというところで、 上長というか開発責任者というんですかね、 エンジニアリーマネージャーの方と相談をして、 1人入れたいと、業務委託だったり、 第三者検証の方からまずは1人入れたいですみたいな、 そんな話調整をしたりしたなというのを 読んでて思い出したりしています。 あとは休憩チームを立ち上げるというところに関しては、 大体このくらいの人数が必要、 こういうスキルの人が必要だというところを考えて提案をして、 採用活動を行ってチームを作っていたというのもあるので、 そういうのも予算をどのくらいかかるかというのを考えたり、 その時に決定権というのはないので提案という形になるんですけど、 提案をして採用活動して人をハイヤーしていって、 テストプロジェクトにアサインするみたいなことはやっていましたね。 あとはある時に開発責任者の方が変わったタイミングで、 テストの予算というか人件費かけすぎだ、 人件費かけすぎだみたいな話になって減らしなさいとか、 外部業務委託じゃなくて正社員しなさいみたいなのがあって、 なかなかわちゃわちゃした時期もあったりしました。 ということで今回はテストスケジュールの定義と、 あと予算とリソースの配分についてお話をしました。 何か学びありましたでしょうか。 ぜひコメント欄で教えていただけると嬉しいです。 # 今日のほっこり話🍜 今日のほっこり話です。ラーメンの話をします。 先日ですね、夫がお昼にラーメンを作ってくれたんですけれど、 まあ作ったといっても、そうですね、チャーシューが手作りで、麺以外が手作りって感じですかね。 あとスープもなんかホタテの出汁とか、あとそのチャーシューを作った時の残りのスープというかタレというかでラーメンを作ってくれました。 これがですね、めちゃくちゃ美味しくて、 なんか気づいたら寸胴鍋が家にあったとかですね、なんか気づいたら夜のようなラーメン作ってるみたいなことにならないといいなと思っております。 以上今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただき、ありがとうございました。 次回はVoicyのトークテーマ、健康をデジタル管理についてお話をしていきます。 多分、Apple Watchの話になるんじゃないかなと思います。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 是非、画面右下、ハートマークでいいねを押していただけると、とっても励みになります。 是非是非、フォローもよろしくお願いします。 それでは、また明日お会いしましょう。 ごきげんよう。