1. はじめに
ソフトウェアに機能追加をしていると、時折デグレーション（以下デグレ）が発生します。
デグレが発生すると、
- 修正コストがかかる
- ビジネス上のリスクとなる
- 開発者のモチベーションが低下する
と、いいことなしで今後の開発に重大な影響を及ぼすことがあります。
ただ、デグレが起きないようにテストしようとすると、どうしてもテストの範囲が膨大になります。テストの範囲が膨大になると当然テスト工程に時間がかかり、工数を取られることになります。
そのため、テストを効率的に行う必要があると考え、これまでの自分の経験からどのように効率的なテストを行なってきたか、をまとめて見ました。
2. 効果的なテストとは？
個人的に思う効率的なテストとは、
- テストケースが少ない
- 多くの不具合を出す
- 不具合がある程度ないことを証明できる
と思っています。
テストケースが少ない
これはただ単にテストを減らすのではなく、重要な部分のみをテストすべき、という考えになります。
重要な部分とは
- ユーザーに大きな影響がある
- 基本機能が動かない（メッセージが送れない、ログインできない、など）
- 誤った金額が請求される
- サービスが停止する
- 大量アクセスによるシステム停止（コンサート、限定販売、など）
- データが削除され、復旧できない
重要で無い部分とは
- 複雑なパターンでのみ発生する
- メッセージが送れない場合、特定の端末で特定の情報を持つユーザーで特定の時間で...など条件がある
- 不具合発生したユーザー数が少ない（ログなどから判断。レアケースなもの）
- 不具合が起きてもなんとかなる部分
- エラーが表示されても、再度実行すると動く
- 他の機能で代替できる
多くの不具合を出す
これはそのままで、不具合を見つけやすい質の高いテストケースである、と言うことです。
例えると、
- 開発者が気づいていない点（影響範囲外と思ったが、実は含まれていたもの）
- DBにカラム追加が追加された →対象データのダウンロード機能周りに修正漏れはないか？
- 新機能が追加された →対象機能を誰が使うのか権限管理の機能に修正漏れはないか？
- 開発者が影響範囲外です、と言ったところ →少しでも気になる様であればテストする（開発者にバレないようこっそりと）
- 過去に大きな障害が出た点（1度2度あれば3度目がある）
- 料金計算に不具合が多い →プランごとの料金や特別な計算あたりを網羅的にテストする
- 大量アクセスで遅延が発生した →性能試験を実施
また、こちらは事前に開発者へ確認しておくべきこと、でもあります。そのため、テスト設計の段階でもいいので、
「ここのカラムを追加した場合、ここも影響を受けそうだけど...」
と、相談しておきましょう。
不具合がある程度ないことを証明できる
絶対に不具合がないことは証明できません。なので、「ある程度ないことが言えればいいかな」、と思っています。もしくは、リリース判定できるぐらいの材料となっていること、と言い換えてもいいかもしれません。
こちらは前述の2つ（重要なものだけテスト、不具合がありそうなものをテスト...）を行なっていれば、ある程度証明できます。そこにプラスして、関係者が気になっている点を含める感じになります。
- お客様から問い合わせ等で来たものに対してテストできているか？
- ステークホルダーの気になっているところをテストできているか？
- 開発者、PM、プロダクトオーナー、..など
3. 効率的なテストには何が必要？
効率的なテストの重要な要素としてテスト自動化があると思っています。手動でテストすることも大事ですが、全てのテストケースを期間内に実施することは、ソフトウェアの規模が大きくなるにつれて難しくなります。
そのため、自動でテストできるところは自動テストで実施する方がいいと考えています。もしくはテスト観点表など、テストケースを作成するのに支えとなるものがあるといいと思います。
弊社では共通観点（どの機能でも割とテストしておいた方がいいもの）と、機能特性ごとの観点を作成し運用しています。（最近取り入れたばかりのため、効果については計測中。）
4. 実際にどうテストしている？
では実際にどのようなテストを行なっているか、説明すると以下のような感じとなります。
- ちょっとした変更でも最低限の基本機能は確認する
- メッセージが送れるか、タグが設定できるか...など
- 1シナリオだけ確認。複雑なパターンはテストしない
- 重要な機能or修正規模が大きいものはQAがテストを作成、実施する
- 別の担当者の目線を入れる
- 何度も同じテストは不要。各環境ごとの観点を見ればOK
- 開発環境 →作ったものが正しいか確認する
- 検証環境 →作ったものが他のリリースする機能に影響がないか確認する
- 本番環境 →作ったものがリリースされているか軽く確認
- (修正規模が小さければ、開発環境のテストを飛ばじて検証環境で見てもいい)
- 無闇に組み合わせテスト技法を使わない
- 組み合わせ技法を使うと、網羅性は上がるが意味ある組み合わせは減ってくる。
- どうしても組み合わせが大きくなりすぎる時だけ使うようにする
- （取り組み中だが）できるだけ自動テストを増やし、手動テスト以外にも対応できるようにする
- 重要な基本機能は、ほぼここでテストできるように作成中
- テストケース作成中に抜け漏れがないか、テスト観点表を見てもらう
- （まずはQAチームのみで利用し、全体に展開できるか実証中）
5. まとめ
今回効率的なテストとは何か、と思っていることをまとめてみました。必ずしも正解はないと思いますが、自分がどんな観点でテストを行なっているのか、を一度振り返って見るのはいいかもしれません。
Discussion