# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、Q-Engineerのさみぃが、ソフトウェアテストやソフトウェアの品質保証を中心に、日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 テストの方やリスナーのあなたと、テストウェア品質の世界を広げていきます。 # リクエスト回✨テスト技法の選び方 こんにちは、QAエンジニアのさみぃです。 今日もワクワクしていますか? 今回はテスト技法の選び方についてお話をします。 こちらのトピックは先日のおしゃべりリクエストボックスで 水源さんから頂きましたトピック、トピックというかリクエストですね。 テスト技法を使ってますか?というご質問を頂いたので、 そちらの回答じゃないですけどリクエスト回ということでお話をしていきます。 今回の話はあくまでもNイコル1の私の経験ということで 聞いて頂ければと思います。 結論なんですけど、テスト技法って使えないシチュエーションとか使ってますか? というご質問については基本的にはテスト技法を使ってますという回答かなと思います。 とはいえ全部の各テスト技法で全部のシチュエーションを モーラーできているかというとそうは思ってもいないので、 もちろん使わないシチュエーションでもあったりします。 本題に入る前にというか前提というところでテスト技法ってどういうものがあって、 それぞれのテスト技法ってどういうものだっけっていうところはこの放送ではお話ししません。 それは各書籍を読んでいただくか、JSTQBのテストアナリストも 参考にしてもらいつつでいいと思ってます。 1個おすすめなのが本ありまして、緑の練習帳ですね。 ソフトウェアテスト技法を練習帳、知識を経験に変える40問という本がありまして、 これ一番おすすめです。 サンプル問題とか実際に手を動かして設計をしながらその技法を覚えるというのがすごくいいかなとおすすめの本です。 今回の放送で出てくるリンク系とかですね、書籍のリンクとかは全部概要欄に入れておきますのでそちらご覧ください。 他のテスト設計で、とはいえ本買っても自分で手を動かさないなぁみたいな感じであれば、 ぜひイベントというか若手というグループがあるので、そちらの若手の勉強会に参加することをおすすめします。 若手は夏と冬と年に2回やっていて、オフラインが多いかな。最近だとオフラインかなと思うんですけど、いろんなキャッチアップができます。 毎回テスト設計をやってるのかな、やってないかもと思いつつ、わりかしテスト設計のトピックはあるのかな、年に1回ぐらいあるのかなとか思ったりします。 今回の放送はテスト技法をある程度知識としてはわかっているよう前提でお話ししていければと思います。 本題のテスト技法の選び方なんですけれど、先日、2023年に若手に参加しまして、その時のテスト技法のおさらいというセッションがすごく振り返りというか思い出すのがよくて、 そのスライドの一番最後、各セッションにスライドがあるんですけど、テスト技法について、こういうテスト技法、道地分割とか境界自分次第、ギリゼションテーブル、状態遷移、ユースケステストというのがあって、 それぞれのメリットと使いどころとか注意点というのが書かれた素晴らしいスライドがあるので、テスト技法をどう選ぶかというのは結構それを見てくださいというのが正直なところだったりします。 さすがに総合説明だと雑なのでもう少し補足をしていきたいんですけれど、これは私なりの考え方ではあるんですけど、テスト技法を選べるようになるためにはというのを考えた時に、 ファーストステップはやっぱりそのテスト技法のことをちゃんと知って理解しているというのが大前提だと思うんですよね。 じゃないと選べないので、実務でぶつかった時というか、これってどういうテスト技法を使ったらいいんだろうとなった時に、そもそもの知識がないと選べないので、 ファーストステップとしてはどういうテスト技法があって、それぞれの中身とかやり方とかというところはしっかり頭に叩き込んでおく必要があると思います。 その後のステップ2としてテスト技法を選ぶというところですかね。 同時分割とか境界地分割分析みたいなところの使いどころとかポイントっていうのは、入力地とかシステムにインプットされる値によって何か処理が変わるかどうかですよね。 例えば動物園のチケットの入園料とかって結構年齢によって変わってきますよね。 そういう感じその入ってくるインプットの情報で年齢というものがあって、10歳未満だったらいくらとか6歳未満だったらいくらとかそれ以上、6歳未満だったら7歳以上だったらいくらみたいな、 そんな感じで入力地の値によって何か挙動が変わるアウトプットが変わるものについては同時分割とか境界地分析とかが適してるねみたいなところ、そんなことを考えたりします。 続いてデシジョンテーブルについては条件が複雑なときに使います。 よくある例はその荷物の送料の金額の算数とかですよね。 購入金額がいくら以上だったら送料は無料になるとか、そもそも離島だったら送れないというか送料かかるとかそういう結構いろんな条件によって最終的な送料が変わるみたいなそういうときはデシジョンテーブルを使いますよね。 先日も新機能のプランニングをしてるときとかにこれの仕様ってどういう風になってるんだっけって結構いろんなパターンというか組み合わせじゃないな、いろんな複数の条件で最終的な結果が決まるもの、挙動が決まるものっていうのをデシジョンテーブルを使ってちゃちゃっと仕様の整理をしたりもしました。 あと続いては状態遷移図とかですかね。はもうその名の通り状態が変わるときには使います。なので例えばプラン系はよく状態遷移図を使いますね。プランがいくつか複数のあってそれぞれどういうアクション、オペレーションをしたらその別のプランになるのかとか、 AというプランからBのプランにはいけるけどAからCというプランにはいけないよねとかそういう制約みたいなものを分かりやすくする、使用を分かりやすくするとかどういうテストが経路でのテスト必要なんだっけみたいなのを考えるときに状態遷移図、状態遷移テストとかをやったりします。 そんな感じですかね。あとそのリクエスト、アンケート、おしゃべりリクエストボックスでいただいたところだと使えないシチュエーションってあったりしますかというご質問いただいてるんですけど、なんかパッと思いつかないんですよね。 普段の業務だとわりかしデシジョンテーブルを使うことは多いです。その複数の条件によって動作が決まる、挙動が決まるというようなことが多いので、そんな世の中のプロダクトってシンプルじゃないじゃないですか。 なのでデシジョンテーブルを使って仕様を明確化したりとか、このパターンでテストをしたら良いよねっていうところのコミュニケーションを取ったりするのにもよく使ったりします。 デシジョンテーブルを作ってみたんだけれど、やっぱり実装と乖離があったというか、開発者と話をして、これって別にデシジョンテーブルを書く必要なかったな、みたいなことはあったような気がしますね。 そもそもそのデシジョンテーブルで組み合わせた条件の部分の内容がそこは別に関連がないというか、組み合わせる必要がないみたいな言葉になれば、デシジョンテーブルをわざわざ作らなくてもいいよねって話になるし。 そのくらいですかね。他の状態遷移とか境界値分析とかで外すことはないんですよね。明らかに状態遷移だったら何かの状態が変わるっていう部分を確認したいし、状態っていうものがキーワードになってるから、そこが大きく認識がずれてるってこともあまりないし、境界値っていうところも、 期間とかこれからいつからいつの期間だったらこうなるみたいな、あと年齢みたいに数字の何歳以下とか何歳以上以下とか未満とか出てきたら、境界値とか同時分割みたいなところが使えそうだなっていうのはすごくわかりやすいので、あまりそこをこの技法を使えなかったなみたいなところはミスジャッジっていうのはこれまであんまりないかなという感じです。 はい、ということで今回はテスト技法の選べ方についてお話をしました。もっとここ深掘りしてほしいとかこういうお話聞きたいとかありましたら、ぜひコメント欄でコメント、質問いただけるととっても嬉しいです。 # #120のコメント返し😍 コメント返しのコーナーです。今回は120話目のコメントを開始します。 1週間前の120話では、開発チーム全体に品質意識を広めるために行っていることについてお話をしました。 コメントは2件いただいております。 まず1件目が松田さんですね。初コメントですかね。おめでとうございます。パフパフということで。 良いチームは勉強や認識合わせの目的とした時間を明確に確保しているよなって放送を聞きながら改めて思いました。 開発チームの中でテスト改善、自動化や効率化をやっていたので、過去放送を含め楽しく聞かせてもらっています。ありがとうございます。 とコメントでいただいております。ありがとうございます。 楽しく聞かせてもらってますっていう言葉で、本当に力と言いますか、元気をいただきますね。こちらこそありがとうございます。 あとは、そうですよね。やっぱりいろんな前提を持った、背景を持った人たちが集まって一つのものを作っていくわけなので、 認識合わせとか前提を揃えるとかって大事ですし、なんかテクノロジーの進化ってとても凄まじく早いので、 それに合わせてと言いますか、品質保証のやり方も変えていかないといけないし、そうなると勉強ってやっぱりずっと必要になってくるので、 そういう時間を確保していくのってとても大事ですよね。そういう環境にも働いていらっしゃった、いらっしゃるのかなっていうところも聞けてとても嬉しく思っております。 はい、2件目、水犬さんからコメントいただいております。ミスが起きたときに仕組みにフォーカスするの大事ですよね。 ポストモーティングのときにしっかり意識していきたいと思いますとコメントいただいております。水犬さんはいつもコメントありがとうございます。 本当に励みと言いますが、次いつコメント来るかなっていうのをいつも楽しみにしております。仕組みにフォーカスするの本当大事なんですよ。 人によってはっていうのかな、前に1回あったんですけれど、ポストモーティングやってたときに開発担当してた、メインで担当してた方が本当にすいませんみたいな感じで、 すごく申し訳なさそうにしてたんですけど、いやそんなことないからねって私はすごく何度もお話をしていて、 決してあなたのせいではないし、そういう自分が悪いって思わなくてもいいし、あなたは開発チームのリーダーなんで、 そういう姿っていうのはあまり見せないでほしいみたいなことをお伝えしたりしました。 これは人の問題じゃなくて、宿命組織の問題として捉えて、じゃあどう次同じようなことを起こさないようにするかっていう未来にフォーカスするっていうのをとても大事にしています。 はい、ということでコメント返しのコーナーでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はリリース後に見える品質、ユーザーのフィードバックを 品質改善に生かす方法についてお話をします。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 ぜひ画面右下ハートマークでいいねをしていただけると、とっても励みになります。 XなどSNSでのシェア、コメント、あと口コミでぜひ周りの方に、 こんな放送あるよということをお伝えしていただけると、とっても嬉しいです。 それではまたお会いしましょう。ごきげんよう。