ソフトウェアテスター/QAエンジニア · 業務ごと

手動の回帰テスト

台本に沿った回帰テストは以前から自動化可能だった。変わったのは、平易な言葉の説明から実際の画面を操作でき、画面が変わったら自分の台本を直せるようになったことであり、それによって、チームを手動のテストに留めていた保守の負担が消えた。これはたいていの検証の職で最も大きな時間の塊であり、それが速く失われつつある。

これはたいていの検証の職で最も大きな時間の塊だと、はっきり言っておく。残りの業務のどれも、その一週間を埋めていた人たちを吸収できるほど大きくない。

テストケースと自動化を書く

仕様から、あるいはコードそのものからテストを生成することは、コード生成の道具の最も効く使い方の一つであり、一つの開発期間をかけて用意していた網羅が、いまや午後のうちに現れる。ただし生成されたテストは、生成されたコードと同じ意味で浅い——コードが何をすべきかではなく、コードが何をしているかを確認してしまう。だからこそ次の業務のほうが重い。

生成されたテストは、コードが何をすべきかではなく、何をしているかを確認してしまう。欠陥ではなく網羅率で測っているチームは、この業務はもう解けたと結論する。それは測り方の問題であり、割を食うのはテスターである。

探索的・敵対的なテスト

生成されたテストは仕様かコードから導かれるので、その死角をそのまま受け継ぐ。誰も想像しなかった壊れ方を見つけるには、現実の利用者と現実の系がどう振る舞いを誤るかについての頭のなかの模型が要り、それはこの製品とこの領域での経験から築かれる。道具は探す範囲を広げる。どこを見るかという仮説のほうは今も人のものであり、そして高くつく不具合はそこにある。

どこを見るかという仮説は、いま消えつつある回帰テストの仕事をやってきたことで築かれる。この業務を守っているのは、もはやその流れが生み出さなくなった経験である。

出してよいかを決める

これは組織的な結果を伴う責任の判断であり、チームがそれを委ねたがる気配はまったくない。画面は状態を要約する。この版、この顧客層、この一週間がどの程度の危険を背負えるかという一声は、チームがその判断を信じている人が下す。

多くのチームでは、この一声はテスターではなく開発の管理職のものである。そうである限り、これが守っているのは他人の職である。

モデルを抱えた系をテストする

新しい製品の多くは輪のなかにモデルを抱えており、固定の出力を突き合わせる形ではテストできない。評価の設計、敵対的な指示、振る舞いの回帰検出は新しい分野であり、やっている人は少ない。そして検証の構え——壊れていると思え、どう壊れているかを突き止めろ——はそのまま移る。

やっている人が少ないのは、いまの話である。この分野は若く、最終的にどれだけの大きさになるかは分からない。そして検証ではなくモデルをつくるチームの内側に収まってしまう可能性もある。