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

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

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

目次

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

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

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

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

トップページのUI（「ボトムス」「その他」カテゴリの記載は省略）

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

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

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

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

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

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

目次

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

自動テスト（E2Eテスト）のテスト内容の選び方

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

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

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

目次

*1:テストを自動化するのをやめ、自動テストを作ろう

*2:mablでE2Eテストを自動化するためのベストプラクティス 2020年版

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

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

そこで、本記事では私が行っている欠陥流出原因を分析する方法を紹介します。私の方法は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の活用方法を誤っていただけの可能性もあります。

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

目次

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

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

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

目次