はじめに
このシリーズでは「JSTQB ALTTAを学びまくろう」というコンセプトで連載として続けたいと思っています。
このシリーズは、秋山さんの下記の連載をもとに、とにかく乗っかって勉強したいと思っています。
私自身はJSTQB ALのTAとTMを持っています。
そこで、最後に残されたピースを埋めるために、TTAに挑戦しよう思っています。
現状、日本では試験を行っていませんが、日本語でなくても英語でも受けるという強い気持ちで勉強を続けたいと思っています。
つまり、英語力もテストエンジニアリング力も両方ない私は、英語とシラバスの勉強が両方とも必要になります。
実は、英語については毎日勉強しています。
このシリーズではまずシラバスの内容を日本語で理解したいと思っています。
デシジョンテスト
今日はデシジョンテストについて学んでいきたいと思います。
デシジョンテストは、判定結果に着目するというところに特徴があります。
いわゆる if文、case文、loop文などです。これらについて、判定結果に着目するのがデシジョンテストのようです。
判定結果に着目するので、ステートメントテストとデシジョンテストにどういう違いがあるのかというのは、あんまりわからなかったです。
今の所の私の解釈では、オブジェクトに対する網羅性なのか、それともコードに対する網羅性なのかについて違いがあるというところなのかなと思いました。
コンパイル時に実行コードに変更された場合、 if 文 が分岐していたとしても実行コードとしては同じステートメントでコンパイルされているというところがあるぽいので、これがどうやら ステートメントと デシジョンテストの違いになりそうという理解をしました。
ISTQBの試験においては、そんな難しい問題は出そうにないのかなと思っています。
分岐する判定結果をきちんと理解して、それを満たすテストケースの数を出すことが大事なのかなと思っています。
ここで必要なことは、全ての判定結果を洗い出すということではなく、全ての判定結果の処理を通るような値のセットをテストケースとするというところだと思います。
特に if 文 がネストしている場合は、1つのテストケースで複数の判定結果を評価することになるので注意がするべきなのかなと考えています。
判定結果の数を網羅するので、判定に複数の条件がある場合は考慮しないのではないかなと考えています。だから、フロー図で定義されたものを基本的にカバーすると考えるのがいいのじゃないかなと考えました。
そうなってくると、デシジョンテストとステートメントテストにどんな違いがあるかと言うと、実務上はあんまり違いがないと思いました。
試験においてもあんまり違いがないのではないかなと思っています。
この辺はバイザーの「ソフトウェアテスト技法」で学んでみたいと思っています。
