こんにちわ。QAマネージャーの@sakaimoです。弊社では新卒エンジニアを対象にして各種社内レクチャーを実施しています。GitとかHTML/CSSとかオブジェクト指向だとかTDDとかペアプロやるぞとかアプリ開発したりします。毎年入ってくるメンバーに合わせて少しずつ内容をカスタマイズしています。
QAレクチャー
その枠の中に「QAレクチャー」というコーナーがあります。弊社くらいの規模のWebの会社でQA(品質保証とかテストするチーム)が、開発チームとは別に存在する事自体が珍しいのかもしれませんが、そゆチームが存在しています。
今年は3人のエンジニア(自己紹介はこちら)が入社しましたが、これからエンジニアとして活躍する3人に下記をゴールとしたレクチャーを行いました。
見返してみたらパワポが150枚。レクチャー時間は約4時間。うん。みんな頑張った。
座学の内容としては
...などの話をしました。体系立てられた何かというよりも、ガイアックスでエンジニアをやっていく上で必要だなと(私が)思ったことをピックアップして伝えるという形にしました。
座学だけだとつまらないので、ワークとして手を動かしてみるアクティビティも入れました。
ワーク：エンジニアクエスト
私が(自分のRailsの練習のために)作ったバグだらけの「イベント掲示板」をテストしてみましょう、というワーク。これはドラクエ仕立てになっておりまして、バグを見つけると魔王(?)のHPが減るので、いっぱいバグ見つけて倒そうぜ！というテイストです。私にとってのドラクエ全盛期はIIIなので「16歳になる誕生日に王様から呼び出される」ことを最近の若者が知らなくて残念な思いをしたことはヒミツです。
そして旅立つのです。
とはいっても、こんなレベル、こんな装備じゃ魔王は倒せないのです。
そう。簡単に死んでしまうのです。
そもそもこのイベント掲示板がどういう目的で、どういう仕様で、、、という情報が無いままテストをしても、何がダメなのことなのか判断しにくいよね、ということを伝えたかったわけですね。
そこで、もっとレベルを上げて、いいアイテムを手に入れるのです。
仕様書を手に入れました！(ここで実際に紙に印刷した仕様書を渡す) これによって、何が意図した動きなのかがわかるようになりました。一方で、その仕様で本当にいいのかを考える必要も出てきました。
ここでの「バグの定義」としては(※)
- 仕様と異なる動き、をバグとします
- なんか変だな、とか、こりゃバグだな、と思ったらそれをバグとします
としました。 これによって3人がいろんなバグを見つけてくれたおかげで世界は救われたのです！やったね！世界の半分をもらわなくてよかった！(それはドラクエI)
※JSTQBの定義に従うなら今回のワークは「インシデントを見つけよう」になるんだと思うのですが、まぁよし。
ワークで伝えたかったこと
1つはテストする時って「仕様書通りに動くか」だけじゃ足りなくて、仕様を作る人とか開発者が想定できなかったことをどこまで想定できるかが大事だよね、ということ。
もう1つはバグって言ってもいろんなパターン(?)があって、
- 仕様を満たしていない
- (仕様に明記されていないけど)普通に考えておかしい
というものから
- 仕様がおかしい (組織によっては「仕様バグ」という名前が付いている？)
- こっちのほうがいい(「要望」と呼ばれるもの)
ということもたくさんありますよ、ということ。
一方で、開発者自身が仕様を考える場面も多いのがこの業界。(ですよね？あれ？) 「自分が考えた仕様をQAに正しく伝えること」もとっても重要ですね。私としては完璧にドキュメント化することは不可能だと思いますし、メンテナンスコストも大きいし、伝える側と伝えられる側の双方で共通の暗黙知があるならば「ここの入力バリデーションはいつものやつで」で十分だと思っています。そこには何度も一緒に仕事をしているとか、とても仲がいい、みたいな要素はとても重要。(逆に全く新しい機能とかはちゃんと決めておきたい)
品質について考えるとは
私がテストやってて困ること、テストやる時に考えるべきこと、そしてうまくできていないこと。それは
なぜそのテストで十分なのかをどう説明するのか
答えとしてまず思いつくのは品質特性の話。このシステムが出来上がったときにはこういう品質がこの程度必要だよね、確認したい品質特性によって行うべきテストの内容は変わってきますよね、だからこういうテストをするのだよ！という説明ができるととてもスマートですよね。
...がしかし。
正直なところ社内において「品質特性」という言葉を使う機会がほぼ無いです。本当は(テストだけじゃなく)プロジェクト開始時に関係者全員で共通認識を持ってからスタートする、ってのがセオリーなのはわかってるのですが、社内でそういう関わり方ができていないのは反省点。
...って思ってたら。
新卒研修の最後の仕上げとして6月いっぱい使って「3人で1ヶ月でWebサービスを作る」というアクティビティがあって、そのサービス開発のキックオフ時に品質特性についてディスカッションがされてるという話を聞いて胸アツです！
まとめ
総じて今年のメンバーは品質とかテストに関する意識が高くてステキ。特に北野くんは、ソフトウェアテスト界では有名な宮崎大学の片山先生の教え子で、ソフトウェア工学(の一部として品質とかテストとか)をちゃんと学んでいるだけあって、むしろ私よりも詳しいし、ソフトウェアを開発する側から実戦で役に立ちそうなことをいっぱい持っているので、爆速で私の屍を越えて行ってほしい。
今回のレクチャーでは触れなかったのですが、作り終わったものをテストするという従来の(?)やり方だけだとスピードについていけないのがWeb業界だなと感じています。ですので品質の観点を持っている人がプロジェクトメンバーの一員として一緒になって作っていく、という試みが必要なんだろうなと。
スクラムにおけるQAメンバー(非開発者)の関わり方を模索してみた で紹介しましたが、これまで「外から」テストしていたQAメンバーが「一緒になって」やっていける手段を探ってみてたりします。この方法はアジャイルとか、スクラムというものがどういうものなのか、が理解された上であればうまいこと回るんじゃないかなというのが私の感想です。
一方で、QAがエンジニア(開発者)になってしまえばいいじゃないか、と思うところもあります。「技術を使ってQAする」についてはまさにチャレンジしているところ。その先にガイアックスのQAとしての新しい姿が...あるといいな！
「組込みとWebの比較」についてご興味ある方は[WebのQAを5年間運営してみた]のP33からを参照ください。前職のデジカメの話とWebの話を比較してみました。
