ピクサー展を通じて思ったこと

　東京都現代美術館で開催されているピクサー展に行きました。

　「トイ・ストーリー」など映画の制作過程で描かれていた展示物を鑑賞して思ったことは、ソフトウェアテストやレビューに応用できそうなネタがあることです。具体的には下記3点です。

1. キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。
2. キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。
3. ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。

1.キャラクターのイメージ作りのため、監督からのイメージを絵に何枚かかいて、監督がしっくりくるまで何度も捨てては描く。

　私がテスト分析するときは、テスト実行のイメージが具象化するまで、製品と製品の周りの世界を裏紙にポンチ絵で描いては捨ててを繰り返しています。通信機能を有するソフトウェアの場合、送信と受信のやりとりをハンドシェイクのように描いて、開発者にソフトウェアで実現したいことを確認しています。後々、テスト条件で抜けや誤りが無いよう、テスト実行して確認したいことを満たせるようなテスト仕様へブラッシュアップします。

2.キャラクターの詳細な部分を描画するために、CGでいきなり描かずに粘土人形を何個か作り、CGで描くために必要な要素を洗い出している。

　外部仕様に記載されていることを「○○であること」とコピー&ペーストして内容を少し変えただけのテスト仕様にするのではなく、たとえば機能Zの設定Aと設定Bのパラメータが連動しているので、設定Aが変化したとき設定Bがどう変化して、機能Zはどうふるまうのか、外部仕様の要素を分解して要素間の関係を確認してから、機能αと機能Zの関係を確認しています。

3.ストーリーの流れをストーリーボードという大まかな絵で何点か描いたものは付箋で並べるようににして、ストーリーの流れの内容を発表(時には熱く演じて)し、スタッフと確認しながら議論やアイディアを出し、問題が無ければ徐々に詳細化している。

　外部仕様でお客様の利用シーンが上手く描けていないだけでなく、誤っていたり、機能として意味がなかったりするので、1.のポンチ絵をフローにしてから「機能Zは、□□のふるまいをして、ユーザーは△△という出力を提供しますか？」といった質問を繰り返しながら、開発工程の早い段階で欠陥を発見するようにしています。

さいごに

　自分の興味あるものや過去に学問として学んだこと、趣味といった自分の活動から、ソフトウェアテストに限らず開発全般で応用できることがありますので、ソフトウェアテスト(開発全般)が楽しくないと嘆くよりは一味工夫してみて、ソフトウェアテスト(開発全般)が楽になったりミスが減ったりして、やってみてよかったと感じることも大切だなと思いました。