asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。 皆さまにも一緒に学びを楽しんでいただけたら幸いです!

ASTERセミナー標準テキストを活用した品質向上の試み

はじめに

2024年4月から一人目のQA(Quality Assurance: 品質保証)エンジニアとして挑戦している高津です。

株式会社asken (あすけん) Advent Calendar 2024およびソフトウェアテストAdvent Calendar 2024の12月13日分の記事です。

QAエンジニアとして取り組んできた活動の中から、特に注力したポイントと学びをふりかえります。

現状の把握

asken一人目のQAエンジニアとして今期待されていることは「チームに対してQAスキル習得やプロセスの改善を支援し、チームのアウトプットの質とスピードを改善させる」ことです。

まず取り組んだのは、チームの現状を正確に把握することでした。

そこで、書籍「LEADING QUALITY」で紹介されているチームの品質ナラティブを見極めるためのアンケートとその分析を実施しました。

品質ナラティブとは

品質ナラティブ(Quality Narrative)は、チームで品質について考えたり話したりしている、その「語られ方」です。 品質ナラティブには、以下の3要素があります。

  • 責任ナラティブ (The Ownership Narrative)
    • 誰が品質に責任を持つかが考えられ、語られている
  • テストナラティブ (The “How to Test” Narrative)
    • 品質向上につながる正しいテスト技法はどれか・どのツールを使うべきかが考えられ、語られている
  • 価値ナラティブ (The Value Narrative)
    • 品質に投資した場合の見返り(ROI: 投資収益率)が考えられ、語られている

アンケート分析結果

アンケートの回答を分析した結果、チームの品質ナラティブは以下であることが分かりました。

アンケートの分析結果 理想 ギャップ
責任ナラティブ 自分は品質に関係がない、責任がないと考えているメンバーはいない チーム全員で品質に責任を持っている 小
テストナラティブ 何をテストすれば良いのか自信が持てていない、テストが不足していると感じているメンバーが多い どうやって品質を担保したのかを説明でき、安心してリリースできる 大
価値ナラティブ リリース前の動作確認に時間がかかる、等のコストに関しては認識がある テストのメリットとコストを考えて、実施するorしないを判断できる 中

チームとして課題感が強いテストナラティブのギャップを埋めることが、効果が高そうだと判断しました。

社内勉強会の開催と成果

テストナラティブのギャップを埋めるためにはテストスキルの向上が必要です。チームのテストスキル習得を支援するために、テスト設計ワークショップや実例マッピング体験会のような社内勉強会を開催しました。

ですが、勉強会開催後にもリリース後に緊急度の高い障害が複数回発生しました。緊急度の高い障害が発生している状態は、品質として問題があります。これまでの勉強会では改善できていないということです。

発生した障害の再発防止として有効な施策は何か、改めて考えてみました。実施したテストに不備があり、障害が検出できていませんでした。テストに不備があったことを、テスト設計レビューで指摘することができませんでした。

そこで、テスト設計やテスト設計レビューのスキルを改善するために、開発プロセスとテストレベルの関係や、どの開発プロセスで非機能テストの設計やレビューをするべきかについて認識を合わせるための勉強会を開催しました。

「開発プロセスとテストレベル」勉強会

開発プロセスとテストレベルのような、ソフトウェアテストの基礎的な技術に関するセミナー資料をASTER(ソフトウェアテスト技術振興協会)が公開しています。ASTERセミナー標準テキストです。ソフトウェアテストの基礎的な知識を学ぶためには、ASTERセミナー標準テキストはとても効果が高いです。

ASTERセミナー標準テキストV3.1.2「2.1 ソフトウェア開発ライフサイクルモデル」と、asken用に追記した資料とで説明を行い、その後ディスカッションという流れで勉強会を実施しました。

この勉強会で、以下の点について認識を合わせることができました。

  • システムテストに対応する基本設計にて、機能要件と併せて非機能要件の整理とテスト設計も行う
  • 開発プロセスで対応するテストの設計およびレビューを行う (シフトレフト)

「シフトレフトでテスト設計までやると、手戻りが発生した際にテスト仕様書を更新するのは負荷が高いのではないか」「テスト仕様書の完成は求めておらず、どんなテストをするのかをレビューできれば箇条書きでもなんでもいいのでは」といったディスカッションができました。

チームでテストレベルの理解が進み、テスト設計レビューを行うタイミングが明確になりました。 開発プロセスとテストレベルの関係性が明確になったので、テストするべき対象が以前よりも明確になりました。 その結果、テスト設計やテスト設計レビューでテストケースの漏れを検出できることが期待できます。

また、設計や実装と同時に対応するテストレベルのテスト設計を行うことで、テストを実施する前に設計や実装の問題点に気づけるケースが増えます。結果として、設計や実装のアウトプットの質の向上が期待できます。テスト実施前に問題点に気づけるので、手戻りも減りスピードの改善も期待できます。

発生した障害の再発防止策の1つとしてこの勉強会を実施しました。

今回の再発防止策では対応できなかった障害や潜在障害が検出されたときは、チーム全員で原因の分析と、効果的な再発防止を策定できるようになりたいです。 そこで、次の勉強会のテーマは分析や再発防止としました。

「エラー・欠陥・故障と分析、再発防止」勉強会

まずASTERセミナー標準テキストV3.1.2 P25「エラー・欠陥・故障」からP27「故障・欠陥・エラーへの対応」を使って再発防止等の基礎を共有しました。その後、フィッシュボーン図となぜなぜ分析について、実例ベースでどうやって使うのかを説明しました。 参加してくれたEMが再発防止のアンチパタンとGoodパタンに関する書き込みをしてくれたおかげで、どんな再発防止策が求められているのかがわかりやすくなりました。なぜなぜ分析は実例を元に説明したことで、実施のイメージができて良かったとのコメントが貰えました。

再発防止策のアンチパタンとGoodパタンに関する書き込み

これまでをふりかえって

QAエンジニアになる前から、自分が学んだ技術を共有するために勉強会をやっていました。一部の参加者は実践してくれましたが、チーム全体に大きな影響を与えられませんでした。

「チームのアウトプットの質とスピードを改善させる」ためには情報を共有するだけでは足りないことを学びました。勉強会や他の取り組みも含めて「チームのアウトプットの質とスピードを改善に繋がるのか」を意識して、チームと共にQAスキル習得やプロセスの改善を進めていきます。

おわりに

askenを一緒に盛り上げてくれる仲間を絶賛募集中です!

www.asken.inc