テスターは開発初期から関わるべき！
グエン・ティ・ タム実際のプロジェクト経験から見る考察
こんにちは！メディアフュージョンでテスターをしているタムです。Webサイトやアプリ、APIのテスト、SQLなどを担当しています。最近は自動テストに興味を持ち、JavaやPostman、Seleniumなどを勉強しています。これからこのブログで日々の学びを発信していきたいと思います。よろしくお願いします！
Ⅰ. はじめに
ソフトウェア開発プロジェクトには、さまざまな役割が連携して関わります。たとえば、開発者は機能を実装し、UI/UXデザイナーはユーザー体験を設計し、プロジェクトマネージャーはスケジュールや進捗を管理します。しかし、その中でソフトウェアテスト担当者は、よく「最後に呼ばれる」ことがあります。「テストは、開発がほとんど終わってから行うもの」と思う人も多いです。
でも、私が今まで関わったプロジェクトでは、テスターが早くからチームに参加すると、開発がスムーズに進み、バグが減り、ソフトの品質も向上すると強く感じています。
Ⅱ. 開発の各段階におけるソフトウェアテストの役割
実際にプロダクト開発のプロジェクトに関わってみて、私は強く感じました。テスターは開発プロセスの「最後」だけでなく、最初から関わることでチームにとってとても大事な役割をはたすことができます。これは、私がチームといっしょに仕事をしたとき、テスターがそれぞれのステップでどう関わったかの例です。
まず、要件定義の段階（Requirement Analysis）では、テスターもビジネスアナリスト、プロジェクトマネージャー、開発者と一緒に話し合いに参加するべきだと思います。テスターはただ要件を理解するだけでなく、「もし〜なら？」という質問をよくします。 たとえば、
- ユーザーが間違った形式で入力したら、システムはどうしますか？
- ネットワークが使えないとき、この機能はどう動きますか？
- 入力できる値の上限・下限はありますか？
このような質問をすることで、チームはドキュメントに書いていないケースや、大事だけど見のがしやすいポイントに気づくことができます。結果として、要件のわかりやすさと実現可能性が高まり、後の設計や実装がスムーズになります。
設計の段階（Design）では、テスターはリスクを見つけて、どこをしっかりテストするべきかを考えることができます（リスクベーステスト）。また、テスターはユーザーの目線で設計をチェックすることもできます。開発者やUIデザイナーは技術や見た目を中心に考えることが多いですが、テスターは「使いやすいか？」「分かりやすいか？」など、ユーザーの立場から気づくことができます。
テストとリリースの段階では、テスターにとって一番大切な階段ですが、もし最初から参加すれば、システム全体の流れを理解できるのでテストの正確が上がります。事前に自動テストやテストデータの準備ができていて、リグレッションテストも効率よく実施できるため、バグ修正のコスト・時間・労力を大きく減らすことができます。
Ⅲ. テスターが「後から参加」するとどうなるか？
私が見てきたプロジェクトの中には、テスターが開発の後に呼ばれるケースがありました。そのような場合、いくつかの問題が発生しやすいです。
まず、要件がよく分からないことです。テスターが最初から参加していないと、テストはドキュメントだけを見て実行します。でも、ドキュメントは多くの場合、正しくない。その結果、テストケースが足りなかったり、例外のパターンをチェックできなかったり、ユーザーの本当の使い方に合わないテストになることがあります。
次に、開発の最終段階では非常に忙しくなります。テストを最後にすると、テスターは時間をあまり割り当てられなく、ストレスを感じます。開発者はバグ修正に追われ、プロジェクトマネージャーはリリースが予定通りに完了するかを心配しています。この状況は製品の品質にも悪影響を与えます。
また、テストを最適に行うのもむずかしくなります。時間がないため、良いテストケースを書いたり、自動テストを作成したり、テストデータやテスト環境を整えるのが困難になります。その結果、テストは「簡単なチェック」だけになり、本当のバグは見つけにくくなります。
Ⅳ. なぜテスターは開発の一部として早くから参加すべきか？
私の経験から、テスターが開発の初めからチームに入ると、多くのメリットがあります。
まず、「バグを見つける」から「バグを防ぐ」への意識の変化があります。バグが出てから直すより、出ないようにする方が大切です。テスターは、要件をしっかり確認して誤解を防いだり、設計のリスクを見つけたり、ユーザーが使いやすくなるようなアドバイスを出すことで、問題が出る前に気づくことができます。
また、テスターはチームといっしょに製品を作る仲間です。受け入れ条件の作成をサポートしたり、テストカバレッジについてアドバイスしたり、テスト自動化パイプラインの構築にも関わることで、より積極的に貢献できます。
さらに、テスターが初めからプロジェクトに入っていると、スプリントがスムーズになり、リリースの締め切りも守りやすくなります。品質も安定し、バグが少なくなります。結果として、顧客からの信頼も高まり、チーム全体のプレッシャーも軽減されます。
Ⅴ. ソフトウェアテストの種類と実際の例
製品を開発するとき、ソフトウェアテストにはいろいろな分け方があります。私はいつも3つのグループに分けています。
- テストレベルによる分類
- ユニットテスト（開発者）：calculateTotal() 関数が、カートが空のときに正しく動くかどうか
- 結合テスト（開発者／テスター）：決済APIと注文システムが正しくデータをやり取りするかどうか
- システムテスト（テスター）：ユーザーが会員登録して、確認メールを受け取れるかどうか
- 受け入れテスト（顧客／PM／テスター）：登録フォームに電話番号入力が必須になっているかどうか
- テストアプローチによる分類
- Black-box（テスター）：メールアドレスが正しくない → エラー表示が出るか確認
- White-box（開発者、QA）：if-else のすべてのパターンをテストする
- Gray-box（QA、開発者、テスター）：APIの戻り値の構造を知っていて、正しく返ってくるかチェックする
- 実行方法による分類（Manual ・ Automation）
- 手動テスト：ブラウザを変えて、決済画面の表示をチェックする（Excel）
- 自動テスト：ログイン・ログアウト、入力フォームのバリデーションを毎回のビルド後にチェックする（Selenium、Cypressなど）
私のチームでは、重要でよく使う機能は自動化して、リグレッションテストの時間を減らしています。
Ⅵ. 結論
今回のブログでは、ソフトウェア開発の各フェーズにおけるテスターの役割と、なぜ早い段階から関わることが大切かについて紹介しました。テスターが早くから参加することで、チーム全体の品質向上につながると、私は実感しています。
しかし、開発チームと本当の意味で一緒にものづくりをするためには、テスターもAPIテストやデータベースの知識とスキルを身につける必要があります。
次回のブログでは、実際の業務で私が行っている「APIテスト × SQLによるデータ検証」についてご紹介します。ぜひ次回のブログも楽しみにしていてください！
参考資料
- JSTQB公式サイト（Japan Software Testing Qualifications Board）https://jstqb.jp/
