テスターがソフトウェアチームに貢献する方法として、品質ギャップを伝えること、良いテストのために場を整えること、自動化コードを書くことが挙げられる。Maaret Pyhäjärvi氏によれば、私たちはテスターではなく、テスト自体について考える必要があるという。チームメンバー間のコラボレーションやコミュニケーションは、製品やユーザー体験に有益な影響をもたらす。
Pyhäjärvi氏は、HUSTEF 2023でソフトウェアチームにおけるテスターとテストの影響について基調講演をした。
テスターがソフトウェアチームに貢献する方法として、品質ギャップを特定し、伝えることが挙げられる。これをバグレポートと呼ぶ人もいるが、テスターの真の価値である「コミュニケーションを取り、理想の品質に対し何が欠けているか見極める機会」を逃してしまう、とPyhäjärvi氏は述べている。
テスターは、チーム内で良いテストのための場を整えることができる。特にペアリングテストとアンサンブルテストは、単に問題点を指摘する代わりに、ソフトウェア開発者がテストを行うべき部分を発見する手助けになるだろう。
ある日、私は何をテストして何をすべきかを言わないことにしました。彼らは私を見て、"ここをクリックしてほしいんだろう"と言いました。私は何も答えませんでしたが、彼らは私がすると思ったものを選んでクリックし、自分たちが見落としていた問題を見つけてくれました。
Pyhäjärvi氏は、時には私たちが行うことを減らしてテスターに多くを任せるべきであり、ただそのパターンを指摘すべきであることに気づいていなかったと述べた。「開発者たちのために発見するのではなく、開発者たちを発見へと導く」ことによって、その瞬間にも長期的にも、より大きな影響を与えると気づいたことは、馴染みはないが価値ある貢献である、と同氏は付け加えた。
Pyhäjärvi氏が説明するように、読者諸氏が職場から離れたときに残って仕事をするオートメーションを書くことも、ソフトウェアチームにおけるテスターの貴重な貢献方法である。
単にバグを見つけて修正することだけではありません。オーナーシップの構築、私自身がテストを実行できなくなったときのための構築、また、テスト自動化によって、過去の教訓を実行可能な文書として記録しておくことも重要です。
Pyhäjärvi氏は、人はテストを通じて製品を変え、UXを変え、そしてより良いテスターやプログラマーになることができると述べた。
テスターではなく、テストについて考えたいと思っています。そして、私たちには変化を生み出しサポートするような会話をする勇気が必要です。
Pyhäjärvi氏は、価値の高い影響が一人の人間からもたらされることはほとんどないと主張した。そのようなものは、様々な人やペアの存在による協力や、誰のアイデアが最終的に実装されたアイデアに反映されたかもはや正確にはわからない、ラダー効果（はしごのように段階を踏んで意識改革を行い、モチベーションを高めていく手法）の存在が必要なのである。コラボレーションの功績とは、アイデアの最終形を話した人だけでなく、すべての関係者を認めることだと同氏は締めくくった。
InfoQは、テストの生産性とストーリーの共有についてMaaret Pyhäjärvi氏にインタビューした。
InfoQ: テストの生産性はどのように測定できるのでしょうか？
Pyhäjärvi氏: テストの仕事は、見えないインクを塗った白い紙を持っているようなもので、何を発見する必要があるのかをあらかじめ正確に伝えることは誰にもできません。私はプロジェクトであらゆる種類の近似値を使用します。アプリケーションのツアーや調査をしながら少しテストした後、私は通常、どれだけのバグが隠れているかを推測し、それを予算として設定し、それに照らして作業し、バグ発見の進捗を追跡します。計画に基づいて作業することで、学習に応じて最終目標を更新するだけでなく、進捗のステップを示し、より労力をかけてカバレッジのアウトラインを作成できます。
しかし、テスターの生産性の欠如は、ノイズ（他の人に迷惑をかけてしまう）や沈黙（関連する結果を見逃してしまう）として現れると言うほかありません。テストはあくまで情報を提供する程度のものです。最悪の場合、テストは人々が望まない、あるいは気にも留めない情報を提供しかねません。私はそのような情報をノイズと呼んでおり、これは他の人を悩ませてしまいます。
InfoQ: なぜテスターが自分たちの体験を共有することが重要なのでしょうか？
Pyhäjärvi氏: バグはその影響なしでは意味を成しません。意味は実体験で伝わるのです。
時間をかけて改善すること、同僚に何かを教えること、同僚から学ぶこと―これらは実体験の物語で共有するのがもっとも良い影響を与えます。
InfoQ: 共有したいテスト体験はありますか？
Pyhäjärvi氏: あるプロジェクトでは、テストの自動化を計画することから、そのほんの一部を実装することへと転換するために、2年間かけて少なからぬ努力を要しました。そして、自動化の限界について警告することに費やす時間は、自動化による成功から遠ざかる時間であることを理解しました。
私は以前、自動化ですべてができるわけではないと言っていました。自動化の限界を何度も説明してきました。そして自動化を減らしました。ここで、私は違う選択をしました。自動化の限界を警告したくなるたびに、それに価値ある仕事を加えることを選びました。その結果、私は便利で改善された自動化を手に入れました。それはまだ完璧ではないし、私自身がもっと考える必要があります。しかし、もし私が、それがうまくいかないかもしれないと考えるのに時間を費やしていたら、どうすればうまくいくかを学べなかったと思います。
これは、私たちが既に持っているにもかかわらず、そのことに気づいていない選択についての話だと思います。大きな変化の時に押し通すことは、物事を変えるよりも安全だと思われるからです。探索的テストを中心に据え、テスト自動化における厳選された教訓を文書化していなければ、良いテストはできなかったと思います。