Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テストについて考えていること
Search
shimarisu_121
April 23, 2024
Technology
0
55
テストについて考えていること
2024.04.13
「テストについて」というお題についてある場所で話した際のLT資料です
自分はどういうことを考えてきたのか?を振り返るような内容になりました
shimarisu_121
April 23, 2024
Tweet
Share
More Decks by shimarisu_121
See All by shimarisu_121
私のVSCodeの設定
kawana77b
0
36
喫煙のこと
kawana77b
0
43
Other Decks in Technology
See All in Technology
ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring
visional_engineering_and_design
1
120
SaaS型なのに自由度の高い本格CMSでサイト構築と運用のコスパ&タイパUP! MovableType.net の便利機能とユーザー事例のご紹介
masakah
0
110
マネジメントって難しい、けどおもしろい / Management is tough, but fun! #em_findy
ar_tama
7
1.1k
freeeのアクセシビリティの現在地 / freee's Current Position on Accessibility
ymrl
2
200
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
50
19k
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
360
LLM時代の検索
shibuiwilliam
2
150
いつの間にか入れ替わってる!?新しいAWS Security Hubとは?
cmusudakeisuke
0
120
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
27k
Glacierだからってコストあきらめてない? / JAWS Meet Glacier Cost
taishin
1
160
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
280
OPENLOGI Company Profile for engineer
hr01
1
34k
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Adopting Sorbet at Scale
ufuk
77
9.5k
Navigating Team Friction
lara
187
15k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Balancing Empowerment & Direction
lara
1
430
Typedesign – Prime Four
hannesfritz
42
2.7k
Gamification - CAS2011
davidbonilla
81
5.4k
Bash Introduction
62gerente
613
210k
How STYLIGHT went responsive
nonsquared
100
5.6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
The Invisible Side of Design
smashingmag
301
51k
Transcript
テストについて考えていること 2024/04/13 shimarisu_121
テストの5大要素 すべてのテスト技法は以下の要素を持つ • テスト実施者 • カバレッジ • 発見したい問題(推測される潜在的問題は何か?) • 作業内容
• 結果の判定方法(パスする基準は?) 出典: ソフトウェアテスト293の鉄則
テストの7原則 • テストは欠陥があることは示せるが、欠陥がないことは示せない • 全数テストは不可能 • 早期テストが時間とコストを節約 • 欠陥は偏在する •
テストは弱化する • テストはコンテキスト次第 • 「欠陥ゼロ」の落とし穴 出典: JSTQB FLシラバス
テストにおける思考 テストとは探求であり、その為に3つの思考法を利用する(探索的テストで重要) • 前方思考 ◦ Aというボタンが実在するよね、これを押したらどうなるのだろうか? • 後方思考 ◦ 機能Bなんてものがあってもいいよな。モジュールCをチェックしよう
• 水平思考 ◦ この機能面白いな。もっと過激にしたらどうだろう? 出典: ソフトウェアテスト293の鉄則
モンキーテストも時には行う 衝撃のバグが見つかることもある。しかし、基本的に経験則ではあま り効率は良くない。日々の数%くらいの時間で取り組むと良いのかも しれない テストの自動化は致命的欠陥の予防に相当役立ちますが、 経験則的には潜在的欠陥の多くは 意識して探さないと見つかり ません
寄り道:コーディングするときの思考 主にコードリーディングで意識していること • エディタの型定義や参照機能を利用して、コードを「掘って」中身の正しさを チェックする ◦ スクリプト言語(pythonなど)なら外部パッケージも掘れる • gh searchやsourcegraphでオープンソースの類似コード事例やissue
をチェック • testsフォルダの単体テストはその関数の「使い方」を示している場合も多い • アーキテクチャやデザパタ、各種サードパーティライブラリの勉強は「チャレ ンジで見た」形式で理解の促進に一役買う
バグを発見しやすい方法 • 境界値 ◦ 鉄板。単なるパラメータだけでなく、時間、レイヤ、あらゆる部分の「切 れ目」がバグ要因になる ◦ 単体テストコードを作成するときに根拠を持った上で仕込むべき部分。 一方、老朽化したらまず疑うのもここ •
例外処理・イレギュラー処理のチェック ◦ 保険処理と言われる類に対して「イジワル」をしてみる • 同値分割(バグが出た箇所と似たクラス値) • 何かしらの別構成 ◦ OSやバージョン、プロセッサのタイプを変えたら?
ガチガチにやるのなら ブラックボックステストにおける様々な方法の例 • デシジョンテーブル • 状態遷移表 • 直交表 • 仕様書の点検(文言に嘘はないか?)
超面倒なので頑張って取り組む必要はないと思うが、 組合せテストのテスト手法を引き出しに持っている だけでも見えてくるものもある 画像出典: 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/
単体テストは積み上げられる 安定依存の原則(SDP)を達成すればするほど、テストの労力を 下げつつ、安全なソフトウェアを作成しやすくなる なぜなら、 安定に向いたパッケージの境界値テストが厳密に行われている のなら、それに依存したパッケージのテストは境界値の定義をよ りゆるやかに出来る(手抜きできる)為
バグリポートについて • 「なんか変です」みたいな抽象的な報告をしない • それは明らかな仕様相違ですか?疑問・疑念ですか?あなたの個人的願 望ですか? • 何をどうしたらそうなるのですか?(とにかく再現手順) ◦ 唐突に気付くこともあるが、「記憶・記録」が大事
◦ スナップショットしつつ、ロールバックして差異を確認できる ような環境があると 良い(コードベースなら、だからgitがある) ◦ 手っ取り早く再現できる方法・ツールがあるのは超重要 ◦ カメラ撮影など、ベタなアナログでも有効な方法・証拠になりうる ◦ 自動化は環境構築頑張ったわ~、な満足感は注意報かも。 古典的でダサく 単純な方法で良い場合もある。全員にとって楽でシンプルが正義
あるべきバグリポートの方法 (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を活用
あるべきバグリポートの方法 (2) • 問題点をハッキリ報告し、解決策は書かない ◦ 解決方針はまた別に決めるから ◦ 正直組織開発だと、だからトホホな部分もあるけれど • 再現性なきバグはない
• ツールや環境関連バグへの感度を上げる ◦ OSSだったら、他のリポジトリのissueとかもちゃんと調べたか、み たいな話。本当にそのアプリのバグですか? 出典: ソフトウェアテスト293の鉄則
OSSの良い例も参考にする - Mozillaの例 - 参照: https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html 分類と環境 再現手順 実際の結果 期待結果
解決策ではなく、問題を説明してください
バグ修正について(プログラマの立場から) • 何をどう変えて解決したか、明確にしているか? ◦ ログがないのに「修正しました」で終わらせない • 原因は明確か? ◦ なぜそうなったのかは理解したのか? •
場当たり修正になってないか? ◦ 役所対応で「言われたからしました」が新たなバグを呼び 起こす。全体を見て他の可能性は考えた?
自分への課題 実務に慣れてくると、QA・プログラマ双方で本音は「 誘導したい自分(達)」がいることに気付く • QA:「このチケットとかにも影響が出るから、 この報告は◦◦という方向で修正してくれないかな 」(そう思っ てリポートの文章を仕込む) • プログラマ:「事情も知らずめんどくせえ、
こうしとけば黙ってくれるかな 」(そう思って変更のコードを仕込 む) 「隠れた本音」が生まれる頻度が増えるが、 ほぼほぼ悪い結果を生む よりスマートな問題解決のプロセスでは、(ストレスフルな)「感情」の介入は不要のはず … (片方の立場にしかないって人が結構いる事情は大きい。特に PGが傲慢になりやすい傾向がある) お互いのリスペクトと問題を解決していこうというポジティブな価値観 を理解し、 事実をありのままに見る目線でいることがエンジニアには必要!!
欠陥(Detect)とは何か? ~品質は誰かにとっての価値である (G.M.Weinberg)~ • 「バグ」という言葉で抽象化されがちだが、 QA用語では正確には「欠陥」 • 「欠陥」が発見されると「故障」の状態(結果)が成立する可能性がある 仕様相違とかコードミスとか色々あるけど、、私個人の価値観では エンドユーザにとって納得感がある仕様か
が最も大事だと思う。かなり違和感のある状況があれば、 それは欠陥かもしれません。 直せるチャンスが今あるなら、そこは追求したい。自分は。 …色々難しかったけどね。。
ありがとうございました!