JSTQB ALTAを学びまくろう #5 複合条件テスト

はじめに

このシリーズでは「JSTQB ALTTAを学びまくろう」というコンセプトで連載として続けたいと思っています。

このシリーズは、秋山さんの下記の連載をもとに、とにかく乗っかって勉強したいと思っています。

 

note.com

 

私自身はJSTQB　ALのTAとTMを持っています。

そこで、最後に残されたピースを埋めるために、TTAに挑戦しよう思っています。

現状、日本では試験を行っていませんが、日本語でなくても英語でも受けるという強い気持ちで勉強を続けたいと思っています。

複合条件テスト

今日は久々にブログを書いていこうと思います。

秋山さんのブログでは、しばらくの間MC/DCテストの話がされていたので、私は一旦お休みしていました。

今日からは、新しい単元について感想を述べていきます。

複合条件テストは、シラバスで紹介されているテスト技法の中では最もテストケース数、あるいは網羅すべきカバレッジの基準が大きくなるもののようです。

シラバスの中でもある程度言及されていますが、必ずしも複合条件テストがふさわしいというわけではありません。

実際に私がおすすめするテストの本、『Effective Software Testing』では、複合条件テストよりMC/DCテストが推奨されています。

複合条件テスト自体はテストケースを作成しやすく、不可分条件の数だけテストすればいいため、(ソフトウェアテストではなく)ISTQBの試験においてはかなり解きやすいでしょう。

実際にサンプル問題でも、複合条件カバレッジの50%を問われるような問題がありましたが、これは不可分条件の数を数えれば、必要な判定の数を導き出すことができます。

 

ただし、ここで重要なのは、複合条件テストで網羅すべきパスの数と、複合条件カバレッジを達成するテストケースの数は違うという点です。

1つのテストケースで複数の網羅すべきパスをカバーできる可能性があるため、単純にテストケースの数を数えるのではなく、ある程度不可分条件について理解した上で試験に臨むを必要があると考えています。

テスターはどの時点で関与すべきか？

はじめに

先日、関西PHP勉強会でLTを行いました。

phpkansai.connpass.com

簡単なテストレベルの概念やテストタイプの概念を紹介したのですが、そこで頂いた質問について改めて考え、回答したいと思います。

「テスターはどのタイミングで関与するのが良いのでしょうか？」

早期テストで時間とコストを節約

ソフトウェアテストの原則として、「早期テスト」というものがあります。

これは、プロジェクトのできるだけ早期の段階でテストの視点を加えることで、早期にバグの予防・検出を行い、品質リスクと品質コストを軽減することができる。結果として手戻りの抑制にもつながるという原則です。これは、ほとんどのプロジェクトで適用できる考えです。

したがって、テスターが参加するタイミングは、プロジェクト開始時、要件の策定段階など、何かが始まった時です。

少なくとも、テスターが参加できる段階になったら、その時点で参加することが望ましいと考えられます。

最も望ましい早期テスト

最も望ましい早期テストは、会社設立時だと考えます。

会社設立時に、テストの考え方、あるいはそれからより踏み込んで、品質保証の考え方をきちんと取り入れ、プロセス品質、内部品質、外部品質ともに十分に組み込める業務プロセス、開発プロセスなどを整備しておくことが理想です。

TQMに基づいた会社設立は、最も望ましい早期テストだと考えます。

プロジェクト開始時点、製品企画時点

とはいえ、そこまでできる会社は多くないでしょう。

次の段階としては、プロジェクト開始時点、あるいは製品の企画時点が考えられます。

様々な開発プロセスや仮説検証の方法を考える中で、テストの視点を加味して、どのように進めるのが最適か、また、その中でどのようにテストを行うのか、テストプロセスをどのように組み込むのか、あるいはどの程度テストすれば十分に仮説検証ができるのか、といったことをテスターの視点で考えることが大切です。

仕様が出来上がってからではなく、ビジネスの観点、仕事の進め方の観点を考慮する際に、テストの気持ちに思いを馳せることが重要です。

仕様や要件の策定開始時点

それでも難しい場合はあるでしょう。

その場合は、仕様や要求を考える時点で、テストへの配慮が必要です。

この場合、開発プロセスは決まっているかもしれませんが、製品仕様を検討する中で、様々なテスト容易性の配慮、品質特性の配慮が可能になるからです。

レビューはテスターの専門分野でもあります。

より効果的なレビューの技術を適用することも考えられるでしょう。

現実的な線では、この段階でテスターが参加可能ことが最も多く、そして、多くのテスターの実力が発揮できるタイミングだと思います。

仕様が出来上がった時点

仕様や要件のFix後はテスターが参加できる最も遅い段階です。

これより遅い段階は、基本的に許容できない、あるいはほぼ確実にテストの失敗につながると言っても過言ではありません。

可能であれば、仕様を作成している最中からテストを検討することが望ましいです、多くのテストに理解がない多くの現場やコストがかけられない現場では、調達の関係でテストベース（仕様）が出来上がった段階で、テスターが作業を開始することがあります。

これは、ソフトウェアの詳細設計やコーディング中に、テスターがテスト設計やテスト計画を行うということです。

この時点で、テストを考慮したプロジェクト計画は立てられない可能性があります。

しかしながら、こういった場合でも何とか良い仕事をして成果を上げるのがテスターの役割だと考えます。

それ以降

コーディング中、特にソフトウェアが完成した後にテスターを集めている現場も少なくないでしょう。

これは基本的に手遅れです。

しかし、そのような状況でも、素早くテスト設計を行ったり、探索的テストを採用したりして、何とか頑張ることも必要です。

早期から入ってもうまく働けないテスターもいる

ただし、これらの提案は、テスター自身がある程度の実力を持っていることが前提となります。

例えば、「テスト実行以外したくない」「テスト設計の実力がない」「ビジネスについて考えたくない」といったレベルのテスターであれば、早期から参加してもあまり意味がないでしょう。

したがって、テスターの実力に応じて、テスターの関与のタイミングをある程度考慮する必要があります。

また、早期から参加しているプロジェクトマネージャーやビジネス側の人の品質への理解も重要です。

テスター自身に実力があっても、品質へのモチベーションが低い状態では、早期での参加があまり意味をなさなくなってしまいます。

必ずしもテスターは必要ではない

ここで「テスター」という言葉を使いましたが、必ずしもテスターという固有の役割を持つ人間が必要というわけではありません。

テスターという独立したロールがいるというよりも、テストの知識や視点を早期から取り入れることが重要です。

したがって、どうしてもテストの専門家をプロジェクトの早期から参加させられない場合は、自分自身がテストの知識や知見を持ってプロジェクトに貢献することが必要だと考えます。

 

JSTQB ALTAを学びまくろう #4 MC/DC

はじめに

このシリーズでは「JSTQB ALTTAを学びまくろう」というコンセプトで連載として続けたいと思っています。

このシリーズは、秋山さんの下記の連載をもとに、とにかく乗っかって勉強したいと思っています。

 

https://note.com/akiyama924/m/med2a46adef31

 

私自身はJSTQB　ALのTAとTMを持っています。

そこで、最後に残されたピースを埋めるために、TTAに挑戦しよう思っています。

現状、日本では試験を行っていませんが、日本語でなくても英語でも受けるという強い気持ちで勉強を続けたいと思っています。

つまり、英語力もテストエンジニアリング力も両方ない私は、英語とシラバスの勉強が両方とも必要になります。

実は、英語については毎日勉強しています。

このシリーズではまずシラバスの内容を日本語で理解したいと思っています。

 

MC/DC

今日はMC/DCについて勉強していきます。

MC/DCとは、AC/DCみたいですが、英語ではModified Condition Decision Testingという略らしいです。

MC/DCカバレッジは、1つ以上の不可分条件から構成される場合に規定よう可能です。

不可分条件とは、英語でアトミックコンディションというらしく、これは学びになりました。

デシジョンテストは、1つの判定の真偽をやる一方、MCDCでは不可分条件まで見て、その真偽を見るという形になるということです。

重要な点は、やはりテストケースの数なのかなと思いました。

不可分条件がn個の場合、テストケースの数はn + 1になるということです。

 

ISTQB試験のコツとしては、やはりテストケース数を最初に把握するということだと思います。

テストのパターンとしては、テストケースの数と、それを満たすテストケースを導き出すことだと思うので、最初にテストケースの数を出して、その後、それぞれのアトミックデシジョンをTrueとFalseを返すようなものをテストすればいいのかなと思っています。

スクラム道関西オープンジャムに行ってきた

スクラム道関西のオープンジャムに参加してきたので、その感想を書きます。

スクラム道関西とは、関西のスクラムやアジャイルなどのコミュニティで、今ではたまにOSTや飲み会をやったりしているようなコミュニティです。

今回はOSTだったので、その感想を書いていきたいと思います。

Doスクラムマスター

最初のセッションは、私がセッションオーナーをやっている「Doスクラムマスター」というセッションでした。

スクラムマスターをやるということになったら、どういうことをしたらいいのかという話題になりました。

ここでは、例えば、コントスクラムマスターをやってみたりだとか、スクラムがきちんと機能しているかを、スクラムをやりたいと考えた目的から立ち返って、それを検査するというのがいいかなと思っていました。

スクラムマスターの役割とは、チームにアクセルをかけたり、ブレーキをかけたりといったことができるような役目、そのための様々な問いかけや、様々なチャレンジを後押しできるような、そのような存在になるといいという話がありました。

組織を変えるためには

組織を変えるために、どのようなことをしたらいいか。アジャイルを導入するにはどうしていったらいいかということを話すようなセッションが2つ目でした。

組織を変えるためには、ビジネスの側面から見たいだとか、文化の側面で見たいだとか、それぞれの困っていることをボトムアップで考えていくとか、そういったことの議論がありました。

みんなのアジャイル

「みんなのアジャイル」という本がめちゃめちゃいいという話がありました。

私も話の流れで買いました。

色々この本を題材にお話を聞いたのですが、この中で私が一番刺さったのは、「スクラムマスターはある意味、自分がいなくても回るようなチームを目指す」というところです。そのために、あえて自分がいない状況を作ったりだとか、そういったことをするという話がありました。

これは、今のプロダクトチームでは、ある意味私自身も考えているところではあるのですが、一方で、職能横断のチームであったりだとか、QA組織というところだと、自分なしで回るか、それができるのか、そういう体制を作る気があるのかというところで、自分自身そうは思っていないことに気づきました。

これからどうしていいかわからないですが、すごく自分の中で自己認識として気づいたところになります。

アジャイルコーチにはどうなる

最後は、アジャイルコーチの話をしました。

私自身、コーチングやシステムコーチングにとても興味があるので、すごく楽しみにして聞きました。

世の中では、スクラムマスターの上位互換としてアジャイルコーチが期待されている側面があるかもしれないという話や、アジャイルコーチになるには、ただ単にスクラムのことを知っているだけではなくて、プロダクトマネジメントや組織のあり方、あるいは事業の理解など、様々な面が期待されるということを知りました。

JSTQB ALTTAを学びまくろう #3.5 休憩

はじめに

このシリーズでは「JSTQB ALTTAを学びまくろう」というコンセプトで連載として続けたいと思っています。

このシリーズは、秋山さんの下記の連載をもとに、とにかく乗っかって勉強したいと思っています。

ALTTAのテキストをつくろう｜Kouichi Akiyama｜note

私自身はJSTQB　ALのTAとTMを持っています。

そこで、最後に残されたピースを埋めるために、TTAに挑戦しよう思っています。

現状、日本では試験を行っていませんが、日本語でなくても英語でも受けるという強い気持ちで勉強を続けたいと思っています。

つまり、英語力もテストエンジニアリング力も両方ない私は、英語とシラバスの勉強が両方とも必要になります。

実は、英語については毎日勉強しています。

このシリーズではまずシラバスの内容を日本語で理解したいと思っています。

休憩

今日はMC/DCカバレッジについて学ぼうと思ったのですが、当の秋山さんがステートメントテストとデシジョンテストの説明に入っていったので、私もそれに合わせていきたいと思います。

ここで学んだことは、デシジョンとブランチというのがまた別のカバレッジ基準を持っているということです。

これは私は知らなかったのですが、理解できたのは良かったと思います。

ただ、実際的に業務としてはどちらでも同じ意味を持っているのかなと思いました。

TTA試験について

ここまでが秋山さんのブログのアンサーなのですが、ではちょっとここでTTA学習の進捗についてずっと触れていきたいと思っています。

TTAのサンプル問題をある程度解いてみたのですが、特に4章が難しいかなと思いました。

やはり、英語の単語の理解あるいは品質特性の理解が甘いなというところで、私はISO 25010を買いました。

これの学習をしようと思っています。

いつに受けるかは検討しているのですが、11月と言わず、もう少し早めに受けても大丈夫なのかなと思っています。

現在、バキバキQAでシラバスの読書会をしているのですが、もう少ししたら問題を解く会というのをやってみようと思っています。興味ある方はぜひ参加してみてください。

JSTQB ALTTAを学びまくろう #3 デシジョンテスト

はじめに

このシリーズでは「JSTQB ALTTAを学びまくろう」というコンセプトで連載として続けたいと思っています。

このシリーズは、秋山さんの下記の連載をもとに、とにかく乗っかって勉強したいと思っています。

 

note.com

私自身はJSTQB　ALのTAとTMを持っています。

そこで、最後に残されたピースを埋めるために、TTAに挑戦しよう思っています。

現状、日本では試験を行っていませんが、日本語でなくても英語でも受けるという強い気持ちで勉強を続けたいと思っています。

つまり、英語力もテストエンジニアリング力も両方ない私は、英語とシラバスの勉強が両方とも必要になります。

実は、英語については毎日勉強しています。

このシリーズではまずシラバスの内容を日本語で理解したいと思っています。

デシジョンテスト

今日はデシジョンテストについて学んでいきたいと思います。

デシジョンテストは、判定結果に着目するというところに特徴があります。

いわゆる if文、case文、loop文などです。これらについて、判定結果に着目するのがデシジョンテストのようです。

判定結果に着目するので、ステートメントテストとデシジョンテストにどういう違いがあるのかというのは、あんまりわからなかったです。

今の所の私の解釈では、オブジェクトに対する網羅性なのか、それともコードに対する網羅性なのかについて違いがあるというところなのかなと思いました。

コンパイル時に実行コードに変更された場合、 if 文 が分岐していたとしても実行コードとしては同じステートメントでコンパイルされているというところがあるぽいので、これがどうやら ステートメントと デシジョンテストの違いになりそうという理解をしました。

 

ISTQBの試験においては、そんな難しい問題は出そうにないのかなと思っています。

分岐する判定結果をきちんと理解して、それを満たすテストケースの数を出すことが大事なのかなと思っています。

ここで必要なことは、全ての判定結果を洗い出すということではなく、全ての判定結果の処理を通るような値のセットをテストケースとするというところだと思います。

特に if 文 がネストしている場合は、1つのテストケースで複数の判定結果を評価することになるので注意がするべきなのかなと考えています。

 

判定結果の数を網羅するので、判定に複数の条件がある場合は考慮しないのではないかなと考えています。だから、フロー図で定義されたものを基本的にカバーすると考えるのがいいのじゃないかなと考えました。

そうなってくると、デシジョンテストとステートメントテストにどんな違いがあるかと言うと、実務上はあんまり違いがないと思いました。

試験においてもあんまり違いがないのではないかなと思っています。

 

この辺はバイザーの「ソフトウェアテスト技法」で学んでみたいと思っています。

JSTQB ALTTAを学びまくろう #2 ステートメントテスト

はじめに

このシリーズでは「JSTQB ALTTAを学びまくろう」というコンセプトで連載として続けたいと思っています。

このシリーズは、秋山さんの下記の連載をもとに、とにかく乗っかって勉強したいと思っています。

 

note.com

私自身はJSTQB　ALのTAとTMを持っています。

そこで、最後に残されたピースを埋めるために、TTAに挑戦しよう思っています。

現状、日本では試験を行っていませんが、日本語でなくても英語でも受けるという強い気持ちで勉強を続けたいと思っています。

つまり、英語力もテストエンジニアリング力も両方ない私は、英語とシラバスの勉強が両方とも必要になります。

実は、英語については毎日勉強しています。

このシリーズではまずシラバスの内容を日本語で理解したいと思っています。

ステートメントテスト

言語の選択

今日はホワイトボックステスト技法のステートメントテストというところを勉強したいと思います。

秋山さんはPython を使ってソースコードを書くとのことです。

私も Python は多少書いたことがあるので、それはありがたいなと思います。

Python についてはかなり読みやすい言語であると思っています。

特にTTAの範囲であるホワイトボックステストを学習するというところであればかなり勉強しやすいと思います。

一方、 6章の勉強だと、コードレビューを行ったり、Pythonでは省略できる部分をレビューする必要があるので、そこは工夫して勉強する必要があるかなと思っています。

 

ステートメントテストとは

ステートメントテストというのは、処理を網羅するやつです。

秋山さんがおっしゃる通り。実行可能なステートメントというところは試験では重要なことだと思いました。

コメント行や空行は入りません。

一方気になったのは、到達不可能なコード、つまりデッドコードはステートメントに入るのかどうか？というところです。

ちょっとこれは、もともとのコンピューターサイエンス的なところを見ないとちょっとわからないかなと思ったりしました。

ちなみに、Geminiに聞いてみたら、到達不可能なコードはステートメントカバレッジの分母に入らないという結果が出ました。

ステートメントテストのポイント

ifæ–‡

ステートメントテストのポイントとなると、if 文になるでしょう。

例えば、if 文だけのものと、if と else がある場合だと、前者は 1 つのテストケース、後者は 2 つのテストケースが必要ということになります。

ういったところを注意したら基本的にはステートメントテストのテストケースの数ということはわかるのではないかなと思っています。

例外処理とループ

例外処理というところもあるので、これについても if 文と同じように考える必要があると思います。

ループ文というところもあると思います。

ループ文は 0回で終わるんじゃなくて、ループ処理をやりたいので、多分1回はやるということになりそうです。

switch æ–‡

試験にあるかどうかわからないんですが、switch 文にも少し注意が必要かもしれません。

それぞれの分岐に対してカバレッジする必要があるので、スイッチ文で分岐している分だけテストケースを用意する必要があるのではないかなと考えています。