Hamata log

[2018-06-16]思いつきで開設したものの、続くのかどうか・・・

WARAI冬の陣2022でテスト計画についての話を聞いた(2022/11/26)

このブログ、とんでもなく休眠期間が続いてしまいましたが、WARAI(関西ソフトウェアテスト勉強会)に行ってきたので更新してみます。(またすぐ休眠するかもですが)

WARAI冬の陣2022 組織的テストプロセスとテスト計画を学ぶ

オンラインで自宅からラクラク参加です。コロナが流行してからというもの、色々と不自由ですがこれだけはありがたいなと思います。

タイムテーブルはこちら。

10:00~11:00 Sect.1 テスト計画を学ぶ
11:00~12:00 Sect.2 組織的テストプロセスの理想と現実
12:00~13:00 休憩
13:00~14:00 Sect.3 アジャイル開発におけるテスト計画
14:00~15:00 フリーディスカッション&情報交換会

資料は公開可能な部分がいずれ公開されるということでした。

今回の参加の動機は自組織でのテスト計画をより良くできないかなという感じのものです。テンプレートは用意するものの、結局それ埋めてハイ終わりみたいな感じの対応をされることが多く、おっさんとしては言いたくないものの魂入れてほしいなぁとか思ったりするのです。でも今どき「魂入れろ」とか言ったところで通じるわけないので、何かないものかと。できればテンプレートレベルアップできないかなみたいな動機ですね。

ちなみに今回の勉強会のきっかけは登壇者いわく、「テスト計画がテンプレートを埋めるだけの『テスト計画を作る』というタスクになっていて本質を見失ってやしないか?思考停止では??」という思いからだそうです。はい、私の動機見透かされた上に下心打ち砕かれました。いやまぁそんなうまい話ないですよね。(だいたい私が勉強会に参加するといつもこんな感じですけれど)

ということでSection1です。

Section1はASTER標準セミナーテキストとISO29119を参考に構成されているとのことでした。ISO29119は一部しか無償公開されてないので、代わりに参考書籍「ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書」 が紹介されていました。ちなみにこの本、Qbookで無償公開されているらしいです。(要会員登録)

まずASTER標準セミナーテキストによると

テスト計画は「テストの使命を明らかにし、目的を定義する」

ものなんだそうです。うーん使命ですか。そこまでは考えたことなかったなというのが正直な感想です。

ということで当然使命ってなんなんだということになります。登壇者いわくは使命とは「なぜ我々は居るのか」、目的とは「我々のミッションとはなんぞや」ということではないかと。たしかにそもそもQAを置いているのは何のためなのか、どういう事態を避けたいがために人員として自分は配置されてるの?というのを一度考えてみるというのは根っこのところの再確認のためにはいいかもしれないですね。答えが思い当たるのかという心配はありますけど。

そしてその使命や目的に合致するようにテスト活動を構築する、と話は続きます。状況(今後起こりうること)により課せられる制約(テストがどうやりにくくなるか?)の中であってもテストの目的を達成するためのアプローチとして、プロセスやルールを規定しないといけないと。その結果適切な技法なりタスク、日程を導いていくことになるようです。

で、言われてみればそうだけどできてないな、と思ったのが以下。

テスト計画はモニタリングとコントロールのフィードバックに応じて更新する

うん。書きっぱなしになってること、あるあるです。テスト後のふりかえりもあやしいくらいなので進行中のテスト計画を明示的に修正&更新なんてとてもとても。(状況の悪化に応じて悪あがきすることはありますが、それとは当然違いますからね)

テスト計画をレビューすることを考えても結局過去のテストからの教訓が必要になるわけだし、それが貯まるためには相応のプロセスがないと個人の記憶以上のものは利用できない、となってスケールしていかないですよね。

計画とはこれからの道筋を作ることで、そのためにはいろんな疑問や障害の解決を明示していくことが必要。それができれば安心感と自信をもってプロジェクトやテスト実施に臨むことができるというのが登壇者なりの解釈ということでした。

次いでISO29119の方ですが、こちらではテスト戦略およびテスト計画プロセスというのは以下から構成されているとのこと。

  1. コンテキストの理解

  2. テスト計画作成の準備

  3. リスクの特定と分析

  4. リスク低減のアプローチの特定

  5. テスト戦略の設計

  6. 人員配置とスケジュールの決定

  7. テスト計画の文書化

  8. テスト計画の合意形成

  9. テスト計画の通知と利用の開始

おぉ、こんなにあるのか。そして私が悩んでたテンプレートを埋める段階というのは7番目じゃないか。いきなりこんな後半からやったらそりゃうまくいかないわ・・。おまけに9番までやって完成じゃなくて3番から6番は反復的に実行して完成度を上げていくのだそうです。ここでも更新が大事というわけですね。

で、それぞれの要素を説明していくべきなのでしょうけど、そこは私が変に説明するよりも規格なり解説書読んでもらったほうがよさそうです。

てなわけで早々に話はまとめに。

テスト計画は段階的な策定プロセスの中で様々なステークホルダと合意形成しながら進める。

そうなんですよね。テンプレート埋める作業から始めるのではなくて、まずは関係者との対話が必要ということなんですね。うん、確かにそうだ。

テスト計画はテストチームのためだけにあるのではないし、テンプレのテスト計画書を作りきって終わりというものでもない。

ぐぬぬ。ぐうの音も出ません。

そして組織的テストプロセスとの関わりとの考察として以下が続きます

計画の合意事項に置いては過去の結果、データを参照する場面が多い。組織的なテストプロセスによって得られるテストに関するデータを新たな計画に対して用いることでテスト計画が誤った方向にいかないように是正する。

これまた納得でプロセスがないと作りっぱなしになりがちだし、見直そうとおもっても素材がない、となるんだなと。計画が大事なんだけど、エイヤッと気合を入れればなんとかなるというわけではなく、ここでも地道な積み重ねなんですね・・・。

以上がSection1の内容でした。

Section2は非公開の内容が多いので書くのは控えておきます。あと、Section3のアジャイルに関しては自分があまりアジャイル開発経験がないのと、聞いていて感じたのが「アジャイルだから特別に何かやらないといけない」みたいなのは無いんだなと言う印象だったのでこれまた特筆しなくてもいいのかなと。

短期間なのでプロセスを軽量化しないといけない、みたいな話はあるにしても根本的に違うものを持ち出さないとダメ、ということは無いんだよ、というふうに自分には聞こえました。

「検索してたどり着いたけど、ここにも欲しいこと書いてなかったかー」と思った方がいらっしゃったら、多分次のWARAIに参加してdiscordに招待してもらうのがいいかもしれません。資料も貼ってありますし、過去開催回のディスカッション内容も参照できますのでオススメです。

ということでスッキリ解決、とは行かないものの考え続けることが大事という話なのでした・・・。