QAエンジニアが「自分が本当にやりたい仕事」を分析する手法を試してみた話

もし自分のやりたいことと業務を関連づけることができれば、業務に対してやる気が出たり、高いパフォーマンスを発揮したりすることができます。

私は今までQAチームのマネージャーとして、日々の1on1や人事評価などを通じて意識的にメンバーのやりたいことと業務との関連付けを行ったりしていました。

しかしながら、以下のようなことが起きて上手くいかないことも多くありました。

• メンバー自身が自分のやりたいことを自覚していない
• メンバーがやりたいと思っていたことが、実はそのメンバーに合わなかった

また、私自身も自分のやりたいことについて考えるのは得意ではなかったので、同じような経験をすることがしばしばありました。

そんな中で、私は以下の動画と出会い

youtu.be

以下の書籍を知ることになりました。

www.diamond.co.jp

そこで、私は書籍の内容を私自身で実践することにしてみました*1。

本記事では、私自身が書籍の内容を実践した結果の一部を紹介したいと思います。 マネージャーの方、自分自身のやりたいことがわからない方、自分自身のやりたいことをやっているはずなのにモヤモヤしている方の参考になれば幸いです。

なお、私自身はキャリアやコーチングの専門家ではないため、本記事の内容が誤っている可能性があります。 本記事の土台となる詳しい理論などについて知りたい方は上記の書籍をご参照ください。

*1:誰かのコーチングをするためには、まずは自分自身をコーチングできなければならないという著者の1人である李さんの言葉を実践します。

テスト分析・テスト設計を一人で練習するのが難しい話

本記事はあまり誰かの参考になる記事だとは考えていませんが、私の感想を書き留めておきます。

最近は他の人のテストスキルを効率的に向上させるにはどうしたら良いかを考えています。 しかしながら、タイトルの通りテスト分析・テスト設計を一人で練習するのが難しいと感じています。

本記事における「テスト分析・テスト設計」とは、誤解を恐れず簡単に言うと「テスト対象の情報収集から何をどこまでテストするかアウトプットするまでのプロセス」だと思ってください。

テスト分析・テスト設計の詳細は以下の資料などをご参照ください。

• JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-
• ASTERオンラインセミナー - YouTube の#4, #5

スキルアップに必要なサイクル

人がスキルアップするための仕組みとして経験学習サイクルなどありますが*1、 基本的には、以下のようなサイクルを通じてスキルを身につけていくと考えられます。

1. テスト分析・テスト設計を行ってハイレベルテストケース*2のアウトプットを出す
2. 上記1の結果が良かったか・悪かったか（アウトプットの質）を確認する
3. 何が原因で上記のアウトプットの質になったかを分析する
4. アウトプットの質がより良くなるための方法を考える
5. 新しい方法で上記1に戻る

本記事では、ハイレベルテストケースアウトプットの質とは以下のことを指しています。

• 必要なテストが漏れているかどうか
• 不要なテストが含まれているかどうか

何が必要なテストで何が不要なテストなのかは本記事では割愛します。

一人で練習するのが難しい点

テスト分析・テスト設計を一人で練習する場合は、上記のステップ2の自分のアウトプットの質を確認することが難しいと考えています。受験勉強で例えるならば、模擬試験を受けても答え合わせができないので、自分がどの程度正しく回答できたかがわからないという状態です。

実務ではテスト分析・テスト設計のアウトプットの質を以下の方法で確認することが多いと思います。

• テストケース通りにテストを実施してどの程度バグを見つけられたか
• 市場バグ（リリースしてしまったバグ）の有無
• 他の人からアウトプットに対するレビューを受ける

しかしながら、テスト分析・テスト設計を一人で練習する場合は上記の方法を取ることは難しいです。

最近挑戦していること

以上の課題を克服するため、現職ではQAエンジニアのオンボーディング用に現職のプロダクトを題材にした問題と解説をいくつか作成しました。 もしこれらの活動でテスト分析・テスト設計スキルを伸ばすことに成功した場合、遠い未来の話ですが誰でも活用できる教材を公開できれば良いなと考えています。

また、今ならばChatGPTなどの生成AIを使ってアウトプットに対する評価をもらうことは一応できます。生成AIは誤った内容を正解のように回答することもあるので注意が必要ですが、うまく活用できたらテスト分析・テスト設計を一人で練習できるようになるかもしれません。テスト分析・テスト設計を一人で練習するための生成AIの活用方法も検討したいと考えています。

おまけ

テスト分析・テスト設計スキル向上に役立つ可能性のあるイベントを紹介しておきます。 テスト設計コンテストは私も過去に参加したことがあります。

• テスト設計コンテスト
• WACATE : 若手テストエンジニア向け勉強会・ワークショップ

また、テスト技法の練習については、以下の書籍やJSTQB向けの問題集などを活用すれば一人でもある程度練習できます。

• ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～：書籍案内｜技術評論社

*1:https://www.hrbrain.jp/media/human-resources-development/learningby-oing

*2:ハイレベルテストケースについては、こちらの記事がわかりやすいです。 http://blog.amateur-factory.jp/?eid=1444288

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

はじめに

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

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

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

---

目次

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

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

それでは本題です。

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

---

目次

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

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

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

目次

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

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

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

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

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

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

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

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

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

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

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

目次

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