ソフトウェアの品質を保ちつつテスト工程を減らすには？

ソフトウェアの品質を高めたい、でもテスト工程を減らしたい、でもどうしたらよいの？と思っている方々もいると思います。

今回はエンジニア目線から見たテストについて語りたいと思います。

自己紹介

プログラミング歴15年の現役プログラマー。現在は都内のIT企業でソフトウェアの開発を行っております。 DevOpsを実践しながら、毎日戦っています。

テストチームって必要なの？

チームとして存在する必要があるかどうかで言えば、なんとも言えません。ただ、テストの仕組みを作る人や計画を練る人、テストを実施する人は必要です。

テストしなければバグが見つかりません。エンジニアも神ではないので、当然、実装漏れや勘違い、設計が違ったなんてこともあります。

しかしながら、四度の転職をして、四度目の転職で、ようやく真面目にテストチームがテストしている会社に転職しました。

本当か？と思う方もいるでしょう。もしかしたら、私の経験が世間とズレている可能性は大いにあります。しかし、少なくとも私が知る限りQAチームがあるにもかかわらず、まったくテストしない会社というのが現実に存在します。そのような会社のQAは判子を押すのが仕事だと思っているようで、実質何もしていない人たちでした。

それらの会社はエンジニアが頑張って品質を担保していました。結果としてエンジニアの負荷が増大し、QAが会社のコストセンターになっていました。

このような経験から、テストチームやQAチームの存在価値を問われると、私は答えに窮します。ただ、自信を持って言えるのは、テストを誰かがやらなければいけない、ということです。 ですので、この記事では、誰が、ではなく、何をに焦点を当てていきたいと思います。

テスト真面目にやると一生リリースできない

思いつくテストをすべてやると、一生かけてもリリースするのが不可能になります。よって、境界値テストなど、テスト数を減らす手法が数多く編み出されました。

それらの手法を知ることは大切です。特にブラックボックステストをするときは、ある程度根拠をもってテスト工程を減らす必要があるでしょう。

例えば、ユーザー情報を入力する画面があったとして、すべての文字列の組み合わせをテストしていたら、計算するのも面倒なくらいに時間がかかるでしょう。

もし、テスト経験が浅い人であれば、テスト工程を減らすことに抵抗を感じるかもしれません。しかし、現実的に考えると、テスト工程を間引くというのはテストを実施するのと同じくらい大切です。

こちらの本では、基本的なテストの考え方が説明されているので、ぜひ一読することをお勧めします。

一生リリースできないソフトウェアにはなんの価値もありません。リリースできない完璧なソフトウェアよりも、リリースできる細かいバグがあるソフトウェアの方が価値は高いといえます。よっていかに効率よくテストするかが重要でしょう。

テストの自動化

テストを少しでも効率化するには、テストの自動化は避けられないでしょう。
私の前半のキャリアのうち半分はテスト自動化のソフトウェアの開発をしていました。

私が開発していたテストツールと同じような商用ツールはすでに販売されていたのですが、Windows上で動く上に、2ライセンスで数十万円する代物でした。よって、これをLinuxで作り、機能的にはまったく同じかそれ以上のものを作りました。

Linuxだったので、無限にインストールしても無料、稟議もいらない、しかも品質も担保できる、という仕組みを作り上げました。貢献したことは以下です。

貢献したこと

• テストの費用を億単位で削減。
• 製品の品質向上による社会的信用の向上
• 営業のセールストークとして使用
• 海外の協力会社へテストツールを提供し、技術的連携の強化
• QAが機能していなくても品質向上

社会的信用の向上はかなり重要で、以前、私が勤めていた会社の製品が市場で不具合を爆発させたことがあり、信用を失っていました。それを回復するというのは大きな使命であったと思います。

私の給料なんて、これらの利益に比べたら軽いものではないでしょうか。企業からしたら、安くてリターンのよい投資だったと思います。

実際はそこまでテストにお金かけられない、と考えている人たちもいるでしょうし、システムによっては確かにテスト自動化するのが難しいものもあると思います。

しかし、部分的でもよいのでテストを自動化できるところがないか、そして、それを考える人を専属で一人割り当てても、お釣りがくるかもしれませんよ！

ソフトウェアテストエンジニアに会ったことがない

これはもしかしたら日本企業の特徴かもしれませんが、私はソフトウェアテストエンジニアと呼べる人にまだ会ったことがないです。おそらく、一番それに近いことをしたことがあるのは私かもしれません。

以下はIndeedで"Software Test Engineer"で場所をカリフォルニアで検索した際の募集要項にあったものを一部掲載します。ちなみに、要求が軽いやつを選びました。

Role & Responsibilities

• Review Customer Solution Requirement Docs (SRDs)
• Design and Validate Customer use cases
• Automate use cases using Pythons
• Participate in innovative Software test initiatives
• Work closely with the field to successfully enable the Solutions

Automate use cases using Pythonsという所ですが、Pythonでテストケース自動化してね。という意味です。要するに、テストケース考えるのは当たり前で、テストケースを自動化するところまでがあなたの仕事ですよ、という意味です。

面白いのでもう一つ例をあげましょう。こちらは少々重いヤツです。

Role & Responsibilities

• Implement software and systems from requirements to production and commercial deployment
• Develop,code, test and debug system software
• Developand manage schedules
• Performand document comprehensive system and unit level testing
• Interfacewith firmware and hardware teams
• Assessthird party and open source software

いや、これ普通にソフトウェアエンジニアじゃね？って私が思うのは、私が日本人だからでしょうか。

以前、オーストラリアの上司とテスターを雇うかどうかの話になったときに、日本人のテスターはスクリプト書けない人多いと思う、と言ったところ、上司は、え、マジで？？という感じで絶句していました。

ただし、日本だとそもそもお客様神様の文化なので、お客様の使用を細かく実装しようとしすぎて、いちいちテストなんて書いてられない、という反論も聞いたことがあります。確かにそれも一理あります。それが正しいとするならば、ソフトウェアの品質をあげつつテストのコストを下げるには、まず文化を変える必要があるということになりそうです。

まぁ、それが原因かどうか分かりませんが、今だにソフトウェアテストエンジニアに会ったことがないのです。そして、テストの自動化が難しい原因がおそらくそこにあるのではないかと思います。

DevOpsはどうなのよ

DevOpsを聞いたことない人のためにざっくり説明すると、小さいチームを作って、組織の縦割りの壁をなくして、みんな一緒に協力して成果をあげよう、という思想であり方法です。

私はこの考え方は賛成です。

基本的に大きい企業よりもベンチャー企業の方が動きは速いです。DevOpsは小さいベンチャーを社内につくる行為とも解釈できます。テストとなんの関係があるの、というと大いにあります。ほとんどの会社において、テストチームを別チームとして扱っています。しかし、同じチームにテスターを入れてしまうわけです。

私の今のチームでもDevOpsを実践しています。テストする人と嫌でも直接コミュニケーションとるので、無駄なテストというのは今のところ発生していません。

DevOps界隈では結構有名な本(だと思う)ですが、こちらは大きい組織がいかにしてDevOps体制に行くまでかが記されています。テストとは直接関係ないですが、小説みたいな感じで書いてあるので読みやすいです。ちょっと半沢直樹入ってるかも？

同じチームにテスターがいると、客観性の欠いたテストになりそうです。確かにその傾向がありますので、今度はエンジニアとテスターがどういう距離感で仕事をするのかが現状の課題といったところです。

それでもやはり、効率面を考えるとDevOps体制は試す価値があります。

TDDは実際どうなのよ

Test Driven Developmentの略です。テスト駆動開発のことであり、最近注目されている開発手法です。

フロー

1. テストを書く
2. テストFailするのを確認
3. テストがパスするコードを汚く実装する
4. テストPassするのを確認
5. リファクタリングする
6. テストPassするのを確認
7. 1に戻る

この手法のよいところは、テストコードが仕様書である、という点です。実際1年以上TDDを実施して、私が感じた長所短所をあげたいと思います。

長所

• テストコードを見れば仕様が分かる
• リファクタリングしやすい
• アルゴリズム系のコード実装には最適
• 無駄なテストが入りにくい

短所

• どこまでTDDを適用すればよいか不明
• 仕様変更になったときに辛いことになる
• 無理やりやろうとすると、どうテストを実装するかで悩むことが多い

アルゴリズムやロジックの実装にはTDDは非常に有用であり、ぜひ導入すべきだと思います。こちらの本が分かりやすいです。

しかし、結合を伴うようなモノの場合、無理してTDDすると仕様変更が起きた場合にかなり辛いことになります。TDDの適用範囲を間違えると内部設計を縛ってしまうことになるので、かなり変更に弱いソフトウェアになってしまいます。

よって、私はフレームと部品とを分けて設計するように心がけています。TDDを適用するのは部品のみに絞り、フレームは手動でテストしてあとは結合テストで結合が上手くいっているかを見るようにしています。その話はテストの間引きにも関係していますが、どちらかというと設計寄りの話なので、別の機会に取り上げたいと思います。

TDDさえやれば完璧かのうような論調で話す人をたまに見かけますが、そんなことはありません。むしろ、他の手法と組み合わせて使うべきです。

長所もあるので、ぜひ導入を検討しましょう。

でも、やっぱりバグ出るよね

それでもバグはでます。やはりでます。ですので、バグが出たら、どうすればこのバグは出なかったのかをその都度考えて、可能な範囲で改善していくしかないと私は思います。

結局、仕様をそもそも勘違いしていたり、単純に想定していなかったりと、いかにも人間臭い理由で問題が起きます。想定していないものや、勘違いがまったく起きないのであれば、交通事故はゼロになるでしょう。

こういうやり方をやれば、理論的には問題がなくなる、というのは非現実的な考え方だと私は思います。例えばTDDを適用しても、そもそも想定しているケースが抜けていたら、不完全なコードができあがります。他にも、開発している最中に仕様が変わっていき、もともとバグじゃなかったものがバグ扱いされる、というケースもあります。

どうやってそれらを防ぐのでしょうか？私は答えが見つかりません。

だからこそ、なぜその問題が起きたのかを分析するかが重要になるのです。ケースバイケースで対応、改善するしかないでしょう。