# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # リリース判断をしているときの頭の中 こんにちは。QnEngineerのさみぃです。 今日もテストしてますか? 今回はですね、リリース判断をしている時の 頭の中について言語化を試みます。 今ですね、モバイルのアプリのリリースを 毎週やっているので、 そのリリースの前に全体の挙動を確認する リグレッションテストを行っているわけなんですけど、 その結果とか状況を見ながら 毎週リリース判断をしているということになります。 今回このトピックを話そうと思ったきっかけというのが、 チームメンバーとのお話をしている時にですね、 結構どういうふうに判断したらいいかが難しいと、 判断基準だったり、どういう状況だったらどういうふうに判断すべきなのかが難しいんですよねって話をもらって、 それを受けて結構、私は結構無意識的にいろんなことを、 情報とかをインプットして判断してたんだな、 これなら出せるなとか判断してたんだなというところを学んだというか、 気づいたので、今回リリース判断している時に頭の中でどういうことをしているのかというところを言語化を試みようと思った次第です。 リリース判断って一言で言っても、多分新機能のリリース判断と リグレッションテストで毎週アプリを出しているわけなんですけど、 そこでの判断、リリース判断って多分違うと思います。 今回はこの後者のリグレッションテストでのリリース判断について深掘っていきます。 まず、ざっくりリリース判断するときに参考にしている情報、 インプットしている情報は何かというと、ざっくりですけど、テストの実行結果と、 検出された不具合の情報になります。 それらの2つの情報の状況で、頭の中で条件分岐しているようなイメージを持っています。 一番シンプルなパターンは、テストを全件実行しました、 全件丸でしたとかOKでした、だからリリースできますというのが一番シンプルなパターンだし、 そういう状況だったらそんなに困らないですよね。 なんだけれど問題なのは、テストの結果でNGがあったかつ不具合が報告された場合ですよね。 ちょっと分け道されるんですけど、テストの結果がNGというものと、 不具合が記表される、報告されるっていうのは一緒じゃないの?って一瞬思ったんですけど、一緒じゃないですね。 テストの結果がNGだったときに報告される不具合、 あるいはその事象、何か意図していない事象というものは複数の場合もありますよね。 だから1対Nの可能性もあるし、テストケースとしては全部OKなんだけど、 それ以外にテストケースに書かれていない動作を少し確認をして、 何か問題、これはおかしいなと、 これは意図した挙動じゃなさそうだなという事象が見つかれば、 それは不具合かもしれないということで報告されるので、 必ずしもテスト結果のNGと不具合が報告される、 不具合というものがイコールになるわけではないですね。 本数値に戻ってきます。 リリースの判断って小さい単位でクルクルやってるのと、 最後にドンってやってるパターンがあって、 小さくクルクルっていうのが不具合が報告されたタイミング、 随時のタイミングでまずチェックしてるんですよね。 不具合が記表報告されました。 じゃあその検出された不具合というのは、リリースをブロックするものなのか、 ブロッカーなのか、それともブロッカーじゃないのかっていうのをまず判断してます。 最終的にドカンとリリース判断してるっていうのは、 夕方だったり夜のタイミングだったり、 テストが全件実行された後に、 その○×テスト結果のどのくらいNGがあったのかっていうのと、 報告されている、記表されている不具合の数、 数じゃないな、中身、内容っていうのを加味して、 最終的にリリース判断をしてると、 この2軸というか2つのパターンがあるかなというふうに考えてます。 毎週のリグレッションテストという文脈だと、 結構時間との戦いなんですよね。 なので1つ不具合が報告されると、 そのたんびに細かくリリース判断を入れていて、 じゃあこの不具合は今回の修正、 今回のビルドによって発生したものなのか、 それとも違うのか、それとも前のビルド、 前のバージョンでも発生するのかっていうのをまず確認をしますよね。 あと同時にシステム的なインパクト影響度と、 例えばデータを破壊してしまう系だとシステムへのインパクトが大きいし、 あとビジネスインパクトというところを見てます。 あとユーザーが遭遇する頻度というところも見てます。 これらの直近今回入った修正による 不具合であるかという点、 システムインパクト、ビジネスインパクト、 ユーザーの遭遇頻度というところを見て、 総合的に判断して、この不具合、この事象はブロッカーです、 ブロッカーじゃないですという判断をしてますね。 例えば今回の修正で新しく入り込んだ、 購入した不具合なんだけれども、 システムインパクトも低い、ビジネスインパクトも 低いということであれば見送る場合もあります。 どちらかというと、今回のビルドで購入したものというのは、 なるべく修正を入れることが多いかなと思ったりします。 あとよくあるのは、購入の時期はだいぶ前、半年とか1年前なんだけれど、 テストの実行者がいつもと違って検出を見つかった不具合とか、 それに関してはビジネスインパクトだったり、 問い合わせが来ているかというところを見ながら判断はしますけれども、 基本的にはずっと半年以上発生しているという事象であれば、 ブロッカーとはせずに見送ることが多いかなと思ったりします。 難しいのが、夕方とか夜とかのタイミングでテスト実行は終わりました、 検出された不具合が複数件あります。 その時点では、例えば原因が分かっていない不具合があるとか、 再現できない不具合があるとか、そういう時ですね。 あとは、原因は分かっているんだけど、 修正が終わっていないとかね。 でも、いずれにせよシステム的な深刻度とビジネスインパクトで、 特に大体手段があるかどうか、ユーザー側で回避するオペレーションがあるかどうか、 あと、想定される遭遇頻度はこの3つぐらいで判断しているかな。 例えば、特定の経路とかパターンでログインができないというのは、 システムインパクトは結構高い。 ユーザーインパクトはどうですかね。 他に大体手段がある、他のログイン方法だったらログインできるとかあれば、 ちょっとユーザーインパクトは下がるかなと思います。 あとは、その特定のパターンというものが、 どのくらい頻度としてユーザーが遭遇しそうかというのも1個。 もし、そんなにその特定のパターンに該当するユーザーがいないのであれば、 優先度をブロッカーにするかというところの温度感としては低くなります。 そしてその事象が、例えば再現はできたんだけど、 原因がなかなか分からないと数時間調べても分からないとなったときに、 リリースのOKサインを出すかというのは非常に難しいですよね。 そのときは情報を書き集めるしかなくて、 このくらいのリスクはあるけど許容するみたいな感じでリリースOKとするとか、 あるいは原因が分からないので、 今回はリリースをストップするという決断もあり得るわけですね。 どっちの決断をするかというのは、 そのときのプロダクトの成熟度だったり、 フェーズ、新機能をどんどんまず出していこうというフェーズなのか、 ユーザー数が増えてきたから品質を重視するデグレードとかがないということを重視するのであれば、 リリースは止めるだろうしというところで、 そのときのプロダクトや組織の状態によっても決断、結論というのは変わってくるかなと思います。 ということで、今回はリリース判断をしているときの頭の中について言語化を試みてみました。 まとめますと、まず最初は今回の修正による不具合なのかどうなのかというところを判断をして、 それでブロックアウトするかを判断します。 そこで最初に振り分けます。 あとはシステムへのインパクト、ユーザーインパクト、 ユーザーインパクトの中にユーザーが遭遇する頻度というところも入ってくるかなと思いますけど、 そこら辺の情報を総合的に加味して、 リリースOKとするのかブロックアウトするのかというところを判断しています。 # 今日のほっこり話🍛 今日のほっこり話です。カレーの話をします。 毎週末ですね、来年食べたいというのを夫に聞かれまして、 カレー食べたいなーって話をしたので、カレーを作ってくれました。 私は辛いものあまり得意じゃないんですけど、程よい中辛っていうんですかね、辛さですごく美味しかったです。 私の装い方が悪かったのかな、お肉が1個しか入ってなくてですね、 サイコロステーキのキューブみたいなお肉だったんですけど、 1個しか入ってなくてちょっと悲しい気持ちになりましたという話です。 以上、今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はゲストトークになります。 デザイナーの京谷さんをお呼びして UI UXとかユーザー体験とか 日々業務しているときにどういうことを考えているのかについてお聞きお話をしました。 今回の放送を聞いて なるほどな確かにな窓辺になったなと思った方は 是非画面右下ハートマークでいいねを押していただけると とっても励みになります。 また現在ですねオフ会を絶賛企画中でございます。 読書会ではソフトウェアテストを徹底しない賞を読む予定です。 あと食事会をします。 是非興味ある方はですね チャンネルページのトップに固定してあります放送をお聞きください。 今はですね日程調整のフェーズでして Googleフォームからこの日なら参加できるよという情報を 皆さんから提出いただいております。 日程調整の期日が今週末ですね 7月13日日曜日の正午となっておりますので 是非お忘れなく提出をお願いします。 それではまた明日お会いしましょう。 ごきげんよう。