テスト実行者の技術的専門性と生み出す価値
はじめに
本記事なテスト実行フェーズを主に担っている「テスト実行者」というロールに焦点を当て、その技術的な専門性について思っていることを記載します。
また、「テスト実行者」は専門性の高さに関わらず、低単価で扱われることが多いです。ついでにその点についても考察します。
本記事の趣旨は「テスト実行者はそれはそれで高いスキルが必要なんだよ」ということを記載する記事であり、「低単価で扱われる」ことに理由付けすることが目的ではありません。
そのため、最後に「テスト実行者というロールが低単価を脱するには」についても考察いたします。
必ずしも答えは出ないかもしれませんが、試しに書いてみます。
テスト実行者ってなんなの？
「テスト実行者」とは「テスト実行」を専門的に担う人々です。
レガシーな現場では「テスター」とか「テストオペレーター」と呼ばれたりします。
テスト実行とは
テスト実行とは、実際のソフトウェアを動作させて、そのふるまいを確認して、明示的あるいは暗黙的な期待結果と照合し、合否判定あるいはそれによるFBをどこかに与えることです。
特に本番環境に近い状態で実施する「システムテスト」のテスト実行は一般的には時間がかかり、場合によっては実施するための準備にも手間と時間がかかります。
「準備」に関してはテスト設計やテスト環境構築などの専門のタスクや技術があったりしますが、ここでは詳しく触れません。
テスト実行はコンポーネントやモジュール単位の単体テストやサービス単位の結合テストでも用いられますが、特に単体テストはソフトウェア設計やソフトウェア実装と同時に実施されることが多く、比較的テスト実行には時間がかからないと言われています。
また、それらのテストに「テスト実行者」というロールが割り当てられることをあまりみたことがありません。
この後のパートでの「テスト実行」とは「システムテストでのテスト実行」について述べようと思います。
テスト実行者の必要性
(システム)テスト実行というのは前述のとおり、最も工数のかかる活動のひとつです。
テスト実行は何かのタスクと並行して実施することは困難です。
手と目と場合によっては耳とか他の五感をフル稼働させて、ソフトウェアのふるまいを確認するからです。
また、多くの場合はテスト実行による「不具合」(色々な呼び方をしますが、ここでは期待結果との差異を不具合と呼びます)が発生し、単純にソフトウェアの動作を確認するだけでなく、レポートやふるまいの分析といったタスクが随時発生します。
これらのタスクを安定的に捌くためにも、「テスト実行者」というテスト実行を専に行うロールが必要になることが多いです。
テスト実行者の専門性
体系的な整理についてはIVECという認証試験のシラバスが詳しいです。
また、解説についてはK.AさんのZennが参考になると思います。
以下からは私が考えるテスト実行者の専門性について記載してみます。
決してMECEではない点をご注意ください。
言語化する力
テスト実行において私が特に重要だと思うスキルは「言語化する力」です。
テスト実行によって得られた不具合を端的に表したり、暗黙的な期待結果との差異で得られる「違和感」などの「違和感」で留めずに、きちんと根拠と客観性を伴って報告する言語化の力が重要になります。
「不具合報告」はテスト実行の要であり、最も重要な成果物の一つと言ってもいいでしょう。
ここでいう言語化とは、文書の正確性もありますが、速さも重要です。
テスト実行を遅延させず、素早く正確な言語化を実施して、すぐさまテスト実行に戻るアジリティも大変重要なスキルになります。
分析する力
言語化する力と近いものがありますが、実際の動作を分析する力も必要になります。
不具合を発見した時の切り分け力に関係すます「どうしてこのような動作をしてしまったのか？」などの条件を整理して、実際に試し、最低限の手順を示すような分析力がテスト実行者では必要になります。
製品から学び、テストすべきことを導く力
これは割とプラスアルファな専門性です。
いわゆる探索的テストの能力に近いでしょう。
要件定義やテスト設計成果物だけでは読み取れない、製品独自の動きや、実際のエンドユーザーのニーズを認知、想像して、実際にテストを実行し、暗黙的な期待結果と照合を行う力です。
これらは分析する力や文書化の力と密接に関わり、テスト実行の内容からテストケースを導くような、本来の意味での探索的テストのスキルに繋がったりします。
文章の理解と手の速さ
テスト実行する場合、多くの場合にテスト計画書、テスト仕様書やソフトウェア設計仕様書、要件定義書などの文書を読む必要があります。
これらを素早く読んで、理解し、テストすべきことや、あるべき姿などを理解してテスト実行に臨むことが必要になります。
また、実は手の速さを重要になります。
文書化の際のタイピングの速さもありますし、狙った動作を狙った手順で行うために慎重さと素早さを兼ね備えた手の速さはテスト実行者の大きな武器となります。
その他、雑多なスキル
他にも色々ありますが、IVEC見たらいい気がするので箇条書きで適当に書きます。
ステークホルダと報告連絡相談するヒューマンスキル
自分のタスクを整理したり計画し、実行するタスク管理スキル
テスト環境について正しくセットアップするためのITスキル
社会人として必要以上にサボらない倫理観
テストエンジニアとして開発者を見下さないリスペクト
テスターとして不具合を見逃したり品質不正をしない正義感
テスト実行の価値
テスト実行者は度々低単価で扱われます。
またその成果物についてもあまり価値を見出されません。
その点について考察します。
不具合報告書の寿命が短い
テスト実行によるアウトプットの一つに「不具合報告書」がありますが、これらは基本的にはソフトウェア設計書のように長生きするドキュメントではなく、基本的にはなるはやで対策され、クローズされる運命になります。
どれだけテスト実行者がこだわって不具合報告を行なっても、直す側はそんなに意識せず対策し、チケットはクローズされます。
不具合報告は他のロールの手柄へ
不具合報告は不具合の対処以外にも様々な用途で使われます。
典型的には不具合分析や、ブロックなどによるテスト進捗報告、不具合摘出によるプロダクトリスクや被害の低減などです。
ただ、それらの活動はテストマネージャーやテストアナリストといった別の専門性を持つロールの手柄として扱われ、テスト実行者がどれだけ工夫をしても上記のロールの手柄として吸収される運命になることが多いです。
意外と誰でもできるテスト実行
私は「テスト実行者の専門性」として挙げましたが、これらの専門性を求める人は少ないです。
それよりも「安い単価でさっさとテストケースを消化してほしい」というニーズが高いように思えます。
システムテストのテスト実行は、基本的なコンシューマ向けの製品であれば、割と誰でもテスト実行が可能ですし、そうでなくでも要件定義書やマニュアルなどで、操作方法は自明だったりします。
そのため、「テスターとして不具合を見逃したり品質不正をしない正義感」と「最低限テスト実行する仕事力」があればテスト実行者として十分と思っている組織も存在したりします。
「テストすべきこと」はテスト設計(開発)の時に考えること？
テスト実行の中でテストすべきことが導出されたりしますが、基本的なメインストリームでは「テスト設計フェーズ」が設けられており、その時にテストすべきことを考えるケースが多いです。
そのため、テスト実行時に「テストすべきこと」を見つけるという思想があまりなく、やはり「誰かが考えるテスト設計を消化する」というニュアンスが強かったりします。
ちなみにそうでない考え方も存在します。
Context Driven Testingが詳しいです。
それでもテスト実行を愛する
私は最近TEコンサルタントとして、テストのマネジメントやテスト設計技術の導入などのロールを担うことが多いです。
それでも私はテスト実行が一番好きですし、愛しています。
「テスト実行」の儚さ
前述しましたが、テスト実行の成果物の一つである「不具合報告書」はどれだけ細部をこだわっていても、どれだけ工夫して早く報告しても、「ふうん、直さなきゃなあ」って感じで普通に直されて普通にクローズされることが多いです。
また、テスト実行が早くなったとしても、芸術的なソフトウェアアーキテクチャの実装とかと比べると、そんなに早くなりません。せいぜい数割が目安でしょう。
そんな細部にこだわったテスト実行が軽く扱われ、軽く処理されること自体を私は憂いていません。
むしろ侘び寂びの一つとして趣深いなあとすら感じています。
職人のこだわりみたいなものですね。
「テスト実行」が一番学びが深い
「テストプロセス」と呼ばれるものは概ね経験しましたが、私は「テスト実行」に最も学びを感じます。
実際の製品がどのように価値を届けているのか、製品の機能的な構造、テストでの発見など、様々なメイクセンスを得られます。
なので私はリーダー的なロールではありますが、テスト実行は忘れずにしようと考えています。
実際に私は「毎日製品を触る会」を実施して、毎日強制的に製品を触る時間を設けています。
ちなみに毎日何かしらの指摘(機能的なバグもあればマニュアルへの指摘やUXの指摘など様々)出しています。
それは私が優秀なDirty Testerだからです。(ドヤ)
テスト実行者というロールが低単価を脱するには
このタイトルを考えている時点では考えていませんが、書きながら考えます。
アウトプットの価値を高める
アウトプット自体の価値を高める必要があると思いました。
これらはテスト仕様書を実行するようなテストであっても、どのようなテストを実行することで、どれだけの価値を高められたか、プロダクトリスクを低減できたかの客観的な指標が出せたらいいと思いました。
また、テスト実行によってテスト設計や要件定義へのフィードバックができるといいと思いました。
これらを成り立たせるにはやはりジュニアとしてのテスト実行者ではなく、ある程度知識があると思われた上で「あえてテスト実行しています」みたいな印象を持たないと厳しいかも？と思いました。
Context Driven Testing
テストは本来的に製品から学習しながら行うというある種逆転的な発想です。
これらは価値観に支えられていますが、「優秀なテスター」の存在によって、クリティカルなバグを出し続けたり、「品質に対する自信」をとり続けるようなふるまいによって、テスト実行者の価値が上がるようにも思えます。
一方、私はテスト対象からの学習をしても、それは製品をリリースするためのボトルネックになる時間を増やすだけではないか？と懸念したりします。
その点について、探索的テストのエヴァンジェリストの人はどう考えているか知りたいです。
おわりに
テスト実行に対する考えをちょっとだけ記載してみました。
だからどうというわけでもないですが、誰かの助けになれば幸いです。
この記事が気に入ったらサポートをしてみませんか？