ボトルネックその1:テスト観点出し 初回レビュー時 手続き設定(機能名) A 従業員項目設定が初期値の時に手続き設定にカスタムカテゴリーが表示されない B すべてのカスタムカテゴリー・項目に従業員項目設定が反映される(表示名と補足文章がすべて入力なし) C すべてのカスタムカテゴリー・項目に従業員項目設定が反映される(表示名と補足文章がすべて入力あり) D すべてのカスタムカテゴリー・項目に入力必要性設定が反映される E 従業員項目設定にて、カテゴリー・項目が使用になっている項目のみ手続き設定で使用できる F 従業員項目設定を変更した際、手続き設定にも反映される G 手続き設定で一度保存された従業員項目(カスタム)は、従業員項目設定で非使用に変更しても、設定値が保持さ れる H 手続き設定で選択したカテゴリーが、従業員項目設定ですべて非使用に変更されたとき空の手続き設定になる I 手続き設定の作成中に従業員項目設定を非使用に変更された場合、非使用になった項目は作成されない J 手続き設定の編集中に従業員項目設定を非使用に変更された場合、非使用になった項目は反映されない K 手続き設定の作成、編集中に選択しているすべてのカテゴリーが非使用に変更されたとき、手続き設定が保存され ないこと L デフォルトカテゴリーを含めた手続き設定を作成できる きになるポイント 観点ではなく機能仕様では? 観点ではなくテストパターンでは? 自明もしくは重複の情報では? 網羅性をどうやって判断しよう🤔 文字数が、文字数が多い…!
「テストをスクラムチームに還すためのQAエンジニアの取り組み」 このタイトルは「Modern Testing Principles」の7と@mkwrdさんの「独立QAチーム1年戦記」から 着想を得ています。 「還す」という言葉ほど、人事管理チームではテストを外に出していたわけではありませんが、私が チームにジョインした時点で「テスト」の知識がある開発エンジニアはかなり少数でした。時代に伴い 「開発者自身がテストをする」場面が減ってきているのではないかと感じます。 テストはQAエンジニアの生業かもしれませんが、開発エンジニアにとっても大事なプラクティスのひ とつと考えます。品質を作り込めるのはどの時代においても開発エンジニアだけです。その開発エンジ ニアが「テスト」の知識を得ることにより、開発チームはスケールし、プロダクトをよりよい品質で、 かつアジリティを損なわずにリリースできる未来への一歩になると信じています。 https://www.moderntesting.org/ https://speakerdeck.com/mkwrd/210107-rsgt2021-an-independent-qa-teams-1-years-war?slide=55 “We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.”