右脳系エンジニアのブログ

エンジニアとしての生き方のプロトタイピング、新しい社会のプロトタイプづくりをしています。

ソフトウェアテストについてこの1年で学んだこと

ソフトウェアテスト

「Software Test & Quality Advent Calendar 2011」の12/3エントリーとして書かせていただきます。よろしくお願いします。

私がソフトウェアテストについて勉強をはじめて2年ほどになりますが、今年の1年はさまざまなキーワードに触れたり、取り組んだりすることで考え方が広がったように思います。
今回は、それらについてまとめさせていただく機会にしようと思っています。

ドキュメント・仕様

  • XDDP/清水吉男氏
  • Sphinx
  • BlockDiag

ドキュメントって、意外と良い書き方やフレームワークについては触れられてないんだな・・・
という印象を持っていたんですが、清水吉男氏のXDDPや書籍「要求を仕様化する技術・表現する技術」
私的に興味深いと思いました。

ドキュメントを書いてもすぐに陳腐化してしまうのは悩ましいところです。。
仕様書とテストを上手く結びつけて管理できるツールがあればと思っていますが、今のところクリティカルなものには出会っていません。

SphinxやBlockDiagは先日の勉強会で紹介されていました。
まだ触っていないので内容を紹介できないのですが、興味深いツールだったのでキーワードとして紹介させていただきます。

来年はこのテーマを中心に据えようと思っています。

要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?

Sphinx
http://sphinx-users.jp/

BlockDiag
http://blockdiag.com/ja/blockdiag/

レビュー・プロトタイピング

このテーマについて、今年の話題で私の興味を引いたのは、SQiPでの中小路さんによる
講演だったと思います。

ソフトウェア品質シンポジウム2011（SQiP2011）
http://www.juse.or.jp/software/327/?juse-sqip

通常のレビューやデザインカンプみたいなものだと、GUIに関わる「いい感じの動作」
をレビューできない（それを「時間についての表現ができない」とおっしゃっておられました）という問題がある
という命題について、考える良い機会となったと思います。

私も多少デザインをやるので、そうした場所に立ち入ることがありますが、
HTML/jQueryでささっと表面を実装してしまい、レビューするという方法もやってみたりしていました。

また実装が多少なりともともなう場合は軽量のフレームワークを使ってプロトタイピングするという方法で
上手くレビューを行うことができるのではないかなと思います。
Play!などは縁あって触る機会があったのですが、非常に軽量に開発を行うことができるため
こうしたフレームワークを利用したプロトタイピングを検討してみる、
あるいはもっと最適化されたツールを探したり開発したりするのも面白いのと思います。

ブラックボックステスト

  • All-Pair法
  • 探索的テスト

ブラックボックスについては非常にたくさん考え、取り組みを行ってきた分野でした。
その中でもPairwise（All-Pair）法は長い時間をかけて取り組んだ話題でした。
組合せを自動的に生成してくれるというだけではなく
因子と水準を上手く管理していったり、TestLinkなどの管理ツールと上手く連携すれば
もっと面白い手法になってくるんじゃないかなと思います。

また、1月のJaSST Tokyo の基調講演でリー・コープランド氏が紹介されていた
「探索的テスト」は非常に興味深く、上手く導入を進めていければと思う一方、
現状では「何をするためのテストか」という説明をしにくく、
また理解も得られにくい方法だろうな・・・ということを考えたりしました。

計測・定量化

前回のエントリーでEmmaについて書かせていただきましたが、テストのカバレッジ計測について
調べたりもしました。

Emmaを使っていて面白いなと思ったのはブラックボックステストをおこなってもカバレッジが取れるところで
これを使って何かできないかな〜とか考えていました。

直接品質の高さを示すような指標としては難しいかもしれませんが、
「仕様の記述が十分であったかを仕様テストの実施後にカバレッジを出して、少なくとも通っていないところがあったら不合格にする」
というような社内プロセスの基準値としては応用可能かもしれません。

最後に

こういう仕事をやっていて思うのですが、ソフトウェア品質をあげるためのもっとも良い方法は
それを評価する制度を設計することではないかなと思いました。

ユニットテストも自動化もドキュメントも、たくさんの方法が議論されていて、でもそれを使えないのは
社内の抵抗が強かったり、やったところでたいした評価もされないような組織のあり方なんじゃないかと
ぼんやり思ったりします。

でもそれは、もともと私がエンジニア畑の人間ではなく、マネジメントとかマーケティング、コーチングなどをやってきた人間だからなのかもしれません。
ソフトウェアテストに取り組む原動力も「こうしたらみんなもっと楽しく開発できるじゃん」という感じの人間なので。

いつかは、エンジニアがよりよく働ける環境をつくれるような立場で仕事をする、ということが出来たら幸せなのかな。


＃まだまだ参加人数少なく、これでは12/25まで持たないので、
＃このエントリー見てくださった方も、一緒に Advent Calendar やりませんか？
http://atnd.org/events/22833