「知識ゼロから学ぶソフトウェアテスト」を読んで ～ホワイトボックステスト
今週は、QAエンジニアの面接に向けて、この本を読み返していました。
JSTQBのテキストよりも簡単、初心者におすすめ、ということで薦められて読み始めた本です。
まずは、ホワイトボックステストの章について簡単にまとめます。
ホワイトボックステストとは
Weblio辞書によると下記のとおりです。
ホワイトボックステストとは、システムのテスト手法のうち、特にどのような論理構造で作成されているかに着目したテストのことである。
ホワイトボックステストでは、プログラムの外部仕様には着目せず、論理を実現するために使われている命令や、分岐が正しく動作するか、といった部分についてチェックが行われる。
つまり、あくまでプログラムの論理構造のみに注目するテストです。そのシステムによって成し遂げたい業務、仕様については気にしないテストの種類です。
ホワイトボックステストの具体的な手法 制御パステスト法
制御パステスト法は、筆者曰く『プログラムがどのようなふるまいをして、どのように制御され実行されていくかテスト』するものらしい。『カバレッジ率』の値を取るために使われるため、『逃れられないテスト法』とのことです。
カバレッジ率とは？
「テストでカバーできている範囲＝テストで検証済みの範囲」のことらしい。
この記事が分かりやすかったです。
カバレッジ (coverage) -「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
そのソフトウェアの品質を問われた際に、〇％といった風に明確な数字で示すことができる。そのため『逃れられないテスト法』と言えるのだろう。
制御パステストの種類
コード内の命令文（ステートメント）を少なくとも一回は実行する。しかし、分岐でのエラーが見つけられないため、非常に弱いテスト方法。
・ブランチカバレッジ
分岐についても網羅する。しかしテストケース数がかなり増える。
→部分的に利用する？
カバーされないコード・見つけられないバグ
カバレッジテストではカバーされないコードや見つけられないバグが多数ある。（詳細に書くと、あまりにも本の丸写しになるため割愛する）
→カバレッジテストですべてのバグを見つけるのは理論的に不可能である。
ホワイトボックステストの現状
いくらカバレッジ率を割り出せるとはいえ、ケース数が増える、見つけられないバグが多数ある、理論的にすべてのバグは見つけられない、となると、ホワイトボックステストは今でも利用されているのだろうか？という疑問が湧きました。筆者も、『プログラムのファイルサイズが数Ｋバイトで、高価なコンピュータを皆で使っていた時代に盛んに使われた手法です』と記しています。
私自身は普段、受入テストしか行っていないため、ホワイトボックステストは全く行っていない（発注側なので当然なのかもしれないが）。ベンダーの様子を見ても、主観ではあるがシステムテスト（論理構造ではなく、要求事項に着目）に力を入れているように感じます。
しかし、近年のアジャイル開発の流行により、ホワイトボックステストが復権していると章の最後で著者は述べています。TDDというテストのフレームワークを著書内で紹介しています。
まとめ
まとめ
・ホワイトボックステストは論理構造に着目するテスト
・命令文および分岐に着目してテスト設計
・しかし、全てのバグは見つけられない
・アジャイル開発により、ホワイトボックステストの手法が改めて取り入れられるようになった
感想・課題
・TDDについては、本だけではあまり理解できなかったため、調べて内容を理解し、まとめられるようにする。
以上です。
このブログについて
自己紹介
情報システム部で、一応社内ＳＥのような仕事をしています。２年目です。
色々と思うことがあり、転職を視野に入れて色々と勉強をしております。
（「色々と思うこと」については、長くなるため転職エントリとかでいつか書きます。）
このブログの目的
Qiitaの記事（化学系研究者が完全未経験からWeb系自社開発企業に転職するまで - Qiita
）を参考にさせていただき、下記の目標を掲げています。
情報システム部勤務2年目で、業務上で全くコードに触れることが無いことに疑問を持ち、プログラミング勉強を始めることにしました
— さと (@sato01101) April 15, 2019
①毎日プログラミングや技術関連書籍に触れる
②毎日、勉強記録をツイートする
③週に1回、学んだことのまとめをブログに投稿
というわけで、このブログは「その週に学んだ内容を自分なりにまとめてアウトプットする」ことを目的としています。
また、多少でもどなたかの役に立てたら嬉しいため、「読みやすさ」も少し意識して書いていきたいと思います。
内容について
- QA・テストについて →理由：第一志望がQAエンジニアのため
- プログラミング全般（まずはHTML/CSS/JavaScript） →見た目でわかりやすく、モチベーション保ちやすいため。UIデザインにも興味があるため。）
その他、興味のあることを随時書きます。
プログラミングに関してはHTML/CSS/JavaScriptと書きましたが、今受けてる自社開発の会社（QAの求人がある）に落ちたら、バックエンド寄りの言語をゴリゴリやっていくと思います。
理由：未経験で受けられるQAの求人がほぼ無いので、まずは開発側の経験を積める会社に転職する用のポートフォリオ作成のため。
まずは「一度立てた目標をやり抜く」「継続」に重きを置いていきたいと思います。（これを機に三日坊主も直したい）
頑張ります。
