この数ヶ月、ずっとテストばかりしている気がします。
開発中のシステムの動作に問題が無いことを確認する為の不具合テスト(バグ潰し)です。

当たり前ですが、システムは製造工程を経て、はい、おしまい。とはなりません。
人が作るものですから何かしら不具合や問題が潜んでいることもあります。それを見つけて修正する為のテスト工程を乗り越え、やっと初めてユーザーに提供できるシステムに近付いていくわけです。

ところで「システムが完成した」という判断はなにを根拠にしているのでしょうか？
全てのテストが問題無く完了したなら終了根拠になりそうですが、結局、テスト(テストの設計～実施)も人がやっているので人為的ミスは否定できません。
それを払拭する為に要求仕様や設計動作を満たしているか等の、開発の正しさを「品質」という観点から確認する品質評価工程が必要になります。
冒頭のテストにはこの「品質評価」の工程も含んでいます。

システム開発にはいくつかの段階がありますが、その段階ごとに品質を確保して完成の根拠にします。
段階としては大まかに要件定義、設計、製造、テスト、リリース等があります。

要件定義では、顧客とのコミュニケーションが欠かせません。要件を正確かつ明確にして共有することは、顧客の期待に応える製品を開発する為に不可欠です。
余談ですが、「顧客が本当に必要だったもの」でググってみると為になる情報が見つかるかも知れません。

設計では適切なアーキテクチャとデザインが重要です。システムが効率的に動作し、拡張性を持つために、慎重かつ柔軟な思慮が求められます。設計には顧客も把握できず要件としても定義が漏れてしまう事柄(ステルス要件)が往々にして存在します。
システムエンジニアとして、その事柄を顧客に問い掛け、また提案出来るか。それは顧客にとって、本当に必要なエンジニアに求める能力のひとつかと思います。

製造においては、メンバー同士でコードレビューをしたり、ペアプログラミングと言って2人のプログラマーが1台のPCを操作してプログラミングをすることで開発の品質を担保します。

テストもひとつではなく、ユニットテスト・結合テスト・システムテストなど段階を経てシステムの各機能が期待通りに動作するかを確認します。
部品ごと・部品を組み合わせた部分ごと・ひとつのシステム全体で一連の操作～動作を想定した綿密なテストを行うことで品質を担保します。

リリースした後もシステムの品質をモニタリングし、顧客からのフィードバックも収集しながら品質向上と改善を目指す必要があります。顧客の声を受けて製品やサービスを改善することで、持続的な品質向上を実現させます。

ちなみにテストにかける期間ですが製造と大体同じか、それ以上になる場合が多々あります。
つまり製造期間が長いと、テスト期間も長くなり、バリバリにプログラミングがしたい！という人には辛い期間にもなるわけです。
まあ、テスト期間が長くなると言っても、バグ修正や設計の振り返りでプログラミングに触れる機会もありますし、その流れを経験することによって将来役立つ知識や業務のコツも発見できるので、地道に少しずつ努力することが肝要かと思いますし、「品質」の追求は、必ず新しい技術力の習得の礎になると思います。

あさ