当たり前。しっかりテストされたソフトウェアは質が高い。

2020-05-04ソフトウェア開発

この記事はソフトウェアの品質やテストについて知りたい人向けのものとなっています。

質の高いソフトウェアを想像してください、と言われた時どんなことを考えるでしょうか？

• たくさんの便利な機能があって、どれも使いやすいこと
• 動作もキビキビしていること

こんなことを考える人が多いのではないでしょうか？確かに、スマホやタブレットを使っていると、こんなことを期待してしまいますよね。

自分の職場では、質の高いソフトウェアとは

• ドキュメント通りに動くこと

とされていました。高機能や高速で動作すること、使いやすいことよりも優先されていたわけです。

それは何故でしょうか？

職場で開発しているソフトウェアの規模が大きいため、機能仕様や設計内容通りに動かないことがしばしば起こっていたのです。

原因を分析してみると、テストが十分実施されていなかった、という項目が毎回上位に入っています。

逆に考えると、テストを十分に行ってさえいれば、設計通りに動くソフトウェアとして洗練され、品質を高めていけるということになります。

今回はソフトウェアのテストについて以下の内容を紹介していきます。

質の高いソフトウェアって何だろう？

改めて、質の高いソフトウェアについて、僕の職場の考え方を紹介します。

「ドキュメントに書かれている通りの動作を行うこと」

当たり前のことが書かれていますが、ソースコードの規模が大きくなるほど、これを守ることが難しくなってくるのです。

変更を加えるソースコードの理解度不足、変更箇所や追加部分に関連するモジュールに対する確認不足、作成された仕様の不備など、理由は様々ですが、100万行以上のソースコードに変更を加えるのは簡単なことではありません。

そのため、ソースコードに手を加えたところや手を加えなかったところ、どちらも設計した通りの動作をするか、というテストを行うことが重要になってきます。

何故、手を加えなかった部分もテストを行うのか？それはソフトウェア開発ではソースコードに手を加えたことで、思ってもみなかった部分に影響を与えてしまう場合があるためです。

僕の職場では「ドキュメントに書かれている通りの動作を行うソフトウェアが質の高いsohtuである」と考えています。それを実現するため「十分なテストを行って、動作チェックが行われていること」が必要になっています。

ソフトウェアのテストってどんなものがあるの？

テストが重要であると書きましたが、具体的にどのようなテストを行っているのか紹介していきます。

これから紹介するテストはあくまで僕の職場で定義されているものなので、世間一般の定義とは異なるものかもしれません。

最初に行うテストはコーディングに対するものです。「プログラムの設計内容通りに、コーディングできていますか？」というチェックを行います。

ここで大切なことはプログラムの設計内容がテストで確認できるものになっていることです。答えがYesかNoになる、数字や文字が出てくる等、正しいか間違いか人間が判断できることが求められます。

人間が判断できない動作を設計した場合、結果の正しい/誤りを判断する方法が準備されていなければ、テストを行うことができず、コーディングの間違いを発見することができなくなってしまいます。

次のテストは機能仕様を満たすかどうかのテストです。「製品の機能として成立しているか？」というチェックになります。

コーディングが正しく行われ、設計通りに動作するソフトウェアが出来たとしても、ユーザーに提供する機能が成り立っていなかったら、未完成品ということになってしまいます。

製品を構成する部品一つ一つは設計通りに作られていたとしても、組み合わせを間違えてしまった場合に、このようなことが起こる可能性があります。

この誤りを修正するには、部品の組み合わせを再検討し、足りない部品の設計やコーディングやテストをやり直すことになります。たくさんの時間を使うことになってしまうため、機能を設計する時は部品の組み合わせについて、間違いが無いようにしなければいけません。

最後のテストは機能仕様に書かれていない部分のテストです。「製品を使っていて、不満に感じる部分は無いか？（例えば、長く待たされたり、目がチカチカしたりすることはないか？）」というチェックを行います。

このテストは個人によって感じ方が違う内容を含んでいるため、製品に精通している人、製品をあまり知らない人、どちらの評価結果も慎重に分析する必要があります。

仕事で出会った残念なテストたち

これまでに出会った残念なテストたちも紹介します。さすがにこれは無いでしょ！と感じるかもしれませんが、僕が実際に見かけたものです。

ソースコードを基にテストを作る

このケースは時々見かけるもので、主な理由は「作業時間不足のためテストを省略した」です。お試し実装がそのまま製品コードになってしまったケースでも見かけました。

このテストで問題なのは「全てのテストが合格になる」ことです。設計通りに実装が出来ているのか、どこかに誤りがあるのか、抽出することが出来ません。後工程でバグが出てしまうと、バグの原因になりそうなところがどこなのか検討をつけられず、総当たりで調査するなんてことになってしまいます。

設計と実装を同時並行で進め、作業の締め切りが迫ってくると、この様なテストになってしまう様です。作業計画には十分な余裕が必要ですね。

一部の条件でだけテストをしている

パラメータの値によって、動作を変える機能であるにもかかわらず、よく使うパラメータのテストだけを行い、テストを合格にしていることがあります。

あまり使わないパラメータを設定してみると、機能が正常に動作しなかったり、ソフトがクラッシュしてしまう可能性があります。

パラメータの組み合わせがたくさんあり、それぞれが違う結果になる機能のテストでこのような手抜きを見かけました。このような手抜きの理由は「テストの締め切りが迫っていたので、よく使うケースを中心に確認した」というものです。

最初の事例もそうでしたが、締め切りが迫っているとテストを省略してしまう作業者がいる様でした。

製品ソースコードを改変して動作確認している

製品ソースコードにログ出力コードを埋め込んで確認を行っているテストがありました。手を加えた部分がどこにも記録されていなかったため、動作内容にどれほど影響があるのか判断できず、僕の職場ではテストやり直しとなりました。

製品ソースコードのままで全てのテストが完了できるようになっていることが理想ですが、そうもいかないと思います。ソースコードに手を加える時は記録に残して、問題が見つかったら再現できるようにしておきたいですね。

まとめ

僕の職場のソフトウェアの品質やテストに対する考え方、ソフトウェアテストの重要性について紹介しました。

ソフトウェアのテストが重要なことはよく分かっている方がほとんどだと思いますが、実際の開発作業では手を抜いたり、ズルをしたりしてしまうことがあります。

スケジュールには余裕を持ち、テスト内容の第三者チェックをしっかり行って、質の高いソフトを開発していきたいですね。