修正内容に応じたリグレッションテストの実施範囲

本記事はソフトウェアテストの小ネタアドベントカレンダー18日目の記事です。

リグレッションテストと言えば自動化ですが、様々な事情で手動のリグレッショテストが必要になる場合があります。 そこで、本記事では、修正内容に応じたリグレッションテストの実施範囲を決める際に私が行なっている方法を紹介します。

目次

  • 修正したコードの依存関係から決める
  • 変更があったDBのテーブルの依存関係から決める
  • 変更があった外部仕様の依存関係から決める
  • 性能面への影響を考慮して決める
  • リリース・ロールバックの各手順から決める
  • 過去の不具合や経験や直感に基づいて決める
  • 上記分析にミスがある場合に備えた念のためのテスト
  • 参考文献
続きを読む

私の仕様レビューのやり方(抽象的な観点から指摘事項を導くまでの具体例)

仕様レビュー時のプロセス、マインド、観点リストはWeb上などでも多く文献を見かけます。ただ、私の経験上、抽象的な観点リストがあっても観点から具体的な指摘事項を洗い出せるか否かは比較的属人化していました。 そこで、本記事では、いくつかの属人化しがちと感じた観点について、私が仕様レビューを行う際の思考過程を紹介します。 *1

本記事では、自社が運営するメンズファッションのECサイトにおける追加開発のプロジェクトで仕様レビューを行なっていきます。 重厚な要件定義書や基本設計書などがない現場という前提で*2、プロジェクトの仕様レビュー時に与えられた情報は以下の通りです。

  • ECサイトのトップページの上部に「おすすめのアイテム」という枠を新たに追加する
  • 「おすすめのアイテム」枠には、DBの販売開始日の新しさ上位3点の商品、サイト運営者が選んだ定番商品3点を表示する
  • 「おすすめのアイテム」枠に表示する内容は1時間毎に更新(商品一覧を返すAPIはレスポンス内容を1時間キャッシュする)
  • 「おすすめのアイテム」枠の下のエリアには、元々トップページに表示していた「トップス」「ボトムス」「その他」というカテゴリ毎の商品を、注文数の多い順に6点ずつ表示する(仕様変更なし)

f:id:kawabeaver:20211103231645p:plain
トップページのUI(「ボトムス」「その他」カテゴリの記載は省略)

上記を見てツッコミどころがたくさんあるとウズウズしている方は、ぜひ本記事を読む前に仕様レビューを実施して指摘事項を考えてみてください。 その後、本記事を読んだ皆さんが新たな指摘に気づけるようになったのであれば、本記事は成功です。 それではレビューをしていきます。*3

*1:仕様レビューという言葉が曖昧なので、本記事の内容を皆さんの現場のプロセスに当てはめて考えてください。

*2:私が重厚なドキュメントのある現場での業務経験がないため

*3:なお、本記事中の指摘内容の適切さは本記事の主題ではありません。

続きを読む

テスト設計時に最低限のテストケースを選ぶための工夫(テストケース削減の工夫)

私が所属する事業会社では自社サービスを運営しており、受託開発のような決められた納品日や予算(テストにかけられる工数)が殆どありません。どの程度テストを実施するかはQAエンジニア自身が最終的に意思決定をすることになります。テスト量を増やせば欠陥を検出できる可能性は高まりますが、その分リリースが遅れて機会損失が発生します。そのため、会社の利益を最大化するためには、なるべく最低限のテストで品質を担保しなければなりません。そこで、本記事では私が最低限のテストを選ぶために行なっている工夫を紹介します。なお、必ずしも記載している順番で行う必要はありません。*1

目次

  • 目指す品質(テストで担保する品質)を決める
  • プロダクトリスクの大きさや予測される障害を分析してテスト量のメリハリをつける
  • テストはなるべく小さい部品単位で行う
  • テスト観点(抽象的なテストケース)の洗い出しは網羅的に
  • テスト設計ミスを想定して保険のテストを実施
  • おわりに
  • 参考文献
    • テスト設計の流れ
    • プロダクトリスクの大きさや予測される障害を分析してテスト量のメリハリをつける
    • テストはなるべく小さい部品単位で行う

*1:実際私が作業を行う際も、工程が行ったり来たりします。

続きを読む

自動テスト(E2Eテスト)のテスト内容の選び方

自動テスト(E2Eテスト)は初期開発工数だけでなく、仕様変更に伴う修正工数が継続的に発生します。そして、闇雲に全てのテストを自動化すると自動テストの修正工数が膨大となり、やがて自動テストのメンテナンスが追いつかなくなります。そのため、自動テストのテスト内容は費用対効果を考えながら厳選していく必要があります。

そこで、本記事では私の考えた自動テストの目的に応じた自動テストのテスト内容の選び方をご紹介致します。自動テストの目的は複数持っても構いません。セキュリティや性能のテストは本記事のスコープ外です。

なお、本記事では触れませんが、手動テストにとって効率的なテスト手順は自動テストにとって非効率な場合が多いのでご注意下さい。*1*2

目次

  • 自動テストの目的
    • 手動テストの工数削減、リリース頻度の増加
    • テスト漏れをカバーする保険
    • 欠陥混入時に生じる工数やリードタイムの削減
  • 自動テストの目的に応じたテスト内容
    • 手動テストの工数削減
      • 削減工数(テスト実施工数 × テスト実施頻度)が大きくなるテスト
      • 自動テスト以外の手動テスト工数削減方法も検討する
    • テスト漏れをカバーする保険
      • テスト漏れがよく発生するテスト
      • 重大な損失をもたらす欠陥を検出するテスト
    • 欠陥混入時に生じる工数の削減
      • 欠陥を多く検出できるテスト
  • テストレベル(E2Eテスト, APIテスト, ユニットテスト)の選択
  • おわりに
  • 参考記事
続きを読む

不具合分析(テスト漏れ・欠陥流出原因の分析)のやり方、私の場合

本番障害の再発防止策が「テストが漏れたテストケースをリグレッションテストに追加して毎回確認します」となる場面を何度か見かけます。しかしながら、上記の再発防止策では欠陥流出原因(テスト漏れ)の根本原因を解決していないため、別の機能における改修で同じ原因によるテスト漏れが発生する可能性が高いです。

そこで、本記事では私が行っている欠陥流出原因を分析する方法を紹介します。私の方法はSEIテクニカルレビュー「ソフトウェアバグ発生時の真因分析手法の策定」を参考にさせていただいております。主になぜなぜ分析だけでは分析が上手くいかない方の参考になれば幸いです。

なお、不具合分析では欠陥流出原因だけでなく欠陥混入原因の分析と再発防止策の検討も行いましょう。欠陥混入自体を防ぐ対策も行った方が望ましいです。

目次

  • 欠陥混入工程と欠陥検出工程の特定
  • 欠陥検出工程における問題のある工程の特定
  • 欠陥流出原因の分析
  • 再発防止策の検討
    • 仕事のやり方(プロセス)を変える
    • 継続的な工数があまりかからない方法にする
    • いきなり工数がかかり過ぎる方法にしない
  • 再発防止策の効果測定
  • その他参考資料
  • 終わりに
続きを読む

QAチームの指標としてDDP(欠陥検出率)の観測をやめた話

私が所属していたQAチームでは、過去にDDP(Defect Detection Percentage:欠陥摘出率)を観測して欠陥検出力(テストによって欠陥を検出する力)をモニタリングしていました。しかしながら、ある時DDPの観測をやめてしまいました。 本記事では、DDPの観測をやめた経緯について私が想像した内容*1を記載したいと思います。

DDPについては、こちらの記事がわかりやすいのでご参照ください。 www.kzsuzuki.com

また、上記の記事や以下の記事のようにDDPを上手く活用しようとしている事例もあります。

www.nttdata.com

developers.freee.co.jp

そのため、私が所属していたQAチームでは単にDDPの活用方法を誤っていただけの可能性もあります。

上記を踏まえた上で本記事を読んでいただければと思います。

目次

  • 本記事の前提
  • 過去のDDPの利用方法
  • DDPをやめた理由
    • DDPの数値を見ても正確な欠陥検出力はわからない
    • DDPの数値に影響を与えるのは欠陥検出力以外のことが多い
    • 欠陥の埋め込み削減を目指すとDDPの数値が悪化する可能性がある
  • DDPの観測の代わりにやったこと
    • 本番障害の件数とビジネス上の影響度を観測
    • 本番障害について検出漏れの原因分析
  • 解決できていない課題
    • 欠陥検出力をリリース前にチェックできない
    • 本番障害がない場合に欠陥検出力がわかりづらい
    • 複数の開発チームで欠陥検出力を比較しにくい
  • まとめ

*1:私は当時の意思決定に関与していなかったため、本当の経緯はわかりません

続きを読む

開発チームやQAエンジニアは品質意識だけではなくビジネス的視点も持つべき

最近「開発チームも品質意識を持つべき」「開発チームに品質文化の醸成が必要」といった発言が多くみられるようになりました。 品質は確かに重要ですが、品質向上はビジネスを成功させるための手段であり目的ではありません。 本記事では、私の事業会社での経験を基に、ビジネス的視点を考慮しないで高品質なプロダクトを目指すことの弊害を取り上げたいと思います。 事業会社で勤務している方、事業会社への転職を検討している方などの参考になれば幸いです。

目次

  • 話の前提
  • 顧客満足度向上に寄与しない品質にこだわったテスト
  • プロダクトや機能が仮説検証の段階でも高品質を目指したテスト
  • 会社の利益に寄与しない品質にこだわった仕様の提案
  • 開発の費用対効果を考えないで高品質な機能を目指す
  • リリース前の品質だけ確認する
  • まとめ
続きを読む