ダイの大冒険という漫画が大好きなbun913です。
皆さんはソフトウェアテストについてどのように学習していますか?
私は個々のテスト技法である「同値分割」や「境界値分析」の手法・やり方などは知っていたものの、テスト全体のプロセスなどについて体系的に学習ができていませんでした。
そこでJSTQB 認定テスト技術者資格というテストの存在を知り、「受験に有無に関わらず、体系的に勉強してみよう」と思い、以下書籍を購入してみました。
結論から言えば、本自体がかなり読みやすく理解度チェックとして章末問題もあるので、資格試験の受験をしない方にもおすすめです!
私の付箋ポイント
本の内容をそのまま書き写すわけにもいかないため、私が個人的に重要・面白いと思ったポイントを少し紹介します。
- テストレベルと目的
- コンポーネント(単体テスト)
- 統合テスト(結合テスト)
- システムテスト
- 受け入れテスト
- QAとQC
- 品質保証のことを一般的にQAと呼ぶ
- 品質が適切なレベルに到達していることを示すための活動
- QCは品質コントロールと呼ばれる
- 品質が適切なレベルに到達するように、テストを含む適切な活動を行うこと
- テストの7原則(感想: 言い回しが面白いものが結構ある)
- 参考:
- テストは欠陥があることは示せるが、欠陥がないことは示せない
- 全数テストは不可能
- 早期テストで時間とコストを節約
- 感想
- てっきりウォーターフォール的な流れを意識している認定試験だと誤認していました
- そのため、シフトレフトの考え方が取り入れられていることに驚きました
- 欠陥の偏在
- 故障の大部分は特定のモジュールに集中するというあれ
- パレートの法則的なやつかと思った
- 殺虫剤のパラドックスにご用心
- 同じ殺虫剤を使い続けると相手にも耐性ができて聞きにくくなる的なやつ
- 境界値分析は条件分岐の欠陥を見つけやすいが、例えば入力値そのもののバリデーション(Nullが入ってくるとか)はできていなかったり
- 感想
- これはテストの観点を考える上でも常に意識しないといけない
- 全数テストは不可能なので、関数やクラスのロジックに対して効果的なテストを行う必要がある
- 単一の条件に対しては境界値分析は有用だけど、複合された条件の際にはデシジョンテーブルを作るとかの基本は守ろう
- 複合的な条件が出るとコードも複雑になってきている
- 経験的にそのようなコードがビジネス上に重要な意味を持っていたりする
- 金額計算とか
- テストは状況次第
- 「バグゼロ」の落とし穴
- ソフトウェアライフサイクル全体を通してのテスト
- 設計書はコードのレビューも立派な静的テスト
- テストの種類や目的などが他にも体系的に書かれている
- コンポーネントテストやコンポーネント統合テストはCIにより自動化されることも多い
- 感想
- 体感的にもここまでは自動化した方が良いと思っていたので合致していてよかった
- その他、「リグレッションテスト」こそ早めに自動化するべきというのもすごく納得
- など
といった項目に付箋を貼りながら読んでいました。
その他、例えば「境界値分析の実践」や「カバレッジの種類とそれぞれの算出」などの個々のテスト技法を学べるのも非常によかったです。
最後に
本書の感想をさらっと述べましたが、「アジャイル開発の際の注意事項」や考え方などの書いていて非常によかったです。
「テストの自動化」やCIの実装はしたことがあるものの、肝心の「テストの書き方」や「テスト技法」「テスト戦略の立て方」などは独学の人も結構多いと思います(勝手な感想です)。
そういった方にも「これまでの経験ではこう考えてきたけど、この教科書でも同じようなことが書いている!」といった体験もできると思いますので、ぜひご検討ください。
なお、私はせっかくなのでJSTQBのFoundationレベルの試験を受験してみようと思います。
以上、読んでいただきありがとうございました。