|
SQLite本体のコードが67ksに対して、テストコードが4m5678ksらしい。 679倍の規模のテストがあるわけで、SQLiteプロジェクトの品質に対する熱意がよくわかる。 天の孔雀はかつて回帰テストの自動化をするためのプロジェクトに参画することがあったが、回帰テストをコーディングするためには、たしかにかなりの労力が必要であることはその時に分かった。ただ、残念ながらそのテストコードはMSVBScriptのスキルが必要であったが、そのプロジェクトにいる人が皆COBOLな人たちで、なんでわざわざVBScriptを覚えて、テストコードを書かなければならないのか理解してもらえなかった。彼らの言い分としては、これらの画面の仕様は自分たちの頭の中に入っており、テストコードを記述しなくても、何を試験すればいいのか分かっている、ということだった。 ちなみにCOBOLプログラムを検証するVBScriptのコードの規模は同等の規模であった。残念ながら、私はプロジェクトを離れたため、テストコードを記述する人がいなくなってしまったが、今でもこのCOBOLプログラムは人力によってテストが行われているらしい。一応、テストスクリプトを最短で作成する方法を記述したドキュメントは残したのだが、COBOLの世界からは出ることはなかったようである。 巷には特定の開発言語のプログラミングに関する書籍は大量に溢れているが、テストに注力して書かれている書籍はかなり少ない。そうとうニッチな本である。言い換えるとプログラマの人々はテストの重要性を理解しながら、テストを効率よくやるということには目がいかないのではないかと思う。それは要求された仕様をどのように実現するかということだけに思考が向かっており、仕様が満たされているかどうかを検証することはあとで考えればいい、みたいな風潮があるのかもしれない。
そう、そういえば同じ部署で以前、天の孔雀に少し火が付いているプロジェクトで、手が足りないので結合試験を一週間で実施してほしいというオーダーが下されたことがあった。一応、引き受けてはみはしたものの、設計には何のかかわりもない私には、残念ながら実施することができなかった。テストの目的が不明、テストの対象となるドキュメントが未整備、実装だけに特化している設計書、これらからテストを導き出すには到底無理であった。その他の要因にもより、(天の孔雀は口が悪く思ったことはすぐ口に出すので、これがプロジェクトの一部の人にはムカつかれたのであろう、私に対して苦情が何件も届いたらしく、部署のトップマネージメントは私をいい加減にしてくれと言ってテンションをさらに下げたので、)私は一週間後に「無理です」と言って断ってしまった。 テストは理想的に言えば、設計を行ったものがテストを作成することが望ましい。設計とは何の関係もない人にテストを無茶振りするのはマネージメントの失敗としか言いようがない。逆に言うと、設計の段階で試験をどのように実施していくことがイメージ出来ていなければ、システム開発はどつぼに嵌まるのは間違いない。
だから、SQLiteのテストコードの多さは、このプロジェクトがテストをどう考えているかを如実に表す数値であり、これこそ品質を大事にするという考え方の物的証拠なのだと思う。 また、テスト工程というのはテスト実施→バグ発生→故障票記入→再現確認→プログラム改修→構成管理→再リリースという手順があるだけに、意外と生産性が低くなりやすい。プロジェクトによってはテストの生産性がコーディングよりも高めで設定されている場合もあるが、むしろテストの生産性は低いと考えたほうが現実的なのかもしれない。実装の生産性に対してテスト工程の生産性は半分くらいと考えたほうが適切かもしれない。しかし、大抵のプロジェクト計画ではテスト工程の生産性は実装の生産性よりも高く見積もっているところがほとんどであろう。だが、もう一度SQLiteのテストコードの規模を見れば、テスト工程のほうが実装工程よりも作業量が多いというのはあながち嘘とは言い切れない気がする。
そこで、天の孔雀としては、設計の成果物として、テスト項目票を入れるというのがいいのではないかと考える。また、フレームワークの設計などで、極力POJOを使うようなアーキテクトを採用したりするのも方策の一つなのではなかろうか。な〜んて、適当なことを考えながら、『現場で使えるソフトウェアテストJava編』を読みつつ、今日は眠ることにする。 |
- >
- コンピュータとインターネット
- >
- コンピュータ
- >
- ソフトウェア
コメント（0）
