読者です 読者をやめる 読者になる 読者になる

底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

ソフトウェアテストに関する知見

下流工程 プロジェクトマネジメント ソフトウェアテスト

テストが楽しい人って存在するんですかね。プログラミングですら「ヒーヒー」言ってるのに、さらに「テスト」となると一気に逃げ出したくなるんですよね。

 

 

「テスト」フェーズに入ると一気にゲンナリする

日々システム開発に従事していて、一つプログラムが完成すれば「次は単体テストだ」となり、関連する二つの機能が出来上がればそれらを組みあわせて「さて、結合テストだ」となる感じなんだけども、実際この辺のテストに関する技法というか手段とかって、その場その場で全く個人的に蓄積されていない。

 

単体テストに関して言えば、ロジック周りのテストなのでまぁ感覚としてわかる部分も割とあるけれど、これが結合テストとかシステムテストになってくると単体テストのノリで進めていいのかどうか正直悩むことがある。単体テストのノリでやるものでないというのはわかるのだけど、明確に「じゃあ、どうすれば正解」というのがハッキリしてないので、テスト仕様書がテスト仕様書としてきちんと書けない。で、「それ、単体テストみたいなテスト仕様書になってるよ」と言われてしまうわけです。

 

自分だけでしょうか...。

 

 

というか、本当に単体テスト結合テストのテスト項目ってそんなにかけ離れたものだったっけ。場当たり的に対応してきたので、その辺の知識が知識になっていない。

 

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

 

 

周りの人はスラスラとテスト項目を書き上げてるようにみえるので焦る

例えば画面系のシステムで、

入力テキストフィールドに数値Aと数値Bを入力して、「計算」ボタンを押下すると計算結果が結果テキストフィールドに表示されるような機能

があるとして、その画面系のテストは「結合テスト」ってことでいいのかな。

 

この場合、「入力テキストフィールド」に数値以外が入力されたら「エラー」として再入力を促すメッセージが出力されることを確認する、とか結果テキストフィールドに出力される計算結果が想定した結果になるか確認するというのは「単体テスト」で確認していることなので、結合試験ではそのテストは行わないということでいいのだろうか。

 

画面の機能と内部の計算機能が合わさって「計算結果を表示する画面」ということなので、「入力→ボタン押下→結果表示」がきちんと出来てるかどうかの項目さえあれば、「入力値が数字以外の場合」とか「計算結果が想定内の結果であるかどうか」というのはモジュール個別のテストになるので結合テストではやらなくて良い、ということでいいのか。

 

「当然やらなくて良い」という人が多いと思うけど、「やっても良い」と考える人もいるのではないか・・・。その辺の判断が過去の経験だとかでキチンと蓄積されていればよいが、場当たり的に作業をこなしてきた自分のようなクソエンジニアの場合非常に不安になる。

 

例であげたシステムは非常にシンプルなので問題ない(?)けれど、もっと複雑な仕様だったりした場合は判断が難しい。判断、というか「どんなことをテスト項目として上げればいいのか」すら浮かばないこともあるデシジョンテーブルのような、項目と条件によってどのような結果になるかを網羅的に判定するようなテスト項目など。このあたりはもう「仕様の理解がどれだけあるか」にかかってくる気がする。

 

先ほど、「入力→ボタン押下→結果表示」がきちんと出来てるかどうかの項目さえあれば、というふうに書いたけど、WEBアプリケーションの場合結果表示までのレスポンスタイムとかも項目として必要になったりしないんだろうか。今だとPCブラウザだけでなく携帯やスマホのブラウザからもキチンと確認できるかどうか等も。そもそもレスポンスタイムについては「何秒」が適正なレスポンスタイムなのかどうかも知らないし・・・。

 

ソフトウェアテスト入門 押さえておきたい<<要点・重点>>

ソフトウェアテスト入門 押さえておきたい<<要点・重点>>

 

 

結局「テスト」=「どれだけ仕様を把握してるか」の確認作業

あるプロジェクトのあるシステムにおける、ある機能の仕様に関する結合テストの1項目という非常に視野の狭い見方でテスト項目を作成するので、プロジェクトを異動して、別システムのある機能の仕様に関する結合試験、となるともうお手上げというか「最初から仕様を把握し直さないとテスト項目なんて作れません」となる。

 

C#とかの言語的な仕様(標準クラスだったり、標準メソッドだったり)はMSDNのライブラリを参照することで、必要な例外処理がわかったり引数の種類がわかったりするけれど、テストに関して言えばそういうライブラリがない。こういったテストであれば、このテスト項目を確認すればOK!というような標準も特にない。

 

たった1項目消化するだけなのに、条件に合致した大量のデータが必要だったりして項目消化自体を非常にめんどくさい。仕様を把握してれば、その機能が条件によってどういう結果を返すかを網羅的に把握できてるかどうかが鍵なんですけども。

 

基本から学ぶソフトウェアテスト

基本から学ぶソフトウェアテスト

 

 

テスト要員の地味さったらない

とはいえ、テストに関する知識が蓄積されればどこのプロジェクトのどんなシステムだろうともすぐに対応できるだろうし、そういったものは陳腐化しないのでエンジニアとして長生きできそうである。ついついプログラミングというと、言語的な知識に偏りがちだけど、もっとテストに関してきちんと勉強する必要があると思う。 

 

海外(多分アメリカ)では、テスト要員とかではなくれっきとした「テストエンジニア」という職種があるらしい。テストに関してある程度確立した知見が存在することの証明だろう。日本でもインフラ部分であるサーバ管理とかサーバ構成なんかを担当するインフラエンジニアが存在するが、テストに関してはプログラミングの添え物的なニュアンスがまだ強いのかテスト要員として招集されることはあっても、テストエンジニアとして呼ばれることはまずない。危険だと思う。

 

 

ソフトウェアテスト実践ワークブック

ソフトウェアテスト実践ワークブック

 
経験ゼロでもできるプログラミング現場の単体テスト

経験ゼロでもできるプログラミング現場の単体テスト

 
体系的ソフトウェアテスト入門

体系的ソフトウェアテスト入門