ソフトウェアテストの進め方 研修コースに参加してみた
今回参加した研修コースは ソフトウェアテストの進め方 です。
前回レポートした ｢単体テストとテストケースの作り方｣ でも触れていた品質の考え方や品質モデルについて深掘りして解説いただきました。
特にセキュリティの品質という点では、どこまで担保すべきなのか、とても難しいところですが、目からうろこの基準を示して頂き、勉強になりました!
もちろん品質の考え方だけでなく、フェーズ毎にどのテストをすべきなのか、現場感覚のある考え方を学べました。
プロジェクトの上流でQAの基準を考える立場にある方にはオススメのコースです!
では、どんな内容だったのかレポートします!
もくじ
コース情報
| 想定している受講者 | プロジェクトのリーダをこれからやる方、今務めておられる方 |
|---|---|
| 受講目標 | 基準作りの大切さを知る。非機能要件とは何かを明らかにする |
講師紹介
単体テストのコースに続き、 大石 宏一さん が登壇されました。
大石 宏一
AI をはじめプログラミング/ソフトウェアテスト/PMなど幅広く、かつ現場で使える知識と技術にこだわる人気トレーナー
そして、イントロで受講者の方にアンケートです。
受講者の皆さん、なかなか困り顔です。私自身、そう言われるとスプリントでデモが通れば、リリースしていました。。
というわけで、大石さんから ｢基準づくりをしましょう｣ という言葉に納得です。
ソフトウェアテストとは
- プログラムが正しく動作するか
- バグをできる限り多く発見することが成功
- ただし欠陥がないことを証明することは出来ない
ソフトウェアとテスト
ソフトウェアだけでなくシステムというのが重要ですね。個人的にはシステムを置き換えると、ユーザー体験と言えるかも知れません。
システムの品質
- お客様からの明示的な要求だけではない
- 暗黙の特性がある
- 言われなかったとしても、例えば、パスワードリマインダはいる
- 法律に抵触しない
- お客様自身がドメイン知識がないことがある
- 開発者側が必要なこと
- ログを残しておくこと
この “暗黙の特性” が業種･業務をどこまで理解しているか、ということに繋がるので、例えば、保険業の xxxx システムの実績などが重要になるのですね。
信頼度成長曲線
プロジェクト･プロダクトによって、どこまでテストするのかは変わります。例えば、趣味で作ったトーナメントシステムなのか、病院向けシステムなのかで変わります。
このため多くの場合、この信頼度成長曲線を使っています。
- X 軸はテスト項目消化件数
- a が理想
- 初期はバグが大量に出て、落ち着いて収束が見えてくる
- 実際にも a のようになる
ただし、プログラムのステップ数に応じてテスト回数を決めて、画一的にテストしているケースが多いので、これでは品質を満たしている、とは言いにくいのが現状です。
なお b になるパターンは、、炎上プロジェクトでありがち、ということでした。うむむ。
テストの種類
- 開発中のテスト
- 受け入れテスト
- 保守テスト
- 新機能のテスト。特にデグレが起きていないか
- 運用テスト
- 劣化などのテスト
デグレ、とっても聞きたくない。。恐怖です。ちなみに劣化にはどんなテスト手法があるのか気になりました。(日々の監視で閾値を設定するのはテストでも無いですし。。)
テストの原則
- テストは欠陥があることしか示せない
- 全数テストは不可能
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- ｢バグゼロ｣ の落とし穴
単体テストのコースでは触れる程度でしたが、このコースでは深掘りします。ここでは特に印象的だったことを紹介します。
全数テストは不可能
全数テストではなく優先順位を決めてやる必要があります、という言葉を聞いたとき、｢ユーザーの 8 割が、 8 割の時間を使うところから開発しなさい｣ という私の師匠の言葉を思い出しました。この ｢ユーザの 8 割が、～｣ からテストすべきということですね。
初期テスト
- 初期テスト、例えば、詳細設計がでたときに単体テスト、テストケースを書く
- 最後の結合テストのときぐらいからテスト工数が増えるのは、だいたい手戻り
- 手戻り防止にも効く (!!)
- 初期テストのやり方にレビュー技法というのがあります
- レビューにはリーディング技法と呼ばれている手法がある
リーディング技法、めっちゃ気になりますね。大石さんは実際に入ったプロジェクトで、初期フェーズの仕様レビューに時間を掛け、プロジェクト終盤で他チームのモジュール開発が炎上するなか、大石さんのチームはスムーズに終了されたそうです。
品質計画
テスト全般の話の次は品質です。ユーザーにとってはプログラムが正しく動作したとしても、動作が遅ければ納得できません。
その品質に関して解説いただきました。
品質基準
補足して大石さんからわかりやすく、どこまでやるのか指し示していただきました。
利用時の品質
(自社製品の開発の場合は ↑ まで)
(受託開発の場合は ↓ まで)
外部品質
内部品質
品質特性一覧とテストフェーズ
先程の利用時の品質から内部品質を、さらに詳細にします。
- 機能要件と非機能要件を 非機能要求グレード(後述) で分類すると良いです
- 機能要件は機能性と使用性しかない
- 非機能要件はシステムテストでしかテストできない
ユーザーが出してきにくい非機能要求をどうテストするのか、後工程でテストするだけに、上流でどれだけ明確にしておくのか、重要になりますね。
テスト技法
テスト全般、品質の考え方に続き、具体的なテスト技法の解説です。
単体テスト技法
単体テストについては ｢単体テストとテストケースの作り方｣ で詳しくレポートしていますので、ここでは割愛します。
結合テスト技法
- トップダウン
- 上位の機能からテストする
- 下位モジュールが無いので、スタブをよく使います
- ボトムアップ
- ほとんどがこの方法
- 入出力の整合性
- 入出力を網羅しようとすると死にます。なので小さめなやつでやりましょう
- システムテスト
シナリオテスト
- ペルソナを作ってやるとよい
- 23歳若手社員はこんな使い方をする (例えば地下鉄に乗って携帯でやる)
- クリティカルさによって優先度を決める
- 正常系と異常系に分けて、コストとの見合いから異常系をやっていく
システムテストで致命バグが出るのは、なかなかシビれる局面なので、テストを延期して開発に集中したほうが良いということを知っていると、遅延を少しでも抑えられそうです。
非機能要件のテスト
最後に、途中話題に挙がった非機能要件のテストです。とても出てきにくい要件なので、どうすると洗い出せるのか、そこでオススメされたのが 非機能要求グレード です。
- 主に可用性･性能･運用･移行性などをテスト
- 非機能要求グレードをもとに プロジェクトごとに必要不必要、基準値を作ってお客様にもっていき、洗い出すとよい
一方でセキュリティはお客様も開発側も将来の脅威を予測できないので、 IPA のチェックリストを埋めておくとよい とのことで、この11項目に対策してお客様に安心していただくというのはとても使いやすそうです!
最後に現在のトレンドとなっている CI 周りのツールやサイクルを紹介して、このコースは修了しました。
まとめ
テストや品質全般の概念について解説いただきました。
特に上流での非機能要求グレードを使った要求の洗い出し方、セキュリティの品質基準、初期テストのやり方など、明日からでもマネできそうなノウハウがあり、上流に携わるプロジェクトリーダーやマネージャにはとてもオススメです!
冒頭の ｢リリース判定基準はありますか?｣ をプロジェクトごとに考えて、答えられるようになるコースでした。
SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。