読者です 読者をやめる 読者になる 読者になる

情報系の凡才日記

エンジニアりんぐの試行錯誤とか参加したイベントとかについて書いていこうとおもいます。

「知識ゼロから学ぶソフトウェアテスト」を読んで

「知識ゼロから学ぶソフトウェアテスト」を読んだので、まとめ兼書評的なものを書いてみる。

この本を読んだ目的

いま自分が所属する開発チームには以下のような課題がある。

  • 手動テストはあるが、そのテスト項目の決め方にガイドラインのようなものがない。(何をテストするのかが決める個人の裁量によって決まっている)

  • 手動テストなので人によってテストの質が違う。

  • 自動化テストなどがまったくない。

  • APIに至っては、レスポンスの目視チェックとクライアント側を開発するときに作りながらチェック。

このような状況なので、僕のようなプロダクトの仕様を把握しきっていない新人にとってはバグを生み出しやすく、またテストも不十分な状態でリリースされてしまう問題がある。

まずは、自分がテストによってどうやって品質を担保するのかをちゃんと知ろうと思い以下ブログを参考に読んだ。

新卒ソフトウェアエンジニアのための技術書100冊

内容について

前半

前半は、ホワイトボックステストブラックボックステスト、同値分析、境界値分析、ディシジョンテーブルなど既知の内容だったので特に学びにはならなかった。 また、独自に「探索的テスト」なるものを提唱していたが、 テストスキルの高い人が、プロダクトを触りながらテストを行うというもので、そのスキルの高い人がいない現状なのであまり興味を惹かれなかった。

後半 -非機能要求テスト-

まず非機能要求で担保するべきなのは、

  • パフォーマンス
  • 機密性
  • 信頼性

の3つだそうだ。

パフォーマンスのテスト

パフォーマンステストで見つかるバグは最悪(最悪設計のし直しが発生する)なため、なるべく最初の方にやることを推奨される。

このテストを行う上で重要なのは、まずはパフォーマンスの定義を明確にすることで、例えば「1分以内に20MBのデータを処理できる」など。ただし、「1分で20MB処理できるけど、30秒だと1MBしか処理できない」といったケースも考えられるので、様々な状態やケースでテストするべきであるとのこと。

また、パフォーマンステストは以下の手順で行うと良いらしい。

1 設計が間違っていないかの確認

データベーステストなどの場合、DBとデータが用意できた時点でそこにアクセスするプロトタイプを作り、処理能力が要求に合致しているかをテスト。

2 パフォーマンスベンチマーク

実際に開発されたソフトウェアがパフォーマンステストできる状態になったら即要求に照らし合わせてテスト。

3 パフォーマンス回帰テスト

開発していて、変更などがあった段階で、変更によってパフォーマンス低下が発生しないようにすぐテストする。

4 最終確認

5 本番のデータなどになるべく近い環境でテスト

機密性のテスト

セキュリティのテストのこと。 攻撃手法はどんどん増えていくのでいたちごっこ。 ツールとか使うといいかもね、というお話。

信頼性のテスト

信頼性とは、「ある条件下で安定して要求された機能を果たす能力」らしい。その指標としてMTBFというものが使われる。 これは、平均故障時間と呼ばれるものらしく、どのくらいの時間ソフトウェアを使用するとバグやハングアップ、リブートなどが発生するかの平均時間。

Web系の会社でこういうのちゃんと測ってリリースしてるところってあるのだろうか・・・

今後自分がどうしていくか

テストの質がばらついているのと、何をテストするの?というのが曖昧なので、まずはテストのガイドラインなんかを作ってチームに浸透させるのが当面な目標なのかな・・・

ガイドラインについて

ガイドラインとしては以下の内容がちゃんと伝わればいいのだろうか。。。

  • なんでテストしなくちゃいけないのか
  • 何をテストしなくちゃいけないのか
    • 機能テスト
      • 正常ケース
      • 異常ケース、例外
    • 非機能テスト
      • セキュリティ
      • パフォーマンス
      • 信頼性

導入に関する懸念点

  • ガイドラインを明確にしたうえで、どうやってチームに定着させていくか。
  • あまり複雑にしすぎると、障壁が高い。
  • 決めるのはいいが、全部一気にやらせるより一部分だけやらせていくのはどうか。

余談

ブログ書いてる途中で結構面倒くさくなった。