ソフトウェアテスト・品質勉強会（投影資料）/Software test and quality study (Presentation)

ソフトウェアテスト・品質勉強会 @nihonbuson P1

Agenda • はじめに • テストの立ち位置とは • 何をテストすべきか • どうやってテストケースを作るのか •
どうやってテストを実施すべきか • おわりに P2

はじめに P3

おことわり • 今日の発表は一個人のお話です。 • 所属する会社や団体とは一切関係ありません。 • ただの野菜が喋っているだけです。

アンケート • 開発者？テストエンジニア？ • 勉強会が初めての人？ • テスト関係の勉強会が初めての人？ • JSTQBを知っている人？
• テスト関係の勉強会を運営している人？ • JSTQBの運営に何かしら関わっている人？

こんな経験していませんか？開発はできたけど、テストをどうやれば良いのか分からないよ…。リリースしてからトラブルがいっぱい起きるなぁ…

こんな経験していませんか？開発はできたけど、テストをどうやれば良いのか分からないよ…。リリースしてからトラブルがいっぱい起きるなぁ… 品質やテストのことを学べば解決できるかもしれない！

今日話す内容は… QAチームはどうしていくべきか

今日話す内容は… QAチームはどうしていくべきか ↓ 開発者はどんなことをすべきか

いきなりですが質問です品質とは何でしょうか？テストの目的は何でしょうか？ P4

品質とは何か？

品質とは何か？「本来備わっている特性の集まりが要求事項を満たす程度。」 (ISO9000) 「品物またはサービスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体」 (JIS Z
8101:1981, 1999年に廃止)

品質とは何か？東京海上日動システムズ顧問横塚裕志氏の講演内容より【具体例2】デジタルニュースの普及により、ニュースは、確実な推敲・校正よりも、「早く伝える」「修正」へ【具体例1】
トラブルは0でも、国民の5.8%にしか使われない住基ネットカード。「ソフトウェアの品質（＝存在意義）としては失格」 ※ソフトウェア品質シンポジウム 2014の基調講演にて http://www.publickey1.jp/blog/14/_2014.html P5

テストの目的は何か？

テストの目的は何か？以下のような目的があります。 • 欠陥の検出 • 対象ソフトウェアの品質レベルが十分であることの確認 • 意思決定のための情報の提示 • 欠陥の作りこみの防止
JSTQBシラバスより http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14 開発前に行うこともあるテストの7原則①テストは「欠陥がある」ことしか示せない P6

全体の開発サイクルの中でのテストの立ち位置とは P7

Vモデル(一般的なSIの場合) 要求定義要件定義基本設計詳細設計コーディング単体テスト結合テストシステムテスト受け入れテスト
http://jasst.jp/symposium/jasst12tokyo/pdf/D4-1.pdf を元に作成 P8

Wモデル要求定義要件定義基本設計詳細設計レビュー&受け入れテストの設計レビュー&システムテストの設計レビュー&
結合テストの設計レビュー& 単体テストの設計受け入れテストの実施システムテストの実施結合テストの実施単体テストの実施コーディングデバッグデバッグデバッグデバッグ P9 http://jasst.jp/symposium/jasst12tokyo/pdf/D4-1.pdf を元に作成

なぜ早期のテスト・レビューをするのか http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf#page=31 P10

何をテストすべきか P11

次の仕様に対してどんなテストをすれば良いか。 • パスワードは4文字以上12文字以下の英数字のみを許容する • パスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックする http://www.slideshare.net/takashiyamasaki378/ss-55384920 例題 P12

パスワードは4文字以上12文字以下の英数字のみを許容するパスワードを3分以内に4回以上間違って入力するとアカウントを5分間　ロックする文字列長文字種誤期間入力管理誤入力回数管理
ロック保持期間状態遷移 P14

パスワードは4文字以上12文字以下の英数字のみを許容するパスワードを3分以内に4回以上間違って入力するとアカウントを5分間　ロックする文字列長文字種誤期間入力管理誤入力回数管理
ロック保持期間状態遷移許容しないとどうなる？ (ボタン制御orエラー画面) 5回目の入力はどうなる？ P14

パスワードは4文字以上12文字以下の英数字のみを許容するパスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックするもしもドキュメントが無かったら… どのようなテストを行えば良いか分からなくなります

テストすべき内容（テスト観点）の見つけ方 http://jasst.jp/symposium/jasst13niigata/pdf/S2.pdf P15

視座・視野・視点のイメージ https://tech.drecom.co.jp/viewpoint-of-being-leader/

視座 P16

視野 P17

視点 P18

（参考）品質特性 http://www.atmarkit.co.jp/ait/articles/0905/13/news124_3.html P19

使用性の例

使用性の例面白いデザインだ！採用！デザイナーどこに何があるのか分からない！利用者

使用性の例並び変えるだけでも分かりやすくなる https://note.openvista.jp/2011/redesigning-shinjuku-building-sign

どうやってテストケースを作るのか P20

テストケースはいくつ？パスワードは4文字以上12文字以下 1文字、2文字、3文字…100文字膨大な数のテストケーステストの7原則②全数テストは不可能 P21

テストケース作成者「◦◦◦のテストをします！」司会者「ほぉ～、それはどうしてだい？」テストケース作成者「【理由を一言】」 P22 テストケース作成の心得

テスト設計技法　～境界値分析～テストの7原則④欠陥の偏在 12 4 有効無効無効 3 13 パスワードは4文字以上12文字以下
P23

テスト設計技法　～境界値分析～テストの7原則④欠陥の偏在 12 4 有効無効無効 3 13 パスワードは4文字以上12文字以下
P23 0

テスト設計技法　ストップウォッチの例スタート/ストップリセット https://goo.gl/iAvVm8

テスト設計技法　～状態遷移テスト～待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップ
P24 待機中計測中一時停止中

テスト設計技法　～状態遷移テスト～待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/ ストップ
P24 待機中計測中一時停止中計測中

テスト設計技法　～状態遷移テスト～ P24 待機中計測中一時停止中スタート/ストップリセットスタート/ ストップスタート/
ストップ

テスト設計技法　～状態遷移テスト～待機中計測中一時停止中スタート/ストップリセットリセットリセットスタート/ ストップ
スタート/ ストップ P24

テスト設計技法　～状態遷移テスト～計測中にリセットボタンを押したら計測中状態から変わらないなんて、問題文（仕様）に書いてない！

テスト設計技法　～状態遷移テスト～今回は私なりに答えを定めました。実務では、動作が不明な時点で開発者に確認すべき。仕様に書いていない→抜け漏れの可能性大→バグの可能性大

どうやってテストを実施するのか P25

テストは実施して終わりではないパスワードを「123」にしてログインしようとしたら、ログインできなかった P26

テストは実施して終わりではないパスワードを「123」にしてログインしようとしたら、ログインできなかった何を確認したくて「123」にしたのか？「ログインできない」とはどのような状態なのか？期待通りの結果なのか？
P26

テストレポート例テスト目的再現手順期待値 OK or NG 実際の結果パスワードが 3桁以下の時
ログイン失敗ページに遷移することパスワード欄に「123」と入力する。ログインボタンを押す。ログイン失敗画面に遷移する NG ログイン画面から遷移せず、「ログイン失敗」と表示される他の人や1年後の自分が見ても分かるように書く P27

まとめ P28

まとめ • テストの目的は欠陥の検出以外に欠陥の未然防止がある • テストには開発開始前に行う活動もある • 早期にテストやレビューをすることでコストを削減できる • テストすべき内容には、仕様書から見つけられる内容以外にも、過去の経験から得られることや品質特性などがある
• 全てを闇雲にテストすると膨大なケース数と時間が発生するが、その数を削減できる手法がある • テストを実施したときは、他の人が分かるように結果を書く P29

おまけ（講座中にあった質問）

QAチームは何をするの？これだけテストが充実できればQAチームは必要ないのでは？

QAチームは何をするの？これだけテストが充実できればQAチームは必要ないのでは？ ⇒まだまだ必要なことが多いです。本来、テストエンジニアはCheckingではなく Testingを行いたい

QAチームは何をするの？ http://www.satisfice.com/blog/archives/856

QAチームは何をするの？ https://www.infoq.com/jp/news/2009/12/testing-or-checking

QAチームは何をするの？ http://www.jasst.jp/symposium/jasst17tokyo/pdf/A7.pdf#page=29

（ブラウザ）自動テストについて何でも自動テストにすれば良いんじゃない？（テストの工数が0になるのでは？）

（ブラウザ）自動テストについて何でも自動テストにすれば良いんじゃない？（テストの工数が0になるのでは？） https://www.thoughtworks.com/insights/blog/qa-dead 自動テストは既存のテストの自動化

（ブラウザ）自動テストについて何でも自動テストにすれば良いんじゃない？（テストの工数が0になるのでは？） 1. 自動テストは手動テストを自動化するだけであり、　新たな不具合を発見できない　（テスト自動化の8原則③） 2. 自動テストはテスト結果分析というコストが発生する　（テスト自動化の8原則⑧）
なので「自動テストが出来れば工数が0になる」ということはありません。

（ブラウザ）自動テストについて自動テストはどんな内容が適しているの？

（ブラウザ）自動テストについて自動テストはどんな内容が適しているの？ http://jasst.jp/symposium/jasst16tokyo/pdf/D4.pdf#page=5

他社のテスト事例を知りたい

他社のテスト事例を知りたい https://techbeacon.com/how-tech-giants-test-software-theres-no-one-way-qa

他社のテスト事例1 Google 4段階のテストプロセスを採用している。 1. 専用のテスター(Googleの従業員)によるテスト 2. クラウドテストプラットフォームでのテスト 3. Google従業員に日常業務で使ってもらう (Dogfooding)
4. Google製品のエンドユーザーの　小さなグループに製品を使ってもらう(βテスト)

他社のテスト事例1 Google http://nihonbuson.hatenadiary.jp/entry/2017/03/19/000722 「ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて」（　　　　　　　　　パネルディスカッション）より

他社のテスト事例2 Facebook 専用のテスターを一切使用しない。代わりに、開発者が自分自身でテストする。カナリアリリースを採用している。先行ユーザーの使用状況によって、対象ユーザーを増やすか、完全にその機能を破棄するか選択する。

他社のテスト事例3 Amazon 簡単にdeployでき、簡単にロールバックができるため、広範囲のテストを必要としない。収益が減少していたり、不具合によって顧客が遠ざかると分かった時に、テストの努力を増やす。

テストの勉強方法を知りたいどうやってテストの勉強をすれば良いの？テストの勉強ができるオススメの書籍が知りたい！

テストの勉強でオススメの書籍（入門者向け） https://www.amazon.co.jp/dp/4822282511 https://www.amazon.co.jp/dp/4817193603

テストの勉強でオススメの書籍（自動テスト、入門者向け） https://www.amazon.co.jp/dp/4873118166/ 画面上の自動テストの開発に関わらない人も、第1章と第8章を読むべき

テストの勉強でオススメの書籍（中級者向け） https://www.amazon.co.jp/dp/4798124699 テストとはどうあるべきかが分かる本資格勉強用の本だが、資格を取らなくても勉強になる

おしまい…？

この講座で伝えたかったこと（裏の目的）

社外イベントからの引用が多い

テストの勉強は「習うより慣れよ」 • 1泊2日のワークショップ形式のイベント • 半年に1度開催（6月と12月）。 • 10周年を迎えました！ • 新卒1年目の開発・QAも多く参加 •
参加費は22000円 • 35歳以上は26000円 • ほとんどが宿泊費・経費で利益は無し http://wacate.jp

最新のテスト事情を知るには JaSSTがオススメ • 日本最大級のテストのイベント • 年に8回、各地で実施 • 東京では3月7日と8日に実施（2018年の場合） • JaSST'18
Tokyoの基調講演は GoogleのJohn Micco 氏！ http://www.jasst.jp/

明日も面白そうなイベントが… https://twitter.com/YasuharuNishi/status/966875334762098688

http://www.jasst.jp/symposium/jasst17tohoku/pdf/S1.pdf#page=56

参考資料1　テストの7原則 ①テストは「欠陥がある」ことしか示せない ②全数テストは不可能 ③初期テスト ④欠陥の偏在 ⑤殺虫剤のパラドックス ⑥テストは条件次第 ⑦「バグゼロ」の落とし穴 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=15 P31

参考資料2　テスト自動化の8原則 ①手動テストはなくならない ②手動で行って効果の無いテストを自動化しても無駄である ③自動テストは書いたことしかテストしない ④テスト自動化の効用はコスト削減だけではない ⑤自動テストシステムの開発は継続的に行うものである ⑥自動化検討はプロジェクト初期から ⑦自動テストで新種のバグが見つかることは稀である ⑧テスト結果分析という新たなタスクが生まれる https://sites.google.com/site/testautomationresearch/test_automation_principle
P32

参考資料3 この発表で工夫したこと • 発表の納得感を上げる • 伝えたいことを印象付けるといった発表時に気を付けたことを書きました。「ソフトウェアテスト・品質勉強会」での発表時に工夫したこと http://nihonbuson.hatenadiary.jp/entry/2017/12/09/171946

（本当に）おしまい

ソフトウェアテスト・品質勉強会（投影資料）/Software test and quality study (Presentation)

ソフトウェアテスト・品質勉強会（投影資料）/Software test and quality study (Presentation)

More Decks by nihonbuson

Other Decks in Technology

Featured

Transcript