スクラム開発入門 スクラム開発のテスト アジャイル・スクラム勉強会 Satoshi Harada

WF開発のテストをおさらい ● WF開発の設計は工程毎に区切って順番に進める ● テストは、各設計工程に対応する内容でこちらも順番に 進める ● 設計同様に、テストも前工程に戻ることは良しとしない ► つまり各テストは１回だけ行う想定となっている ※図の出典 https://webrage.jp/techblog/v_shaped_mode/

スクラム開発のテストは？ ● スクラム開発はスプリントという単位で繰り返し機能を 開発する ► １つのスプリント内で機能に対する要件定義・設計・実装 ・テストまで行い、機能を完成させる ► １つのスプリント内で単体テスト・結合テスト・システム テスト・受け入れテストを行う ► スクラムはスプリントの最終日にスプリントレビューを行 うので、これが受け入れテストとなる ※図の出典 https://webrage.jp/techblog/v_shaped_mode/

WFとスクラムで何が異なるのか ● テストの回数が異なる ► WFでは、単体テスト・結合テスト・システムテスト・受け入れテストをそ れぞれ１回だけ行う ► スクラムでは、１スプリントで最低１回はテストを行うので、４スプリント あれば最低４回はテストを行う ● テストにかけられる時間が異なる ► WFでは、テスト工程という比較的長期の期間を確保してテストを行う ► スクラムでは、テストのためだけの期間を確保せず、スプリントという限ら れた時間の中でテストを行う必要がある ● リグレッションテストの頻度が異なる ► 過去に完成させた機能について、新たに追加した機能で意図しない影響が及 んでいないか確認する必要がある ► WFでも変更があればリグレッションテストは行うが、スクラム開発ではス プリント毎にリグレッションテストを行うためテスト項目数が増えていく これらの理由から、スクラム開発（アジャイル開発）では頻 繁に・短時間で・大量のテスト項目を実施できるしくみを整 える必要がある。

テストの実施方法 手動テスト 自動テスト テストの 実施方法 テストケースの実施手順に 沿って手動で実施 テストコードに沿って自動 で実施 テスト結果の 確認方法 テストケースの確認手順に 沿って目視で結果の正しさ を確認 テストコード内で結果の正 しさが自動で検証されるの で、成功・失敗の結果サマ リーを確認 テスト実施・結果 確認の所要時間 長時間 短時間 テストの正確さ テスターに依存 正確 テストの成果物 • テスト観点 • テストケース • エビデンス • テスト観点 • テストケース • テストコード テストの実施方法は手動テストと自動テストがある。 テストコードが既にある状態であれば、自動テストが断然効率的。 まだテストコードが無い状態だと、まずはテストコード作成に時間 と人的リソースを投資する必要がある。

全てのテストを自動化する？ ● フロントエンド（HTML, CSS, JavaScriptなど） ► 見栄えに関するコード（HTMLやCSS）は、変更の頻度が多くI/Oで検証でき ないためテスト自動化は難しい ✔ テスト自動化による工数削減よりも、テストコードのメンテナンスコストのほう が大きくなる場合が多い ✔ デザインが確定したタイミングでUIのスナップショットを作成し、E2Eテストと スナップショットテストを組み合わせてデザインを壊していないか確認するのは 有用 ► ロジックに関するコード（JavaScript）は、UIほど変更頻度が多くなくI/O で検証できるためテスト自動化を進める ● バックエンド（Java, C#, PHPなど） ► I/Oで検証ができるため、テスト自動化を進める ✔ DB操作やファイル操作を伴うテストは難易度が上がるが、モックやスタブを駆使 してテスト自動化を進める 自動テストは全パターンのテストケース網羅（テストカバレッジ100%）を目 指すことが目的ではない。 壊れやすい箇所や、壊れたらヤバい箇所を頻繁に・短時間で検証できるよう にすることが目的。そのため、必要だと思う箇所を優先して自動テストを作 成し、必要ではないところには自動テストを作成しないという判断もアリ。

最初からテストコードを書く？ ● 最初からテストコードを書くのがベストではある ► 併せて、TDD（テスト駆動開発）でテストコードを書きな がら設計を行い、設計完了＝テストコードの作成完了であ れば更に良い ● 最初は手動テストとし、後からテストコードを追加する のでも良い ► プロジェクト序盤は時間的制約やスキルの問題でテスト コードまで手が回らないことはよくある ► テストコードが無いよりは、後出しでも良いのであったほ うが良い ✔ スプリントが進む毎にリグレッションテストの範囲が増えるの で、手動テストは確実に辛くなる ✔ リファクタリングをしようとしたときに手動テストでしか機能 を壊していないことを確認できないと、怖い＆壊していないか どうかの検証が面倒なので手が出せない

テストエンジニアの役割 テストエンジニアというロールが開発チームに参加する場合、テスト エンジニアの役割はWFとスクラムで異なる。 ● テストケースの検討やテストコード作成は開発エンジニアが行う ► 理想的には、TDD（テスト駆動開発）でテストコードを書くので、テ ストケースを考えたりテストコードを書くのは開発エンジニアの仕事 ● では、テストエンジニアの役割とは？ ► テストのルールや観点を考える ✔ どの範囲まではテストコードを書くべきで、どの範囲は手動テストで行う か取り纏める ✔ 単体テスト・結合テスト・システムテスト・受け入れテストではそれぞ れ、どのようなレベルのテストを行うかについて観点として取り纏める ► テスト自動化を推進する ✔ テスト自動化の重要性をチームメンバーに説く ✔ テスト自動化の下地を作る ✔ テストフレームワークの選定 ✔ テストコードの書き方を教育 ✔ アサーションの書き方の例を作る ✔ モックやスタブを使うちょっとむずかしいテストの書き方の例を作る などなど

質問Time ※全員に質問 テストコードを書いたことはありますか？ 書いたことがある人は、テストコードを書くと きにどのあたりが難しいと感じましたか？ テストコードがあると、ビジネスコードの改善 （リファクタリング）を安全に行うことができ ます。安全に行える理由を説明してください。 また、リファクタリングを行うとどのようなメ リットがありそうでしょうか？