オープニングとテストへの向き合い方
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QA
エンジニアである私 ブロッコリー が、テストや品質に対する私なり
の考えを約10分間で語っていく ポッドキャスト番組です。オープニング
は、最近あった出来事なんですけれども、 自分には子供がいまして、その子供
が鉄道が好きで、とある施設に行った 時に、30分限定でプラレールを一式
渡されて、30分限定で線路を作り していいよっていう、そういう場所
があって、そこに参加した時に、 あらかじめこの線路のセットと
この電車があって、みたいなのを 渡された時に、じっと子供を観察
してたら、30分限定の線路作りの中で、 子供がそこの場所にいて、最初に
やったこと、どんなことだと思います かね。プラレールをまず組み立て
てみようとか、大体の子供はそういう のが多いかなと思うんですけど、
うちの子は、まず配布された電車が、 電池切れしてないかどうか、まず
電車、何もレールがないところで 電車を動かして、動くね。よし、じゃあ
プラレール作ろうみたいにやって いて、すごいテスト志向っぽいな
うちの子はっていうふうに思った っていう、そんなお話でした。
テストプロセスの細分化：JSTQBの定義
今日は、前回のプロセスの話の続き で、テストでの志向もプロセス
で表現してみようというお話を していきたいなと思います。ということで
今回もbtesting.fmスタートです。 テストでの志向もプロセスで表現
してみようという話なんですけれども、 どういうことかっていう話ですね。
皆さんが普段今までテストを実行 するって言ったときに、どういう
過程でやっていましたかね。よく ある話かどうかは分かんないですけど、
実際テストをするよって言った ときは、テストを実際に実行する
っていう話と、それよりも前に行う 内容、例えばテスト準備みたいな
一括りにしちゃうみたいな、そういう 人がいるかなと思っています。
テスト準備っていう呼び方であった りとか、もしくはそれをテスト設計
って呼んでいる人とかもいるかもし れません。それに対して、ここでも
何回か紹介しているJSTQBの中では テストプロセスとしてもう少し
細かく分けられるんじゃないっていう 話をしています。何かっていうと
テスト分析、テスト設計、テスト 実装、テスト実行ですね。まずテスト
分析で何をテストするかっていう のを考えて、その次にテスト設計
でそれをどうテストするかとか、 テストのパターンを考えるみたいな
ところですね。その後、テスト実装 としてテストの実行をしていく
にあたって必要なものすべてを 準備したかとか、これ何言っている
かっていうと、例えばこういう 環境でやりましょうとか、具体的に
こういうユーザーデータを使い ましょうとか、そういうふうな
準備の内容をテスト実装として やって、最後にそれを実行するっていう
テスト実行っていうふうに分け たりしていますと。この中でさっき
言っていたテスト実行とその前に テスト準備みたいに一括りにして
しまっていると、例えば自動テスト っていうとテストのスクリプト
を書くであったりとか、手動テスト であってもテストの手順を書く
みたいな、そういうふうなこと っていうのは、実はこのJSTQBの中で
言うテスト実装にあたるわけで して、それよりも前にどういう
パターンが必要なのかっていう のを本来考えるべきだし、もっと
手前に何をテストすればいいんだろう って考えるべきなんだけれども、
実は考えてはいるんだけれども それを頭の中で済ませてしまっている
と。無意識的にこういうパターン あるかな、もしくはもう無意識
なのでわざわざパターンがどう こうとか考えてなくて、もう本当に
無意識的にこういう今回機能を 作ったんだったらこのテストを
書けばいいよねって言って、いき だりテストスクリプトを書いて
いたりとかテスト手順を書いている っていうふうになっている人も
いるかなと思っていますと。テスト 分析、テスト設計を無意識的に
終わらせてしまっているっていう 人が結構いるかなと思っています。
テスト分析の重要性と議論の必要性
それに対してこういうふうにちゃんと プロセスとして分けましょうよ。
前回の話で計算問題とかをいきなり 答えを出すんじゃなくて、まず
掛け算割り算が先だなみたいな 計算順序を考えましょうよとか、
繰り下がりの引き算だからっていう ふうにやりましょうよとかっていう
細かく分けられるところは分けて 考えていきましょう。思考プロセス
をちゃんと持ちましょうっていう のはこのテストプロセスにおいて
も言えるかなと思っています。この 中でも特にこのテスト分析について
話すと何をテストするかっていう のを決定するという話ですね。
これは以前に具体的な例として パスワードの問題があったと思うん
ですけれども、パスワードの何文字 上何文字以下だけ有効だよとか、
だったらその文字数を気にすべき だよねとか、あとはロックされている
時間がどれぐらいかっていう話 であったりとかみたいなそういう
のをパスワードの例題でやった と思うんですけど、あの時に考えて
いたことですね。何テストすれば いいんだろうっていうふうに考える
ことがこのテスト分析に当たる かなと思っていて、この部分っていう
のが結構頭の中で考え終わらせて しまうことが多いかなと思うん
ですけど、むしろ個人的には何テスト すればいいんだろうっていうもの
こそいろいろ議論して決めていく べきかなと思っています。
JSTQBのテストプロセス全体像
先ほどJSTC Bの中でテストプロセス は分析 テスト設計 テスト実装
テスト実行っていうふうにプロセス を分けているよっていう話をしたん
ですけれども、実はそれだけではなくて 全体的にはもう少し話している
ことがあって、テスト計画っていう 話ですね。どういうふうにアプローチ
をしていこうかっていうのを定義 したりとか、あとはテスト完了
ですね。テスト実行が終わって完了 したものをちゃんとデータとして
まとめようみたいなところであった りとか、あとはテストのモニタリング
とコントロールっていう実際の 進捗度合いを比較して何か改善
すべきところには手を入れよう みたいなものもテストプロセス
としてJSTC Bの中では語られている んですけれども、このテスト計画
モニタリングとコントロール テスト完了っていうのはもう少し
広いものというか、いろいろな テストを総合的にやっていての話
が多いかな。マネジメントの要素 も含む話かなとは思っているので、
今回紹介したこのテスト分析 テスト設計 テスト実装 テスト実行っていう
のは単一のというか何か一つテスト を考えるときでテストスクリプト
を書いて実行するっていったときに その前段階として考えるべきこと
かなっていうので、今回紹介して いきました。なので皆さん是非
質問コーナー：ユニットテスト提案の前提
今までテスト実行の前に何かしら やらなくちゃなテストスクリプト
書かなきゃなって思っていきなり テストスクリプトを書いている
とかテスト手順を書いていた方 も是非その手前にあるテスト分析
何をテストするのかとかどういう パターンがあるのかっていうのを
考えるテスト設計の部分っていう のを是非これから意識して考えて
もらえるといいかなと思っています。 では今日も質問コーナーということで
以前自分が登壇したときにいただ いていた質問を勝手に拝借して
このPodcastの中で回答していこう というコーナーですね。今日もらった
質問はこんな質問ですと、こういう ユニットテストが必要ですみたいな
話っていうのはそのまま受け入れ てもらえるのでしょうか。これは
何かというと前提として自分が ユニットテストをQAエンジニア
が考えてこういうのも必要じゃない ですかって開発と一緒にコラボ
してやっているみたいな話を発表 の中でしたんですけれども、それ
に対しての質問でですね、この ユニットテストが必要ですって
言ったらそのまま受け入れてもらえる ものなのでしょうかと。ユニット
テストを追加で書くということは プロダクトコードを書く時間を
使うことになると思うのですが テスト コードもプロダクトコード
の一部のような受け入れてもらいやすい 前提があるのでしょうか。それとも
都度議論しているのでしょうかっていう 話で、まず質問ありがとうございます。
基本的には都度議論するっていう のはまず大事だとは思います。ユニット
テストで本当にやるべきかとか、 これユニットテストじゃなくてとか
そういうふうな議論はもちろん するんですけれども、今回質問で
いただいたとおり、まず前提が一 つとあって、これは自分の今いる
ところとかがまさにそうで、すごい いいなと思っているところなんですけ
れども、まずテストっていうものは QAがオーナーになるみたいな感覚
があんまりなくて、テストとか品質 っていうのを開発チーム全体で
持とうみたいな感覚を持っています。 もっと言うと、以前のエピソード
でも話したんですけれども、開発 は自分たちでテストを何とかしたい
んだけれども、やり方が分からない からQAに求めているみたいな感覚
をすごい持っていて、この間も自分 は開発者に言われた話があるんですけ
れども、本当なら別にQAの皆さん がいなくて、自分たちでやりたい
んですと。自分たちでやりたい けれども、それがどうしようもでき
てなくて、しょうがなくQAにお願い しているみたいな、そういう話を
されていたんですね。この感覚って 開発者が開発をして、開発が終わった
から、じゃあテストはQAよろしく と、全くマインドが違うわけですよ
ね。どうにかして自分たちでやり たいけど、それがやりきれないから
しょうがなくお願いしているみたいな その感覚は結構前提として違う
なと思います。そうすると、そういう ふうに思ってもらえていると、こういう
ユニットテストが必要ですっていう のに対して、なんでそんなこと
やらなくちゃいけないの、みたいな 拒否感はまずなくて、なるほど、
こういうユニットテストが必要か っていうふうに、結構受け入れて
もらいやすいかなとは思っています。 ということで、質問ありがとうございました。
エンディングとリスナーへの呼びかけ
ではエンディングです。ptesting.fm ではリスナーさんからのお便り
を募集しています。エピソード の感想や、私に聞いてみたい質問
やテストのお悩みなど、どんなこと でもかまいません。投稿フォーム
は番組概要欄にあります。またエピソード の感想は、ハッシュタグBテスティング
BアンスコテスティングでXのポスト をお願いいたします。今日のエピソード
で言えば、テストプロセスっていう ものを今回紹介しましたけれども、
自分のところではテスト設計っていう ふうに言っていたけれども、実は
テスト実装手順の話ばっかり書いて いたなとか、いやいや、うちはちゃんと
テスト分析やってますよとか、そんな 皆さんの状況とかっていうのも
ぜひ投稿フォームでやったりとか、 Xのポストとかしてもらえると
嬉しいなと思っています。もしも これからも聞きたいという方は
お手持ちのPodcastアプリで番組の フォローもお願いします。最新回
が上がったときにすぐ気づける と思います。今回の話とかで言う
と、前回から引き続きテストプロセス プロセスっていう話をしました
けれども、そういうふうな話をこれからも していきたいですし、それ以外にも
今日の質問コーナーの話であった りとかをおきっかけとして、こういう
エピソードもちょっとしゃべって みようかなっていうのは、これから
でもいろいろ考えていきたいですし、 それが毎週月曜日だけじゃなくて
最近は木曜日も含めて結構公開 したりしているので、ぜひフォロー
していただけると、そういうとき にもすぐ気づけるかなと思っています。
ということで、今回はここまで です。それではまた次回。バイバイ。
