理解されないソフトウェアテストの難しさ

この記事は約3分で読めます。

ソフトウェアテストは、ソフトウェアが正しく期待通りの動作をするかどうか、意図しない動作をしないかどうかを確認する作業のことです。

このソフトウェアテストですが、製品開発の現場では軽視されがちです。

たかがテストという風潮は少なからず存在し、テストは設計開発ができない人がするもの、もしくは開発エンジニアが片手間に行うもの、そのようなイメージはいまだ根強く残っています。


最近でこそ、世の中のIT化の流れを受けてソフトウェアテストに対する重要性の認知は高まってきてはいますが、ソフトウェアに疎い会社の上層部の人たちはソフトウェアの性質を学ぼうともしません。

過去の自分たちの経験に当てはめて、精神論でことを語りがちです。

私はそれに大いに不満を感じています。

軽視されているテスト工程

メーカーにおける花形と言えば、やはり開発エンジニアでしょう。

開発はモノづくりの上流工程に位置し、すべてはそこから始まります。

開発工程がモノづくりの要であることに疑いの余地はありません。


一方で、出来上がった製品やサービスの評価やテスト工程というのはどのように捉えられているでしょうか。

私自身、このような製品の評価・テストに携わる立場の人間ですが、実際のところ評価・テスト工程というのは開発工程や設計工程に比べて軽視されていると感じています。

「品質は上流工程で作り込む」という言葉もあるように、下流工程に求められる役割(品質保証)も実質的に上流工程が担っているというところがあります


逆に言うと、テスト工程自体に求められる役割が曖昧になってしまうため、テスト工程が抱えている問題点なども顕在化しにくく、軽視されてしまうのです。

ソフトウェアテストの問題点

多くのソフトウェア開発の現場においても、それは同様なようです。

たかがテストという風潮は少なからず存在し、テストは設計開発ができない人がするもの、もしくは開発エンジニアが片手間に行うもの、そのようなイメージはいまだ根強く残っています。

また、そのような風潮の中で行われるソフトウェアテストの標準化はあまり進んでおらず、属人的な作業に頼っている(担当者任せの作業となっている)ケースも多く見受けられます。


しかしながら、ソフトウェアテストは専門的な技術やノウハウが必要なものです。

単純な入力テストにしても、すべての入力項目の組み合わせをテストしようとするとその作業量は膨大な量になってしまいます。

時間がいくらあっても足りません。


ですから、総当たりのテストを行うことなく、それでいてソフトウェアの欠陥を見逃すことはない、そんなテスト方法を考案できるソフトウェアテストエンジニアには大きな価値があると言えるのです。

理解されないソフトウェアテストの難しさ

ですが、そうしたソフトウェアテストの価値や実情をわかろうとせず、軽はずみな発言をする人たちは多くいます

特に、日本のメーカーでは組織のトップや経営陣が機械またはハードウェア系のエンジニアであることも多く、ソフトウェア、ことソフトウェアテストに対する認知は進んでいないように思えます。

品質保証に携わるエンジニアにしても、機械や電気系の評価はできてもソフトウェアのことはまるでわからないという人たちも少なくありません。

結局、ソフトウェアテストは開発エンジニアが担当することになり、それがソフトウェア開発者の負担の増大を招く一因となっています


それでいて、ソフトウェアの不具合が見つかると、しきりに開発エンジニアが非難の矢面に立たされるのです。

ソフトウェアのことはわからないと開発エンジニアに仕事を丸投げしていた人たちが、開発エンジニアが知恵を絞って考えたテストの方法に不平不満を述べるわけです。

知恵を出してくれるわけでもない、手を貸すわけでもない人たちが、口だけは出してくるわけです。


何を隠そう、それが私の(部署)の仕事です。

このような仕事に対して、私は大いに不満を感じています。

コメント

タイトルとURLをコピーしました