『練習帳』の問題を解きながら、デシジョンテーブルと組み合わせテストの位置づけについて考える

　『ソフトウェアテスト技法 練習帳』の第4章「組合せテスト」*1を解き終えました。

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

　仕様の文章内に因子と水準が明示されているケースだけでなく、ラルフチャートを用いた因子・水準の洗い出しや、既存の仕様からの差分に着目したテスト設計などの応用にも手を伸ばしています。
　またPictMasterの使い方についても、制約条件・エイリアス・サブモデル・原型シートの機能を使えるように問題が設計されており、とてもバランスの取れた章だと思います。

　ということで、また「わたしはこう考えた」のコーナーです。

問題の内容

　問題4.5は、健康診断申し込みシステムです。
　性別、年齢に加えて、任意で追加できる検診項目（眼底検診、メタボ検診、婦人科検診、脳検診）を選んで「申込」するというもので、以下の制約があります。

• メタボ検診と婦人科検診は、年齢が35歳以上の人のみ選択できる
• 脳検診は、年齢が45歳以上の人のみ選択できる
• 婦人科検診は女性のみ選択できる

　問題としては、「2因子間網羅のテストを行う」なのですが、この仕様を見て最初に頭に浮かんだテスト技法は、組み合わせテストではなく決定表でした。各因子がとる水準の組み合わせによって、システムの挙動が変わるためです。

デシジョンテーブルと組み合わせテストの目的

　デシジョンテーブルを書くと、こんな感じでしょうか。*2

デシジョンテーブル

　ところでこのデシジョンテーブルは、何を確認するためのテストなのでしょうか。
　それは、「プログラムの実行結果が、因子の組み合わせに依存する」仕様の確認です。
　たとえば「年齢」が同じ40歳であっても、婦人科検診を選択可能かは「性別」に依存します。この組み合わせならこれを選べる、あの組み合わせならあれを選べない、と組み合わせを確認していくのが、デシジョンテーブルでのテストです。いわゆる「有則のテスト」ですね。

　一方この問題で取り扱っている組み合わせテストは、「プログラムの実行結果が、因子の組み合わせに依存しない」仕様の確認です。　
　男性でも女性でも、20歳でも30歳でも40歳でも50歳でも、性別と年齢の具体的な値の組み合わせに関係なく、同じように「眼底検診」を選べる、ということを確認していくのが、組み合わせテストです。いわゆる「無則のテスト」です。

　ただしこの問題では、組み合わせることのできない制約（または「禁則」）があります。組み合わせ生成時に、これらの制約に相当するパターンが現れないようにしています。
　決定表で赤字のXになっている部分が、禁則に相当します。組み合わせに現れない（ようにしている）ため、個別に確認することを忘れないようにしなければなりません。

デシジョンテーブルと組み合わせテストのケースの比較

　上の決定表と同じように因子・水準と制約を設定して*3オールペアの組み合わせを生成すると、以下のようになります。

2因子網羅

　デシジョンテーブルにおける因子の全組み合わせ30パターン、うち許容される20パターン（〇）に比べても、2因子網羅は12ケースと絞り込まれていることがわかります。ただこれくらいなら、デシジョンテーブルに基づいて全組み合わせを確認してもよさそうですね。

　問題は、各因子の水準が多い場合です。
　練習帳では、「年齢」因子に、7つの水準を使っています。今後「任意追加項目」因子の水準も増えることを考えると、組み合わせテストによるテストケース削減が威力を発揮します。
　ただもちろんこれは、デシジョンテーブルの〇部分がすべて同じふるまいをする（つまり因子の組み合わせに依存しない）場合の話です。組み合わせによってふるまいが変わる場合は、それぞれの組み合わせをデシジョンテーブルで確認する必要があります。

ついでに、水準の選び方について

『ソフトウェアテスト技法練習帳』は4.5でひっかかったままだったんだ。「20～34、35～44、45～60」で同値分割するのは理解できたんだけれど、これを
20～33、34
35、36～43、44
45、46～60
に分けるのが納得いかず悶々。34は境界値として特別扱いするのに、20と60をそうしない理由は？ 優先度が低い？

— Kazu SUZUKI (@kz_suzuki) 2020年6月13日

　こちらでも言及したのですが、制約に基づいて「年齢」因子を「20～34、35～44、45～60」で同値分割するのはいいとして、水準として

• 20～33、34 (上限とそれ以外) → 代表値は 20、34
• 35、36～43、44 (上限と下限とそれ以外) → 代表値は 35、36、44
• 45、46～60 (下限とそれ以外) → 代表値は 45、46、60

を選んでいるのはどうも一貫性がなく、解せない点です。境界値を別の同値クラスとするのであれば、

• 20、21～33、34 (上限と下限とそれ以外) → 代表値は 20、30、34
• 35、36～43、44 (上限と下限とそれ以外) → 代表値は 35、40、44
• 45、46～59、60 (上限と下限とそれ以外) → 代表値は 45、50、60

のように選ぶべきではないのかなと。この辺はみなさんのご意見を伺いたいところ。

　以下、秋山さんご意見です。いつもありがとうございます。

私は、前者の「45、46～59、60」として、「46～59」をエイリアスにするのが良いと思っています。
45と60は境界値で、46～59はどれでも良いと判断した範囲だからです。

— あきやま🐾 🐾 (@akiyama924) 2020年6月13日

*1:わたしは「組合せ」「組み合せ」「組合わせ」ではなく、「組み合わせ」派です。

*2:デシジョンテーブルの形式が少し変かもしれない。「申込」ボタン押下時に挙動が判明するのであれば、検診項目も条件部の方に入るのが正しい。性別と年齢を選択した時点で「任意追加項目」で選択可能な値が変化するのであれば、この表でもいいかな。

*3:『練習帳』より因子が粗いです。

状態遷移テストの ignore と not happen について、astah*とともに整理してみる。

　先日の記事で、状態遷移テストのカバレッジについて書きました。

www.kzsuzuki.com

　この記事のために利用させていただいている、モデリングツール「astah*」。このastah*で描く状態遷移表に用意されている、ignore と not happen という選択肢について、astah*内での位置づけと、テストの要否について考えてみました。

　なお本記事は、Twitterにおける秋山さんとの以下のスレッドをベースにしています。

例えば電卓で1を押し続けたときに、それを無視するのと「111…」とイベントを処理して同じ状態に戻るのとは違います。
後者についてNスイッチでテストするとカバレッジ率が上がることは当たり前と思うのですが、前者（1を押し続けても初めの1しか受け付けず捨てる）のときどうなるのかなと思いました。

— あきやま🐾 🐾 (@akiyama924) 2020年5月6日

ignore と not happen

　前回の記事に書いた通り、ignore と cannot happen はおおむね、以下のような意味を持っています。

• ignore: 当該イベントが発生しても、発生しなかったように扱う。
• cannot happen: 当該イベントは発生しえない。

　似ているように見えますが、前者は「イベントが発生しうる」、後者は「イベントが発生しえない」ので、根本的に違いますね。

　例を挙げて説明してみます。
　会社なんかでよくある「カードタッチで解錠するドア」を考えましょう。ざっくりこんな仕様。

• 内側からは、タッチなしで開けられる。
• 外側からは、タッチで解錠したうえで開けられる。
• ドアが開いたまま、最後のタッチから一定時間経つとアラームが鳴動する。
• アラームは、カードタッチすることで停止する。
• アラーム鳴動中はデッドボルトが飛び出しており、そのままドアを閉めることができない。アラームを止めてデッドボルトが引っ込んだ状態にしたうえで閉じる必要がある。

　5個目の長くてわかりづらくて不自然な仕様は、説明のためだと思って受け入れてください。平行線公準のようなものです。

　ステートマシン図は以下のようになります*1。

ステートマシン図

　astah*で自動生成してくれた状態遷移表は、以下の紫セル。
　白セルは、個別に埋めていく必要があります。ここに書かれた ignore と cannot happen の意味を考えてみましょう。

状態遷移表

ignore と自己遷移

　ignore は2つのセルに書かれています。

• ドアが施錠された状態で、外からドアを開ける。
• アラームが鳴動している状態で、外からドアを開ける。

　これらのケースでは状態が遷移しないだけでなく、何も起きません。

　一方、以下のセルはどうでしょう。

• ドアが開いた状態で、カードタッチする。
  • 「ドア開＆鳴動なし」×「カードタッチ」→「ドア開＆鳴動なし」

　これも同じ状態に留まりますが、アラームが鳴るまでの時間経過をリセットするアクションが内部で動いていると考えられるため、「同じ状態に遷移した」と解釈するのが妥当でしょう。

cannot happen の区別

　cannot happen はけっこう出現していますね。
　たとえば以下の2つは、まさに「起こりえない」イベントといえます。

• ドアが開いている状態で、外からドアを開ける。
• ドアが閉じた状態で、ドアを閉じる。

　一方、以下はどうでしょうか。

• アラーム鳴動中に、ドアを閉める。

　これは確かに「仕様上は起こりえない」ことになっていますが、原理的に「起こりえない」イベントではありません。実装が間違っていて、仕様通りにデッドボルトが飛び出さなかったら、「閉じ」れてしまう可能性があります。この種のイベントは、cannot happen というよりは、should not happen とでも扱うのいいのかもしれません。ともあれ、2つを区別する必要があるでしょう。

状態遷移表のセルのパターン

　以上の話を整理すると、以下の5つのパターンに分けられます。

1. イベントが発生すると、別の状態へ遷移する。(遷移)
2. イベントが発生すると何かが起きるが、同じ状態にとどまる。(自己遷移)
3. イベントが発生しても何も起きず、同じ状態にとどまる。(無視 = ignore)
4. イベントが発生しないことになっている。(仕様的不可 ∈ cannot happen)
5. イベントが原理的に発生しない。(原理的不可 ∈ cannot happen)

　カッコの中の日本語は、ここで暫定的に付けた名前です。ちゃんとした呼称があるかも。

　ではこの5つのうち、状態遷移テストで検証すべきものはどれでしょうか。
　a.とb.は「遷移」そのものなので、当然確認する必要があります。e.は起こすことができないのですから、そもそも検証不可能です。

　c.はどうでしょう。イベントを起こすことができるので、「本当に無視するか」を確認する必要がありますね。
　d.も考え方は同じです。「本当にイベントを起こせないか」を確認する必要があります。

カバレッジで網羅されるパターン

　astah*のプラグインで導出される状態遷移パスを確認してみましょう。

状態遷移のパターン

　導出された「遷移回数=1」の13ケースの遷移に、「無視」パターンも含まれていることがわかります。「遷移回数=2」でも同様で、ignore が2回続く（そして2回とも無視される）パターンも含まれています。

　一方で、cannot happen については、「仕様的不可」と「原理的不可」の区別がないため、起こりえない＝テストできない とされ、テストケースに含まれません。
　よってスイッチカバレッジのテストを行う際には、「起こりえない」がどちらのパターンなのかを峻別したうえで、「仕様的不可」については「仕様通りに動作する（イベントが発生しない）こと」を個別に確認しなければなりません。

*1:ツッコミどころはあるかもしれない。ドア開での「一定時間超過」とドア閉＆解錠での「一定時間超過」を同じイベントとして扱っていいのか、とか。

英単語の発音を様々なシチュエーションで聴いて学ぶ、Youglish

　英語の勉強についての雑談です。

　英単語の中には、どうも発音がしっくりこない！というものがありますよね。
　ここ最近で思い当たるのは、rationale。rational だと「理性的な」「合理的な」という意味ですが、e が付くと「論理的根拠」「理由付け」みたいな意味になります。
　ちなみに発音記号を見てみると

• rational　rǽʃənəl
• rationale　ræ̀ʃənǽl

　・・・いや、わからんて。「伸ばす」っぽいことくらいでしょうか。

　そういう時に、発音を調べるだけならオンライン辞書でもわかります。たとえば Cambridge Dictionary ですね。

dictionary.cambridge.org

　さらに、「文章の中での使われ方」も含めて知りたいときに有効なのが、YouGlish。
　無数にあるYouTube動画から、その単語を使っているタイミングを次々に見られるWebサービスです。

youglish.com

　キャプションも付いている*1ので、文脈もわかりやすい。
　TEDや著名人による演説が多いので、面白そうならそのまま観てもいいと思います。
　画面イメージはこんな感じ。

YouGlishのイメージ

　このサービスで、rationale は、気取った感じに「ラショナ～ﾙ」と伸ばせばまあそれっぽくなるのかなとわかりました。発音がうまくなるわけではないが・・・。

　また先ほどオンライン英会話で初めて出会った、furlough。floral っぽいから、お花関係かしら？うふふ…と思ったら、「レイオフ、自宅待機」。。。
　意味はともかく、発音もイメージできなかったんですよね。YouGlishで確認してみると別にそんなややこしくなくて「ファーロｩ」みたいな感じでなんですけど、聴かないとわかりませんでした。

　そんな感じで、「いろんな人による発音を、いろんな文脈で聴く」ことを目的として、Youglish、お勧めします。

　なお、発音を調べてみてわかった大事な気づきは、以下の2つです。

(1) really と rarely は、一生聴き分けられない。
(2) -based って、「ベースド」じゃなくて「ベースト」じゃない！？

dictionary.cambridge.org

*1:というか、自動キャプションを付けられるからこそ、単語を拾ってこられるのだろう思いますが。

状態遷移テストのカバレッジについて、astah*とともに整理してみる

　『ソフトウェアテスト技法 練習帳』のPart3「状態遷移テスト」の章で、カバレッジ基準の表現が2種類あることに気が付きました。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

　「1スイッチカバレッジ」と、「C1カバレッジ（遷移網羅）」という表現です。
　「C1カバレッジ」という表現はコードカバレッジの文脈でしか見たことがなく、状態遷移テストにおいてあたるのは初めてだったのでつぶやいてみたところ、秋山さんからコメントいただきました。

29119-4では、状態、0スイッチ、全パス、Nスイッチが定義されていて、0スイッチは有効パスだけです。
C1については、どこの定義を見たら良いか分かりませんが、『知識ゼロ』本あたりから、「N/Aもテストしよう」というのが広まっているように思います。

— あきやま🐾 (@akiyama924) 2020年5月6日

　これを機に、状態遷移テストのカバレッジ基準について整理しておきましょう。
　ちなみに、コードカバレッジについては以下で書いてます。

www.kzsuzuki.com

キャッツの方の連載における定義

　まずは、状態遷移テストにおける「C0」について調べてみましょう。
　浅く検索しただけではあまり見当たらないのですが、キャッツの塚田 雄一さんによるMONOistの連載「状態遷移表による設計手法」では、状態遷移表に基づくホワイトボックステストが解説されています。

monoist.atmarkit.co.jp

　この記事には「C0」「C1」という表現が出てくるのですが、状態遷移テストにC0・C1という網羅基準があるという話ではなく、コードカバレッジのC0・C1を、状態遷移表から簡易に導出することができるというお話です*1。

　この記事では、C0は命令網羅、C1は分岐網羅のことを指しています。状態遷移表におけるアクションを「命令」と見なし、これをすべて通過するようにテストケースを導出することで、命令網羅を達成できます。
　また、（後述のastah*でいう）「ignore」や「cannot happen」も含めてすべてのアクションセルをカバーするようにテストケースを導出することで、分岐網羅を達成できるという考え方です。

　いずれにせよ、『練習帳』でいう「C1カバレッジ（状態網羅）」とは違うものですね。

ISO/IEC/IEEE 29119 Part4における定義

　国際規格をのぞいてみましょう。
　ソフトウェアテスト設計技法を扱うISO/IEC/IEEE 29119 Part4では、状態遷移テストの網羅対象として、以下の4つを扱っています。

• 状態: モデルにおけるすべての状態に到達する。
• 単一遷移（0スイッチカバレッジ）: モデル内の有効な単一遷移をすべてカバーする。
• 全遷移: モデルにおける有効な遷移と無効な遷移をともにすべてカバーする。（無効な遷移とは、有効な遷移が指定されていないイベントによる遷移）
• 複数遷移（Nスイッチカバレッジ）: モデルにおける連続(N+1)回の有効な遷移をカバーする。

　「C1カバレッジ」はありませんが、「遷移網羅」に近いのは、「単一遷移」でしょう。
　また『練習帳』では「C1カバレッジ（遷移網羅）、および、遷移しない無効トリガー動作」と表現されています。これは「全遷移」に対応すると考えてよさそうです。無効な遷移は、『練習帳』では「N/A」、後述のastah*でいう cannot happen に相当します。

astah*によるモデリング

　いきなりですが、モデリングツール「astah*」で、問題3.5の状態遷移をモデリングしてみましょう。
　なおastah*は「新型コロナウイルスで働き方に影響を受ける皆様へ」という形で、暫定的な無償ライセンスを提供してくださっています。粋な計らいですね。
　今回はこのライセンスを使用させていただきます！

astah.change-vision.com

状態遷移図と状態遷移表

　描いた状態遷移図は以下の通り。問題の内容は、書籍を読んでくださいね！
　「超電磁バリア」→「超電磁バリア」の遷移は、あえて省いています。

状態遷移図

　ここから自動生成される*2状態遷移表は、以下の通りです。

生成された状態遷移表

　たくさんのセルが空白のまま残っています。別の状態に遷移しない場合、以下の2つのいずれかを入力します*3。

• ignore: 当該イベントが発生しても、発生しなかったように扱う。
  • たとえば、「超電磁バリア」中に「敵を発見する」*4。
• cannot happen: 当該イベントは発生しえない。
  • たとえば、「停止中」に「敵を発見する」。

　なお『練習帳』では、ignore は同じ状態への遷移（たとえば超電磁バリア→超電磁バリア）と扱われ、cannot happen は「N/A」と表記されています。

空白セルを埋めた状態遷移表

テストケースの導出

　さてastah*では、プラグインを導入することで、状態遷移表からテストケースまで導出することができます*5。その結果が以下です。

0スイッチカバレッジのテストケース

　遷移回数が「1」というのは、0スイッチカバレッジを意味します。
　状態遷移表の紫色をカバーすることで、0スイッチカバレッジ = 100% を達成できます*6。
　ただ上図を見てわかる通り、ここに現れるのは「有効な遷移」のみです。cannot happen セルは含まれていません。

　遷移回数を2にすると、1スイッチカバレッジとなります。
　状態→遷移→状態→遷移→状態 となっていることがわかります。
　遷移が2つ、状態が3つなのに「1」スイッチカバレッジというのは正直いまだにしっくりきませんが。

1スイッチカバレッジのテストケース

他の網羅基準

　さて、ちょっと余談。
　「遷移網羅」というのは一見、もっとも基本的な網羅基準にも思えますが、実はより単純な網羅基準があります。

• イベントカバレッジ: 定義されたすべてのイベントをカバーしている。
• 状態カバレッジ: 定義されたすべての状態をカバーしている。
• アクションカバレッジ: 定義されたすべてのアクションをカバーしている。

　まあそのままなのですが。
　たとえば以下のテストケースがあるとしましょう。

1. 状態「停止中」でイベント「スイッチを押す」を起こす
2. 状態「起動中」でイベント「敵を発見する」を起こす
3. 状態「超電磁バリア」でイベント「敵がいなくなってから30秒経過する」を起こす

　この場合、イベント網羅は100%(3/3)ですが、「停止中」に遷移するテストケースはないので、状態網羅は67%(2/3)になってしまいます*7 。さらに、有効な遷移5つのうち3つしか実行していないので、遷移網羅は60%ですね。

　また、ファンクションネットでは reachability という言葉が出てきました。指定した状態に到達できるか否かという話です。

www.kzsuzuki.com

　状態遷移テストでも、開始状態と指定状態を指定した場合に可能な経路の網羅など、遷移の数とはまた違う視点のカバレッジ基準があるようです。

*1:実際のコードではないので、「モデルベースのコードカバレッジ」とでも呼べるかもしれません。

*2:astah*素晴らしいですね。

*3:詳細説明は以下。 www.changevision.co

*4:この場合、30秒タイマーがリセットされると考えると、「無視する」とするのは適切でないかもしれません。

*5:astah*素晴らしいですね。

*6:秋山さんに指摘されて気づいたのですが、状態遷移表では紫になっていない ignore も含めてパスが導出されていますね。ignore を29119でいう「無効」と考えると、astah*における「遷移回数=1」のカバレッジは、29119における無効パスも含むと考えられます。全網羅に相当・・・？

*7:ここでは「遷移後」に状態が出てきて初めて網羅されたとみなしています。29119の状態網羅の定義に visited という言葉があるというのが、その根拠です。

【翻訳】テストにおいて避けるべき、6つのペルソナ

　Kristin Jackvonyさんのブログ「Think Like a Tester」に掲載されたポスト『Six Testing Personas to Avoid』を、許可を得て翻訳してみました。

thethinkingtester.blogspot.com

　「ダメエンジニアの類型」みたいな記事って、バーナム効果的に「どれも自分に当てはまるかも・・・」となって面白いので、反省のために読んでしまいますね。

テストにおいて避けるべき、6つのペルソナ (翻訳)

　エンドユーザ向けのソフトウェアを作っている会社で働いていれば、「ユーザペルソナ」について聞いたことがあるでしょう。ユーザペルソナとは、アプリケーションのエンドユーザの一つの側面を表現したものです。
　たとえば、自宅を改善するための製品のウェブサイトを作っている会社で働いているとしましょう。この場合、最初の家を購入したてで、自宅のこまごまとした点を直す経験はあまりない、「新居を買ったばかりのNick」が、ユーザペルソナの一つとなりえます。他には、家を自分でなんでも直せる経験をもつ、「DIYのDora」もペルソナになるかもしれません。

　わたしは最近、テストにおいてもペルソナというものがあるのではないか、と思いつきました。ただこれらのペルソナは、ユーザペルソナとは違って、わたしたちが避けるべきものです！ 当てはまるペルソナがないか、読んでみてください。

1. テスト手順派のTed (Test Script Ted)

　Tedはテストを手動で行い、終わったときにチェックマークを付けることが大好きです。テストが通ったことを見ると、満たされた気持ちになります。
　アプリケーションがどう動くかを理解しているかどうかについては特に気にしていません。言われたことをすることで満足してしまっています。アプリケーションがどう動くかを理解していないので、時に重大なバグを見逃します。おかしな動きを見かけても、テスト計画の中で扱われていないので、問題なしとしてしまうのです。彼の仕事はテストすることであり、物事を理解することではない、というわけです。

2. 自動化のAnnie (Automation Annie)

　Annieは自分のことを、自動化エンジニアを見なしてます。手動テストは大きな時間の無駄であり、もっと難しいこと―――自動テストの作成と保守にのめり込みたいと考えています。
　新しい機能が作られても、探索的テストに時間を割いたりはまったくしません。すぐにコーディングを初めて、自分の素晴らしい自動化によってどんなバグでも見つかると考えています。

TedとAnnieの共通点

　TedとAnnieは、違う理由で同じ失敗をしています。二人は、アプリケーションがどう動くかを真に理解するために時間を費やしていません。二人とも、理解不足からバグを見逃しているのです。Tedはフィーチャを動かすコードを理解せず、Annieはアプリケーションのユースケースを理解していません。

TedやAnnieにならないために・・・

　しっかりとしたテスターたるもの、フィーチャがどのように動くかを理解するために時間を使うことが重要です。手で試して、その制限を探索してみましょう。他にテストしようがないかを探るために、コードを覗いてみましょう。理解できない部分があれば、質問を投げてみましょう。

3. プロセス屋のPatty (Process Patty)

　Pattyは品質に情熱を持っています。物事が正しく動いていることを好みます。ですがそれ以上に、プロセスと基準があることを愛しているのです！
　 テスト計画とメトリクスを持ち込み、自分のチームは一語一句それに従うと思っています。探索的テストの前にリグレッションテストが完了していなければならず、そのリグレッションテストは大量にあります。問題は、隔週でリリースするにあたり、探索的テストを行う時間がないということです。プロダクトをテストする新しいやり方はないか、見逃していることはないかと立ち止まって考える余裕もありません。リグレッションテストがすべて終わっていることが必要なのです。

4. 深掘りしすぎのRay (Rabbit Hole Ray)

　Rayもまた、品質に対して熱い思いをもっていて、バグを見逃したくないと思っています。ですので、IE10でアプリケーションを動かしてみて何かおかしな点が見つかれば、何が悪いのかを解明しようと心に決めます。調査に何日もかけ、ログを見て、別の構成のシナリオでも再現しないか試します。フィーチャがリリースされようというときに、標準のリグレッションテストを終わらせずに放置していたとしても、関わりたがりません。IE10を使っているのが顧客のわずか1%だということなど、気にもしません。謎を解こうとするのです！

PattyとRayの共通点

　PattyとRayはともに、時間を無駄にしています。第一の目的、つまり「最低限の欠陥で、良いソフトウェアを、期日通りにリリースする」こと以外にフォーカスしているのです。
　Pattyはプロセスに捕らわれ過ぎて、新しいバグを見つけうる探索的テストの重要さをわかっていません。Rayは自分が探索している難しいバグに取りつかれ過ぎて、もっと多くのユーザに影響を与える重要なテストを無視してしまっています。

PattyやRayにならないために・・・

　新しいフィーチャをテストしたり、既存のフィーチャのリグレッションテストを行う場合、もっとも大きなインパクトを与えるテストが何かを考え、それに応じてテストを計画することが重要です。プロセスに捕らわれ過ぎないように気を付けましょう。また調査中の捉えづらいバグがエンドユーザに大きな影響を与えそうにないのであれば、放っておきましょう。

5. 仕事の安定が一番のJim (Job Security Jim)

　Jimは今のポジションで何年も働いており、自分たちのアプリケーションのことを知り尽くしています。もっとも古いフィーチャがどのように振る舞うかといったどんな疑問に対しても、頼りになります。会社が自分を手放すことはできないとわかっています。わかり過ぎていると言えるでしょう。
　ですので、新しいスキルを学ぶ理由はあるとは思っていません。今のところ、彼の知識で十分やっていけるのです。仕事が終わった後に、最新のプログラミング言語やテストツールについて勉強したりすることなど、時間の無駄にしか思えないでしょう。

6. カンファレンス好きのConnie (Conference Connie)

　Connieは技術が大好き！ 最新のテスト技術や開発のトレンドについて話を聞くことが好きです。ウェビナーに参加登録し、カンファレンスに行き、ブログ記事を読み、オンラインコースを受講します。あらゆることについて、ちょっとだけ知っているのです！
　ですが新しく学んだことを実際に導入したことはまったくありません。カンファレンスやウェビナーに行くのに忙しくて、通常のテストのタスクをこなす時間しかないのです。それに加えて何かに取り組むというのは大きな仕事。他の人がどのように取り組んでいるかを見るだけの方が、楽です。

JimとConnieの共通点

　JimとConnieは一見、まったくの逆に見えますね。Jimは新しいことを何も学びたくはないし、Connieは新しいことなら何でも学びたい。ですが抱えている問題は同じです。テスターとして成長していないのです。
　Jimはすでに知っていることだけで満足していて、それ以上何かを学ぶ理由が見つけられません。ですがある日、会社がソフトウェアの書き直しを決め、突然新しいスキルが必要になったら・・・・彼はショックを受けることになるでしょう。
　Connieもたくさんの良いアイデアを持っているのですが、試してみないことには何の意味もありません。知識を実業務で使おうとしていないのですから、会社に何の利益ももたらしていないのです。

JimやConnieにならないために・・・

　新しい言語、ツール、技術について学ぶことで、テストの技術を維持することが重要です。世の中のすべてを学ぶ必要はありません。今の会社に一番メリットがあると思えるものをいくつか見繕ったうえで勉強し、一つ二つの領域でそれを実践してみましょう。あなたが導入したソリューションに、チームメイトは感謝してくれるでしょう。次のポジションに向けて、あなたの市場価値を向上させることにもなります。

ペルソナではなく、素晴らしいテスターでありましょう！

　わたしたちは誰でも、時にはこういったペルソナになってしまいます。ですがそれを意識していれば、自動化のAnnieや深掘りしすぎのRayや、他のどれかに陥りそうになっても気づくことができます。
　素晴らしいテスターは誰よりもアプリケーションについて学び、どんなテストをいつ行うかを正しく決め、テストをより良いものにし続けるために、自分のスキルをアップデートを継続するのです。

この記事を読んでみて

　正反対に見える2つのダメペルソナが、実は根本的には同じ間違いを犯している、という分類が面白いですね。
　また意外に、「ソフトウェアプロジェクトでのめんどくさい人の扱い方」とあまりかぶらないんですよね。

www.kzsuzuki.com

　最後に書かれている通り、誰もがこれらのダメペルソナになりうると思います。わたしは劣化版Connie（少しのことについて少しだけ知っている）になりがちかな・・・。
　良きエンジニアでいるために、アンチパターンを時々振り返るのは、いい習慣かもしれませんね。