QAを学んだきっかけ
私がQAを学んだきっかけは、1年目に担当した改修案件で、受入テストと運用開始後に想定外のバグが多数発見されたことです。
入社してから2つ目の案件で、既存システム（ほぼAPI）で利用していたライブラリが廃止されるため、代替のライブラリに置き換える作業でした。
これまでそのシステムの保守を担当していた方から説明を受けたものの、
- 仕様書が存在しない
- 複数のシステムと連携するが、そのシステムについて聞いても抽象的な回答しか返ってこない。
- 初めてクライアントアプリを開発する
そんな状態だったため、全体像がつかめないまま開発は進み、
想定していないバグの発生や要望の追加が発生しました。 - セキュリティソフトの影響で、必要なexeがダウンロードできない
- Chromeだけではなく、FireFoxの対応もしてほしい
- 連携に必要な処理ができていなかった（Windows Registry）
そこで、後から何が悪かったのか振り返ってみたところ、
テストケースが不十分だったのでは? と考えたのがきっかけです
そもそもQAって?
QAとテストの違いをご存じの方は飛ばして大丈夫です。
QAという言葉を使っている以上、定義しておくことが重要と思い、載せています。
よく、QA(Quality Assurance)とテストはごっちゃにされがちですが、明確に違いがあります。
テストは、成果物に対して、その品質を検証・保証することを指します。
例えば、システムに対し、ある特定の操作をした際に、期待する結果になることを検証すること、です。
一方で、QAは成果物を作成するための開発工程を向上させよう、という取り組みを指します。
そのため、各工程の方針の検討（例, コードレビューは何を対象とするか、各テスト工程では何を目的とし、どう行うか）は、QAにあたります。
そのため、この後紹介するように、テストやQAを学ぶことは、テストケース作成だけでなく、
設計やチームの方針策定にも寄与します
※しかし、本記事では、QAとテスト両方をひとくくりにQAと表現します。
QAを学んでから変わったこと（メリット）
効率の高いテスト設計と実行ができる
効率の高いテスト設計には、必要なテストケースを正確に洗い出すこと、そして、各テストケースに優先度を割り振ることが重要です。
テスト技法を用いることで、仕様に対して十分なテストケースを洗い出すことができます。
境界値テスト、ディシジョンテーブル、状態遷移図、そういったものを対象の仕様に正しく適用し、
複雑な仕様でも、漏れなく重複なくテスト設計することができます。
しかし、100%漏れなくテスト設計できたとしても、それを全て通すことができるかはまた別の問題です。
私は、納期が近づいていても、テストを全て通さなきゃという思いがあり、苦しんだことがありました。
しかし、チーム全体で「今は〇〇を達成するために、優先度1のものを対応する」、という方針がある、
だから、今は優先度1のテストケースのみを通し、優先度2のうち、すぐに対応できるものは対応する。
そういう考え方ができると、「時間が足りない、どうしよう。」という迷いをなくし、「良いものを作りたい」と
納期のバランスをとることができました。
外部設計の質が上がる
テストケースの作成を学ぶことによって、常に外部設計書を「テストケースを（楽に）作成できるか?」という観点で見る習慣がつきます。
そうすると、これまでは説明だけで終わっていたところを、例を入れてみたり、
文章だけの部分を表にまとめたり、といった一工夫つける習慣ができます。
特に、ディシジョンテーブルや状態遷移図を外部設計の段階から積極的に導入することをお勧めします。
例えば、
- AがA1の場合～
- AがA2の場合～
- AがA3の場合～
とだけ書くよりは、ディシジョンテーブルも隣に添えてあると、認知負荷がかなり減ります。
また、状態遷移図については、
- AがA1になった場合はステータスを進行中にする
- BがB2になった場合はステータスを保留にする
- CがC1になった場合はステータスを完了にする
のような仕様を明確に示す場合に役に立ちます。
多くの場合、上記3つの仕様は設計書内にばらばらに散らばっているため探しづらく、
機能の重複や不要なステータスが入っていても、影響範囲が不確かな以上、
それを踏襲するしかない、という状況がよく発生すると思います。
実際、私も状態遷移図を作成することで、最初は4つあったステータスが2つになり、
ステータスを減らすことによって、関連する機能の処理も単純になった。経験があります。
最後に、外部設計を明瞭にすることで、不要な処理やステータス、操作を削減することができます。
これは、設計書の可読性向上、実装時の手戻り回避、に繋がるだけでなく、ユーザー自身も気づいていない
問題点を発見、改善案の提案に繋がることがあります。
JSTQBで学べること
私は、JSTQBのFoundationとTest Analystの2つの資格を取りました。
Foundationは、テストやQAの基礎を学ぶことができ、漠然とテストを勉強してみたいんだけど、何から勉強したらよいかわからない、
という方にはお勧めです。
一方、Test Analystは、テスト設計がメインなものの、テスト計画や各テスト工程の役割、
非機能テストの基礎等、もう少し踏み込んだ内容になります。
より理論を身に着けたい場合やQA知識の証明をしたい方にはお勧めで、
基礎がしっかりと身につくため、現場でわからないことがあった際に、AIや人に聞いた時の理解度が大きく異なるように感じました。
但し、試験はFondationよりも格段に難しくなっており、さらに過去問の数も少なくなっているため、難易度は上がっています。
そのため、もうちょっとテスト設計勉強したいな、という方はシラバスだけを眺めたり、本や試験のサンプル問題を解くのもいいかもしれません。
まとめ
- 効率の高いテストを実行できる
- 拡張性・保守性の高い仕様の作成
- 機能の追加、変更、廃止が容易にできる
- 開発の引継ぎが容易である（属人化が起こっていない）
- JSTQBのFoundationは基礎を学ぶのにおすすめ
- さらに体系的に学びたい方はJSTQBのTest Analystがおすすめ
- 特定の部分のみを学びたい場合は別資料や本で勉強することがおすすめ
コメント