Encraft #13 に参加して感じたこととか

株式会社ナレッジワークさん主催のイベント「Encraft #13 QA Enablement - Insight by QA activity」に参加してきました。 自組織の課題と照らし合わせて、様々な気づきがあったので、自分用のメモとして記していきます。

knowledgework.connpass.com

登壇者はもとい、参加者にも業界内で著名な方が数多くいらっしゃっており、イベント参加メンバーだけでJaSSTが開催できてしまいそうなメンツですよね。

「品質保証からの情報提供」について考えよう

1つ目のセッションは、ナレッジワークkoyaman(小山)さんからのバグ傾向Dashboardに関するお話でした。

イベントの前日にバグ傾向Dashboardに関してのBlogを公開してくださっていたので、内容が理解しやすかったです。

zenn.dev

発表の中では、テストにより「知ったこと」を“誰かに”伝え、“誰か”が動けるようにするために、5W1Hのフレームワークを使って整理していきましょうというお話がありました。

過去の自分にも思い当たる節があるのですが、新しいツールを導入するときって、Howの部分ばかりが先行しがちです。
導入した結果誰がどのように嬉しいのかが置いてきぼりになりがちなんですよね。

完成形ではないとは言え、2週間でシュッとこのDashboardを作れるスキルもすごいと思うのですが、
Howに寄りすぎず、一歩引いてWhoやWhyを考えて実現されているのが素晴らしいと思いました。

私は自組織の課題と照らし合わせて次のようなことを考えながら聞いていました。

Dashboardを作る際には当然メトリクスが必要になります。
ただ、ある程度組織が大きくなってから「全社的に」とか、「部門全体に」とかチームを跨いでDashboardを作成しようとすると、
チームごとに使用しているBTSが違ったり、フィールドがなかったり、分類が違ったりするので、共通のDashboardを作ることが実質的に困難になります。
はい、今まさに私が所属している組織がそんな状況です。

ナレッジワークさんは品質へのこだわりが高く、開発者により検知したものも含めてバグをJIRAに起票するプロセスが根付いてるからこそ、実現できたとのことでしたが、
ある程度、チーム毎のプロセスが固まってから、それを変えるのは相当な覚悟と勇気と努力が必要になります。 なので、どんなに混沌とした状況(例えばスタートアップのようにとにかく早く価値を提供し、利益を出さないといけない状況)であっても、バグの管理の方法や、そこで付与する属性・値というのは統一しておくべきだなと感じました。
今のところ、1人目のQAになるつもりはないですが、そのときのために。

そして、上記のようなことを考えると同時にいけださんのこのポストを頭に思い浮かべていました。(唐突)

パネルディスカッション

パネルディスカッションでは、開発チームに対するQAエンジニアの関わり方として、下記の4つの仮定に分類してディスカッションが行われていました。

  • In Dev
    • QAエンジニアが開発チーム内でテスト業務を行う
    • QAエンジニアが主要なスクラムイベントに参加
  • Out Of Dev
    • QAエンジニアが開発のチームとは離れている部門でテスト業務を行う
  • Bridge
    • 自社内開発で、ブリッジのQAエンジニアor PdMがいて、テスト業務は第三者検証に委託する
  • Assistance
    • 開発チームとは離れている部門がQA活動に対する情報提供を行う(テストはしない)

パネリストが事前準備なしで臨むというなんともパネリスト泣かせの企画です。
確か、前回のEncraft #9 QA回もそうでしたよね？
そのような状況下でもディスカッションできるパネリスト陣がすごいです。
その場で考えて発言しなければならないので、コンテキストが伝わりづらい場面もありましたが、別のパネリストが補足するような愛を感じるやりとりもありました。

いくつか個人的に良いなと思った内容があったので箇条書きで書いておきます。
(私は聴いた内容を文字に起こすのが極端に苦手なので、異なるニュアンス・表現に変換してしまっていたらご指摘ください。)

  • In Devのメリットはチームと自然に会話できること

    • broccoliさん(@nihonbuson)：「こういうテストをやろうと思っている」ということを「予告」する。予告したところは開発者が気をつけるのでまずバグは出ない。バグを報告して、それを修正して、確認してーというコストを減らすことができる

  • QAエンジニアのメンタルの持ち方、情報を提供する(伝える)時の考え方について

    • ゆもとさん(@yumotsuyo)：強気、対等になることが重要。「自信」を持つ。
      • 自分が一番システムを使っているという「自信」
      • 自分が一番欠陥に遭遇している時間が長いという「自信」
    • broccoliさん(@nihonbuson)：「ここで困っているんです」を伝える。
    • koyamanさん：QAエンジニアは「情報を提供する」ことが仕事(報酬を貰っている)。その目的を達成するために必要だから伝える。

おわりに

たくさんの気づきが詰まっていて、パネルディスカッションについては、ずっと聴いていたい内容でした。
イベントの企画・運営・会場設営・配信に関わってくださった関係者の皆様、ご登壇された皆様、大変お疲れ様でした。そしてありがとうございました！

テスト設計パターン(仮)を考える会 仕様スニペット001

上記について考えてみます。

与えられた仕様スニペットは次の通りです。
例としても挙げられている通り、Aを部署、Bを社員として考えていきます。

1. 2種類のエンティティAとBには親子関係があり、Aが親、Bが子となります。
2. 親Aの数は、全体で0個以上64個以下です。この範囲で追加・削除ができます。
3. 子Bの数は、全体で0個以上128個以下です。この範囲で追加・削除ができます。
4. 親Aは、0個以上16個以下の子Bを持つことができます。
5. 子Bは、必ず1個の親Aを持ちます。
6. 子Bは、いつでも削除することができます。
7. 関連づく子Bが1つ以上存在する限り、親Aを削除することはできません。

分析クラス図を作る

〜以上とか〜以下というキーワードが出てきた時点で、境界値分析を適用することを頭に浮かべます。
ただ、データベースっぽいなと思ったのと、関係を明らかにするために、まずは分析クラス図を作っていきます。

部署と社員の関係

1. 2種類のエンティティAとBには親子関係があり、Aが親、Bが子となります。  

4. 親Aは、0個以上16個以下の子Bを持つことができます。  
5. 子Bは、必ず1個の親Aを持ちます。

上記の仕様から部署と社員の関係を表していきます。
部署と社員が多対多の関係であれば、部署と社員を関係づけるテーブルが必要になりそうですが、
今回は、社員は1つの部署にしか所属が出来ないので、以下のようなクラス図になるはずです。

部署・社員の数

上記だと親Aの数、子Bの数を表現することができないため、仮想のクラス「会社」を作って社員数と部署数を表現します。

2. 親Aの数は、全体で0個以上64個以下です。この範囲で追加・削除ができます。
3. 子Bの数は、全体で0個以上128個以下です。この範囲で追加・削除ができます。

制約

与えられた仕様の中に制約に関する記述がありました。

6. 子Bは、いつでも削除することができます。
7. 関連づく子Bが1つ以上存在する限り、親Aを削除することはできません。

部署と社員の関係 でも示した通り、社員は必ず1つの部署に所属しなければならないので、
部署に社員が関連づいている場合は、「削除」することができません。これは書いてある通りですね。
「追加」については考慮しなくてよいのでしょうか？

仕様には明示されていませんが、部署・社員の数 で示した通り、部署は0であることがあり得るので、
部署が0のとき、社員が追加できないことを確認する必要があることに気づきます。

こうして、分析クラス図を作ると、どの境界をテストしたいのかが明確になるような気がしますよね？

不足しているコンテキストの追加

「部署」と「社員」という例が提示されており、それらを「追加」「削除」できるということから、
社員検索データベースのようなシステムを想定してみます。

  • 社員(名)を検索すると、所属部署を表示できる
  • 部署(名)を検索すると、その部署に所属している社員を一覧表示できる
  • 社員を追加、削除できる
  • 部署を追加、削除できる

これをもとに各クラスの属性と操作を考えてみます。

テストケースを作る

上記をもとにテストケースを作っていきます。

部署に所属する社員を取得

  • 部署に所属する社員が取得できる
    • 部署に所属できる社員の上限(16)、下限(0)
    • 部署(社員)が存在しない(0)

部署を追加

  • 部署を追加できる
    • 部署が存在しない(0)
    • 部署数の上限(追加後に上限の64)
  • 部署の追加に失敗
    • 部署数の上限+1(追加後に65)
    • 部署(名)を指定しない

コンテキスト次第では、上記に加えて、部署の文字列長や、文字種なども確認したいです。

部署を削除

  • 部署を削除できる
    • 部署に所属する社員が存在しない(0)
  • 部署の削除に失敗
    • 部署に所属する社員が存在(1以上)
    • 部署を指定しない
    • 指定した部署が存在しない

所属部署を取得

  • 所属部署が取得できる
    • 社員が存在(1以上)
    • 社員(部署)が存在しない(0)

社員を追加

  • 社員を追加できる
    • 社員数の上限(追加後に上限の128)
    • 部署に関連する社員数の上限(16番目を登録)
    • 部署に関連する社員が存在しない(0)
  • 社員の追加に失敗
    • 部署が存在しない(0)
    • 部署に関連する社員数の上限+1(17番目を登録)
    • 社員総数の上限+1(129番目を登録)
    • 社員を指定しない
    • 部署を指定しない

コンテキスト次第では、上記に加えて、社員の文字列長や、文字種なども確認したいです。

社員を削除

  • 社員を削除できる
    • 社員が存在(1以上)
  • 社員の削除に失敗
    • 社員を指定しない
    • 指定した社員が存在しない

その他、このシステムに複数人が同時でアクセスできるというコンテキストが追加された場合は、
CRUD(Create、Read、Update、Delete)を考慮したテストをしたいと思いました。例えば、以下のようなものです。

  • Aさんが削除中にBさんが取得
  • AさんとBさんが同時に同じデータを削除
  • Aさんが部署を削除中にBさんがその部署に社員を追加する

RDRAをテスト要求分析に使った話

RDRA2.0をテスト要求分析に活用してみたというお話です。
はじめにおことわりしておきますが実業務で使ったわけではなく、テスト設計コンテストのOPENクラスに出場した際に適用したものです。

RDRA2.0とは

RDRA(ラドラ)2.0は、要件定義を行うためのフレームワークです。

RDRAには4つのレイヤーが存在します。*1

  • システム価値
  • システム外部環境
  • システム境界
  • システム

各レイヤーにはそれぞれ目的があります。

  • システム価値：要求を整理してシステム化の目的を明らかにする
  • システム外部環境：システムがどう使われるのかを明らかにする
  • システム境界：人とシステムの境界であるシステム境界を明らかにする
  • システム：システム化する情報と、その情報の変化を「状態」として明らかにする

「システム価値」から「システム」までの各レイヤーには依存関係があるため、段階的に詳細化することができます。
依存関係が存在するため、必然的にトレーサビリティを取ることもできます。
具体的には次のような構成要素にてモデリングしていくことで、各構成要素間の関連を紐づけていきます。

  • システム価値：アクター、外部システム、要求
  • システム外部環境：業務、ビジネスユースケース、業務フロー、利用シーン
  • システム境界：ユースケース、画面、イベント
  • システム：情報、状態

RDRA2.0に興味を持たれた方は次の書籍を読んでみてください。(2024/03/30現在、Kindle Unlimitedに加入していれば読み放題対象になっています。)
この書籍では、RDRA1.0と2.0の違い、4つのレイヤーの詳細、図書館システムを事例にしたモデリングの実例が示されており、RDRA2.0について詳しく知ることができるでしょう。

RDRA2.0 ハンドブック

RDRA2.0 ハンドブック

Amazon

なぜテスト要求分析にRDRAなのか？

さて、話の対象をテスト要求分析に戻しましょう。
テスト要求分析とは、何をテストすべきなのかを明らかにしていくプロセスです。

テスト要求分析では、各画面で起きうるイベントやそこでやり取りされる情報など詳細化された内容と、
システム化の目的などシステム全体を俯瞰視した内容を、行ったり来たりしながらテスト要求を明らかにしていくと思います。

仕様書や設計書などのテストベースからシステム化の目的やシステムに関わる人々を特定し、
テスト要求分析を行うこともできますが、テスト対象システムの規模が大きくなればなるほど、全体を俯瞰することが難しくなってきます。

そこでRDRAです。

RDRAは、システム化の目的からトップダウンで読むことはもちろん、テスト要求を抽出したい機能の「画面」を起点にどんな「ユースケース」で使うのか、そこでやり取りされる「情報」はどんなものがあるのかなど関心事を中心に読んでいくことができます。

RDRAを活用する上での注意点

繰り返しになりますが、RDRAはあくまで要件定義のフレームワークであり、システムをどのようなアーキテクチャで構築していくのか、情報をどのように表現するかなどのHowは関心事として扱いません。
テスト要求分析においては、Howも関心事として扱いつつ、テスト要求を明らかにしていく必要があるので、Howの部分を補う別のフレームワークを適用する必要があるでしょう。

実際に使ってみてどうだったのか

テスト設計コンテスト2023 OPENクラスのテスト対象システムは動物園の入場管理システムで、 テストベースの総ページ数が数百ページに至る大規模なテスト対象でした。
純粋にテストベースを上から読み進めるだけでは全体像の把握は難しく、RDRAでモデリングをしていく過程で、テストベースの別々の部分に書かれた文章の内容を、モデルとして"つなげて"いくことで、テスト対象への理解を深めることができました。
特に、抽出したユースケースと情報のつながりは、RDRAのモデルなしに理解することは難しかったので、テスト対象を理解するという目的においては大きな効果を発揮しました。

おわりに

なんだ、大規模なウォーターフォール開発にしか適用できないのか、そう思った方もいらっしゃると思います。 現状、私がおしごとで関わっているチームはアジャイル開発を採用していることが多いですが、
手が空いた時にRDRAのモデルを一つ作っておけば、システムの全体像を俯瞰でき、エンハンス開発を進める中でもテスト要求分析に活かせるのではという期待を持っています。
実業務で使って良い成果が得られた際にはお知らせしたいと思います。

「RDRAをテスト要求分析に使ってみたよ」という方がいらっしゃいましたら、事例を共有いただけると嬉しいです。

*1:https://www.rdra.jp/article1

テスト設計におけるLLMとの向き合い方

AIとテストについて議論するとき、次の二つに分類し、どちらの議論をしているのかを最初に明らかにすべきと考えています。

  • AI for Testing: AI「で」テストする
  • Testing for AI: AI「を」テストする

今回の記事は、前者の「AI for Testing」について書いていきます。 具体的には、1月27日に行われたテスト設計コンテストにて発表した内容について、伝えきれなかった内容を書いていこうと思います。

AIを活用する上での前提

2022年の暮れから昨年2023年のはじめはChatGPT(GPT-3.5)の話題で持ちきりでした。 実は私自身は、この話題で盛り上がる前から、Transformerの系譜であるBERT(Bidirectional Encoder Representations from Transformers)の活用については関心を持っていて、 社内で有志の研究活動をしていたりしました。( 大きな成果は出せませんでしたが)

新しいものを扱う時、その成り立ちや歴史について理解しておくことは重要だと考えています。 この記事の中で触れることはしませんが、もしTransformerについて知らない方は、参考文献を確認してみてください1

ここでお伝えしたいのは、どんなにAIの精度が良くなっても正答率が100%になることはないということです。 この前提を考慮した上で、テスト設計への活用を考える必要があります。

考えたこと

先の活動をしている中で、にしさん(電気通信大学 故 西康晴氏)からいただいたフィードバックで、記憶に残っているフレーズがあります。

“自分たちのやっているプロセスを一つずつ細分化していけば、AIだって何だって活用できるようになる”

(言葉のチョイスは違うかもしれないですが)

このフィードバックをいただいてから、業務としてテスト設計に取り組む際に、自分のやっていることの一つひとつを考え直してみましたが、 業務の中では時間的な制約もあり、深く考えることはできませんでした。 それから数年後、ChatGPTが登場し、そして、テスト設計コンテストに出場する機会をいただき、改めて真剣にテスト設計とは何かであったり、テスト設計にAIを活用するための方法について向き合うことになりました。

そこで、まずはJSTQB2で示されているテストプロセスを改めて読み込んでみました。

  • 何をテストするか、つまり、テスト要求を洗い出す「テスト分析」
  • テスト分析で抽出したテスト要求をどうテストするかを考える「テスト設計」
  • テストが実行可能な状態になるよう具体的な手順に落とし込むとともに、テスト環境やテストデータを準備する「テスト実装」

テストの目的には、要件が満たされていることを検証する、品質に対する信頼を積み上げる、ステークホルダに判断となる根拠を示すなど、様々なものがありますが、 その目的を果たす上で重要なのは、正確性や信頼性が求められるということです。

人間が実施しても100%の精度で実施できるとは限りませんが、人間が出力した結果は、ルールや法則から演繹的に導くことが多いのに対し、 AIが出力する成果物は、事実や事例から帰納的に導くため、出力結果の導出の根拠の信頼性が低いことが挙げられます。

そのため、導き出したテスト要求をどうテストするのかを考える「テスト設計」や、より具体化が必要な「テスト実装」の活動に、AIの出力結果を利用してしまうと、折角導き出したテスト要求が満たされているのか、説明が難しくなってしまうのではないかと考えました。

そこで、人間が発想を最も広げるプロセス「テスト分析」に活用するのが良いのではないかと考えました。

テストプロセスにAIを組み込む際の留意点

言語モデルが大規模になればなるほど、AIの受け答え(出力結果)は、より自然で違和感のないものとなります。 一方で、前述の通り、精度が100%になることはないため、嘘が含まれることになります。(ハルシネーション)

どのテストプロセスで活用しても同様だと思いますが、人間が考えもせずに最初からAIを頼ってしまうと、 もっともらしい出力結果から思考が発散しないという懸念がありました。

そのため、AIを使うのは人間が十分に思考し、出力結果を出した後に、足りない視点がないかを確認するという使い方をしました。

LLMを用いたテスト分析

コンテストの中では、LLMをテスト分析に用いるための方法として、次の2つの考え方を利用させていただきました。

  • 意地悪漢字3
  • 応用HAZOPのガイドワード4

この2つの共通点は、いずれもガイドワードとして利用できる点です。 AIの仕組みを理解すれば言わずもがなの内容ですが、あくまでAIは非常に高い精度で出現する単語を予測しているに過ぎません。 そのため、インプット(プロンプト)でいかに次に出現する単語のバリエーションを広げてあげるかが重要であると考えました。

コンテストのフィードバックでは、「いずれも提案から時間が経っているので検討が十分だったか」といったご意見もいただいたのですが、 私の今の知識の中でガイドワードとして使え、尚且つISO/IEC 25010の品質モデルのように、よく知られているモデル以外を活用したかったというのがこの2つを選んだ根拠でした。 (意地悪漢字や、HAZOPガイドワードがよく知られていないというわけではないと思いますが、提案から年数が経っていることもあり、知らない方もいらっしゃるのではないかと想定していました)

実際にどのような結果が得られたのかについては、発表スライドにも書いたため、ここでは割愛しようと思いますが、 当時の最新モデル(GPT-4)を使っても、出力結果の全てがテスト分析として活用できるかというとそうではなく、 取捨選択をする必要がある印象でした。

そのため、現時点では、壁打ち相手として自分が持っていなかった視点を得るために相談するのが最適な使い方であると感じました。

  1. https://www.slideshare.net/ssuser3b2d02/ss-236525444↩
  2. https://jstqb.jp/syllabus.html#syllabus_foundation↩
  3. https://www.jasst.jp/archives/jasst10s/pdf/S3-9.pdf↩
  4. https://jasst.jp/symposium/jasst12tokyo/pdf/D2-1_paper.pdf↩

テストアーキテクチャとは何なのかが少しだけわかった気がする

先日のテスト設計コンテストで、聴講者の方からよく質問を受けたのがテストアーキテクチャに関する質問でした。
恥ずかしながら、私もテスト設計コンテストに出るまで、テストアーキテクチャが何なのかよくわかっていませんでした。
でも、参加した後の今なら、ちょっとだけ人に説明できるかもしれない。そう思ったので記事にしてみます。

テストアーキテクチャについて考える上で、わからないポイントが3つあるような気がしました。

  1. テストアーキテクチャがなぜ必要なのか？
  2. テストアーキテクチャで何を表現したいのか？
  3. 具体的にテストアーキテクチャをどのような記法で表現すれば良いのか

この記事では、「1. テストアーキテクチャがなぜ必要なのか？」と「2. テストアーキテクチャで何を表現したいのか？」に焦点を当てて考えてみたいと思います。

テストアーキテクチャがなぜ必要なのか

あなたにはこんな経験がありますか？

  • 具体的な入力値や期待結果などが書かれた数百件、数千件となるテストケース(もしくはその一部)を渡されて、レビューをお願いされた
    • そして、テストしたいこと、バグが出たら困るのでテストして欲しいことがあるけれども、それがどこで確認されているのかわからない
  • 組織におけるテストの全体像はよくわからないけど、とりあえずこれまでの慣習でテストしている
  • 過去のテストスイートを参考にして、いい感じに新しい機能のテストケースを作ってと依頼される
  • 「これを実行して」と渡されたテストスイートが制約事項により実施できなかった
  • テスト実行しているけど、いまいち何を確認したいテストケースなのかわからない

「ソフトウェアテストに携わっているけどそんな経験ないよ」という方は、本当に素晴らしい現場にいらっしゃるので、その現場で経験したことを大事にしていただきたいです。 一方、私は当事者として、少なからず上記のような課題に直面する場面がありました。

これらの課題を解決する一つの手段がテストアーキテクチャの設計であると考えています。

テスコン チュートリアルの資料を見てみます。

テストアーキテクチャ設計とは、テストスイートの全体像を把握しやすくしつつ 後工程や派生製品、後継プロジェクトが作業しやすくなるように、テスト観点を グルーピングしてテスト要求モデルを整理する工程である。

テスト設計チュートリアル テスコン編資料(講義編) https://aster.or.jp/testcontest/doc/2023_tescon_V1.0.0.pdf

この説明を別の視点から考えていきたいと思います。

夢のマイホームを建てるとしましょう。
理想の完成像として、「趣味をとことん楽しむためのガレージルームが欲しいな」、「シアタールームが欲しいな」など夢が広がります。

一方で、現実問題として家を建てる際には、土地の広さや建ぺい率、予算などさまざまな制約があります。
そういった制約を踏まえて、より現実的で「実現可能な完成像」である間取りやデザインが出来上がっていくはずです。

ソフトウェア開発においても同様に、ステークホルダが考える理想の完成像、つまり要求があり、
システム化によって解決できる課題を具体化していくことで、実現可能な完成像がブラッシュアップされ、要件に落とし込まれていくと思います。

その完成像を実現していくために必要なのが、ソフトウェアのアーキテクチャですが、
テストに置き換えるならば、完成像が実現できていることを示すためのもの、それがテストアーキテクチャなのではないでしょうか。

テストアーキテクチャで何を表現したいのか

引き続き、家を建てることを例に取りつつ考えてみます。

先ほど、間取り図やデザインは「実現可能な完成像」であると述べましたが、実際に家を建てるためには、
柱を何本建てるか、材質は何か、壁や窓をどこに配置するか、などの具体的な構造を検討していく必要があります。
そして、検討した構造が法令で定められた基準を満たしているか検査していく必要があります。

テストアーキテクチャとして考えてみると、テストの目的を果たすために、どのようなアプローチを取れば良いのか、
具体的に、どこまでのスコープに対し、どのようなテストレベルを定義し、その中でどのようなテストタイプを選定するのかを検討することであると捉えることができるかもしれません。
(何がテストレベルで、何がテストタイプかというのも、それだけでブログ記事が一つ書くことができそうな話題なので、ここでは雰囲気で察してください)

ここで注意をしなければならないのは、家を建てるときは建築基準法など特定の法令を遵守する必要があるのに対し、ソフトウェアの場合は、対象のドメインによって遵守・適合すべき法令が異なるということです。
例えば、医療機器に搭載されるソフトウェアでは、国内ならば薬事法、米国ならばFDAへの届出・承認を検討しなければならないかもしれません。
つまり、テストアーキテクチャとして何を考慮すべきかは、自分たちが扱っている対象システムによって大きく変わってきます。

さて、考えるのは構造だけで良いのでしょうか。 改めてテスコン チュートリアルの資料を見てみます。

テスト要求を、テストケースを導くエンジニアリング的テスト要求と、
テストケースを導かないマネジメント的テスト要求に分ける

テスト設計チュートリアル テスコン編資料(講義編) https://aster.or.jp/testcontest/doc/2023_tescon_V1.0.0.pdf

先ほど検討したテストレベル、テストタイプは、エンジニアリング的テスト要求に分類されるものです。 従って、マネジメント的テスト要求の検討ができていません。

再び、家を建てる話に戻ります。
土地や道路の制約がなければ、全ての材料を搬入して、建てていけば良いかもしれません。
ただし、現実問題として、土地の広さや前面道路の幅などの制約があり、搬入する順序やタイミングを考慮する必要があります。
また、「アーキテクチャ」ではないかもしれませんが、職人さんが何人いれば良いのか、天候などの不確実な要素に対応するためのスケジュールなどのマネジメントの要素も検討する必要があります。

これはソフトウェアテストにおいても同じことが言えるのではないでしょうか。
例えば、相互に依存関係のあるシステムや機能を考慮する必要があるかもしれません。 また、組み込み機器であれば評価機器などの制約、ハードウェアの開発状況などソフトウェアの外の世界にも目を向ける必要があります。 そして、これまで検討したエンジニアリング的テスト要求を満たすために、テスト全体の規模感を知り、リソースの調整をする必要があります。 すなわち、これらのポイントを考慮してテストアーキテクチャを考えていかなければなりません。

おわりに

テストアーキテクチャの必要性と、テストアーキテクチャで表現すべきものについて、建築を例にとりながら考えてみました。
実際に私がどう表現したのか？という話は今回も筆が乗らなかったのでまたの機会に。

指摘、コメント歓迎します。

テスコンに一人で優勝してみた

冒頭から煽るようなタイトルとなってしまいすみません。
タイトルの通り、テスト設計コンテスト2023 OPENクラス(以降、テスコン)に、ソロで出場し、優勝という結果をいただきました。
過去12回の開催のうち、初出場にして一人で優勝したのは初めてのようです。
これは誤りで、既に一人チームで優勝されているチームがあるとのことです。

このエントリーでは、審査裏イベントでも少し話した、何故テスコンに一人で出場しようと思ったのか？実際出てどうだったのか？について書いていきたいと思います。
一人でも多くの方にテスコンに興味を持っていただき、(独りでも)出場をする人が増えたら、今後のソフトウェアテスト業界の発展に繋がると考えているからです。

審査について

審査員の方が述べられていたように、今回は、決勝のプレゼンテーションで順位が入れ替わる可能性が充分にあり得るくらい接戦だったようです。
会場で成果物を拝見させていただいても、ドキュメントの出来栄えはどのチームも素晴らしく、どのチームが優勝してもおかしくないと感じていました。
それと同時に、私は優勝なんて無理だろうとタカを括っていたので、結果を聞いた時は、何もコメント準備してなくて、あたふたしました。

出場されたチームの皆さん、本当長い期間取り組まれた成果物の作成や準備、大変お疲れ様でした。
また、実行委員の皆様におかれましては、テストベースのご提供と、ハイブリッド開催の運営の両面で大変お世話になりました。ありがとうございました。

何故一人で出場しようと思ったのか

WACATEなどに出たことはなく、コミュニティにお友達がいない、つまりボッチだからです。
また、転職直後で会社の人を誘う勇気がなかったのもあります。

って別にボッチ自慢をしたいわけじゃないんです。

出場のモチベーションは、3つありました。

1つ目は、前回のテスコンの審査委員の湯本さんの講評です。

note.com

誤解を招く可能性もあるため引用はしませんが、 ソフトウェアテストに対して強い想いを持っているからこその、厳しいコメントだと受け止めました。

ソフトウェア開発においては、昨今のOSSの普及などにより、他人の書いたコードを見ることのできる機会は確実に増えました。
一方で、ソフトウェアテストにおいて、現場以外で、他人の作ったテスト設計を見ることのできる機会は少ないように感じます。
テスコンは、その機会を提供してくださる貴重な場でもあると考えています。

テスコンを聴講される方はさまざまな目的を持って参加されていると思いますが、
一つの目的例として、現場や自分自身のテスト設計をより良くするためのヒントを得るために参加されているものと考えています。
私自身も聴講者として参加していた時は、そのような目的意識を持って参加していました。

だからこそ、エンドユーザも含むステークホルダの要求や、システムのアーキテクチャをしっかり捉えるテスト設計を示したかった、それが1つ目のモチベーションでした。

2つ目、OPENクラスの新しいテストベースが興味深い内容だったからです。

感染症対策のため入場者の制限を行う動物園の入場管理システムが対象でしたが、
開発の体制、スコープ、マイルストン、制約事項などが定められており、
実際のプロジェクトに近い状況でテスト設計ができるということにとてもワクワクしました。

3つ目、エントリー前に、やまずんさん(@55_ymzn)、ぐんちゃさん(@gun_chari)とお話する機会をいただけたことです。

テスコンに関しては先輩のお二人とお話できたことが最後の一押しになりました。
自分よりも若い方が、色々なことに果敢にチャレンジしている一方で、自分はこれまで勝手に壁を作ってチャレンジを恐れていた、
そんな壁を少しでも壊したいと思い、エントリーを決めました。

ソロでよかったこと・大変だったこと

複数人で参加する難しさ、ソロで参加する難しさ、それぞれあると思います。

ブレスト・議論・意思決定

複数人で参加する場合、複数人でのブレスト・議論ができるというメリットがあります。
それはソロではできません。そして、自分が選択した方針が本当に良いのだろうかと悩んだ時に助言してくれる人はいません。

ただし、複数人で参加されたチームのメンバーの方とのアフタートークで、自分が納得できない方針で進んでしまったというお話も伺い、そこが複数人参加の大変なことだと改めて感じました。
プライベートがある中で、同期的なコミュニケーションを取るための調整も相当な労力ですよね。
全て一人で完結・意思決定できることはソロの最大のメリットだと感じました。

成果物の作成

複数人で分担して作業を進める場合、予め方針やテンプレート、どこまで情報を書くかなど事前に決めておかないと、成果物間の一貫性が崩れてしまいます。
進め方一つとっても、テスト要求分析、テストアーキテクチャ設計、詳細設計、実装のように工程毎に分担をするのか、
工程内で分担して作業を進めるのかも悩ましい問題です。
また、本業を抱える中で、プライベートの時間とどう折り合いをつけていくのかも、切実な課題です。 チームで参加してると、途中で離脱してしまうメンバー、期限までに成果物が出てこない状況が発生してしまうという話もよく聞きます。

ソロでは、そういった悩みを抱えることなく、一貫性を取りやすい、短時間でも作業に取り組めるのはメリットだと思います。
一方で、今回のテストベースのような大規模なテスト開発を一人で行なっていくのは、結構大変でした。
仕事の忙しさにかまけて、サボっていた時間もありつつも、去年のプライベートの時間はほとんどテスコンに費やしたように感じます。

私は片方の見方しかできないので、どちらが大変かはお伝えできないですが、 チームでコミュニケーションをとりながら、一つの成果物を作り上げた他チームの方はすごいと思いますし、リスペクトしています。

おわりに

この記事によってテスコンに興味を持ってくれる人が増えたら嬉しいです。

私が成果物を作るときに考慮したことや、技術選定の理由、作成した成果物の詳細な説明はさすがにプレゼンの15分では語りきれなかったので、またどこかで書いたり、発信できるとよいなと思っています。

最後まで読んでいただきありがとうございました。