9人のテストエンジニア

この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2017」の20日目の記事です。

エニアグラムを使って、テストエンジニアの特徴を考えてみたいと思います。

『自己成長とコミュニケーションのための人間学』と呼ばれています。

詳しく知りたい方は、ググってみてください(許諾を得ていないため、リンクは載せませんw)

テストエンジニアにいそうな特徴を、エニアグラムのタイプ別に考えてみたいと思います。私自身は認定コースを受講していますので基本的なところについては把握していますが、それでも個人的な主観が入ってしまうことをご了承ください。

業務で自分のタイプに囚われたり、同僚と対立を生まないため、特徴を理解したい想いで考えてみましたので、ご参考程度にしていただけたらと思います。また、タイプは自分の強く出るところですので、他のタイプの良いところを自分のものにして行けば、今後の成長に役立てられると思います。

※　ステレオタイプに当てはめてしまって行動したり、相手の方を当てはめてしまうことを私は望んでいません。

テストを抜け漏れなく確実に実施したり、周りがその通りに行動するような施策を作ることが得意だと思います。

ただ、不要なテストを省略せずに全数実施することで時間が足りなかったり、作った施策を周りが実施しないことにイライラすることがあるかもしれません。タイプ７のように、自分のタスクを気楽に考えること、周りを楽しませるように施策を考えると良いかもしれません。

自分の業務に関係なく、テストの準備を手伝ってあげたり一緒に実施するのが好きなのかもしれません。でも、感謝されないとストレスが溜まる傾向にあると思います。

個人のタスクを達成する事。タイプ４を参考にすると良いと思います。

テストアーキテクチャ設計など、先進的な考えを導入することが得意だと思います。また、効率性が高く、少ないテストケースの実施で、欠陥の検出できるような特徴があると思います。

たとえ、設計が先進的であっても、プロジェクトに適合できるかの検証が漏れてたりします。効率性を重視するあまり、テストケースに抜け漏れがあるかもしれません。

タイプ６のように忠実にテストを実施すること、十分な検証も必要かもしれません。

個人ワークで黙々とテスト作業することが得意だと思います。プロジェクトに影響されずに自分で試行錯誤して解決することができますが、一方でプロジェクトの解決するべき課題にならない傾向にあると思います。

単純なテストケースの実施は苦手かもしれません。。。感覚が優れているので、逆にテスト実施中に別のケースに気づくことがあると思います。ただ、アドホックにならないようにしたいです(自戒の意味も込めてw

タイプ１のように、プロジェクトの課題として改善に繋げることが必要だと思います。

テスト技法や最新のアーキテクチャ設計方法などを自ら調べ知識にしたり、プロジェクトの問題点を分析することが得意です。ただ、プロジェクト全体から一歩引いている傾向にあり、メンバーに知識を提供しますが、それが実施可能かどうかまで検討しない傾向にあるかもしれません。

タイプ８のように、プロジェクトの達成のために積極的にチームに入っていくことが成長につながると思います。

単純なテストケースを実行すること、作業を着実に進めることが得意だと思います。ただし、難しい課題に直面すると、全体像がつかめず一部の問題解決だけを追求することがあるかもしれません。テストの網羅性を把握しない、組み合わせテストで全数テストすることがあるかもしれません。

不安を感じたり分からないことがあれば、全体に問題としてあげること。タイプ９のようにチーム全員で協調することが必要だと思います。

興味を持った技法やテストアーキテクチャ設計をすぐ試したいと思い、周りを楽しく巻き込むことが得意だと思います。ただ、自分の業務を分析せずに適用しようとしたり、反対メンバーに歩み寄ることを苦手とするため、最終的にグダグダになることがあるかもしれません。

タイプ５のように分析すること、反対メンバーがいたら意見を聞くようにすることが良いと思います。

プロジェクトや自分のタスク達成のための目的を本能で理解し、周りを巻き込んで実行する力があると思います。また、不具合が発生した場合にリスクや影響範囲を収集し、いち早く消化する事に優れていると思います。

ただ、実行力に優れている反面、スキルが低いエンジニアを置いてけぼりにする傾向があるかもしれません。タイプ２のように、一人一人に歩み寄り理解してあげる事が良いかと思います。

プロジェクト自体やメンバー全員がまとまっていて協調することに生きがいを感じ、ファシリテーションが優れていると思います。比較的ゆったりとしたペースで作業しますが、自分のペースに合わない状況がプロジェクトで起こると、ストレスを感じるかもしれません。。。

タイプ３のように、成功や効率を求める考え方を取り入れると、自分と一緒にプロジェクト全体を成長させることができるかもしれません。

テストエンジニアとあまり関係ない気がしますね(笑) また、自身のタイプである４は、記述多めです(笑

自分で読み返して思いついたのですが、プロジェクトの各工程の抜け漏れを防ぐためのチェックリストとして活用できる気がしました。

よろしければ参考にしていただけたらと思います。