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