エンジニア経験と今のQAエンジニア経験を合わせれば、およそ20年近くになる。エンジニア経験の方が割合は多いのだけど、まず開発の方は全く出来てない。最初の経歴はC言語からスタートでした。ベーシックな知識は身についたもののどうやってコーディングすれば仕様に沿えるものが出来上がるのか、イメージが全然出来ない上にコーディング能力は向上しないまま。そこからオブジェクト指向言語のC#だったり、厳密には違うのかもしれないがC++だったり開発エンジニアとして関わることはあったものの、どの現場に行っても戦力になれないまま短期間で現場退場を繰り返しです。時にはあまりの自分の仕事の出来なさに鬱っぽくなることもありました。
経歴年数だけはほどほどにあったけど、自分の中にプログラマーとして芯になるものは全く出来上がってなかったのである...プログラミング的な発想力とか発想できたものをコードとして実現する能力が足りてなかった。仕様書を読み取る能力もなかったと思います。
そして現在のQAエンジニアという職業。エンジニアとついてるけど、コーディングは一切ないのでエンジニアと自称していいのかわからない。単にQAと言った方がいいかも。まぁ職業名はこの際あんまり関係ないからあまり触れずに。
QAとして本格的に業務をしたのは、今の現場から。それまでプログラマ時代もテストフェーズに関わったことはあったけど、品質保証という立場でテストに関わることは最初だったので、最初は戸惑った。実際にQAとしてやってることはブラックボックスでのシステムテストとシナリオテスト。おそらく会社や組織によって業務内容は異なってくるのかな？と思いますけど、今の現場は基本テストのみです。
このQAという仕事は、プログラマに比べたらまだ現場の役に立てているようです。なぜなら3年くらい経ちますが、いまだに「もう結構なので退場してください」という戦力外通告を受けてないからです。ただ、自分自身の中では「QAとはこういうこと」という指針になるものが特にないのが気になっています。テスト手法とかもあまり詳しくないし（ブラックボックステストの代表的なテスト手法である、境界値テストとか同値分割テストくらいしか普段のテスト設計に組み込んでない）。
何が言いたいか、というと現場の作法に慣れすぎていて普遍的なQA的能力は在籍年数の割に上がっていないんじゃないか、ということ。プログラミングであれば、現場ごとにコーディングルールなどのローカルルールはあるだろうけど、基本的にコーディングすること自体はやることは一緒なわけで。プログラムと同様に、QAにおいてもローカルルールはあるけど、基本的なQA指針というか「QAの基本確認点」のようなものがあるはず。
書いていて気づいたけど、基本確認点っていわゆるテスト７原則なのかな。
- 「テストは欠陥があることしか示せない」
- 「全数テストは不可能」
- 「初期テストが重要」
- 「欠陥の偏在」
- 「殺虫剤のパラドックス」
- 「テストは条件次第」
- 「バグゼロ」の落とし穴」
うーん...ちょっと違う。この原則自体は大事で頭の中になきゃダメだけど。こういうものではなく、WEBテストであれば、こういうものを確認するのが鉄則、というようなもの。たとえテストをする環境が変わったとしても、揺るぎないものが自分の中に欲しい。どこに行ったって必ず確認する項目って大きく変わらないと思うので、そういう部分をしっかりとしておきたい。WEBっていっても幅広いからなんとも言えないんですけども...
同じ環境でずっと仕事するならその環境に自身が最適化されていれば、良いと思う。でも自分のようにSESでいろんな環境に身を寄せて（この表現でいいのか？）仕事をするなら「これはQAとして基本」みたいな当たり前が欲しい。情けないな。しかし。
当たり前がある状態ってどういうことかというと、たとえ空っぽのQAチームに放り込まれたとしてもそこから状態を0から1以上に構築できるような人材。
