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
Cybozu
PRO
July 13, 2023
Technology
6
4.8k
ソフトウェアテスト
Cybozu
PRO
July 13, 2023
Tweet
Share
More Decks by Cybozu
See All by Cybozu
Recruitment Pitch in New Business Division
cybozuinsideout
PRO
0
12
サイボウズ Office/メールワイズチームの改善の取り組み「困りごと共有会」
cybozuinsideout
PRO
1
16
サイボウズのOSPO
cybozuinsideout
PRO
1
91
非エンジニアの私が試行錯誤の末見出したスクラムマスターの道
cybozuinsideout
PRO
2
130
Kubernetes でもJava アプリでTLS 接続を終端したい
cybozuinsideout
PRO
2
150
Google I/O - 2024 What’s new in flutter
cybozuinsideout
PRO
2
260
Waffle Festival2024(斉藤裕希)
cybozuinsideout
PRO
3
560
主体的な活動で巨大な影響範囲のテストを乗りこなしていく話
cybozuinsideout
PRO
2
360
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
40k
Other Decks in Technology
See All in Technology
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
AI研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
130
フルリモートワークはエンジニアの夢を叶えたか? #cm_odyssey
mamohacy
2
600
LINE WORKSへ簡単通知!Incoming Webhookアプリの紹介
mmclsntr
0
110
可視化プラットフォームGrafanaの基本と活用方法の全て
hamadakoji
0
230
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
年間一億円削減した時系列データベースのアーキテクチャ改善~不確実性の高いプロジェクトへの挑戦~
lycorptech_jp
PRO
3
2.9k
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
220
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
390
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
277
13k
Fantastic passwords and where to find them - at NoRuKo
philnash
42
2.7k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
224
21k
Agile that works and the tools we love
rasmusluckow
325
20k
Mobile First: as difficult as doing things right
swwweet
219
8.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
19k
Fireside Chat
paigeccino
25
2.8k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
24
1.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
652
58k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
17
8.7k
Docker and Python
trallard
37
2.9k
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