テスト計画とテストレポートの作り方 エンジニア向け:新人から中級へ、AI駆動開発でも迷わない型

>100 Views

October 30, 26

スライド概要

profile-image

はじめまして、yukikoと申します。 IT教育支援や、DX推進が可能です。 ◆ スキル LPIC レベル2 AI / Python Splunk BI(データ可視化・分析) ◆ その他 新卒・未経験の学生向けに、エンジニア転職を応援する資料を趣味で作成しています。 もしよろしければご活用ください。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

テスト計画とテストレポートの作り方 エンジニア向け:新人から中級へ、AI駆動開発でも迷わない型 新人向け うさうさ研修工房 中級向け AI駆動開発 査読済み論文

2.

テスト計画で決める 4つのこと 1 2 3 4 範囲 リスクと優先度 終了基準 体制と日程 何をテストし、何をテストしな いか。「しないこと」も書く 壊れると困る所から順に。時 間が足りないときの切り捨て 順も決める どうなったら終わりか。件数・ 重大度・未解決の許容を数 値や文で決める 誰が、いつ、どの環境とデー タで行うか 根拠: Felderer & Schieferdecker (2014)。リスクの評価を使ってテスト工程の全体を導くと、限られた資源と時間でも、重要な欠陥に力を向けやすい。 Garousi & Mäntylä (2016):自動化は、時期・状況・やり方を誤ると失敗しうる。

3.

新人向け/中級向け:計画とレポート 新人向け 中級向け 目標:「テンプレを埋めて、 1ページの計画とレポートを書 く」 目標:「リスクで優先度を付け、判断できる報告にする」 ・計画:まず「範囲」と「終了基準」の2つを決める ・計画:リスクで優先度を付け、省くテストと理由を書く ・レポート:結果の表と、失敗の再現手順を書く ・レポート:残リスクと、リリース可否の判断材料を書く ・つまずき:何をテストしないかを決められない→ 先輩と、壊れ ると困る所を3つ挙げる(筆者の提案) ・つまずき:件数やカバレッジだけの報告→ 数字の意味と限界 を添える(筆者の提案) 根拠:Kalyuga ら (2003)。初心者に効く丁寧な説明は、経験者には効果が薄れることがある。そこで、書き方の目標を分ける。

4.

テストレポートに書くこと 1 2 研究から 結果:件数と内訳(成功・失敗・未実施)と、全体の判定 Zimmermann ら (2010):Apache・Eclipse・Mozillaの開発者と利 用者の調査(466件の回答)で、再現手順・スタックトレース・テ ストケースが、開発者に最も役立つ一方、書き手には最も難し いと報告されました。 失敗の詳細:再現手順・環境・ログ・期待結果 3 残リスクと、未実施の理由 4 次のアクション:誰が、いつまでに、何をするか Inozemtseva & Holmes (2014):大きなJavaプログラムで、テスト 数の影響を除くと、カバレッジと欠陥検出力の相関は低〜中程 度でした。カバレッジは手薄な所を探すのに有用ですが、品質 目標にはしないよう提案しています。

5.

AI駆動開発での計画とレポート 研究から分かっていること Wang ら (2024):LLMをソフトウェアテストに使った102の研究を整理。 テストケースの作成が代表的な用途です。 Schäfer ら (2024):LLMでJavaScriptの単体テストを生成する実験(25 パッケージ)で、文の網羅率の中央値は70.2%、分岐は52.8%でし た。 Perry ら (2023):AI利用者は、安全性の低いコードを書き、安全だと 思い込みやすい傾向がありました。 Luo ら (2014):不安定なテストは、結果への信頼を損ないます。 気を付けること(筆者の提案) 1 計画の下書きは AIに任せてよい。リスクと終了基準は、 人が決める 2 AIが作ったテストの件数や網羅率を、成果にしない。カバ レッジは品質を保証しない 3 4 レポートの数字は、実行ログと突き合わせる 不安定なテストと、本物の失敗を分けて書く

6.

1ページのひな形(筆者の提案) テスト計画( 1ページ) テストレポート( 1ページ) 1 目的と対象 1 概要と全体の判定 2 範囲:含む/含まない 2 結果の表(成功・失敗・未実施) 3 リスクと優先度 3 不具合一覧(再現手順・環境) 4 終了基準 4 未実施・残リスク 5 体制・日程 5 次のアクション 6 環境・テストデータ

7.

根拠と限界 ― どこまで言えるか 研究 分かったこと 注意点 Felderer & Schieferdecker (2014) リスクの評価でテスト工程全体を導く 分類の整理。効果の測定ではない Garousi & Mäntylä (2016) 自動化は時期・状況・やり方で失敗しうる 文献レビュー(実務の資料を含む) Zimmermann ら (2010) 再現手順などが、開発者に最も役立つ OSS3件の調査。テストレポート全般ではない Inozemtseva & Holmes (2014) カバレッジは品質目標に向かない 大きなJavaプログラム。欠陥検出力は変異テストで測定 Schäfer ら (2024) LLM生成テストの網羅率の実測 JavaScript・gpt-3.5-turbo。現在のモデルとは異なる Wang ら (2024) LLMのテスト利用102研究を整理 サーベイ。効果の大きさは示さない Perry ら (2023) AI利用者は安全だと思い込みやすい 2022年ごろのモデル。セキュリティ課題 Luo ら (2014) / Kalyuga ら (2003) 不安定テストの影響/専門性逆転効果 OSSのJava/学習研究 ひな形や運用は、研究から導いた筆者の提案です。自社で小さく試して調整してください。