Web Service QA Meeting Vol.1 の発表資料です。

1. Web Service QA Meeting Vol.1
Webサービスの
ソフトウェアQAと
自動テスト戦略
〜15分版〜
2015/07/13
Masaki Nakagawa
SWET Gr.
Quality Management Dept.
DeNA Co., Ltd.

2. Web Service QA Meeting Vol.1
自己紹介
 #1
⁃ 中川 勝樹
⁃ 株式会社ディー・エヌ・エー
⁃ SWET (Software Engineer in Test)
⁃ SELECKの取材記事
⁃ デブサミ発表資料
⁃ mobage developers blog
 #2
⁃ @ikasam_a
⁃ github.com/masaki
⁃ CPAN Author (metacpan.org/author/MASAKI)
⁃ Testing Casual Talks (#1, #2)
2

3. Web Service QA Meeting Vol.1
3

4. Web Service QA Meeting Vol.1
4

5. Web Service QA Meeting Vol.1
ソフトウェアエンジニアです。
5

6. Web Service QA Meeting Vol.1
SWET (Software Engineer in Test)
 Google の SET とほぼ同じことをしています
⁃ “How Google Tests Software” 参照
⁃ 邦題「テストから見えてくるグーグルのソフトウェア開発」
 やっていること
⁃ 自動テストコード作成
⁃ テスト基盤環境構築
⁃ 自動化技術の応用・実用化
⁃ 品質や開発生産性の向上に関する様々なコンサルや導入支援
 https://career.dena.jp/job.phtml?job_code=476
⁃ SWET という役割に興味のある方は是非！
6

7. Web Service QA Meeting Vol.1
今日話したいこと
 WebサービスのQAとは
⁃ ソフトウェア中心の世界
⁃ Webサービス「じゃない」領域のQAとは
⁃ 違いとは
 WebサービスのQAと自動化戦略
⁃ ソフトウェア中心だからできること
⁃ 逆にできないこと
⁃ エンジニアだからできるQA
⁃ 最適なアプローチ
⁃ やることとやらないこと
7

8. Web Service QA Meeting Vol.1
WebサービスのQAを考える
 Web以外の分野のQAとは
⁃ (例) 従来の工業製品のQA
 ハードウェア出荷製品とQAの関係性
⁃ 何か問題が起こると人命に関わる可能性がある
• (例) 出火、爆発、…
• 人命に関わる問題を起こすわけにはいかない
• 少しでも発生確率があればQAで取り除く必要がある
⁃ 出荷後に全ての製品をアップデートするのはほぼ不可能
• 全国・全世界のすべての製品流通を突き止めることは困難
• 突き止めても全台回収することは非現実的
• リコール
• 出荷前にQAで極力問題を取り除いておきたい
8

9. Web Service QA Meeting Vol.1
WebサービスのQAを考える
 製品の出荷ではなくサービス運用で成立する世界
⁃ リリース後でもサービスアップデートで対応可能
⁃ 多少の問題は後からでもリカバリ可能
⁃ とはいえ絶対に問題を起こしてはいけない部分ももちろんある
 多種多様なユーザが色んな場所から同時利用する世界
⁃ 様々なユーザに使ってもらって初めて分かる事実がある
⁃ そのためにも価値提供のスピードを落としたくない
 WebサービスのQAでやりたいこと
⁃ 如何に事業展開のスピードをQAで落とさずにリリースさせるか
⁃ 且つユーザに使ってもらうために必要なものは揃っているか
⁃ その上で最低限守らないといけない部分を守り切るか
9

10. Web Service QA Meeting Vol.1
WebサービスのQAを考える
 ソフトウェアで構成される世界
⁃ ソフトウェアテスト
 ソフトウェアテストとは
⁃ コンピュータのプログラムを実行し、以下を確認する作業
• 正しく動作するか、
• 目標とした品質に到達しているか、
• 意図しない動作をしないかどうか
⁃ (from: ja.wikipedia.org/wiki/ソフトウェアテスト)
10

11. Web Service QA Meeting Vol.1
ソフトウェアテストの分類
Who Which
How What
11
テストレベル
テスト技法 テストタイプ

12. Web Service QA Meeting Vol.1
ソフトウェアテストの分類
 Who
⁃ Developer Testing
⁃ Acceptance Testing
 Which
⁃ Unit Testing
⁃ Integration Testing
 How
⁃ Black Box Testing
⁃ White Box Testing
⁃ Gray Box Testing
 What
⁃ Functional Testing
⁃ Non-Functional Testing (Performance, Stress, Usability, …)
12

13. Web Service QA Meeting Vol.1
Webサービスの一般的な構成
13
View
Controller
Model
data
data
data

14. Web Service QA Meeting Vol.1
Webサービスの一般的な構成とテスト戦略
14
View
Controller
Model
data
data
data
Acceptance
Integration
Black Box, Gray Box
Functional, Usability, Stress
Developer
Unit
White Box, Black Box
Functional
Developer
Integration
Gray Box

15. Web Service QA Meeting Vol.1
Webサービスの一般的な構成とテスト戦略
15
View
Controller
Model
data
data
data
Acceptance
Integration
Black Box, Gray Box
Functional, Usability, Stress
Developer
Unit
White Box, Black Box
Functional
Developer
Integration
Gray Box
開発者がしっかり
単体テストする
自動化できる部分と
できない部分がある
View/Model 境界
重複しがち

16. Web Service QA Meeting Vol.1
Model のテスト
 開発時にしっかり単体テストをする
⁃ ビジネスロジックごとにテストする
 単体テストできるように設計する
⁃ ビジネスロジックを適切に分割する
⁃ 外部依存を切り離せるようにする
• テストダブル、フィクスチャ
⁃ テスタビリティの高い設計にする
16

17. Web Service QA Meeting Vol.1
View のテスト
 ユーザシナリオに沿ってエンドツーエンドテストをする
⁃ シナリオテスト・機能テストに相当する部分は自動化可能
 自動化できない・しない部分こそ、マニュアルでしっかりやる
⁃ 表示・レイアウトの確認
⁃ ユーザビリティテスト
⁃ スクリーンショットなど効率化できる部分は半自動化
17

18. Web Service QA Meeting Vol.1
Controller のテスト
 いっそのこと重複する部分はやらない
⁃ Model と重複する部分はビジネスロジックのテストとして実施
⁃ View と重複する部分はエンドツーエンドテストとして実施
⁃ 上 (View) と下 (Model) からトータルでしっかり抑える
 重複・スキップするための設計
⁃ Model と View の設計・実装範囲が適切であること
⁃ テスタビリティの高い設計（ｒｙ
 (参考) プログラマの三大美徳
⁃ 怠惰（Laziness）
⁃ 短気（Impatience）
⁃ 傲慢（Hubris）
18

19. Web Service QA Meeting Vol.1
まとめ
 WebサービスのQAとは、
⁃ 如何にスピード感を持ってリリース「させる」かが重要で、
⁃ そのために、必要なことは揃っている状態であって、
⁃ 且つ、守るべきものがしっかり守れているか。
 Webサービスのテスト戦略とは
⁃ 上 (View) と下 (Model) からトータルでしっかり抑えこむ
⁃ そのためにもテスタビリティの高い設計にする
⁃ 自動化できる部分は自動化して効率化する
⁃ 手動テストは見るべきところに注力する
19