2023/3 動作確認やテストを通じて学んだ2年目の失敗
大阪事業所に文系学部から新卒として入社し、2年が過ぎようとしています。
完全未経験でしたが、設計～実装～テスト～運用保守までエンジニアとして経験を積むことができ、自身の課題もたくさん見つかっています。
その中でも特に、実装の動作確認や単体テスト実施の部分での難しさを感じましたので、自分の中で見つかった課題やそれに対する教訓をお話しします。
動作確認での確認漏れ
実装とその後の動作確認はセットになっており、動作確認を疎かにしてしまうと手戻りや、テスト時のバグ修正が増えてしまいます。
自分では動作確認をおろそかにしていたつもりはないのですが、ソース調整した際の影響範囲の考慮不足や、動作確認のパターン漏れで指摘をいただくことが多かったです。
実装は難しい分、「動くものができていく」という面白い部分も多くあるので、完成した際の達成感で「終わった」と勘違いしてしまい、動作確認がおろそかになっていた部分もあるかもしれません。
以前からこの部分に課題を感じていた私は、テスト技法に関する書籍を読んで勉強したのですが、いざ実務になるとなかなか使いこなせませんでした。実際のシステムは画面遷移や動作パターンが多く、付け焼刃のテスト技法ではうまくパターン化できなかったです。結局地道に書き出すほうが今の私のレベルにあっていました。
この課題は継続中で、早く正確に動作確認できるようになる必要があると感じています。机上で学んだテスト技法を実務の中で少しずつ使用していき、慣れていくことを意識して取り組んでいるところです。
テスト仕様書のテンプレートに固執していた
多くのプロジェクトではテスト仕様書のテンプレートが用意されていると思います。プロジェクトによっては同じような機能をいくつも作るため、テスト仕様書のテンプレートもその機能に特化したものとなっていることがあります。
私も、ある機能に特化したテンプレートを使用して仕様書作成を行っていたのですが、ある時、仕様が特殊な機能をテストすることになりました。
当時の私は、いつも通りのテンプレートに無理やり当て込めるようにしてテスト仕様書を作成し、その結果、仕様を網羅しきれずに単体テストで多くのバグを見過ごすこととなってしまいました。
その時の私はテスト仕様書を仕上げることにしか意識が向いておらず、本来の目的である「バグを発見、修正し、品質を上げる」ということがおろそかになっていました。「なんのためにこの作業をしているか」という観点が足りなかったです。
テスト仕様書のテンプレートはとても便利ですが、時にそれだけでは網羅しきれない場合もあります。その場合は無理に当て込まず、別紙にテスト項目を書き出したり、図に起こす必要があります。 大切なことはテスト仕様書をつくることではなく、品質の確保です。
もちろん、テスト項目の別紙を作成したりすることで、テンプレートを使用するだけの時よりも当然工数がかかります。その部分についてはリーダーやマネージャーなどと相談し、スケジュールなどの調整をしていくことが必要があります。
テスト仕様書の作成からソフトウェア開発において大切な心構えや、取り組み方を学ぶことができたと思っています。
テストを前提とした設計をしなかった
設計書の作成を任された際、テスト仕様書は設計書を基に作るということを忘れていました。その結果、テスト仕様書を制作する際に観点の洗い出しで時間がかかってしまったり、テスト観点の考慮漏れが発生してしまうリスクが高くなっていると気づきました。
設計する際には「この設計書を見れば誰でも実装ができるか。」という意識を持って取り組んでいましたが、 「この設計書を見れば誰でもテスト仕様書が作れるか。」
という観点は持っていなかったです。
また、ソフトウェアの不具合は大きく分けて
- 「できるべきことができない。」
- 「できてはいけないことができてしまう」
の2パターンがあり、後者のほうが発見しづらいといわれています。
実際、私が開発していく中でも後者の不具合が多くありました。
設計段階で「できるべきこと」を明確にしておくことが、「できてはいけないことができてしまう」リスクを低減させるはずです。そういった意味でも設計書づくりは高品質のシステムを作るうえで大切なことだと学びました。
テストのことを意識して設計していれば、デシジョンテーブルや状態遷移テストなど、勉強したテスト技法も利用しやすかったでしょうし、動作確認時の観点漏れなどをもう少し減らせたのかなと感じています。
最後に
テストは比較的簡単な作業として、若手エンジニアが担当することが多い工程だと思いますが、その中には設計や実装におけるヒントがたくさんあることに気づくことができました。
テスト・動作確認のことを念頭に置きながら、ドキュメントづくりや開発を行っていくことが不具合の少ないシステムを作るうえで不可欠だと感じています。