- 2016/01/21
- システム保守ってしんどい
- テストってしんどい
- テスト設計って大事
- 経歴
- 新大阪, SI
- 言語 : Ruby, PHP
- 前職
- 入社から2年半、テスト専門チームでテスト担当者
- 現職
- 入社から3か月、先輩の作ったWEBシステムをテスト
- なんか地味
- ○○システムを新規開発しました！
- 新規開発10人月!
- 保守開発20日
→ モチベーション下がる
- ソースコードが汚い
- ドキュメントが古い（実態と合ってない）
→ モチベーション下が
- 手元のPCではデバッグできない
- なぜか本番では動作しない
- 機能追加のつもりがバグ修正になってる
- 当然、自動テストなど無い
→ モチベーション下がる
- 手元のPCではデバッグできない
- なぜか本番では動作しない
- 機能追加のつもりがバグ修正になってる
- 当然、自動テストなど無い
→ モチベーション下がる
- コードが理解できない
- コードをコピペ
- リリース後不具合発生
- やっつけで修正する
- さらにコードが汚くなる
→モチベーション下がる
- Technical debt (1992 Ward Cunningham)
- もしくは、レガシーコード
- いつかは返さないといけない負債
- 技術不足
- 知識不足
- 納期のプレッシャー
- きれいなコードを書く
- 技術
- 適切なツールを適切に使う
- 知識
- 先人の敷いたレールの上をルールを守って走る
-
テスト技術
-
テスト設計
-
テスト技法
-
自動テスト
-
プロセス改善
-
正しく作っているか？に加えて、正しく作られているか？を確認する
-
テスト自動化が流行ってるけど、分析と設計が大事
-
自動化する部分はどこか？どこから手動でやるか？
- 同値分割？境界値？
テストとは、エラーをみつけるつもりでプログラムを実行する過程である
ソフトウェア・テストの技法 Myers 1979 (The Art of Software Testing)
- 「デバッグ」とは何が違うか？
- デバッグは不具合の修正を行うこと
- テストしてもデバッグしなければ品質が上がらない
テスト担当者の精神面による区分
| レベル4 | テストは行動ではない。大げさなテストをすることなく品質の高いソフトウェアを作るための精神的な訓練である。 |
| レベル3 | テストの目的は、何かを証明することではなく、プログラムが動かないことによって発生する危険性をある許容範囲までに減らすことである。 |
| レベル2 | テストの目的は、ソフトウェアが動かないということを示すことにある。 |
| レベル1 | テストの目的は、ソフトウェアが動くことを示すことである。 |
| レベル0 | テストとデバッグには何の差もない。デバッグ以外にはテストには特別な目的はない |
(「ソフトウェアテスト技法」 ボーリス・バイザー 1990)
西 康晴先生(電気通信大学)いうところの「テスト道」
- 「品質が良い」ってどういうこと？
- バグが少ないこと？
- 品質とは
- 誰かにとっての価値（ワインバーグのシステム思考法）
- 出荷後に社会に与える影響（品質工学）
- 備わっている特性が要求を満たす度合い(ISO9000)
- テストができるようになるためには、何を勉強する必要があるか？
マーケティング的側面
| REBOK | 要求工学の知識体系 |
| BABOK | ビジネス分析の知識体系 |
| BABOK | ビジネス分析の知識体系 |
工学的側面
| SWEBOK | ソフトウェア工学の知識体系 |
| SQuBOK | ソフトウェア品質知識体系 |
| ISTQB/JSTQB | ソフトウェアテスト技術者資格認定 |
マーケティング/工学のバランスを取る
| PMBOK | プロジェクトマネジメント知識体系 |
| | |
|:-----------:|:------------|:-----------:|:------------|
| 1 | ソフトウェア要求 | 9 | ソフトウェアエンジニアリングモデル及び方法 |
| 2 | ソフトウェア設計 | 10 | ソフトウェア品質 |
| 3 | ソフトウェア構築 | 11 | ソフトウェアエンジニアリング専門技術者実践規律 |
| 4 | ソフトウェアテスティング | 12 | ソフトウェア・エンジニアリング経済学 |
| 5 | ソフトウェア保守 | 13 | 計算基礎 |
| 6 | ソフトウェア構成管理 | 14 | 数学基礎 |
| 7 | ソフトウェアエンジニアリング・マネージメント | 15 | エンジニアリング |
| 8 | ソフトウェアエンジニアリングプロセス | | |
セキュリティに関しては特殊な勉強が必要
体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
- 正直しんどい
- テスト技術者に必要な知識は、実は○○エンジニアの中でも特に幅広い
- コンピュータ科学・ソフトウェア工学を前提とした柔軟な発想がテスト技術者の真骨頂
- ソフトウェアは腐らない？
いいえ、腐るし壊れます
- 「テストは欠陥があることしか示せない」
- 「全数テストは不可能」
- 「初期テスト」
- 「欠陥の偏在」
- 「殺虫剤のパラドックス」
- 「テストは条件次第」
- 「バグゼロ」の落とし穴」
マインドマップを書いてみる
- 品質のモデル化/体系化
- ISO9000
- ISO9126
- ISO250xx (SQuaRE)
- ISO29119
- RASIS
- FURPS+
- バグを発見するのではなく、予想している
- 「あの人(チーム)ならこんな風に作ってるかも」
- 「そもそもどのように作られるべきなのか」を追求している
- Excelに書かれたテスト仕様書に○をつけるのはテストのほんの一部でしかない。
- 不具合の見つからない○ばかり並んでいるテスト仕様書は、品質の低いテスト仕様書である
ソフトウェアテスト教科書 JSTQB Foundation 第3版
→これくらいは基本書籍として押さえておいてやっと入門者
→開発やってる会社だと新入社員に読ませるテキスト
もっと簡単な本は
-
JSTQB (JSTQB認定テスト技術者資格)
-
JCSQE (ソフトウェア品質技術者資格試験)
-
IVIA (IT検証技術者認定試験)
-
QC検定 (Quality Control 品質管理検定)
-
情報処理技術者試験にはテストエンジニアにあたる区分はない・・・
全てのバグを生まれる前に消し去りたい。 すべての宇宙、過去と未来の全てのバグを、この手で