開発者がテストも兼任するのはやっぱり難しい？開発もテストもやった時に「やらかした話」２選
こんにちは、駆け出しアジャイルQAの三谷です！
前回は、テスト初心者の立場から、探索的テストの記事を書いたのですが（読んでね！）、今回はちょっとだけ思い出も交えつつ。
私、SHIFTに入社するまでは、QAという肩書きを名乗っていませんでした。要件定義も開発もテストもやる、IT何でも屋さんでした。
今は、開発者とは別の第三者として、システムのテストを行っていますが、何でも屋さん当時は違いました。自分が開発者として携わったシステムのテストを行うことも、よくあったのです。
開発者がテストも担当するってアリ？ナシ？
当時は何の疑いもなく、自分が開発に携わったシステムのテストを行なっていましたが・・・それって実際アリなの！？ナシなの！？
テスト界の権威、JSTQBのシラバスを見てみましょう。
ほぼすべての種類のプロジェクトにおいて、複数のテストレベルのいくつかでは独立したテスト担当者がテストを行うのがよい。開発担当者は自分たちの仕事の成果の品質をコントロールするために、特にローレベルのテストに参加すべきである。
という記載があります。
（ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02「5.1.1 独立したテスト」より）
なかなかお堅い文章ですが、これをやわらか語に翻訳すると、
「開発者がテストをやるのは、単体テストくらいまでにしときな〜」
「それ以降のテストは、開発者とは別の人がやりな〜」
という感じでしょうか。
私が開発をやっていた時、結合テストやシナリオテストまで担当することもありました。しかし、シラバスに則ると、品質をコントロールするためには、別の人がテストを担当するのが良いようですね。
開発担当者とテスト担当者を分けたほうがいいのは、なぜ？
開発者と別の人がテストをする利点の1つ(※)として、JSTQBのシラバスには以下の通り記載されています。
独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い。
（同章より）
(※)他の利点は、JSTQBのシラバスを見てね。
つまり、
「開発者と別の人がテストを担当すると、開発者とは違う視点でテストできるよね〜」
「だから、開発時に埋め込まれちゃった不具合を見つけやすいよね〜」
と言っているのだと思います。
これを読んだ方の中には、「別の人がテストを担当すれば、確かに違った視点でテストできるだろうな」と漠然とイメージはできたものの、「具体的には、どんな視点の違いがテストに有利に働くのか、いまいちピンと来ていない」という方も、いらっしゃるのではないでしょうか。
そんな方のために、私が開発もテストも担当した時にやらかしたエピソードを、ここで懺悔・・・ではなく、紹介します。
視点の違いが重要となる理由を、具体的にイメージする一助となれば幸いです。
やらかし①開発者は、違和感のある挙動に気づきにくい
開発をやっていると、システム内部の作りに詳しくなります。
その結果、何が起こったかというと・・・
本来なら違和感があるはずの挙動を見ても、
「あー、ここはソースコードがこうなっているから、こういう処理になるよね。うんうん」
と、脳が勝手にシステム知識で補完して、納得させてくれるようになりました。いらんことするな、脳！！
やらかし②開発者は、設計書にない部分の不具合を見落としやすい
開発は、設計書通りに行われるのが基本です。そのため、開発者の私は常に設計書とにらめっこ。
そうしているうちに、「設計書の記載内容」が、頭の中に定着していきました。設計書にAと書いてあれば、「ここはAと動けばOK！」と、頭に刷り込まれていくのです。
この刷り込みがあるがために、設計不備が原因の不具合を見落としやすくなります。
とりわけ見落としやすいのが、条件により挙動が変わってくる機能。設計書には「A」としか書いていなかったけれど、実は「αの時はA、βの時はB」というのが要件だった、というケースです。
設計書を読み込めば読み込むほど、設計書に書かれたもの以外目に入らなくなる。まるで、恋人を思えば思うほど、周りが見えなくなってしまう乙女のようですね。こんなところで恋心発揮すな。
最後に
開発者がテストも担当した時に、どのような不都合が生じるかについて、2つのエピソードをご紹介しました。
① 開発者は、違和感のある挙動に気づきにくい
② 開発者は、設計書にない部分の不具合を見落としやすい
いずれも、開発者の視点が色濃く出たために、不具合の検出が難しくなってしまった例だと考えています。開発の視点が、無意識下でテストを邪魔してしまうのです。（開発の仕事に一生懸命取り組んだ証拠ですよね。）
同一人物が開発担当者／テスト担当者の両方の役割を担うのは、やはり難しそうだなと、記事を書くなかで改めて感じたのでした。
これらの話から、「開発担当者と異なる視点を持って、テストを行うべき」といわれる理由が、少しでも具体的にイメージしやすくなれば幸いです。
お知らせ
SHIFTは、システムの品質保証に強みのある（でも実はシステム周辺何でもできる）会社です。そんなSHIFTに所属する人々が発信している技術ブログが、この公式SHIFT Group note。筆者のようなQAエンジニアのたまごだけではなく、あらゆる技術のプロフェッショナルが書いた記事が、続々と掲載されていきます！ あなたが知りたかった、あんなことについて書いている記事があるかも・・・？ ぜひ他の記事も見ていってくださいね！
★このライターの他の記事を読む
探索的テスト初心者集合〜！QAエンジニアのたまごが送る たまごの、たまごによる、たまごのための探索的テスト
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール： 三谷 瞳
駆け出しアジャイルQAエンジニア。ITベンダーに勤め、数々の不具合に遭遇した結果、「やはりシステム開発で最も重要なのは品質だ！」と考えるようになり、2020年にSHIFTに入社。アジャイル＆品質保証のプロを名乗る日を夢見て、日々勉強中。
■SHIFTについて
私たちはソフトウェアテスト(第三者検証)のプロ集団です。
■メディア掲載情報
《NEW!!》資料ダウンロード／動画視聴ページはこちらから
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/