テストについて考えていること

2024.04.13
「テストについて」というお題についてある場所で話した際のLT資料です
自分はどういうことを考えてきたのか？を振り返るような内容になりました

Transcript

1. テストについて考えていること 2024/04/13 shimarisu_121
2. テストの5大要素 すべてのテスト技法は以下の要素を持つ • テスト実施者 • カバレッジ • 発見したい問題（推測される潜在的問題は何か？） • 作業内容 • 結果の判定方法（パスする基準は？） 出典: ソフトウェアテスト293の鉄則
3. テストの7原則 • テストは欠陥があることは示せるが、欠陥がないことは示せない • 全数テストは不可能 • 早期テストが時間とコストを節約 • 欠陥は偏在する • テストは弱化する • テストはコンテキスト次第 • 「欠陥ゼロ」の落とし穴 出典: JSTQB FLシラバス
4. テストにおける思考 テストとは探求であり、その為に3つの思考法を利用する（探索的テストで重要） • 前方思考 ◦ Aというボタンが実在するよね、これを押したらどうなるのだろうか？ • 後方思考 ◦ 機能Bなんてものがあってもいいよな。モジュールCをチェックしよう • 水平思考 ◦ この機能面白いな。もっと過激にしたらどうだろう？ 出典: ソフトウェアテスト293の鉄則
5. モンキーテストも時には行う 衝撃のバグが見つかることもある。しかし、基本的に経験則ではあま り効率は良くない。日々の数%くらいの時間で取り組むと良いのかも しれない テストの自動化は致命的欠陥の予防に相当役立ちますが、 経験則的には潜在的欠陥の多くは 意識して探さないと見つかり ません
6. 寄り道：コーディングするときの思考 主にコードリーディングで意識していること • エディタの型定義や参照機能を利用して、コードを「掘って」中身の正しさを チェックする ◦ スクリプト言語（pythonなど）なら外部パッケージも掘れる • gh searchやsourcegraphでオープンソースの類似コード事例やissue をチェック • testsフォルダの単体テストはその関数の「使い方」を示している場合も多い • アーキテクチャやデザパタ、各種サードパーティライブラリの勉強は「チャレ ンジで見た」形式で理解の促進に一役買う
7. バグを発見しやすい方法 • 境界値 ◦ 鉄板。単なるパラメータだけでなく、時間、レイヤ、あらゆる部分の「切 れ目」がバグ要因になる ◦ 単体テストコードを作成するときに根拠を持った上で仕込むべき部分。 一方、老朽化したらまず疑うのもここ • 例外処理・イレギュラー処理のチェック ◦ 保険処理と言われる類に対して「イジワル」をしてみる • 同値分割（バグが出た箇所と似たクラス値） • 何かしらの別構成 ◦ OSやバージョン、プロセッサのタイプを変えたら？
8. ガチガチにやるのなら ブラックボックステストにおける様々な方法の例 • デシジョンテーブル • 状態遷移表 • 直交表 • 仕様書の点検（文言に嘘はないか？） 超面倒なので頑張って取り組む必要はないと思うが、 組合せテストのテスト手法を引き出しに持っている だけでも見えてくるものもある 画像出典: https://shiftasia.com/ja/column/%E3%83%87%E3%82%B7%E3%82%B8%E3%83%A7%E3%83%B3%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%EF%BC%88%E 6%B1%BA%E5%AE%9A%E8%A1%A8%EF%BC%89%E3%81%A8%E3%81%AF/
9. 単体テストは積み上げられる 安定依存の原則（SDP）を達成すればするほど、テストの労力を 下げつつ、安全なソフトウェアを作成しやすくなる なぜなら、 安定に向いたパッケージの境界値テストが厳密に行われている のなら、それに依存したパッケージのテストは境界値の定義をよ りゆるやかに出来る（手抜きできる）為
10. バグリポートについて • 「なんか変です」みたいな抽象的な報告をしない • それは明らかな仕様相違ですか？疑問・疑念ですか？あなたの個人的願 望ですか？ • 何をどうしたらそうなるのですか？（とにかく再現手順） ◦ 唐突に気付くこともあるが、「記憶・記録」が大事 ◦ スナップショットしつつ、ロールバックして差異を確認できる ような環境があると 良い（コードベースなら、だからgitがある） ◦ 手っ取り早く再現できる方法・ツールがあるのは超重要 ◦ カメラ撮影など、ベタなアナログでも有効な方法・証拠になりうる ◦ 自動化は環境構築頑張ったわ～、な満足感は注意報かも。 古典的でダサく 単純な方法で良い場合もある。全員にとって楽でシンプルが正義
11. あるべきバグリポートの方法 (1) • バグの再現方法(できるだけ詳しく)と発生頻度 • 本来の仕様(バグがない場合の望ましい動作。こうあるべき、という 自分の意見でかまわない) • 実際の動作(完全でなくても、自分の記録した範囲で詳しく書く) 出典: プログラマが知るべき97のこと: バグレポートの使い方 https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%90%E3%82%B 0%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88%E3%81%AE%E4%BD%BF%E3%81%84%E6%96%B9/ GitHubなら.github/ISSUE_TEMPLATEを活用
12. あるべきバグリポートの方法 (2) • 問題点をハッキリ報告し、解決策は書かない ◦ 解決方針はまた別に決めるから ◦ 正直組織開発だと、だからトホホな部分もあるけれど • 再現性なきバグはない • ツールや環境関連バグへの感度を上げる ◦ OSSだったら、他のリポジトリのissueとかもちゃんと調べたか、み たいな話。本当にそのアプリのバグですか？ 出典: ソフトウェアテスト293の鉄則
13. OSSの良い例も参考にする - Mozillaの例 - 参照: https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html 分類と環境 再現手順 実際の結果 期待結果 解決策ではなく、問題を説明してください
14. バグ修正について（プログラマの立場から） • 何をどう変えて解決したか、明確にしているか？ ◦ ログがないのに「修正しました」で終わらせない • 原因は明確か？ ◦ なぜそうなったのかは理解したのか？ • 場当たり修正になってないか？ ◦ 役所対応で「言われたからしました」が新たなバグを呼び 起こす。全体を見て他の可能性は考えた？
15. 自分への課題 実務に慣れてくると、QA・プログラマ双方で本音は「 誘導したい自分（達）」がいることに気付く • QA：「このチケットとかにも影響が出るから、 この報告は◦◦という方向で修正してくれないかな 」（そう思っ てリポートの文章を仕込む） • プログラマ：「事情も知らずめんどくせえ、 こうしとけば黙ってくれるかな 」（そう思って変更のコードを仕込 む） 「隠れた本音」が生まれる頻度が増えるが、 ほぼほぼ悪い結果を生む よりスマートな問題解決のプロセスでは、（ストレスフルな）「感情」の介入は不要のはず … （片方の立場にしかないって人が結構いる事情は大きい。特に PGが傲慢になりやすい傾向がある） お互いのリスペクトと問題を解決していこうというポジティブな価値観 を理解し、 事実をありのままに見る目線でいることがエンジニアには必要！！
16. 欠陥（Detect）とは何か？ ～品質は誰かにとっての価値である (G.M.Weinberg）～ • 「バグ」という言葉で抽象化されがちだが、 QA用語では正確には「欠陥」 • 「欠陥」が発見されると「故障」の状態（結果）が成立する可能性がある 仕様相違とかコードミスとか色々あるけど、、私個人の価値観では エンドユーザにとって納得感がある仕様か が最も大事だと思う。かなり違和感のある状況があれば、 それは欠陥かもしれません。 直せるチャンスが今あるなら、そこは追求したい。自分は。 …色々難しかったけどね。。
17. ありがとうございました！