プロダクトの価値をテストする方法について考えてみた

はじめに

プロダクトの価値をテストする方法について、今までは主観的にテストをしていましたが、もう少し効果的にテストできないかを考えてみました。

まだ私が実際に試していないものも多く、特にUXやデザイン関連の知識については学習不足の領域でもあるので、不完全な机上の空論である点を理解して読んでいただければ幸いです。

なお、本記事では顧客の要求を正しく理解する方法についてはスコープ外です。顧客の要求を正しく理解しているという前提で記事を書いています。


目次

  • はじめに
  • プロダクトの価値とは何か
    • プロダクトを通じて得られる利益の大きさ
    • 利益を得るまでの障壁の大きさ
  • プロダクトの価値をテストする方法
    • プロダクトを通じて得られる利益の大きさ
      • 開発組織内で主観的に評価する方法
      • ユーザーからのフィードバックを用いて評価する方法
    • 利益を得るまでの障壁の大きさ
      • 開発組織内で技術的に評価する方法
    • テストするスコープ
  • おわりに
  • 参考文献
    • プロダクトの価値の定義
    • テスト方法
続きを読む

育児のノウハウが品質文化の醸成に活用できるかも!?

本記事は半分ネタ(半分は本気)の記事なので参考程度に留めておいてください。 また、もし仮に本記事の内容を育児に活用する場合は、お子さんの特徴によっては効果がない場合もあります。あらかじめご了承ください。

それでは本題です。

幼児の育児では、歯磨き、片付け、着替え、トイレなど、生活する上で大事なことを習慣づけさせる行為の連続です。ふと育児のノウハウが品質文化の醸成に活用できるかもしれないと考えたので文章にしてみました。


目次

  • 品質文化の醸成って何?
  • 望ましい行動を習慣づけさせるために必要なこと
    • どのような行動をすれば望ましいかを明確にする
    • 望ましい行動をした方が良いと感じさせる
    • 望ましい行動の基準を人の能力に合わせる
    • 望ましい行動をするリソースを十分に与える
    • 望ましい行動をする雰囲気作りに周囲の人も貢献する
  • 終わりに
    • 参考記事
続きを読む

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

本記事はソフトウェアテストの小ネタアドベントカレンダー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テクニカルレビュー「ソフトウェアバグ発生時の真因分析手法の策定」を参考にさせていただいております。主になぜなぜ分析だけでは分析が上手くいかない方の参考になれば幸いです。

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

目次

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