はじめに
私は10年以上、開発をやってきて、急に思い立って、3年前にテストを専門で行う会社にキャリアチェンジした人です。開発者として、プログラマーから始まり、要件や仕様を決め、設計をするエンジニア、プロジェクトを率いるプロジェクトマネージャーと、一通りのロールを経験してきました。エンプラ系に特化しているものの、新規開発からリリース、その後のエンハンスというように、一通りの開発を経験してきました。というバックグラウンドを持っています。
開発経験はあるものの、今の会社に入った時には、テストを専門でやってきている同僚に囲まれてやっていけるのか、という不安がありました。実際の仕事の中で、テスト設計やマネジメントの話をする中でも、同僚たちと自分との間で、ちょっとしたことが考え方が違うなーという違和感も感じていました。
そういう不安があったので、入社してしばらくは、周りの同僚の発言や考え方を観察してみることにしました。自分の考えとの違いを知って、微調整していけば、それっぽくなるのではないかな、と思いました。
そうすると、なんとなく、開発者とテストエンジニアの考え方の違いがわかってきました。
今回、私の気づいたことを紹介したいと思います。
ちなみに、開発の人とテストの人のどちらがいいとか言っているわけではありません
なぜこれを書くか
開発エンジニアからテストエンジニア、開発マネージャーからテストマネージャーへのキャリアチェンジをした人、または、キャリアチェンジをしたい人は、結構いるように感じます。
その一方で、開発の人とテストの人のテストの考え方は違う、と聞くことがあります。しかし、具体的にどういう違いがあるのか、ということについて、直接的に語られている投稿が少ないように感じたため、私の気づいたことが誰かの参考になればと思って、今回紹介したいと思います。
読んでもらいたい人
- 開発の人からテストの人へキャリアチェンジを考えている人
テストの人はここが違う！
私自身の気づきが多かった、
- テスト設計
- テストマネジメント
の２つの活動について、あー、テストの人ってこういう風に考えるのか！、と気づいたことを紹介します。
他の話も探せば色々あると思うけど、私の気づきが大きかったものを挙げます。
ちなみに、ここでの「テスト設計」は、JSTQBのFLの「テストの分析と設計」らへんの活動を意図しています。
テストの人のテスト設計
-
テスト対象を色々な視点で見る
テスト対象を単に仕様書に書いてある機能単位とか、業務単位で見るだけで終わらせず、自分たちの独自の視点で切り取って表現していると思います。それは、モデリングを使ったり、マインドマップに書いたりとまとめ方はいろいろだけど、そこには自分はテスト対象をこういう風に理解しています。が入っているように感じました。
私が開発をやってた時は、何の疑いもなく、開発する単位（機能の単位とか）のただ１つの視点でとらえて、テスト設計をしていたので、ここは違うなと思いました。 -
抽象度の上げ下げができる
テスト対象を表現するときや、テスト観点を挙げるときなど、抽象的⇔具体的の調整を意識してやっていると感じます。初めてこのような考え方に触れたときには、そんなに気にするのことなのか？と必要性がよくわかっていなかったけど、とらえたいことを正しくというか、意図したとおりに表現するには、同じ抽象度で表現することが必要なんだろうと理解しています。 -
テストケースの目的を考える
１つ１つのテストケースの目的というか何を確認したいのか、をはっきりさせるというのも、やっている人が多かったです。テストケースの目的がはっきりしていないと、そのテストケースがOKだったら、何がOKといえるのかがよくわからなくなり、周りに説明ができないということなのだろうと理解しています。これも入社したてのころは、「確かにテストケースの目的ははっきりさせたほうが良さそうけど、どんな良いことがあるの？、やらないとまずいことがあるの？」ということが腹落ちしていなくて、モヤモヤしている時期がありました。
テストの人のテストマネジメント
開発マネージャーの立ち位置としてのテストと、開発チームとは別のテストチームのマネージャーという立ち位置の違いは、裁量でどうにかできる部分が多いか少ないか、だと思います。
テストマネージャーの場合、自分の配下のテストチーム以外の要因で、良くも悪くもなる部分が大きいです。例えば、開発チームが作成した成果物の出来栄えとか、環境構築担当の進捗度合とか。
そういう中、周りのテストマネージャーたちは、プロジェクトマネジメントの活動の中でも、この2つの要素を重視していました。
-
リスクマネジメント
自分のテストチーム以外が担当する活動に関するものに対して、リスクを上げて、テストの計画に織り込めるかどうか。
自分のチームの外の話だから、情報を取りに行って、リスクがあるか、そのリスクの影響などを考えて、計画に織り込んでいくという、自ら動いていくということです。 -
コミュニケーション
上のリスクマネジメントと同じく、自分のテストチーム以外のチームに情報を取りに行き、テストに関する活動に活かしていくということです。たとえば、テスト設計をするには、プロダクトやシステムの情報を開発チームから入手するだろうし、テスト実行の準備をしているときには、開発チームや環境構築チームの作業の進捗状況も気にするということ。
開発プロジェクトのプロジェクトマネージャーの経験があれば、テストチームのマネージャーもできるんじゃ・・・と思う人もいるようだけど、その人の得意分野、不得意分野によっては、「テストチームのマネージャーのほうが難しいなー」という人もいると私は思います。
ということで、ニッチなテーマではありますが、開発の人からテストの人にキャリアチェンジした私が気づいたことを紹介しました。個人の見解ではあるけど、誰かの参考になればうれしいです。読んでいただいて、ありがとうございました。