ソフトウェアテストエンジニアの仕事というと、どうにかしてバグを見つけること、つまり「プロダクトをどう壊してみせるか」が重要だと思われがちです。『How to Break Software』という本もあるくらい。
それだけに、テストエンジニアは開発者から、自分の作品を傷つけにくる「破壊者」として敵視されるリスクもあります。JSTQB Foundation Levelのシラバス（の1つ過去のバージョン）には「テストの心理学」という節があり、このように述べられています。
テスト担当者およびテストマネージャーは、欠陥、故障、テスト結果、テストの進捗、リスクの情報を効果的に伝えることができ、同僚と建設的な関係を構築するための優れた対人スキルが必要となる。
いわゆる「コミュ力」は、テストエンジニアにとって重要な資質ですよね。
ただ、この「わたし作る人」「わたし壊す人」という素朴なパラダイムも、少しずつ変わってきているのかもしれません。大きく2つの理由があります。
1つ目は、アジャイル開発の普及により、開発者とテストエンジニア*1の距離がずっと近くなり、テストエンジニアが「開発の後半で現れる人たち」ではなくなってきているという点です。たとえばシラバス（の最新版）には、以下のような記述があります。
テスト担当者、ビジネス側の代表者、開発者は、実例マッピングに一緒に取り組み、ユーザーストーリーを共同で書き、バックログリファインメントセッションにおいて協力し、ユーザーストーリーと関連作業成果物が、定義された基準、例えば「準備完了（Ready）の定義」を満たすことを確認する。
最近は「シフトレフト」という言葉もよく聞かれますが、単に「誰かが作ったものの欠陥を早い段階で見つける」だけではなく、「最初から共に取り組む」という意志が感じられます。
もう1つは、テストエンジニアのミッションが「バグを見つける」こと（だけ）ではなく、「ユーザにとって価値があるかを調べる」ことでもあると考えられるようになってきた点です*2。
価値というのを「長所が多いこと」「短所が少ないこと」と雑に分けると、「バグが少ないこと」は後者を語るにすぎません。長所が多いことを、テストの段階になってから調べるのでは遅いので、開発の最初の段階から一緒に入っていくわけですよね。
では、テストの段階では何ができるでしょうか。
「共感的テスト」（Sympathetic Testing）というアイデアが、この記事で紹介されています*3。
この記事によると「共感的テスト」とは、プロダクトの価値を理解するために、（プロダクトに挑んでいくのではなく）「このプロダクトがどう素晴らしいのか」を問いながら、肯定的にテストすることを指しています。これは単に「ハッピーパスのテストをする」ことではありません。
その目的は、学習を通じて、プロダクトに対する豊かなモデルを心の中に構築していくことととされます。より良いテストをするための前準備ともいえ、もしかすると、探索的テストの前段階にあたるプロセスと言えるかもしれません。
共感的テストというアイデアは、ソフトウェアテストを直接的に改善するようなものではないでしょう。
ですが、QAにとって「壊す」作業は、「価値を確認する」という、より大きな目的のための1つの手段でしかなく、それ以外にも採るべき手段があるのだということを再認識させてくれる概念だと思います。
補記
最近は、「テストエンジニア」よりも「QAエンジニア」という言葉の方がポピュラーですね。
ですがこの記事では、にしさんのこの意志に敬意を表して、「テストエンジニア」としました。
最初はテスターの復権という文脈を僕も使っていたことは認めるけど、○○の復権というのは人々を非論理的にするという点で麻薬なんだと思うに至り、ある時僕の講演からその臭いはすべて消した。でも心の中にこだわりがあって、僕は「テスター」とは呼ばない。だからまだ麻薬が抜けきっていない。
— Yasuharu NISHI (@YasuharuNishi) 2018年9月30日
