はじめに
私はチームでの品質について考える時、具体的なフローや禁則だけでは難しいのではないかと感じるシーンがあります。それは項目として具体性が不足している時に効果が弱まること、文字数の制限によって局所最適化的となること、強く限定することはハックされ形骸化することを懸念しているからです。
現在ではアプローチとして、メンバーがどのように考えているかの意見交換を大事にしています。
今回取り上げる「ソフトウェアをカイゼンする50のアイデア」から私が気になった項目を取り上げ、意見交換の種となればと思います。
取り上げたアイデア群
「関係者と品質に関する全体像を定義しよう」
これを取り上げたのはまさしく先に書いたような意見交換によって求めるところの一つです。
定義できていない時の例として、
- テスト担当者が重要でない問題を細かく確認していると感じる
- ステークホルダーが持続不可能なデリバリーを求める
などが挙げられています。これが業務グループによって狭窄的な見方によって発生していると考え、全体像を共有しようという建て付け。
共有の方法として、低レベルなアクションではなく比較的高レベルな包括的基準・主要な活動でマイルストーンごとに作業するのが挙げられていました。
これは某ショート動画で流行ってる「バイブスあるねぇ」ではないでしょうか。(細かなアクションはハックされるので、高レベルな概念を提示して擦り合わせていく方が安全という認識)
これはアイスブレイクを企図したジョークです。
「1つのテストでは１つの関心ごとを扱おう」
複数のタスクを実行することで、より高いレベルのアクションを実行しようとするテストは
- 含まれる一部の変更に弱い
- 維持するためのコストが高い
- 期待の理解が難しくなる
対処として
- 共通パラメータを単一のセットアップとしてまとめる
- 前提条件を個別のシナリオに切り離して完全性を高める
- 他のシナリオのコンテキストを説明するだけになっている部分は削除、必要なら期待値を明確にする
などが挙げられていた。
目的となる機能と前提条件といった切り分け方は機能検討などでも便利な考え方だなぁと個人的には好きなポイントです。
「アトミックな外部リソースを提供しよう」
アトミックな、とは更新途中のものではないことがわかるもの(ここではテストに利用するリソース)の状態を指していると捉えました。
例えば、テストの中でランダムに失敗が発生するが手動・ローカルでは成功する場合について、通信環境やファイルサイズによる影響があると(環境の僅かな違いに依存すると)問題の把握と解決が難しいというのが例示されています。
ex. 成功したテストで扱ったファイルサイズがとても小さいから成功しやすかったとか
いくつか紹介された対策のうち、不完全なリソースは「ファイル名を一時的な名前にする」がOSでもやってるよねと紹介されててなるほどとなりました。
「テストの目的から、テストの範囲を切り離そう」
テストの目的に対して広すぎるテスト範囲を実施してしまう例が挙げられている。
- 統合テストとe2eテストを混同し、サービスコンポーネントとデータベースレイヤーが正しくやり取りできているかという目的に対して、多数のコンポーネントを必要とするワークフローを実行してしまう
- ユニットテストと技術的なチェックを同一視してしまい、例えば(独立したコードである)取引税率計算のテストをユーザーインターフェースを介して行うべきだとしてしまう
対策として挙げられていたのは
- 目的と目的に基づくテスト形式を選択しよう
- 設定された目的に応じた最小限のテスト範囲を考える
といった形で提示されています。
その中で「ビジネス面のテストだからという理由だけでユーザーインターフェースを介して」実施するのはやめよう、というのはテスト範囲が目的と合致しているかの判断がない事例としてわかりやすそうです。
「リスクは皆で考えよう」
反復的にフィーチャーを変化させていくソフトウェア開発では数多くのリスク考慮する必要があるため、それらを"開発者だけ""ビジネスのステークホルダーだけ"に把握・決定させるのは不可能だと前提が提示されます。
そうしたリスクを共有するために幅広いフィーチャーに横断した関心ごとをリストでチェックするのは一般的ですが、リストの更新がされなかったり各個人で対処するだけでは対応方法への認識ズレが発生することを懸念されるというのは納得感があります。
そこで開発前には関係者を集めて対象となるフィーチャーとそれに関するリスクと対応方法を考えようという提示です。
なぜこれらを取り上げたか
私が持つ課題感から上記に共通したと感じているポイントがあります。
- 課題・問題は何なのか
- テストの目的は何なのか
それらの積み重ねが品質意識を形作ると考えていて、そのためには高レベルなイメージのすり合わせが必要だと考えています。
この本では特に自動テストへ視点が向けられたものと感じますが、あくまで開発にまつわるアイデアとして捉えると共感性もある話題が多いのではないかと考え取り上げました。
良かったポイント
- 一つ一つのアイデアが長すぎず、コンパクトに読めること
- アイデアが「エピソードと対策」「主な利点」「それを機能させる方法」として、エピソードにガチガチに囚われず一般化して利用可能なのではないかと考えられたこと
余談
こんなに言語化してコミュニケーションするのが難しいのにpromptだけでAIが目的を表現することは無理じゃない？
Discussion