テストというと、当然、新規開発案件の工程のひとつである。
特にQAというと、リリース間際にテスト対象を受け入れ、機能品質保証をする目的が一般的だろう。
では、開発の最終段階で呼ばれ、バグを出し切り、改修確認を済ませ、万事OKの押印をするだけが、QAの役割なのだろうか？
なんとなく違うと思いはじめている、今日このごろ。
私は現在QAをやっている者ではないが、とあるECサイトのデータ分析や、販促まわりの運用に従事している。
中には細々と、新機能の要件定義やキャンペーン設計などを含めた、制作ディレクションを担当することがある。
そこで感じることは、定義した機能をはるかに超える量の、仕様バグという名の「考慮漏れ」だ。
以前はゲームやマッチングサイトなど、いくつかのリリース案件に際して、QAを担当したこともあった。
一般的な要件とその機能には知見があり、それなりに、自信もあった。
しかし実際、自分で組み立てた要件が本番障害という形で露呈することになるとは、夢にも思わなかった。
ここで具体的な障害内容を書くわけにはいかないが、自分が普段使用するサービスのいちユーザー基準で振り返ってみると、実にバカバカしく、恥ずかしく申し訳ない気持ちになる。
自分の手でやって、反響を感じなきゃわからないことが、この世の中には多くあるのだ。
このブログを読んでいる人の大多数は、テストエンジニアリングを極めようと思っている人だと思う。
が、しかし。
今一度、サービス基準の一般解に立ち戻ってみるのも良いのではないかと、強くオススメしたい。
誰のためのサービスなのか。
機能を叩くだけが能じゃない。
ディレクターに鬱陶しがられても、個別の一般解を述べたい。
そんなQA像があっても良いと思う。
ついこの前も、とあるイベントでエンドユーザー様から「わかりにくさ」について、強くお叱りを受けたばかり。
あっけにとられて呆然と立ち尽くす私を尻目に、懸命に謝罪の言葉を投げかけていたCSさんの姿には、頭が下がるばかりだった。
それ以来、運用フェーズにおいても、本来の意味でQAの役割を意識するようになった。
マニアックなスキルに特化するばかりでなく、地道な運用の中で、一般人が求めるサービスへ導ける人に、少しずつなりたいと思いはじめた。
Tweet