Download as PDF, PPTX
テスト自動化入門@Graat勉強会
- 1.
- 2.
- 3.
- 4.
- 5. プロジェクトからプロダクトへのシフト 大竹 章裕(他). ソフトウェアデザイン2022年3月号. 技術評論社. 2022 “プロジェクトからプロダクトへのシフト があり、ソフトウェアは完成させるもの ではなく継続的な変更と改善を続ける ものになりました。（強調筆者）”
- 6. なぜテスト自動化が必要か？ ● 背景 ○ ソフトウェアは継続的に変更と改善がされる ●品質面 ○ 変更毎に、既存のソースコード、システム、機能が破壊さ れていないかを確認する必要がある ● 開発面 ○ 既存の機能がテストされていることで、安全かつ効率的に 変更できる →(特に機能が増加したソフトウェアで)変更毎の手動による回帰 テストはコスト的に非現実的であり、自動化が必要
- 7.
- 8. 手動テストは継続できない 「アジャイル開発において、技術と品質の重要性は不可欠だ（後編）。Agile Japan 2013」 https://www.publickey1.jp/blog/13/agile_japan_2013_1.html
- 9.
- 10.
- 12. 導入は慎重に テスト自動化の導入には様々なリスクがある リスクを考慮しながら導入する リスクの例 ○ テストツールの効果を過大に期待する ○ テストツールを初めて導入する場合に要する時間、コスト、工数を過 小評価する ○大きな効果を継続的に上げるために必要な時間や工数を過小評価す る 「テスト技術者資格制度Foundation LevelシラバスVersion 2018V3.1.J03」 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
- 13.
- 14. テストの一般的な分類 ● 代表的なテスト ○ UI(エンドツーエンド)テスト ○結合テスト ○ ユニットテスト ● その他のテスト ○ Behavioral Testing ○ Visual Regression Testing ○ Exploratory Testing(探索的テスト) 大竹 章裕(他). ソフトウェアデザイン 2022年3月号. 技術評論社. 2022
- 15. ユニットテスト ● ⭕超高速 ● ⭕多目的に利用できる ●❌結合部分の確認に弱い Jonathan Rasmusson. 初めての自動テスト ―Webシステムのための自動テスト基礎. オライリージャパン. 2017
- 16. 結合テスト ● ⭕つながりを見れる ● ❌詳細さに欠ける JonathanRasmusson. 初めての自動テスト ―Webシステムのための自動テスト基礎. オライリージャパン. 2017
- 17. UI(エンドツーエンド)テスト ● ⭕エンドツーエンドで動く ● ⭕ユーザー視点で対象を見る ●❌高コストで遅い ● ❌UIは比較的変化しやすく、テストが壊れやすい Jonathan Rasmusson. 初めての自動テスト ―Webシステムのための自動テスト基礎. オライリージャパン. 2017
- 18.
- 19. テストピラミッド 「テストの基礎」 https://developer.android.com/training/testing/fundamentals?hl=ja “一般的には、小規模テスト 70%、中規模テス ト20%、大規模テスト 10% の割合でテストを 作成することをおすすめします。”
- 20. テスティングトロフィー(Kent C. Dodds氏提唱) 「Learnthe smart, efficient way to test any JavaScript application.」 https://testingjavascript.com/
- 21.
- 22.
- 23. テスト駆動開発(TDD)とは？ 「テスト駆動開発」 https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA “テスト駆動開発 (てすとくどうかいはつ、英: test-drivendevelopment; TDD) とは、プログラム 開発手法の一種で、プログラムに必要な各機能に ついて、最初にテストを書き（これをテストファースト と言う）、そのテストが動作する必要最低限な実装を とりあえず行なった後、コードを洗練させる、という短 い工程を繰り返すスタイルである。”
- 24. 「レッド・グリーン・リファクタリング」サイクル 1. レッド：動作しない、おそらく最初のうちはコンパイルも通らないテストを1つ書く。 2. グリーン：そのテストを迅速に動作させる。このステップでは罪を犯してもよい。 3.リファクタリング：テストを通すために発生した重複をすべて除去する。 Kent Beck (著), 和田 卓人 (翻訳). テスト駆動開発. オーム社. 2017
- 25. テスト駆動開発(TDD)をめぐる議論 ● TDD isdead. Long live testing. (DHH) ○ https://dhh.dk/2014/tdd-is-dead-long-live-testing.html ● TDDはアーキテクチャに悪影響を与えるか？ ○ https://www.infoq.com/jp/news/2017/04/does-tdd-harm -architecture/
- 26.
- 27. まとめ ● テスト自動化 ○ コストメリットもあるが、継続的に変更および改善するソフト ウェアを維持するためには必須の技術 ○とはいえ様々なリスクがあるため、闇雲な導入はNG ○ テスト分類毎にコスト配分を意識する