テスト

実装が完了し、リリースするためのチェック
ここを疎かにすると、リリース後不具合が発生し場合によってはユーザーへ謝罪、返金。
企業として損失。信頼が失われる結果となる。

一番大事な工程です。
開発者がテストしたり、テスト担当者がテストしたりと現場によって異なります。開発者とテスト担当者が確認すべきですね。仕様を理解している開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあうことが品質を高めるのではないでしょうか。
※仕様書が無い場合も多く「企画」、「開発」と連携し進めていく必要があります。

テスト仕様書を作成しテストケースを用意する

「テスト計画」、「テスト設計」をし、「テストケース」を作成します。
レビューも必要となりますので、見積には追加。

「テスト計画」
・どんなテストをするのか（テストの種類）機能テスト、セキュリティテストや負荷テスト
・どこまで担保するのか（決めないと、最後でやったやっていないの問題となります）
・テストを中止する場合や再開する基準は（実施環境の設定不備）
・実行環境の確認（例「テスト環境」→「Staging環境」→「本番環境）」での確認なのか？）
・テスト結果（「OK」はどこまでの範囲か、「NG」はどこからなどを決める）
・テストツールは使用するのか（使用する場合は、対象案件での使用メリットも記載）
・全体のスケジュール（定例MTGや、各テストの期間、実施担当者）
・プロジェクトマネージャーやQAマネージャ、QAリーダー、QAテスターの役割の明記
・仕様変更や、FIX決めの対応
・テストリスク（リスク発生頻度、重大度）と対策事項（リスクレベルの設定）はまとめているか

「テスト設計」
・仕様書から読み取れるレベル（仕様書有が前提）

※仕様書が無い場合、どこまで担保するか線引きをしておく

何をもって確認「OK」とするか、また「NG」とするか。各部署との確認を明確化する。無いからわかりません。やりませんでしたと無いように、テスト準備段階で確認する。

・内部構造を理解し設計するレベル（開発経験がある担当者）
・テスト経験者の勘や知識から実行する探索的テスト（※テスト担当者に依存する）

「単体テスト」、「結合テスト」、「システムテスト」

テスト自動化だけでは難しいので箇所によっては、やはり手動になってしまう。開発用テストケースです。設計書の動作だけではなく、設計書に記載していない箇所もテストケースに入れます。あとは、Webブラウザ単位にテスト。バージョン単位にテスト。

※参考資料
スマホ最新機種
Android OS シェア
iOS OS シェア
ブラウザシェア

下記はテストケース例になります。想定は、WEB系のQAチームになります。※第三者検証のテスト会社になるともう少し、画面単位の粒度が変わります。ナレッジはありますが、開発者との距離が離れてしまう懸念もあります。しかし、開発者では気がつかない不具合を検出するには良いと思います。

1.企画書(構成書)もしくは、設計書からテストケースを作成します

テスト準備シート

①テスト環境が用意されている(※テスト環境に不備がないかどうかも確認)
②Android検証用端末と実行用の「apkファイル」が用意されている
③iOS検証用端末と実行用の「ipaファイル」が用意されている(※リサインが必要であればこれも）
④不具合用親チケットが作成されている
⑤テスター用のアカウントが用意されている
⑥ステータス毎のテストデータが用意されている
⑦テストケースがレビュー済でレビュー修正されている
⑧使用WEBブラウザとバージョンが用意されている
⑨テストツール(Selenium、Jmeter、BurpSuite)が用意されている
※テストツール選定によって異なります。

テストデータ問題がある。
どれだけ用意したらいいのか。ここは難しいですね。どういう方法で作成すれば？？
1.オールペア法と直交表による組み合わせ(※禁則を除く)
2.テストデータツールを使用
PICT（Pairwise Independent Combinatorial Testing tool）
http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi
Excelプラグインツールに「PictMaster」
http://sourceforge.jp/projects/pictmaster/

UIの確認

①入力値チェック
1.maxlengthが指定されている場合(※10文字である場合、9文字、10文字は入力可能。11文字は、入力できないこと)
2.maxlengthが指定されていない場合
3.空白文字
4.半角文字(ｱｲｳｴｵ、ｶｷｸｹｺ)
5.全角文字(あいうえお、かきくけこ)
6.機種依存文字(①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳：㍉㍍㌔㌘㌧㌦㍑㌫㌢：㍻㍼㍽㍾：ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ)
7.記号文字(〃 仝 ゝ ゞ 々 〆 ヾ ― ‐ ／ 〇 ヽ ＿ ￣ ¨ ｀ ´ ゜ ゛ ＼ § ＾ ≫ ￢ ⇒ ⇔ ∀ ∃ ∠ ⊥ ⌒ ∂ ∇ ≡ ∨ ≪ † √ ∽ ∝ ∵ ∫ ∬ Å ‰ ♯ ♭ ♪ ‡ ～ ′ ≒ × ∥ ∧ ｜ … ± ÷ ≠ ≦ ≧ ∞ ∴ ♂ ♀ ∪ ‥ ° ⊃ ⊂ ⊇ ∩ ⊆ ∋ ∈ 〓 〒 ※ ″)
8.小数点（第一位まで、第二位まで）
9.マイナス値
10.HTMLエスケープ(<>&"')
11.JavaScriptへの埋め込み文字(<>&"')
12.SQLエスケープ('"%_％＿)

②リンク表示、リンククリック遷移
③ボタン表示、ボタンクリック遷移
④プルダウン値、ラジオボタン、チェックボックス、テキストエリア
⑤必須項目で未入力の場合の振る舞い
⑥クリックを数回した場合の振る舞い
⑦数回リロードした場合
⑧存在しないパラメータを渡す
⑨画面間のデータの受け渡し
⑩ステータスによる画面表示処理の振る舞い

バックエンド確認（SQL、Linuxコマンドでの確認）

①DataBaseに接続できる
②新規、既存、テーブルがある。カラムの追加がある場合は確認。またテストデータ更新、追加した場合の値の確認。
③「ユーザー」と「管理者」ロール権限の確認
④メール自動設定時のcron設定のパス確認。crontab -l
⑤「http」と「https」のプロトコル確認
⑥config設定が正しい
⑦エラーレベルは適切か。
⑧エラー時には、Error.logに出力。
⑨jQueryのバージョン確認(※使用ライブラリーの確認)
⑩phpのバージョン確認、MySQLのバージョン確認（※バージョンによっては今まで使用できた関数が使えなかったりするので確認が必須）
⑪メール送信時には、送信ログが出力。
⑫ストアドプロシージャ(呼び出しの確認)
⑬マスターDBのダンプ
⑭MySQLスレーブサーバの確認

2.テスターにわかりやすいように、テスト詳細や、前提条件などを用意。
3.重要度「高」「中」「低」やテスト区分「正常系」「異常系」も設定します。
4.テスターは、期待値が実測値とあっているかを確認し、テスト結果をプルダウンから選択「OK」「NG」「PN」を作成。また、不具合管理票にも記載しましょう。
「OK」は、期待値と実測値があっている
「NG」は、期待値と実測値が違っている
「PN」は、テスト環境不備やテストケース自体実行できない場合
5.バグ検出率や、テストケース消化率を算出できるように。ここはExcel関数を使用して集計を楽にしましょう。

※テストを実行するための準備シートも用意
1.テストデータ
2.テスト環境の確認(DBに接続できる、対象のテーブルがある、phpのバージョンが正しい)

トップシート(ここで各シートの計算を表示しています)

1.テストケース件数
2.テスト消化件数
3.バグ検出率
4.テスト消化率

テストシート

不具合の記載

テストケースには、テスト結果項目でNGを選択。
再現手順をバグ管理システムに登録する。
一般的には、JiraやRedmineが使われることが多い。Backlogも。