もっと知ってほしいソフトウェアテストのあれこれ
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
前回、ソフトウェアテストは
みんなに笑顔を届けるお仕事
と言うことをお伝えしたね。
今回はソフトウェアテストの技術者や
ソフトウェアテストのお仕事で
誤解されやすいポイントのお話をするよ。
結構、誤解されてるポイントって多いので、
今日はJSTQB Foundation Level
（以下、JSTQB FLと書くよ）
のシラバスの中にある二つのポイントと、
個人的に誤解されてると感じるポイントを一つ、
合計三つのポイントをお伝えするね。
1. ソフトウェアテストの範囲
ソフトウェアの動きの確認と
不具合探し（バグ出し）だけのお仕事と
思ってる人も多いんだけど、
「ソフトウェアテスト」には
計画を立てたり、分析、設計、実装、実行、
進行状態や結果の報告、
テストしたソフトウェアのの評価まで
色んな活動（プロセス）が含まれてるよ。
テストに関するよくある誤解の 1 つは、テストはソフトウェアを実行し結果を確認するだけだというものである。1.4 節で説明するように、ソフトウェアテストはさまざまな活動を含むプロセスである。テス ト実行(結果の確認を含む)は、それらの活動の 1 つにすぎない。テストプロセスは、テストの計画、 分析、設計、実装、テスト進捗と結果の報告、テスト対象の品質評価などの作業を含む。
テスト対象のコンポーネントやシステムを実行することは、動的テストと呼ぶ。テスト対象のコンポー
ネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストー
リー、ソースコードなどの作業成果物をレビューする活動も含む。
JSTQB FLシラバスにもある通り、
ソフトウェアテストに関わる活動を
テストプロセスと呼ぶんだ。
テストプロセスについては、
また、別の機会に取り上げるよ。
一つ目の誤解について補足すると
IT業界やソフトウェアテストを
知らない人だけじゃなくて、
ソフトウェアテストの担当者の中にも
用意されたテストの確認項目をチェックして
消化していくだけが目的になってる人、
不具合の数だけにしか注目してない人も
少なからず存在しているんだ。
ソフトウェアテストは
プログラマーに比べるとマイナーな
お仕事ではあるし
仮にソフトウェアテストのお仕事に就いても、
会社や部門なんかによって考え方が
大きく違う場合も多いし
ソフトウェアテストのお仕事の目的を
説明したりする人が周りにいないことも
原因の一つなんじゃないかと思ってるよ。
テスト担当のメンバーを管理する人、
教育する人が不足している
と言えるかも知れないね？
2. 検証と妥当性確認
二つ目の誤解は仕様通りに動けばいいと
思ってテストを進めてしまうことがあるんだ。
設計と言う役割でシステムの
設計図（仕様）を作って、
開発で設計されたシステムを作っているから
問題なさそうだけど、それだけでは十分な
ソフトウェアテストをしたと言えないんだ。
テストに関するもう 1 つのよくある誤解は、テストは要件、ユーザーストーリー、またはその他の仕様の検証に重点を置くことがすべてだというものである。テストでは、指定されている要件をシステムが 満たすかどうかを確認することに加えて、妥当性確認も行う。妥当性確認では、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていることを確認する。
技術者資格試験のシラバス（教育要項）な上に、
カタカナ英語の羅列のせいで何言ってるか
分かりにくい表現だよね、、、
仕様通りの確認だけでなく
「妥当性確認」も行うとあるね？
例えばスマホのアプリの画面で
「YES」と「NO」のボタンが表示される
と言う仕様書に書かれている場合に
こんなに小さくて、
ほとんどくっついてるボタンが出たら？
仕様書通り「YES」と「NO」は出ているので
仕様を検証すると言う点で見ると
「正しい」と言う判定になってしまうんだ。
でも、こんなボタンだと指でタップする時、
「YES」を押したつもりが「NO」を押した時の
動きになったり、逆のパターンもあり得るので、
かなり気をつけて操作しないといけないし、
とっても使いづらいよね？
仕様書や資料に書いてないけど
製品やシステムを使う上での
「正しい」かどうか？と言う見方をするのが
妥当性確認と言う考え方なんだ。
かなり極端な例にしたけど、
他にも動作が遅すぎたり、
画面に表示される情報が多すぎて、何を見て
どうすれば動かせるか分からないとか、
製品、システムを使う良い子のみんなが
困るようなこと、顧客満足度を考えて
しっかり見ることが大事だと言ってるんだね。
ざっくり言うと
イけてない製品、システムになってないか？
を確認すると言うイメージでいいんじゃないかな？
もちろん、仕様通りに動くことが前提なので、
どちらか一方が欠けてもダメなんだ。
仕様書や開発側の視点で正しいかどうかを
Verification（検証）。
ユーザーの視点から製品、システムとして
正しいかどうかをValidation（妥当性確認）。
二つを合わせてV&Vと呼んだりするんだ。
3. ソフトウェアテスト技術者
３つ目は「設計」や「開発」と言った
製品、システムを作る人と違って
技術を必要としない「誰でもできる仕事」と
思われがちだったりするんだ。
テストの一部は確かに経験の
浅い人にもできる仕事に入ると思う。
例えば、しっかり整理されたテスト用の資料、
テスト用の環境、テスト実施の細かな手順と
どんな結果がOKでどんな結果が出たら不具合か？も
分かるように書かれているものなどなど
全てのお膳立てが出来ていれば、
テスト項目の消化、不具合を見つけること
はできると思うんだ。
では、そのお膳立ては誰がするか？
手順、期待する結果、各種データや資料については、
しっかりした技術を持った誰かが必要になるよね？
一つ目の誤解に繋がるけど
ソフトウェアテストは
「テストの計画、 分析、設計、実装、テスト進捗と結果の報告、テスト対象の品質評価」
と書かれていたね？
つまり、ソフトウェアテストには
ソフトウェアテスト用の技術が必要で
誰でもできる仕事ではないと言うことは
良い子のみんなにも、誤解してた人にも
分かってもらいたいと思っているんだ。
昔に比べると、IT業界の中では
ソフトウェアテストとその技術の重要性が
理解されてきてはいると思うと同時に
まだまだ誤解している人も
多いと感じることがあるんだ。
最後は少し愚痴っぽくなってしまったね？
でも、僕がここでソフトウェアテストについて
色んなことを書いていくことで
ソフトウェアテスト技術者の地位向上に
繋がればいいなと思っているんだ。
そうすれば、がっぽり儲けられるように…
あ、いや、その、僕も含めた
ソフトウェアテスト技術者の
みんなが笑顔になれるようにだよ！
本音が出たところで次回予告！
次も誤解されてることに近い話で、
本当は別の役割や活動を表す言葉が
ごっちゃになって同じ意味で使われたりする。
そんな話を取り上げることにするよ。
では、今回はここまで！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？