QA 不具合管理
リリース準備ができる QA のための不具合管理ソフトウェア
何を、どの環境で、どのビルドに対してテストしたのかを QA が管理された形で記録し、リリース判断の前に検証の失敗やブロックを見えるようにします。
サインインしてこのサンプルデータ入りビューを確認し、サンプルデータ付きでアプリをインストールして、接続されたレコード、判断、ダッシュボードをテストします。
誤ったクローズを防ぐ QA 管理
不具合管理ソフトウェアは、観測された失敗、修正候補、テスト実行、リリースの関係を保持する必要があります。リリース責任者が検証済みの準備状況と楽観的なステータスを区別できるよう、失敗・ブロックされた検証も合格済みの作業と同じように見えるべきです。
- 検証を実装進捗から分離
- 失敗・ブロックの結果を見える状態で保持
- リリース判断にブロッカーと既知リスクを含める
検証は独立したレコード
テスト証跡は失敗した試行後も残すべきです
失敗した実行はノイズではありません。不具合がなぜ再オープンされたのか、次の候補で何を修正すべきかを説明します。
候補に名前を付ける
特定のビルド、リリース、環境をテストします。
範囲を明示
リグレッション範囲、デバイスまたは設定、期待される結果を記録します。
実際の結果を選ぶ
合格、失敗、ブロックは別々の判断です。
証跡を保持
観測内容と、再オープンまたはクローズの理由を添付します。
リリース判断
不具合ステータスをリリース準備リスクのビューへ変換
リリース責任者に必要なのは、無関係なチケットの山ではなく、ブロッカー数と証跡です。
| シグナル | Question | 判断での使い方 |
|---|---|---|
| 未解決の重大不具合 | 本番影響のある問題が未解決か？ | 明示的に受け入れない限り、リリース不可。 |
| 検証待ち | 完了と主張されている作業のうち、どれだけが未テストか？ | 完了ではなく不確実性を示します。 |
| 失敗またはブロックされた実行 | どの修正に有効な証跡がないか？ | 差し戻す、延期する、または文書化されたリスクとして受け入れます。 |
| 再オープンされた不具合 | どの修正が維持されなかったか？ | リグレッションと診断品質を明らかにします。 |
ソフトウェア不具合と品質記録の違い
リリース不具合を CAPA や不適合と区別する
言葉は重なりますが、統制されるプロセスと証跡は異なります。
このページを使う対象
ビルド、修正候補、検証実行、リリース判断に紐づくソフトウェアの挙動。
品質管理を使う対象
サプライヤー不適合、監査指摘、CAPA、統制された品質イベント、規制対応の証跡。
質問と境界
QA チームとリリースチームのための不具合管理 FAQ
検証、再オープン、リリースリスクをどう扱うべきかを明確にします。
バグと不具合の違いは何ですか？
チームはこれらの用語を同じ意味で使うこともよくあります。このページでは、不具合は QA 証跡とリリースリスクを重視し、バグのページは再現性と修正ライフサイクルを重視します。
ブロックされたテストを合格扱いにすべきですか？
いいえ。ブロックされた実行は、予定していた証跡が得られていないことを意味します。見える状態に保ち、ブロッカーを取り除くか、変更を延期するか、文書化されたリスクとして受け入れるかを判断します。
不具合は誰がクローズすべきですか？
クローズは、合意した候補に対する検証合格の後に行うべきです。修正を実装した人は準備完了にできますが、QA または指定された検証者がテスト結果を記録する必要があります。
Jodoo はリリース準備状況にどう役立ちますか？
サンプルアプリは、不具合と検証レコードをリリース準備レコードにつなぎ、未解決の重大バグ、保留中の確認、失敗またはブロックされた実行、最終判断を表示します。
「修正済み」の根拠を確認
失敗、ブロック、再オープンの例を確認
Jodoo が正確なビルドと QA 結果をリリース判断にどう結び付けるか確認します。