オープニングとJSTQBシラバスの更新について
皆さん、こんにちは。B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私内の考えを、約10分間で語っていくポッドキャスト番組です。
基本的に、このB-Testing.fmの中で紹介しているテスト設計技法とか、そういうものに関しては、JSTQB及び、それの元となったISTQBのシラバスを基準として、それを大いに参考して作っているんですけれども、
このISTQBのシラバスというのが、更新が定期的に行われていまして、そうすると、私が紹介している内容だと、最新版になると変わっている可能性っていうのは結構あるんですよね。
最近で言うと、デシジョンテーブルの部分が簡単化って、今まで呼んでたのが最小化だっけな、そういうふうに変わったりとか、あとグラフィシケーションツリーがファンダメーションレベルからなくなったりとか、そういうのがあったりしているんですけれども、
変わる可能性があるってことは、今まで紹介してきたものが古くなる可能性もあるので、そういうのは改めてまた紹介し直すかもなと思っている感じです。今日はそういうふうに変わったところではないんですけれども、状態遷移テストの続きですね。状態表の作成について、今日は話していきたいと思います。
状態表の定義と役割
ということで、今回もbtesting.fmスタートです。状態表の作成について話していきたいなと思います。まず状態表っていうのは何かっていうと、もともとはこれ状態遷移表とも呼ばれていましたが、これこそまさに最近のシラバスの更新によって状態表と日本語が改められました。
この状態表っていうのは、状態遷移図に相当するモデルですよ。行は状態を表して、列はイベント、存在する場合はガード条件を表します。
テーブルの項目、セルは遷移を表して、ターゲット状態、ガード条件を定義されている場合は、結果のアクションを含みます。
状態遷移図とは対照的に、状態表は向こうの遷移を明示的に示し、空のセルで表すというふうに書かれています。
この文章だけ読んでも分かりづらい部分は多いかなと思うので、具体的な例をもとにまた説明していきたいなと思います。
ストップウォッチの例題と状態遷移図の復習
具体的な例というのは、前回状態遷移図でも使ったストップウォッチの例題を用いて説明していきます。
その状態遷移図の方の説明については、以前のエピソードをもう一度確認してください。
状態遷移図を作成すると、こういうふうな形。待機中状態からスタートストップを多化で計測中、計測中でスタートストップを多化したら一時停止中。
一時停止中の状態でスタートストップを多化したらまた計測中の状態に戻ったりとか、一時停止中の状態でリセットボタンを多化すると待機中の状態に戻るというような状態遷移図がまず作成されています。
状態表の作成プロセス
この前提で状態表を作っていきます。状態表どういうふうに作成するかというと、まず最初行の方に出てきた状態ですね。
待機中、計測中、一時停止中っていうのを行の方に書いて、列の方に具体的な動作を書きます。
イベントですね。スタートストップボタンを多化っていうのとリセットボタンを多化っていうこの2つを書いていきます。
そうするとですね、この間のところ、表の中がまだ空欄になっていくわけですね。
これを埋めていく作業をしていきます。どうするかというと、まず最初ですね、例えば前状態が待機中のとき、一番最初待機中のところでスタートストップを多化した時に計測中になるっていうところがあります。
なので、待機中の行とスタートストップを多化の列のぶつかるところ、ちょうど区区の表みたいな形でぶつかるところに、これを遷移した後の状態を書いていきますと、前状態が待機中でスタートストップを多化っていうイベント動作があると、後状態は計測中になる。
だからここの空欄に計測中って埋めます。で、同様にですね、計測中の状態からスタートストップを多化を押すと、今度は一時停止中になるっていうところがあるので、計測中の行とスタートストップを多化の列のぶつかるところに一時停止中っていう状態を書きますと。
で、次に一時停止中の状態でスタートストップボタンを多化すると計測中の状態になるので、この一時停止中の行とスタートストップを多化の列のぶつかったところに計測中と書きます。
で、一時停止中と今度はリセットボタンを多化すると待機中状態になるので、一時停止中状態の行とリセットボタンを多化の列のぶつかったところに待機中と書きますと。
このようにすることによって状態遷移図に表現していたものを状態表の方に書き写すことができました。
空白セルから気づく「自己遷移」と「非活性（N/A）」
そうすると一つ気になるところが出てきます。
この部分ですね。空欄の場所が2個出てきますと。
何かというと待機中の時にリセットボタンを多化と計測中の時にリセットボタンを多化という2つが空欄であることに気づきます。
この部分ってどうなるかっていうと、実は状態遷移図に表現できてないんですよね。
待機中でリセットボタンを多化した時っていう矢印がない。
計測中の状態でリセットボタンを多化した時の矢印が存在してないことに状態表を書くことによって気づくんですね。
じゃあ実際に書くと例えばこんな感じになると思います。
待機中でリセットボタンを多化、つまり0分0秒の時にリセットボタンを押しても待機中の状態変わらないですよと。
同じように計測中の時、1、2、3って増えている時にリセットボタンを多化してもこれはラップ機能がないストップウォッチっていう前提なので計測はそのまま変わらないですよっていう風になります。
このように自分自身に戻る繊維のことを自己繊維と呼びますがこういうふうな自己繊維の矢印を書くことができます。
そうすると自分自身に戻るっていうものを状態表の方で表すとこういうふうにハイフンで表現することが多いです。
これはちょっと通例の表現ということでこれが標準的かっていうと微妙なところではあるんですが
ハイフンで表現することで自分自身に戻るよっていう表現をすることが多いです。
また状態繊維図の方の自己繊維の自分自身に戻る矢印っていうのも省略して書かれないことがあるんですが
個人的にはこういうふうにちゃんと表現して書いてあげた方が自分自身に戻るんだよっていうのを明示しているのでいいかなと思っています。
今回の場合自分自身に戻る。
例えば本当に0分0秒のときにリセットボタンを押す。
計測中123って増えているときにリセットボタンを押すっていうのは物理的なストップウォッチだったら押すことができますよね。
押すことはできるけど何も状態としては変化がないっていう意味で自己繊維としてハイフンで表現しましたけれども
例えばウェブ上のストップウォッチの画面とか考えるとそもそもリセットボタンを押すことができないみたいなことがありますよね。
こういうふうにリセットボタンを押せないような仕組みになっている場合は自己繊維というよりもそもそもこの繊維が発生しない起こり得ないみたいなことを表現することもあると思います。
このようにですね起こり得ない繊維のときは状態表の方ではNA not applicable 起こり得ないよっていう意味でこういうふうに表現することがあります。
これも通例の表現です。
状態繊維図の方ではもうそもそもそういうのが起こり得ないので先ほどの自己繊維と違って矢印を書かないということになります。
でですねさっき自己繊維で矢印を書いた方がいいって言った理由はこの部分でして非活性で起こり得ない話なのかそれとも起こり得るんだけれども自己繊維として戻るのかっていう区別をするためにも自己繊維はちゃんと自分自身の状態に戻るっていう矢印を書いた方がいいかなと思っています。
このように状態繊維図と状態表を書いていくっていうところになります。
状態表からテストケースへの展開
これを書いたらここまでが実際のテスト設計技法としての状態繊維テストになるわけですけれどもここから実際にテストケースを作るっていうところまで考えていきましょう。
そうするとこういうような例になるかなと思います。
例えば前状態で0分0秒で停止している操作としてスタートストップボタンを動かすと期待結果としてカウントアップが始まるとか。
0分0秒で停止していてリセットボタンを動かしても0分0秒で停止したままになるみたいに具体的な実際に行う最初の状態と操作とその期待結果を書くっていうのをこれをテストケースの例として今回表現してみました。
これがテストプロセスでいうテスト実装に当たっていくわけですね。
先ほどの状態繊維図とか状態表を書いたらもうそれでいいじゃないかっていうところもあると思います。
実際に自分も業務の中でこういうふうな細かいテストケースまで書かなかったりはしますがテスト実装はテスト実装で書いたほうがいいこともあります。
何かっていうと、例えばここのテストケースとして0分0秒で停止しているつまり待機中の状態でスタートストップボタンを動かせるとカウントアップが始まるっていう計測中の話と、
あとはこの中でいう5番目のテストケースですね。
0分5秒で停止しているっていう一時停止中でスタートストップボタンを動かすとこれも計測中になるわけですよね。
けれども最初に言った0分0秒で停止していてスタートストップボタンを動かしてカウントアップが始まるっていう計測中と、
5秒の時に停止していてスタートストップボタンを動かした時の5秒からカウントアップが再開するっていうこの部分。
ここって両方とも計測中っていう状態は差がないわけですけれども、これ実は状態繊維図とか状態表では表現できてない部分なんですよね。
0分0秒でカウントアップが始まる話なのか、5秒のところからカウントアップが再開されるのかっていうのは状態繊維図とか状態表で表現できていない部分なので、
これがテスト設計として留めておく場合とテスト実装まで書いたときの大きな差分になると思います。
テスト実装を書くことによってより具体的な期待結果が見えてくるっていうことになります。
状態繊維テストとして状態繊維図状態表を書いただけで何となくはわかったけれども、もう少しちゃんと期待結果を表現したほうがいいよねって思ったらこのようなテストケースを書いたほうがいいかなと思います。
まとめと次回への展望
ということで最後はテストケースの話まで行きましたけれども、今回は状態繊維テストの一つ状態表の作成について話していきました。
状態繊維テスト、特に状態繊維図の話はよく使ってるよと、別にテスト設計としてだけじゃなくて普段の設計でもよく使ってるよっていう人もいたかもしれませんが、状態表っていうやり方もあるんだとか、
それによって最初状態繊維図書いた時には気づかなかったけれども、こういう繊維もあるんだっていうのを気づくことができる方法がこの状態表の作成だと思うので、
ぜひ状態繊維図を書いておしまいではなくて、状態表まで考えて普段の業務使ってもらえるといいかなと思っています。
それではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想は、ハッシュタグbtestingでxのポストをお願いいたします。
今日の話でいうと、状態表っていう状態繊維図に比べるとあまり使われないことが多いやり方について紹介してきました。
それ初めて知ったよとか、実は使っててとか、そういういろいろな話が聞けると嬉しいなと思います。
ぜひハッシュタグbtestingでポストをお願いします。
もしもこれからも聞きたいという方は、お手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づくことができます。
今回も状態繊維図からの続きで状態表について紹介していきましたが、実はもう少しだけ状態繊維テストについてはお話ししたいことがありますので、
それもすぐにその後エピソードが上がったときに気づけると思うので、ぜひフォローもよろしくお願いします。
ということで今回はここまでです。それではまた次回。バイバイ。
