この記事について
新卒で配属されたQA部門に2年8ヶ月いてみて感じた心の叫びを
垂れ流す記事になっています
自分はあまり文章が得意ではないので稚拙な文章になりますが
どうぞよろしくお願いします
はじめに
どこにでもいる若造の戯言と思って読んでいただけるうれしいです
自分について
・高卒で某電気メーカに入社し、一年間集団研修を受ける
・とある事業部のQA部門に配属されそのままソフトウェアテストにドはまり
QA部門について
・総勢90名以上の大人数
・製品の機能ごとにチーム割されていて十数チームほど存在（チームごとの人員はばらつきが多くある）
自分は2チームを渡り歩いてきたので最初にいたチームをAチーム
今在籍しているチームをBチームとしています
Aチーム
・人が多くいる(10人以上)
・担当機能は3つ存在
・担当機能は最近市場でよく使われることから新規要件の追加や市場からのクレームが多く来る
Bチーム
・Aチームに比べると人は少ない(7人、最近人が良く減る)
・担当機能は4機能+QA以外の認証取得業務等が多数存在
・担当機能はほとんど成熟されているが使い手も多く思いがけないバグを孕んでいることが多い
このような状態でとあるお触れが出ます
テスト技法を統一化し、チェックリスト生成までのプロセスを固定化します
ん？？？？？
自分は思いました
**こんなたった2チームだけでも性質の違うのにほかの十数チームのテスト設計を統一できるのか？**と…
各チームについて詳しく書いてみます
Aチームの場合
人員としては多いもののその機能についての知識が少ない人が多かったです
40代～50代が大多数でソフト系の知識を持つ人は1~2人程度しかいませんでした
担当機能の特性としてRFCやIEEEの規格を頭に入れておかないといけないので
毎週のように勉強会が開かれていましたが、なかなか身につかない状態でした
しかし業務はプロダクトが一度に5~8個常に走っている状態で怒涛のテストが続きます
人員の技術レベルに対して、業務量が見合っていない地獄でした
テストの毛色としては複数の設定値を組み合わせる評価が多く
網羅度が重要視されチェックリストが無限に生産されていました
故に毎回にテスト対象が非常に広く過剰評価では？と思うことも多々ありました
Bチームの場合
人員7名としましたが認証業務などのQA以外の業務に人員が割かれているため
担当機能を評価していたのは4名でした
うち自分を除く3人が担当機能の管理業務をしており、リーダ兼評価者という体制でした
ですがソフトウェアの知識や担当機能に対する知識は非常に豊富でまさに少数精鋭という状態です
前述のとおりプロダクトは一度に5~8個常に走っている状態なので常に人手不足状態
それを解消するためにテスト対象を大幅に減らして必要最低限の評価を行っていました
テストの毛色はAPIテストが多く他チームの機能やアプリとのマッチングが主でした
また、追加要件に対し、探索テストを実施したりとテスト項目の選定にも多くの知識を必要としました
まとめると
| テストの主な種類 | 実施するとき | |
|---|---|---|
| Aチーム | 網羅的な組み合わせテスト | チェックリストにあるものをひたすら |
| Bチーム | 組み合わせテスト、状態遷移テスト、探索的テスト | チェックリストから項目を選定して評価 |
これだけ違うのに
テスト技法を統一化し、チェックリスト生成までのプロセスを固定化します
こんなことできるか！！！と思いました
これから起こる弊害
テスト対象の性質に合わないテストはもちろん
チェックリストの質の低下(カバレッジの低下)
↓
テスト対象のバグが取り除けなくなる
↓
製品の品質の低下
↓
事業の衰退
容易に想像できますね
テスト設計が適切に行われなくなるのでチェックリストの質が大きく落ちるわけです
これから
もちろん自分を含むBチームは猛反対しています
もともと
テスト技法を統一化し、チェックリスト生成までのプロセスを固定化します
その目的は、チェックリストの品質の統一とテスト設計の標準化にあるのですが…
もっと別の方式がいいかなと思いますね
例えば
単純にテスト設計の技術力を高めたいのであれば
・テスト設計の勉強会をする
テスト設計の標準を作りたいのであれば
・ガイダンスや虎の巻程度の目安にするものを作成する
などなど
以上、最近感じた
複数のQAチームのテスト設計技法をまとめて統一化しないでほしいという心の叫びでした