Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ソフトウェアテスト
Search
Cybozu
PRO
July 13, 2023
Technology
7
5.3k
ソフトウェアテスト
Cybozu
PRO
July 13, 2023
Tweet
Share
More Decks by Cybozu
See All by Cybozu
2024/11/25 ReDesigner Online Meetup 会社紹介
cybozuinsideout
PRO
0
170
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
45k
テクニカルライティング
cybozuinsideout
PRO
4
330
サイボウズのアジャイルクオリティ2024
cybozuinsideout
PRO
3
300
モブに早く慣れたい人のためのガイド2024
cybozuinsideout
PRO
3
410
モバイル
cybozuinsideout
PRO
3
210
ソフトウェアライセンス
cybozuinsideout
PRO
4
180
ソフトウェアテスト
cybozuinsideout
PRO
3
290
自動テスト
cybozuinsideout
PRO
3
300
Other Decks in Technology
See All in Technology
Kubernetesを知る
logica0419
16
4.3k
AWS認定試験の長文問題を早く解くコツ
keke1234ke
0
140
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
170
PFN Company Deck
pfn
PRO
2
140
ONNX推論クレートの比較と実装奮闘記
emergent
0
260
メインテーマはKubernetes
nwiizo
2
320
Hyperledger Fabric(再)入門
gakumura
3
6.7k
もう一度、 事業を支えるシステムに。
leveragestech
6
3k
SONY AITRIOSによるAIエッジセンシングの新たな可能性(仮)
iotcomjpadmin
0
310
そろそろOn-Callの通知音について考えてみよう (PagerDuty編)
tk3fftk
1
270
GitHub Copilot全社導入のその後とGitHub×ZOZOTOWNコラボレーションの舞台裏 / GitHub ZOZOTOWN
ikkou
0
120
LLMを「速く」「安く」 動かすには / CloudNative Days Winter 2024
pfn
PRO
4
1.2k
Featured
See All Featured
Facilitating Awesome Meetings
lara
50
6.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
27
2.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Code Reviewing Like a Champion
maltzj
520
39k
Ruby is Unlike a Banana
tanoku
97
11k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
A designer walks into a library…
pauljervisheath
204
24k
Gamification - CAS2011
davidbonilla
80
5k
Faster Mobile Websites
deanohume
305
30k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
How to Ace a Technical Interview
jacobian
276
23k
Transcript
ソフトウェアテスト 2023-05-17 サイボウズ開運研修
いきなりですが。。。 『ソフトウェアテスト』と聞いてどんなイメージがありますか︖
• 存在は知っているけれど、何をしているのかはあまりわかっていない。
• 存在は知っているけれど、何をしているのかはあまりわかっていない。 • ⾯⽩くないし、かっこよくないからやりたくない。
• 存在は知っているけれど、何をしているのかはあまりわかっていない。 • ⾯⽩くないし、かっこよくないからやりたくない。 • ソフトウェアテスト⼤好き︕︕
• 存在は知っているけれど、何をしているのかはあまりわかっていない • ⾯⽩くないし、かっこよくないからやりたくない • ソフトウェアテスト⼤好き︕︕ みなさんはどれが⼀番近いですか︖
この講義の⽬的は、 ソフトウェアテストって実は⾯⽩いのかも︖ と少しでも思ってもらえること︕
1. ソフトウェアテストの概要
ソフトウェアテストとは︖ ▌ソフトウェアテストは、⽂字どおり「ソフトウェアをテストする」⾏為のこと。 ▌ソフトウェアをテストする⾏為とは、ただ闇雲にソフトウェアを動かすだけで はなく l 定義されている仕様を満たす結果が得られるかを確認する「機能テス ト」 l ソフトウェアの使いやすさなどを評価する「⾮機能テスト」 など、様々な観点から作成されたテストを実⾏すること。
もしテストをしなかったら。。。 ▌バグだらけの製品がリリースされてしまうかもしれない
もしテストをしなかったら。。。 ▌バグだらけの製品がリリースされてしまうかもしれない クレームに発展して、最悪の場合は企業の信頼が失われることも。
もしテストをしなかったら。。。 ▌ユーザーが求める要件を満たしていないソフトウェアになってしまうかもしれ ない
もしテストをしなかったら。。。 ▌ユーザーが求める要件を満たしていないソフトウェアになってしまうかもしれ ない 多⼤な開発費⽤を費やしたのに、全く使われない可能性がある。
もしテストをしなかったら。。。 ▌バグだらけの製品がリリースされてしまうかもしれない ▌ユーザーが求める要件を満たしていないソフトウェアになってしまうかもしれ ない ほんの⼀例ですが、これらのリスクはソフトウェアテストを⾏うことで軽減するこ とができます。
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ▌ソフトウェアがユーザーの期待を満たしているかを確認する ▌ソフトウェアの品質を測る ▌ソフトウェアが標準を遵守していることを検証する
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ▌ソフトウェアがユーザーの期待を満たしているかを確認する ▌ソフトウェアの品質を測る ▌ソフトウェアが標準を遵守していることを検証する
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ⽋陥とは・・・ソースコードや作業成果物における誤り つまり、『バグ』のことを指す。
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ なぜ⽋陥が発⽣するの︖⽋陥が発⽣したらどうなるの︖
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ なぜ⽋陥が発⽣するの︖ ⇨⼈間がエラー(誤り)を起こすから。 要件を適切に導出できなかったり、プログラミングでコードに⽋陥をもたらした り。
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ⽋陥が発⽣したらどうなるの︖ ⇨⽋陥が発⽣している箇所が実⾏されると、故障が発⽣する。
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ⼈間が起こしたエラーにより⽋陥が⽣まれ、その⽋陥が実⾏されることで故 障が起こる。
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ユーザーに影響があるのは「故障」。 ソフトウェアテストであらかじめ⽋陥を防ぎ、故障を発⽣させないようにする。
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ ⽋陥の原因になっているものは「⼈間のエラー」。 開発プロセスの改善で、⼈間がエラーを起こしにくくすることも ソフトウェアテストの役割の⼀つ︕
ソフトウェアテストの⽬的 ▌ソフトウェアの⽋陥を防ぐ 1. ソフトウェアテストで⽋陥を防ぎ、故障を発⽣させないようにする。 2. テストを通して、⽋陥の原因である⼈間のエラーを防ぐための体制を整 える。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する ユーザーが求める品質ってなんだろう︖
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する ユーザーが求める品質は、ソフトウェアの性質や使⽤する状況にもよる。 そのため、⼀つの型にはめることはできない。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する ユーザーが求める品質をモデル化した「狩野モデル」というものがある。
ソフトウェアテストの⽬的 ▌狩野モデル 物理的充⾜状況が不充⾜の場合と充⾜の場合のそれぞれの満⾜感の 現れ⽅の組み合わせによる両者の対応関係から品質要素を区分する。 • 魅⼒的品質 • ⼀元的品質 • 当たり前品質
• 無関⼼品質 • 逆品質 狩野 紀昭, 瀬楽 信彦, ⾼橋 ⽂夫, 辻 新⼀ 「魅⼒的品質と当たり前品質」 『品質』, 1984 年, 14 巻 2 号, p. 147-156
ソフトウェアテストの⽬的 引⽤︓https://shiftasia.com/ja/column/狩野モデルから探る品質
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する 狩野モデルに定義されている5つの品質要素のうち、特に品質において⼤き な影響を与える3つの要素がある。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する 1. 当たり前品質 2. ⼀元的品質 3. 魅⼒的品質
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l 当たり前品質 それが充⾜されれば当たり前と受け取られるが、不充⾜であれば不満を引 き起こす品質要素。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l 当たり前品質 ユーザーが当たり前に感じる機能が搭載されていないソフトウェアは誰にも 使われず、企業の評判を下げることもある。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l 当たり前品質 最優先で取り組むべき品質要素︕
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l ⼀元的品質 それが充⾜されれば満⾜、不充⾜であれば不満を引き起こす品質要素。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l ⼀元的品質 ソフトウェアの使いやすさや動作の快適さなどのUXやUIに対応することが多 い。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l ⼀元的品質 他ソフトウェアとの差別化でユーザーの期待を満たす︕
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l 魅⼒的品質 それが充⾜されれば満⾜を与えられるが、不充⾜であってもしかたないと受 けとられる品質要素。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l 魅⼒的品質 ユーザーの隠れた期待を満たすことで、信頼関係をより強固に築く。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する l 魅⼒的品質 ソフトウェアの付加価値をさらに向上させる︕
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する これらのユーザーの求める品質(期待)を満たしているかを評価するのも ソフトウェアテストの役割。
ソフトウェアテストの⽬的 ▌ソフトウェアがユーザーの期待を満たしているかを確認する ソフトウェアテストでは、定義されている仕様についてだけではなく、 ユーザーが求めているソフトウェアが作られているか︖という視点を持つことも ⼤切。
1章のまとめ ソフトウェアテストとは・・・ l ソフトウェアをテストして l ソフトウェアに存在するバグを発⾒して修正して l ユーザーが求めているソフトウェアを探求する⼯程︕
2. ソフトウェアテストの種類
ソフトウェアテストの種類について ▌ソフトウェアテストの種類として、JSTQBではテスト活動のグループを以下 のように分類している。 l 単体テスト(ユニットテスト、コンポーネントテスト) l 結合テスト(インテグレーションテスト) l 総合テスト(システムテスト) l
受け⼊れテスト(ユーザーアクセプタンステスト)
ソフトウェアテストの種類について ▌それぞれのテストが、どの開発内容に対するテストなのか、何に注⽬した テストかを⽰すモデルとして『V字モデル』が存在する。 引⽤︓https://webrage.jp/techblog/v_shaped_mode/
ブラックボックステストとホワイトボックステスト ▌JSTQBでは、ソフトウェアをテストする⽅法をいくつかに分類している。 l ブラックボックステスト l ホワイトボックステスト l 経験ベースのテスト(今回は割愛)
ブラックボックステストとホワイトボックステスト ▌ブラックボックステスト l ソフトウェアの内部処理は気にせず、操作とその結果だけを⾒る。 l ソフトウェアが外部仕様通りに作成されているかを確認する。 l 利⽤者側の⽬線で⾏うテスト。
ブラックボックステストとホワイトボックステスト ▌ホワイトボックステスト l ソフトウェアの内部構造(ソースコード、内部仕様など)をもとに⾏う。 l プログラムが想定通りに動いているかを確認する。 l 作り⼿側の⽬線で⾏うテスト。
ブラックボックステストとホワイトボックステスト ブラックボックステストとホワイトボックステストで、 ソフトウェアの外側と内側どちらからもテストを⾏なって品質をあげよう︕
動的テストと静的テスト ▌ソフトウェアテストは、ソフトウェアが出来上がるまでテストできない︖
動的テストと静的テスト ▌ソフトウェアテストは、ソフトウェアが出来上がるまでテストできない︖ l 「静的テスト」という、要件定義書や仕様書、設計書などのドキュメントか ら⽋陥を⾒つけるテスト(レビュー)がある。 l 静的テストをソフトウェアを動かすテスト(動的テスト)の前から⾏うこと で、⽋陥の早期発⾒が期待できる。
動的テストと静的テスト ▌静的テストで⽋陥を早期に検出するメリットは︖ l ⽋陥の早期検出を⾏うことで、修正コストが⼤幅に削減される。 l 後期に発⾒される⽋陥は、作業成果物の更新や確認、影響範囲の調査及 びテストを実⾏するコストがかかる。 l 静的テストで早期発⾒した⽋陥は、⽋陥箇所のみを修正するだけで完了する など、安価なコストで修正が可能。
ソフトウェアテストのタイミング ▌開発プロセスの初期から静的テストを開始し、動的テストの前に⽋陥の 早期検出で開発コストを下げよう︕ ▌静的テストに限らず、⽋陥は後⼯程で検出されるほど修正にコストがか かってしまう。 l 開発プロセスの早い段階で⾏う単体テストや結合テストも⼤事︕︕
2章のまとめ l テストは開発プロセスのどこでもできる︕ l それぞれのプロセスに適した種類のソフトウェアテストを⾏って、効果的に 品質をあげよう︕
3. ソフトウェアテストの7原則
ソフトウェアテストの原則︖ ▌ソフトウェアテストには、『ソフトウェアテストの7原則』というものがある。
ソフトウェアテストの7原則 1. テストは⽋陥があることは⽰せるが、⽋陥がないことは⽰せない 2. 全数テストは不可能 3. 早期テストで時間とコストを節約 4. ⽋陥の偏在 5.
殺⾍剤のパラドクスにご⽤⼼ 6. テストは状況次第 7. 「バグゼロ」の落とし⽳
ソフトウェアテストの7原則 ▌ソフトウェアテストは万能ではない。 l ソフトウェアで起こりうる故障を全て発⾒することはできない。 l テストで⽋陥があることは⽰せるが、⽋陥がないことは⽰せない。 l 発⾒した故障が少なくても、品質が⾼いとは判断できない。
3章のまとめ l 完璧なテストをすることや、故障が全く発⽣しないソフトウェアを作成する ことは不可能︕ l 限られたリソースの中でソフトウェアテストの最⼤限の効果が得られるよう に、テスト技術を磨くことも⼤切︕
4. ソフトウェアテストのプロセス
ソフトウェアテストのプロセス ▌「ソフトウェアテストをする」=「テストを実⾏する」ではない。 ▌効果的なソフトウェアテストを⾏うためには、テスト実⾏以外にもやるべき ことがある。
ソフトウェアテストのプロセス ▌ソフトウェアテストの全体像 l テスト計画 l テストのモニタリングとコントロール l テスト分析 l テスト設計
l テスト実装 l テスト実⾏ l テスト完了 テスト 計画 テスト 分析 テスト 設計 テスト 実装 テスト 実⾏ テスト 完了 テストのモニタリングとコントロール
ソフトウェアテストのプロセス ▌テスト計画 l テストの⽬的を定義し、テストのアプローチを決定する。 l スケジュールやコスト、メトリクスもここで計画する。
ソフトウェアテストのプロセス ▌テストのモニタリングとコントロール l テスト計画で決定したメトリクスを利⽤してテストの進捗を計測する。 l 計測した進捗から現状のテストの状況を把握し、必要であれば是正 処置を⾏う。 l テストの終了判定もここで決める。
ソフトウェアテストのプロセス ▌テスト分析 l 仕様書やソースコードなどの開発成果物から、ソフトウェアの何をテスト するのかを分析する。 l テスト対象の優先度付けを⾏い、いつテストするのかを決定する。 l 情報を分析することで、仕様の不備に気が付くこともある。
ソフトウェアテストのプロセス ▌テスト設計 l テスト分析で決定したテスト対象をどうテストするのかを決定する。 l 抽象的なテストケースを作成し、テストの全体像やそのテストの必要 性を把握できるようにする。 l テスト技法を使⽤し、より正確に、効率的にテストを作成する。 l
対象のテストの実⾏⽅法を⾃動テストか⼿動テストかを決定する。
ソフトウェアテストのプロセス ▌テスト実装 l テスト設計で作成した抽象的なテストケースを、より具体的なテスト ケースへと書き出す。 l テストケースの⼿順を明確にする。 l テストに必要なスクリプトやデータの作成を⾏う。
ソフトウェアテストのプロセス ▌テスト実⾏ l テスト実装で作成したテストケースを実⾏する。 l テストは⼿動で⾏う場合もあれば⾃動で⾏われる場合もある。 l 検出された故障を報告し、修正された⽋陥を再度テストする⼀連の 活動も含まれる。
ソフトウェアテストのプロセス ▌テスト完了 l テストで得られた情報を集め、今後のテストにどう活かすのかを検討す る。 l テストで使⽤した環境の整備を⾏う。
4章のまとめ l テストはいきなり実⾏するのではなく、プロセスをきちんと踏むことでより効 率的に、効果的にテストを実⾏することができる︕ l どこをどのようにテストしようか︖ l このテストは本当に必要なのか︖ l 仕様にはないけど、ここってテストしなきゃいけないのではないか︖
l テストプロセスを通じて、テスト対象だけでなくソフトウェア全体の品質を考 えよう︕
5. 最後に
最後に ソフトウェアテストは、ただ仕様に沿ってソフトウェアを操作するだけではない んです。 ユーザーに⾃信を持ってソフトウェアを届けるために、バグを⾒つけ、仕様を 改善し、使いやすさを追求する。ソフトウェアテストにはそんな役割もあります。
最後に ソフトウェアテストについて知るべきなのは、QAエンジニアだけではありません。 開発プロセス全体でソフトウェアの品質を上げていくためには、開発者もソフ トウェアテストについて知っておくべきです。
最後に この講義でお話ししたソフトウェアテストについての内容は、ほんの⼀握りの 内容でしかありません。 例えば、「テスト技法」という、テスト設計をもっと効率的にかつ効果的にして くれるスキルもあります。
最後に まだまだ、世間的には開発と⽐べるとテストなんて。。。と思われていることも 確かです。 ただ、この講義がみなさんのソフトウェアテストへの⾒⽅がよい⽅向に向くきっ かけになれば嬉しいです︕
参考⽂献 ▌JSTQB Foundation Level シラバス Version 2018V3.1.J03