底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

【ソフトウェアテスト】全部はテストできない問題【QA】

QAという立場になってしばらく経つ。いわゆるソフトウェアテストの検証専門の仕事だ。開発職から離れてテストエンジニアとして業務をしてから本当に思うのだが、時間が限られている中では当然テストできる範囲というのも限られる。一定の期間で優先度や重大度を見極めてまず優先的に消化するテストを行い、また優先度や重大度を下げたものを消化する。そして、テストが終わればそれら結果を判定してリリースに持っていくかどうかを決める。

 

この「できるテストは限られている」という根本は崩せないのだが、場合によっては優先度や重要度を度外視してテストを増やさないと気が済まないことがある。それは理論的というよりも心理的な要因でテストケースを増やしたくなる。どういう時か?というと、自分が関わった過去のQAのプロジェクトで残存バグが見つかった場合だ。過去のプロジェクトで「対象外」としていた箇所(もしくは「対象」としていた箇所)からの残存バグが見つかった場合、「見過ごしていた」ことになり、その経験から「次のプロジェクトでは見過ごさないようにしよう」という心理が働き、テスト対象を広げてテストケースを増やすことになる。

 

業務仕様が複雑かつプロダクト対象がWEBアプリ、API、Mobileなど多岐にわたる場合そもそもテストケースは膨らみがちだが、なんにせよ時間が有限で見積もり段階で工数を出しているので、テストケース設計段階であれもこれもとテストケースを追加していては、期日に間に合わない。期日に間に合わないとどうなるか?

 

QA完了予定期日に間に合わない

リリースの遅れ

(開発自体に問題なかった場合)「QAは何やってんだ」

QAチーム自体の評価下落

 

このようにQAチーム自体の評価下落につながることになり、よろしくない。特に開発をしているわけでもなく、ビジネス要件を決めているわけでもないQAは、期日内にきちんとした評価をどれだけ出せるか、パフォーマンスが見定められてるので、根拠もなしに「気になるのでテストケースが増えちゃいました」で期日が延びるのはチーム自体の存続に関わる。

 

見積もった工数を提出した段階(要件がある程度まとまっている段階で工数を出すと思う)と、実際にテストケース設計するときに見積もり段階ではきちんと見えてこなかった確認観点が出てきて工数が膨れ上がることはややあるため、そのあたりはPM(プロジェクトの管理者)との相談にはなると思うが、相談もなしにどんどんケースだけが膨れ上がるのは良くない。PMは出された工数の範囲で仕事が終わるだろうと当然思っているので。

 

逆に、PMや開発側などから「ここもテストしてください」などと要求が追加されることもある。その場合は当然追加工数に加えて良いと思う。

 

※なんとなく書いてみたエントリーだったが、タイトルと内容が一致しているか?