テストを良くしたいけど作業を増やしたくないとか言うクソ野郎には、とりあえず同値分割を教えとけ！！

ソフトウェアテストの小ネタ Advent Calendar 18日目です。

qiita.com

17日目は、kz_suzukiさんが書きました。

www.kzsuzuki.com

テスト設計する時に自分がよくハマってる事が載っていましたので、今後の参考にしてみたいと思います。

はじめに

最近、弊社で所属しているグループでテスト勉強会をやっていますので内容について書きつつ、タイトルのことを書きたいと思います。

ちなみに、弊社におけるテストの実情はこんな感じです。

  • いわゆる組み込みソフトウェアの開発
  • 主な開発範囲は、装置を制御するソフトと、操作するためのGUI、などなど
  • 自分たちで開発、テストしている
  • テストケースの再利用はない(きっぱり
  • ソフトウェアのテストに関する知識は、基本情報処理技術者試験に出てくるレベルでは知っているが、JSTQB FLに出る内容は知らない(と思う)

（ちょいちょい実機テストで出る）前フェーズで見つかりそうな不具合や、客先不具合の対応工数をどうにかしたいと、今更ながら上役が思ったんでしょうねー（遠い目

自分は、今年序盤でTOCfEの社内勉強会をやって「仕事をする上での共通の知識の必要性」を実感していました。 同じようにテストの社内勉強会もやるべきと感じていたので、そう考えてくれたのはちょうどよかったです。*1

社内のテスト勉強会について

社内で行っているテスト勉強会について書いてみます。

勉強会ですでにやった内容・これから教える内容

これからの予定*2

  • 状態遷移テスト、ユースケーステスト
  • テスト観点、テストコンテナのワーク

勉強会の目標・方針

目標は「テストに対する共通の知識」を身につけることです。 これによって、各自のテストを見直すとともに、テスト方法をお互いにレビューできるようにしたいと考えています。

最終的には「我々のチームで納得できるテストをするには？を一緒に考えられること」を目標にしています。

勉強会の方針は、こんな感じにしました。

  • 教えることの要点を絞る

「ソフトウェアテストでは、たくさんすることがあるんだよ」と思わせるような内容にしていません。*3
グループメンバーが今不足していることの認識、メンバーができる範囲で考えられる程度に留めています。
一度業務に適用してみて、うまくいかないなら原因を考える、足りないものが見つかったのなら新しい道具を出す、くらいで良いと思っています。

  • ただし、てめーの脳みそで考えさせる・意見を出させる

勉強会の後は自分たちの業務に適用するのですから、最終的には自分たちで答えを出した方がよいです。
なので、ワーク中心でやって、分からないことがあれば納得するまで話し合うようにしています。
答えがないということは強調していますが、個別化されないように注意した方がいいですね(個別化されると議論しない可能性があるため)

  • 完璧な資料は用意しない

一番の理由は、ソフトウェアテストを適切に教えられるほど理解していないから（笑）
かと言って、ちゃんとした資料を作るほど、時間をかけても意味がない。*4
ちゃんとした内容を知りたいなら外部で偉い人・エロい人の話を聞けばいいと思うし、自分も間違いに気づいたらアップデートしていけばよいので、まずはチームメンバーのテスト知識の成熟度に合わせた資料にしています*5 *6

タイトルの話

勉強会自体は一通り実施する予定ですが、現時点では「同値分割（＋境界値分析）だけでも十分効果があるだろう」というのが個人的な感想です。*7

同値クラスによる分類

開発者の設計の時点で、同値クラスで分類していた方がよいと考えています。

例えば、同じドメインの開発者同士(制御開発メンバー同士、GUI開発メンバー同士)ですら、詳細設計レビューで欠陥を見逃す場合があります。
「レビュー観点が少ない」ことが一つの原因として考えられますので、「同値クラスを分類する・名前をつける」ことができれば、そこから議論が始まるのではないか、と考えています。

無効値の意味

特に、無効値については明確にした方がよいと考えています。

例えば、I/Fを提供する側の設計では、

  • 0～255までは有効値
  • それ以外は無効値

と仕様にしたとしても、「無効」の意味によっては呼び出してしまう可能性があります。

  • I/F提供側「そもそも、ありえない入力（入力されることは想定していない）」
  • I/F利用側「提供側で入力の有効値判定があって、エラー（例外）で返ってくるはず（むしろ返って来てほしい）」

という考えの違いが、不具合を生み出しているかもしれないですね。

無効同値という単語が出たら、どんな意味か確認してみるとよいと思います。

実際、社内勉強会ではどんなワークにしたのか？

  • 社内勉強会では、開発しているソフトを使って、同値分割や境界値分析のワーク課題にしています。
  • ワークの課題の問題は、担当しているドメインによっていくらでも解釈可能な感じの曖昧さにしています笑。
  • 答えをどのように導いたか話してもらい、そこから議論するようにしています。

結果的に、担当ドメインが変わると同値クラスが変わりましたが、同じ担当ドメインでも同値クラスに違いがありました^^;;
意図通り、メンバーには設計書作成とレビューの問題に気づいてもらえたかと思います。

おわりに

こんなことなら、JaSST'18 Kyushu行けばよかった^^;;

JaSSTソフトウェアテストシンポジウム-JaSST'18 Kyushu-レポート

*1:彼らが必要性を認識しないと、どんなに説明しても予算が確保が難しいため・・・

*2:すべて終わったら、一度アセスメントしようと思っています

*3:否定的な意見は受け入れてるけど、思考停止すぎて正直聞き飽きた^^;;

*4:きちんとした資料を作っても、参加者が理解に達するに至らない

*5:資料は穴だらけ・間違いも多く、ツッコミ待ち^^::

*6:ただし、業務に合わせた資料作成のため、準備時間はかかっている^^;;

*7:弊社の開発において。グループの成熟度で違うと思います。

社内発表会の話

弊社で年2回行われてる改善提案発表会で、一等賞を貰ったという話です。

内容は
「TOCfEを開発改善に使いましたよ」改め
「TOCfEの勉強会をグループと新人研修で行なったら、得られた気づきがありましたよ」について。
20分の尺の中で、どうやったら「TOCfEが効果的なツールである」と伝わるか考えて、「開発改善の事例」は、ほぼカットした感じ

内容としては、

  1. TOCfEの紹介(と改善事例を少々)
  2. 勉強会の実施と気づき(公開している内容)

を話しました。
ほんのりエニアグラムの知見が見え隠れする内容になっております(￣ー￣)

www.slideshare.net

業務改善のためのツール作成の発表が多い中、思考プロセスとその勉強会を話すのは、弊社の発表会ではかなり特殊になります。

「もしTOCfEを社内で広めたら、業務や職場が変わるだろうか？」と思ったので、ちょっとチャレンジしてみました。まぁ、毎回同じようなネタで飽きてたというのもあるw

ちなみに、公開しているスライドにはないですが、各TOCfEのツールは次のように紹介しました(実は発表スライド作成の大半の時間を費やしていますw

  • ブランチ・・・「割り込みが多いから、作業が計画通りに進まない」の因果関係を明らかにして変える ＆ 実際の開発での改善例
  • クラウド・・・「悪いところを直接メンバーに指摘する」vs「悪いところがあっても指摘しない」(共通目標：チームがよりよく活動する)
  • アンビシャスターゲットツリー・・・「TOCfEを社内に浸透させる」を達成する

TOCfEの紹介に時間を割いた割に、グランドルールに食いつきが良かったです。
勉強会の方針は某bootcampを参考にしていますが、社内では「全員が認識してるけど、対策しようのない課題」だったのだろうと感じました。
グランドルールは、社長から直接「これは良い、今度会議でやってみたい」というお言葉をいただきました^_^

新しい社外監査役から「コンサル経験あるの？」って聞かれました笑
うちのソフト屋は、ソフトしか作らないというイメージが強い分、インパクトは残したかと（￣+ー￣）

残念だったのは、質問がなかった事。
発表内容が当たり前のように感じてしまうくらい分かりやすかったのかもしれないけど、スライドにもある通り「恐れによるもの」で意見を言えない状況が見事に出た感じでした(よく分からないので、変な質問ができない
(自分が使うことを想像して、)自分が納得する質問をしてくれるだけで、十分なのになぁと思いました。

あと、色んな人から「話し方が丸くなった」と言われました。
自分の発表で「社員に、TOCfEに対して悪い印象を持たせたくない」という理由もありましたが、一番の理由は最後の受賞コメントで煽りたかったんですよね笑

なので、最後の受賞コメントで煽りました笑

  • 研修申請したら、部長2人に呼ばれて「そんなの必要か？」と言われて以来申請してないんだよねー　→　部長2人、苦笑する
  • 質問がなかったのは残念。キマイラは子供以下ですか(その後、皆さんの伸び代ですね、と付け加える　→　「いつも通りだ」と言われるw

そんなわけで、褒められたのに、全方位に絨毯爆撃して全て台無しにしましたとさ笑

ブランチにまつわるエトセトラ

ロジック・ブランチで気づかされたことがあったので備忘録として。

ブランチを描く際に陥るケース

ブランチを書く際に、『何をブランチの事象にすればよいか分からない』と言う状況になると思います。

「とりあえず、ゴールを設定してみて、事象を挙げていこう。」と。

そこからアイテム出しをして因果関係を作っていくと、次のケースにぶつかります。

「ゴールに繋がりそうなアイテムが出てこない・・・」

実業務でも、そんな事起こってない？

ゴールを設定して説明しようとして、うまく説明できない事は、現実社会でも起こり得るケースだと思います。

例えば、以下のようなソフトウェア開発を例に説明したいと思います。

  • ソフトウェアテストの計画がなく、テスト実施は各開発者の裁量で行なっている
  • 新機能を開発した際に、単体テスト・結合テストで、正常系/異常系の確認は行った
  • システムテストでUIから可能なテストを実施して、特に異常な動作が確認されなかったのでリリースした
  • ある顧客の環境に新しいソフトをインストールし運用したところ、異常なケースが見つかり損害が発生した。
  • 実は、その顧客向けの特殊仕様があり、新機能には特殊仕様の対応が含まれていなかった。担当した開発者も特殊仕様下のテストを行なっていなかった。
  • 顧客「早急に再リリースしれ。あと、不具合が発生しないことを説明した資料よろ」

顧客にはどう説明する？

「再リリースしたソフトと今後の修正がが不具合がない事」の説明について、思考するんじゃないかと思います。

  • 今回は、抜け漏れていた事を含めて、新機能の正常系・異常系を確認する
  • 今後は、顧客と同等の環境でテストすることを徹底する
  • 合わせて、過去に実施したテスト項目を再確認することを徹底する
  • 担当者によっては何をOKとするか変わるので、今後は過去のテストの動作ログと比較する

でも、現状どれもできていないから顧客を説得することができない。。。何より、

「どうやったら不具合がないって言えるんだろう・・・？」

と考えるのではないかと思います。

『ブランチで陥りやすいケース』に置き換えると

もし『修正したソフトに不具合がないこと』をゴールに設定し、「今回自分たちが行なった作業」をブランチを描くと、こんな図になるんじゃないかと思います。

f:id:kabe-aa:20180526164623j:plain

また、ブランチを描いている最中は、こんな事に悩むと思います（実際に自分で作ってみて感じた事）

  1. 自分たちの作業とゴールに因果関係を作ることができない
    現実と違う事を説明するために、無理矢理繋ごうとしてしまい『ゴールから逆算して推測』し始めます（これ自体は悪くない）
    自分たちの行動と推測の間に因果関係が作れるなら良いですが、そうならない場合は『推測の原因となる推測』を考え始めます。
    考えた末に、『ゴールと同一の推測』や『ゴールとは矛盾してる推測』を作ってしまいます（ブランチを描いている最中は意外と気づいてない）

  2. ゴール達成のための十分な説明ができない
    ゴールを設定しまったことで、ゴール達成の十分性を考えてしまいます。
    下手すると「ゴール達成のために国際規格に準拠することが必要だ！！」と言いかねない状況になりますw*1

ブランチを描くために、ゴールを設定するのか？

実は、自分がブランチ描く際にはゴールを設定していました(笑
で、前述したみたいに、うまくいかないことの方が多かったです。

先日、他人のブランチの作成過程をみて、以下のことに気づきました。

ゴールは設定しない

ブランチを描く際は「現状把握」のために限った方が良いと思います。

そのため、ブランチの一番上にあるものはゴールではなく「最後に起こった出来事」になると思います。

ゴールではなく、あくまで観点として使う

何を事象とすればいいか分からないなら、観点の一つとして使うならありだと思います。

観点として「現状はどうだったのか？」を広げたり、掘り下げていけば、納得のいく現状をブランチで表現できるはずです。

現状とゴールとの差異を見つける

ゴールに近づいているか、作ったブランチを元に考える。

作成したブランチ(開発で実施したこと)がゴールに達成しないのは、そもそも何か問題があるんじゃないか？と気づくはずです。

こんな感じ？

  1. 「顧客環境下で不具合が発生した過程」を現状把握するためブランチを作成する。例えば、こんな感じ
    ※　作成したブランチは何度か修正した最終版。一番初めのブランチは後述します。 f:id:kabe-aa:20180526172053p:plain

  2. 「作ったソフトに不具合がないこと」をゴールとした場合に、
    「（顧客が納得するような）十分な確認方法」として、何が足りなかったか分析する。
    一例として挙げるなら、、、

    • 顧客は特殊仕様で運用している & 新機能の追加によって特殊仕様が動作しなくなっていた
      「なぜ、特殊仕様の事を把握してなかったのか？」「どうしたら次回以降予防できるのか？」を考える　

最小手数で効果的なところを最初のターゲットにして、開発を改善したり、顧客への説明材料にした方が現実的だと思います。 *2

それでも、説明が足りない、と言われるなら・・・

次に改善可能なターゲットを説明すると良いと思う。

もしくは、アンビシャスターゲットツリーを使って、戦略的にゴールを目指す事を説明する方がいいと思うの(今回は省略

余談（ブランチの修正）

この記事をはじめに公開してから、ブランチの図を修正してみました。 どのように変更したか記載します。

修正前のブランチ

一番最初のブランチは次のように作りました。

  1. 「顧客の環境で不具合が発生する」までの出来事を挙げる
  2. 出来事を「ブランチ作成ルール(CLR)」に従って因果関係を繋いでいく
    ただし、声に出して読んでいなかったため、違和感が残ってしまいました。

f:id:kabe-aa:20180526180123p:plain

修正内容について

基本的には「ブランチ作成のルール(CLR)」に従って、声に出して修正していますが、次のように修正しています。

  • 推測の追加
    例えば、一番上の不具合発生の原因は「新しいソフトで運用する」だけでは十分ではないため、「顧客が運用している条件」「特殊仕様に対する修正」を補足情報を追加しました。

  • 因果の組み替え
    「新機能をシステムに組み込む」→「UIから考えられる入力でテストを実施する」、「UIから考えられる入力でテストを実施する」＆「特に異常となるような動作が確認されない」→「新しいソフトをリリースする」までは、声に出して読んでみると、違和感がありました。
    そのため、「新機能をシステムに組み込む」＆「UIから考えられる入力でテストを実施する」＆「特に異常となるような動作が確認されない」→「新しいソフトをリリースする」に変えました。

  • 文章の変更(具体化)など
    特に「顧客の環境で不具合が発生する」は、起こった現象としては抽象的なので、「新しいソフトがインストールされた顧客環境では運用できない」に変更しています。
    また、因果が特に重要そうでないものは1つの事象に統合しました。ただ、パワーポイントのスペースの制約で統合したので、付箋でブランチを作る際は逆に分けたままの方が使いやすいかも。

最後に

やっぱり、声を出して読むと気付きやすいですね(^^;;

まだしっくりこないところや足りない情報があるかもしれませんが、今の自分の実力ということで、生ぬるい目で見ていただいて、アドバイスしていただければ幸いです(^^;;

*1:きっと「国際規格を使ってどうゴールを達成するの？」ってループするんだろうけど^^;;）

*2:この狙い方はSaPIDを参考にしています

相談をストロングスタイルで受けてたつ

友人の相談

あれは昨年8月、新日本プロレスの真夏の祭典・G1クライマックス、Aブロック最終戦を観戦した時に、友人から相談を受けました。

友人「転職を考えてるんだが、転職を経験した立場としてどうなのか知りたい」(超意訳)

その時の答えは、

俺「まずは自分のスキルの棚卸しからじゃね？その上で今の会社で出来ること、そうでない事を整理した方がいい」

と言って放置プレーしてました。

そして、半年後

先日、その友人から連絡をもらいました。

友人「内定をもらったけど悩んでるので話をしたい」

その直後、回答した事は、 俺「そこまで行動したのに(＝結果ももらったのに)、何に悩んでるの？」

彼とのLINEのやり取りだけでは「深く悩む内容じゃないよな」と思っていましたが、会って話をする事にしました。

彼とのやり取りをクラウドにしてみる

彼が解決したいことが何か、TOCのツールの1つであるクラウドを描いてみたら分かるんじゃないかと思い、話をしながら描いてみました。

その時に描いたクラウド。 f:id:kabe-aa:20180210192131j:plain

それぞれの箱の説明

今回の対立している行動は「今の会社に残る」と「今の会社を辞める」(図中の右側の上下の箱2つ)。

対立しているそれぞれの行動に対して要望を入れる(図中の中央の上下の箱2つ) 。
今回は、「今の会社に残る」の要望は「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」
「今の会社を辞める」の要望は「仕事の幅を広げたい」とした。

次に、これらの要望を満たす共通目標を決める(図の左側の箱)。
ここでは「自分の将来を考えたい」に落ち着いた。

納得感が得られるまで作り変える

クラウドを作成するときは、本人の話を聴きながら、要望と共通目標を何度も作り変えています。

実際は複数の要望が出ていますが、色んな要望や目標があった中から、自分も本人もしっくりきたものを選んだつもりです。

仮定を作り、矛盾を見つける

それぞれの箱を接続している矢印には、仮定(前提条件)が存在しているので埋めていきます。
その上で、論理的な矛盾を見つけます。

上側

「自分の将来を考えたい」(目標)ならば、「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」(要望)、何故ならば、「スキルが特殊である」(仮定)。
「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」(要望)ならば、「今の会社に残る」(行動)、何故ならば、「今の仕事に慣れているから」(仮定)。

着目するべき仮定は「今の仕事に慣れているから」で、自分の将来を考えてるなら、「今の仕事のその先を考えて実践していかないといけないんじゃない？」と考えることができる。
つまり、「会社に残ろうが辞めようが、先のことを考えてなければ意味がないんじゃないの？」と言えるようになりました。

下側

「自分の将来を考えたい」(目標)ならば、「仕事の幅を広げたい」(要望)、何故ならば、「今の仕事がなくなるかもしれないから」(仮定)。
「仕事の幅を広げたい」(要望)ならば、「今の会社を辞める」(行動)、何故ならば、「今の会社での先が見えないから」(仮定)。

着目するべき仮定は「今の会社での先が見えないから」で「本当にそうなの？」と自分は疑問に思いました。
つまり、そこに、今の会社に残るための意義があるんじゃないかと思いました。

結論

どっちでもいいんじゃね？笑

自分の言葉で誘導しないようにクラウドを作成してたので本人の純粋な考えをまとめたつもりですし、結論も彼が決めるべきだと思うので。
※本人も相談前から「最終的には自分が決める事だ」と認識済み。

自分は、クラウドを描いてみて、彼の考えてたことを理解しましたし、彼にとって必要なものが何か見えたので、勝手に満足しました笑

少し話を発展させる

クラウドを描くだけだと、無責任感は否めないので笑。

俺「もし内定先の業務内容が似てるなら、どんな職場環境か、ある程度想像できるんじゃね？目標を達成できそうな方を選ぶ方が良くね？」 とは話しました。

共通目標が見えた事で初めて、行動を選択するための判断材料になったと思います。

ストロングスタイルな問題解決とは？

ストロングスタイル - Wikipedia

ぶっちゃけ、このエントリーを読んだ後、 「お前が言ってるのは、ストロングスタイルじゃねーよ！」 と思う人もいるでしょう。
解釈は人それぞれあるので許してくださいw

自分にとっての問題解決は「風車の理論」に近いと思っています。
かつてアントニオ猪木が言った「相手の力を9引き出して10の力で勝つ」というやつです。

ただ、ちょっと違う点としては、、、

相手の力を9引き出すのではなく、10引き出す

要は、相手の抱える不安や生の感情やら、全て引き出した上で問題解決できれば良いかな、と思います。

勝ち負け関係なく、ただ前向きに白熱すれば良い

最終的に、問題解決は本人にしかできないんですよね。

そのために、ネガティブな意見が出てこないように、前向きに話し合うことができたら、あとは勝手に問題解決してくれるんじゃないかと思います。

もちろん、答えが欲しいなら、答えを言っちゃうこともできますが。。。 そりゃあ、しょっぱい試合だった時は、そういうこともしますw

最後に

自分が提唱する「ストロングスタイルな問題解決」を、今回事例も踏まえてブログに書いてみました。

それがいつでもできる訳ではないですが、そんな風に意識して今後相談を受けてたちたいと思っています。

『ゆるファシ』体験ワーク、からの今年の抱負

NaITE #26 『ゆるファシ』体験ワークショップに参加してきました。

nagasaki-it-engineers.connpass.com

  1. ワーク体験
    やった事をざっくり、、、

    • グループ内で各個人が抱える問題を1つ説明して共有する。
      その時の背景や細かい状況は付箋にメモする。 話しているうちに別の問題が明らかになったら、新しい問題にする
    • 各人の問題点について、違いを捉えてみる
      違いを見つけるのは難しいので、最初に共通点を見つけてから、違いを見つける方が良いらしい。　
    • 違いや話した内容から、自分が解決したい問題を特定して、解決するためのアクションを決める
      グループ内で解決したい問題とアクションを宣言しました。

  2. 成果物
    自分の成果物はこんな感じ。
    「自分の作業の進捗が思ったように進まない」問題だったのですが、
    グループで共有しているうちに、「自分が始めた仕様のトレーサビリティの改善が定着しない」ことに気づいて、
    最終的な問題は「改善を進めた結果、自分の負荷が高くなっている」になりました。 アクションは、「他の人に任せられるようにする」です*1 f:id:kabe-aa:20180121121541j:plain

  3. 雑感
    自分が問題解決する際、TOCfEのツールを使って自分が感じた違和感を問いかけるように、本当の問題を見つけるようにしていますので「ゆるファシ」は、自分のやり方にしっくりきました。 でも、ゆるっとファシリテーターの、あのゆるさは正直真似できないなぁ(褒め言葉w

  4. 今年の抱負

実は、今年初めにマインドマップに抱負を起こしていたので、便乗して紹介(笑 f:id:kabe-aa:20180121121531p:plain

  • 会社に対する目標
    「業務時間に余裕を作る」の一つに「他人に作業を委譲する」って書いてたw
    あと、今年は勉強会を開催して、社員を向上していきたいかなぁ。

  • 個人の目標
    今年はプロジェクト管理のために、本格的にスクラムを学んでみようかと。 そのために、色々情報を仕入れている最中です。

*1:変えるときは、まずメンバーに合意とろうよ、自分(^^;;

2017年を振り返る

今年を振り返った。けっこう駄文w

f:id:kabe-aa:20171231102424p:plain

  1. 会社への計画

    • 自分の作業に余裕を作る
      6月あたりから、ほぼ上流設計しかしなくなった。けど、システムの要求仕様まとめるだけで今年は終わった。 。。 そもそも工数の都合でやってなかったので仕方ない… 要求仕様作成の経験者がいない、ってのも… まぁ、良い経験させていただいております(^^;;

    • 社員レベルの向上
      詳細設計、実装、(今までのレベルで)のテストは別の人に任せることができた。ただし1人だけど。
      今の問題は、自分に設計が依存してしまうこと。
      「どう設計してほしいか分からない」と言われるので結局自分で設計する羽目に。むー（；￣ェ￣）
      設計意図を伝えるような書き方を意識してたけど、自律的に向上させるためには、別の方法でサポートした方が良さそうです… 　　

    • 開発プロジェクトの改善
      当初やろうとしたことは手付かず…
      というか、グループ内の仕事改革が起きて、仕事の仕方を見直す場ができた。
      前半でキレて良かったかな(よくない笑

  2. 自分の目標

    • テスト力の向上
      今年は、某塾やモデルベーステスト自動化の分科会、他にも色んな勉強会に参加したので、色々学ぶことが多かった。
      (テスト設計ではなく)機能設計にはだいぶ反映されているかなぁ。。。アウトプットできる成果は今のところないけど。。。 　
    • 設計力の向上
      機能開発以外は、ほとんど他人に任せた、と思う。 その分、他人の設計を読み取る力も身についた。 　
    • 問題解決手法を学ぶ
      今年初めにTOCfEに出会ったのは大きいかも。 あと、エニアグラムの講習を受けた事で、自己理解・受容できるようになった。 自分が感じた違和感を適切な方法で伝えられる、良い方法を一緒になって考えられるようになった事は、今年一番の成果だと思います。 　

  3. 当面の業務
    1つは完成して、必要に応じてアドバイスする程度なので、手離れできた。
    もう一つは、システムアーキテクチャごと変更してるので継続中…という言い訳してるけど、やっぱり見積もりは甘かったなぁという感想。
    でも、今一番欲しいスキルは、見積もりというより、メンバーの力をうまく引き出す方法ですかね。

  4. 最後に
    今年は、『ながーいトンネルの中でようやく光が見えた気がする』一年だった
    多くの出会いと学びをいただいて、皆さんに感謝です。
    来年もよろしくお願いします！

9人のテストエンジニア

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

qiita.com

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

エニアグラムについて

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

f:id:kabe-aa:20171218103419p:plain
エニアグラム

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

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

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

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

タイプ1：改革する人(本能:ガッツセンター)

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

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

タイプ2：人を助ける人(感覚:ハートセンター)

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

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

タイプ3：達成する人(感覚:ハートセンター)

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

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

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

タイプ4：個性的な人(感覚:ハートセンター)

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

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

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

タイプ5：調べる人(思考:ヘッドセンター)

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

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

タイプ6：忠実な人(思考:ヘッドセンター)

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

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

タイプ7：熱中する人(思考:ヘッドセンター)

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

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

タイプ8：挑戦する人(本能:ガッツセンター)

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

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

タイプ9：平和をもたらす人(本能:ガッツセンター)

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

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

最後に

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

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

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