ブログの都合上実際のプログラムとは違う順番で書くことにする。
2日目最後のクロージングセッションでSQuBOKをはじめとした知識体系が紹介された。自宅にもSQuBOKの本はあったがしばらく読んでおらず、取り上げられるということで直前に少しだけ読んでいた。もっとも、本はあくまでもガイドであるということが強調されていた。本当に詳しく知りたいなら参考文献にあたる必要がある、ということだ。
確かに、膨大な知識体系を全て吸収して使える状態になっていればよいのだが、実際にそんなことができる人はほとんどいない。各人の職務や関心に応じて一定のレベルまで知識を持っておき、その先が必要になったら文献にあたる、という使い方を想定しているようだ。もっとも、手法があることを知っていてもベースとなる考え方がないと必要なときに吸収できないし、適切なときに文献を参照する、ステークホルダーに相談する、といった行動をとれるようにするためにもある程度のスキルが必要なのだろう。
私が業務の中でテストに関係して一番問題だと思うのは計画段階でテストすべきことをもれなく抽出することである。最初の段階で間違ってしまったら、その後でどれだけ（技法などを使って）詳細を詰めても十分にテストできないことになってしまう。不覚ながら知らなかったが、テストの研究も優れたエンジニアの思考方法を抽出する、という方向に向かっている、という話も聞いた（文脈を無視してはいけないのかもしれないが）。
発想が問われる問題なので、方程式を解くようなやり方は通用しない。そもそも創造性が問われる状況に対してどのようなアプローチが可能なのか、という問題は以前から疑問に思っていたことである。如何に考えられた話であっても、話を聞いて疑問がすべて解消する、というようなことは期待できないが、学んだこと、考えたことを書いてみたい。
テストの観点をめぐる2つのセッション
テストすべき観点を抽出する、ということに関係する話としては、1日目の「リスクベースドテストを活用しよう」と2日目の「探してみようテスト条件」があった。前者については講演者によって資料が公開されているので、興味を持たれた方はこちらを参照していただきたい。
「リスクベースドテストを活用しよう」 は講義と演習の形式で行われたが、「事象の原因（ハザード）」「事象」「危害」の区別のあたりから少し食傷気味。例題としてネットゲームの話が出てきた が、筆者自身は全くやらないのでアウェーな感じ。席が一緒だった方の一人はゲーム会社に勤めているとのことで、知識としては全く太刀打ちできないが想像力を働かせて考える。
演習では重大度と発生確率の検討、 危害のリストアップ、それから危害シナリオの検討、リスク管理表の作成を行ったが、意図としては重大度と発生確率の検討、 危害のリストアップは危害シナリオより前に、独立して行う、ということだったようだ。確かに考えた危害シナリオに引っ張られてそれ以外のリスクが出てこない、といった可能性もありそうだが、筆者の場合シナリオの方が先に思い浮かんでしまった。
「探してみようテスト条件」ではラルフチャートを使ったテスト条件の洗い出しが講義と演習で扱われた。ラルフチャートはソフトウェアテストではHAYST法で使われる。条件の洗い出しが目的であればマインドマップやブレインストーミングなど他にも方法はいろいろあるが、個人的には好きなやり方である。もっとも、演習で手を動かしてみると渡された仕様書に書いてある内容から洗い出すことはできるが、それ以外のことになかなか頭が回らない。
個人ワークの後で各人が書いたものを持ち寄ってグループワークを行ったが、自分が気づかなかった条件を書いていたりして、まだまだ甘いなと思った。それと同時に、複数人で見ることによって一人だけでは抜け落ちてしまう部分をカバーするというチームとしての使い方を身をもって体験した。（もっとも、チームとして使うことを前面に出すなら、よりインタラクティブに進めることもできただろうし、今回のワークの中ではおまけくらいに考えたほうがよい。）
各方法論の関係性
ラルフチャートの使い方として、「ノイズ」や「アクティブノイズ」を条件として考慮する、という話もあり、その中にはシステムのクラッキングやネットワークの切断なども含まれる。突き詰めれば、あえてリスクベースなる概念を使わなくてもリスク低減を図ることはできてしまうのではないか？一方、リスクベースの「リスク」の概念を拡大していけば、仕様ベースのテストとの境界もかなりあいまいになるのではないか？といった疑問も出てきた。論理的にはそうなのだと思うが、人による違いはあるにせよ、問題によってアイデアが出やすいツールがあるので、道具箱に沢山道具を持っておき、必要なときに使えるようにする、ということでよいのだと思う。ソフトウェアテストの方法論については、例えばこちらにあるように、日本だけを考えても方法論が乱立している、という印象である。（大御所の先生方に対して）それが悪い、と言いたいわけでは全くなく、むしろ、各自の経験や思考方法の違いに応じて、それぞれ自らが納得でき、かつ他の人にも使える方法論を考えている、ということなのだと思う。
アジャイル開発におけるテストの話も少し出ていたのでアジャイルテストの本（これとか）を見直してみたが、 計画段階から詳細な技法レベルまで、「抜け漏れのないテストを行う方法」についてはほとんど記述がなく（！）、その一方でチームとしての協力の仕方や（自動化関係だけでなくアナログなものを含む）ツールの使い方などはストーリーを含めて豊富な記述がある（少なくとも筆者にはそう思える）。
アジャイル開発ではスキルもモチベーションも高いエンジニアが開発に参加するから、詳細な技術は必要になったら学ぶ、ということでテスト条件の抽出などは対象外としているのだろうか。あるいはクリティカルなシステムにアジャイル開発が適用されることは少ない、ということも影響しているかもしれない。
逆にテスト方法論を考える側は重いフレームワークを作っているように感じる。実際には一人でフレームワークに従って進める、というものではなくチームとして品質を保証していることは認識されているが、一人で完結させる前提のときと複数人で互いを補う場合とでは立ち位置は微妙に変わるのではないかと思う。
ソフトウェア開発が扱う仕事の幅は広い。それを単一の方法論でカバーしようとなると、どこかで現実に合わない部分ができるか、実務に使えない抽象的なものになるか、あるいは異なる前提に基づくものの寄せ集めになる可能性が高い。その意味で、クロージングセッションでも紹介されたSEMATのように、異なるプラクティスを組み合わせるという進め方は有効なのだろう。その際にはプロジェクトや個人、チーム、組織の状況に合ったものを採用する必要がある。それも「○○のときは××」といった機械的なものではなく、メンバー間やステークホルダーとの関係も考慮したものになるだろう。
個人と書いたのは、少し話がそれるが、以前あるイベントに参加したときに、どうしてもマインドマップが使えない、と話している方がいたことを思い出したからだ。その方ができることとしては、 無理やりにでもマインドマップを習得する、あるいはマインドマップを使わなくても豊かな発想ができる方法を身につけるなどである。どうするのがよいかは脳というハードウェアの構造次第である。それほど極端ではないにせよ、人による向き、不向きはあるので、外部の状況だけで一概にこのやり方がよいとはいえない。
以上、WACATEで学んだこと、考えたことを独断と偏見に基づいて書き連ねてみたが（一応今回の投稿で終わりのつもり）、ある程度はつながったかなと思う。Scienceの言葉で表現しようとすると一部しかできなさそう（むしろArtに近そう）だが、本当に奥が深い世界である。改めて関係者の皆さんに感謝するとともに、日々の業務で使えるようにしていきたい。
