オイオイオイ書くわアイツ

ほうクソブログですか……たいしたものですね

機能の動作確認をする時に知りたい情報・嬉しいフォーマット

機能開発において、開発チームとは別の人員が動作確認を行う場合、動作確認の担当者に「何を確認して欲しいか」を伝えることになる。
で、ここで合意した内容に基づいて継続的に機能の動作確認が行われるんで、なんかそれなりの内容について合意したい。
それなりの内容ってなんやねん、そういう話になる。

大前提として、株式会社 HERP（以下、"弊社" ）の開発プロセスにおいて、"動作確認の担当者" は機能開発自体にはあんま関与していない。
機能があらかたテスト環境で動くようになってから「挙動確かめてクレメンス〜〜」と依頼される。
この依頼に際して、確かめて欲しい挙動というのはなんなのですか、という部分に焦点が当たる。

CR 動作確認

欲しがっている情報というのは単純に "受け入れ条件" であり、以上っす。
その "受け入れ条件" とはなんやねんということについては、 インターネットに詳しく書いてある。
インターネットの例を 1 つ挙げる。

www.atlassian.com

インターネットによると

Acceptance criteria are the conditions that a product, user story, or increment of work must satisfy to be complete.
They’re a set of clear, concise, and testable statements that focus on providing positive customer results.
Acceptance criteria don’t focus on how you reach a solution but rather on the final desired outcome of the task.

ということであり、要は機能開発が終わった時に何がどうなっていて欲しいのか、 a set of clear, concise, and testable statements で表現したものっス。
これを作るために以下気をつけると良いですよ、とある:

How to write acceptance criteria

Crafting well-defined acceptance criteria is essential for successful software development. Here are some key steps and tips for guidance:

  • User story: Refer to the user story connected to the acceptance criteria. This ensures that the criteria tie to the desired functionality.
  • Outcomes: Express the user experience and expected outcomes criteria. What should the feature achieve for the user? Avoid getting bogged down in technical implementation details.
  • Clarity and concision: Strive for clear and concise language everyone can understand. Technical jargon or ambiguous phrasing can lead to confusion.
  • Testability: Ensure each criterion translates into a clear and verifiable test. This allows for an objective evaluation of whether the feature meets the requirements.
  • Measurability: Whenever possible, quantify the criteria using measurable terms. This facilitates a clear pass/fail determination during testing.
  • Independence: Aim for independent criteria that you can test in isolation. This streamlines the testing process and avoids dependencies.
  • User acceptance testing (UAT): Consider incorporating UAT criteria alongside the development team's criteria. UAT criteria focus on ensuring the feature meets expectations from a usability standpoint.
  • Collaboration: Encourage collaboration during the creation process. Involve the product owner, development team, and other relevant stakeholders to ensure a comprehensive set of criteria that reflects all perspectives.
  • Review and refinement: Don't be afraid to revisit and refine the acceptance criteria throughout development. As understanding evolves, consider adjusting the criteria to reflect the latest information.

These steps and tips help develop acceptance criteria that promote clear communication, efficient testing, and a successful project outcome.

たとえば「スレッドにコメントを投稿する機能」について、「ユーザーはコメントを投稿できる」 と書くのではなく、

  • スレッドにアクセス権限を持つユーザー A は "コメント投稿画面" を開ける
    • "コメント投稿画面" にはテキストボックスと submit ボタンが表示されている（ enabled である ）
    • スレッドのアクセス権限は、
      • 管理者 ロールのユーザーは常に有している
      • ゲスト ロールのユーザーは、管理者ロールのユーザーからスレッドに招待されたユーザーに限り有している
        • スレッドへの招待は、管理者ロールのユーザーが "スレッド詳細画面" を開いて hoge して...
    • テキストボックスに n 文字未満の文字列を入力し、submit ボタンをクリックすると "コメントを投稿" できる
      • 投稿完了トーストが表示された後、"スレッド詳細画面" を開き、投稿した文字列が表示されていることを以て投稿の完了を確認できる
    • ...

など書かれていると Clarity / Testability / Measurability あたりの観点から嬉しい。
また、それのみが書かれている文書に整理し直してもらえると consision 的にも HAPPY。

色々な検討経緯も含めて共有されると（動作確認担当者としては）あんまり嬉しくない

動作確認の担当者 から機能開発チームに向けてのお願い事としてはこんなだが、逆の話も当然ある。
動作確認の担当者 （というか俺）も「受け入れ条件クレメンス」をするにあたり、早めに PO に訊きに行く を気を付けた方が良い。
受け入れ条件は機能開発に全体を考慮して決めるべきであり、少なくとも PO は「全体的な考慮」をできるハズなんで。

して、一旦は「機能開発チームは良い感じに受け入れ条件書いてね」「動作確認の担当者は PO に受け入れ条件のことを訊いてね」ということでやり取りが整理されると嬉しい。
が、根本的には、機能開発チーム / 動作確認の担当者 とかいう謎のくくりがない方が良い。
結局のところ

株式会社 HERP（以下、"弊社" ）の開発プロセスにおいて、"動作確認の担当者" は機能開発自体にはあんま関与していない

に大体問題がある。
"動作確認の担当者" が最初からチーム内におり、機能検討の議論に参加できていれば全部話がうまくいくんじゃないですか。
しかし "動作確認の担当者" の数が単純に足りていないので、話がうまくいっていない。

前向きな対処としては、引き続きテスト基盤を整備して E2E テストを機能開発チーム書いてもらえるようにする。
E2E テストを（てか Playwright によるテストのコードを）機能開発のアウトプットとして要求できると、"受け入れ条件" を別途考えてまとめてもらうよりも現状の組織体制に即しているんじゃないですか。
また、それはそれとして、現状の組織体制というやつもなんとかしたくはある。
一旦、俺が頑張るなどして、動作確認担当者間でのコミュニケーションを増やしたい。
更に、QA・テスト に興味関心を持つ人間が弊社に増えると嬉しい。
俺は採用活動の一環として業務時間にこの文章を書いています。よろしくお願いします。