Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Test Yourself - テストを書くと何がどう変わるか

30,726 views

Published on

ソフトウェアテストシンポジウム 2014 北海道基調講演
2014年9月5日(金)

Published in: Technology
  • 遅くなりました。コメントありがとうございます。一点誤って書いてしまい、申し訳ありませんでした。

    「テストを書いていて何がどうかわるのか」というお題で、自分の想いを書いてみると、テストを書き繰り返し動かすことで、対象とするものの振る舞いや意図を学ぶ効果が高いように思います。

    TDDをすると、ただコンピュータにチェックさせる事を目的にテストコードを書く、というわけでもないですよね。実際に利用するAPIの視点からコードを書いてみる事で、より良いAPIを探る効果が高いはずです。

    その視点から見てみると、「テストを書くことで対象のシステムをプログラマがより理解できる。また、さらにTDDを行えばコードのレベルでより良いAPIを設計できる。だから品質が上がる」と言えないか、と考えます。

    More Agile Testingが手元に届いたので、読み始めているのですが、序文のLinda Risingさんの言葉が結構胸に来ました。
    'To my mind, agile development is about learning...'

    プログラマにとってテストコードは学ぶためのものでもある。これはTestingですよね。そんなことを思いました。

    2月にデブサミでお会いした時に福井にぜひ遊びに来たいと言っていただき、まだ何も動けていませんが、何かできないか模索します。またお会いした時に色々と学ばせていただきたいです。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • テストを書くと開発の力点が変わり、「動くコードに触れるな」というタブーを打ち破れる。変化に対応するために改善を我慢しなくてよくなる、という話をしました。

    なお、テストを書いても品質は上がらない、ではなく、テストを行っても品質は上がらない、です。

    その前段として、 TDD の T はテストではない、という話をしました。TDD は Testing ではなく Checking です。つまり、 TDD だけでは品質保証にならない。

    しかし、テストだけでも品質は上がりません。テストは品質を測るだけであり、測った結果に基づいてコード/システムに手を入れないと何も変わらない。品質が悪いことがわかるだけだ、という話もしました。

    だから、テストエンジニアとプログラマが手を取り合って互いの知見を生かし、 Testing と Checking を使いこなして既存システムの質を上げていかなければならない、というのが最後に言いたかったことです。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • スライドをみるだけだとよくわからなかったのですが、「テストを書くと何がどうかわるのか」に対する答えはt-wadaさんにとってなんだったのでしょうか?
    「TDDをすると品質が上がる」という結論かとおもいきや、「テストを書いても品質は上がらない」というスライドで終わってて「???」となっています。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Test Yourself - テストを書くと何がどう変わるか

  1. 1. Test Yourself テストを書くと何がどう変わるか 和田 卓人 (a.k.a id:t-wada or @t_wada) Sep 5, 2014 @JaSST Hokkaido ’14
  2. 2. 和田 卓人 id: t-wada @t_wada github: twada
  3. 3. 各所で猛威を振るう t_wada.png
  4. 4. よろしく おねがい します
  5. 5. Q. TDDは、まだ良くわから ないです Q. 具体的な方法が分からない
  6. 6. TDD とは何か
  7. 7. 「動作するきれいなコード」、ロン・ジェフ リーズのこの簡潔な言葉は、TDD(テスト駆 動開発)の目標である。動作するきれいなコー ドは、あらゆる理由で価値がある。 ─ Kent Beck
  8. 8. 動作する、きれいなコードへ きれい 汚い 二つの道がある (すぐには)動かない動作する
  9. 9. TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5. 2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングを行 う(Refactor) 7. 1~6を繰り返す
  10. 10. Refactoring TDDと黄金の回転 きれい 汚い Red Green (すぐには)動かない動作する
  11. 11. TDD や Developer Testing に ソフトウェア工学的なメリットはいろい ろあるけれど、最大の理由は工学的なも のではない。最大の理由は心理的なもの •即座にフィードバックを得るため •書いたコードに自信を持つため •これから書くコードに自信を持つため
  12. 12. デモ
  13. 13. http://www.planetgeek.ch/wp-content/uploads/2012/06/ATDD-cycle.png
  14. 14. Why: 顧客は何故それを欲 しているのか What: 何を作れば 良いだろうか How: どう作れば 良いだろうか 頻繁なリリースとデモ 受け入れテスト ユニットテスト 永和システムマネジメント家永氏の資料より
  15. 15. https://www.facebook.com/notes/kent-beck/when-tdd-doesnt-matter/797644973601702
  16. 16. TDDの 導入効果
  17. 17. TDD導入効果(MS, IBM) © Towersquest, Inc. 2010. all rights reserved. 20 IBM Driver MS Windows MS MSN MS Visual Studio ソースコードサイズ (KLOC) テストコードサイズ (KLOC) TDDを採用していない類似プロ ジェクトでの欠陥密度を1とし たときの欠陥密度 TDD採用により増加したコード 実装時間(管理者の見積による) 41.0 6.0 26.0 155.2 28.5 4.0 23.2 60.3 0.61 0.38 0.24 0.09 15~20% 25~35% 15% 20~25% N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and experiences of four industrial teams, Journal of Empirical Software Engineering, vol. 13, pp. 289-302 (2008)
  18. 18. TDD導入効果(エリクソン他) • TDDを実施した場合に報告されている知見 ‣ 機能テストでの不具合検出数が18%削減された ‣ コーディング(実装)の時間が16%増えた ‣ テストのカバレッジが大きくなった • 被験者を対象としたアンケート ‣ 96%の被験者がデバッグの工数を減らすと感じた ‣ 88%の被験者が要求が洗練されると感じた ‣ 92%の被験者がコードの品質を上げると感じた ‣ 50%の被験者が開発工数を減らすと感じた Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004) © Towersquest, Inc. 2010. all rights reserved. 21
  19. 19. Q. 開発者自身がテストを書く ようになったら テストエンジニアは不要だと 思いますか?
  20. 20. TDDの T について 考える
  21. 21. 「動作するきれいなコード」、ロン・ジェフ リーズのこの簡潔な言葉は、TDD(テスト駆 動開発)の目標である。動作するきれいなコー ドは、あらゆる理由で価値がある。 ─ Kent Beck
  22. 22. “テストとは,エラーをみつ けるつもりでプログラムを 実行する過程である”
  23. 23. http://www.developsense.com/blog/2009/08/testing-vs-checking/
  24. 24. TDD は Checking でしかない
  25. 25. https://speakerdeck.com/everzet/bdd-in-symfony2
  26. 26. http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
  27. 27. Q. テストスクリプトの作成コストと維持。ユ ニットテストケースの運用維持が、確実には 出来ていない Q. テストコード自体はプロダクションコード よりも基準が緩いため、難しかったり煩雑な テストコードが散見し、テストコードのメン テナンス性が悪くなっている
  28. 28. (Checking の文脈での) 良いテストは どんなものか
  29. 29. “F.I.R.S.T” => クリーンテストの5つの規則
  30. 30. Fast Independent Repeatable Self-Validating Timely
  31. 31. “A-TRIP” => 良質なテストの特性
  32. 32. Automated Thorough Repeatable Independent Professional
  33. 33. F.I.R.S.T A-TRIP 共通するもの
  34. 34. Fast Independent Repeatable Self-Validating Timely Automated Thorough Repeatable Independent Professional
  35. 35. xUnit Test Patterns より テストのメンテナンスコスト 理想 現実
  36. 36. Fast Independent Repeatable Self-Validating Timely Automated Thorough Repeatable Independent Professional
  37. 37. テストコードの リファクタリング デモ
  38. 38. Q. テスト駆動開発について、テスト専門の人 にアドバイスを貰ったり、質問したりするこ とはあるのでしょうか?テスト専門の立場か ら、開発へどういった貢献が出来るか模索中 です。 Q. 製品コードの作成者とは別にテストコード の作成者を用意して、テストコードの作成を 進めたいと考えています。留意すべきことが あれば教えてください。
  39. 39. テストは品質を上げない 体重計に乗るだけでは 痩せないのと同じ https://www.flickr.com/photos/tompagenet/2271383143
  40. 40. “テストでは品質は上がらない ですよ。テストはあくまでも品 質をあげるきっかけ。品質をあ げるのはプログラミングです。 これは大昔からそう。”
  41. 41. 自動テストの良いところは、 改善を我慢しなくても良く なったこと
  42. 42. ソフトウェアの質は 自分たちで上げる 自分たちでしか上げられない でも、開発者にはテストの 知識が不足しがち
  43. 43. だから、いっしょにやりましょう http://www.flickr.com/photos/recompile_net/3298985098/
  44. 44. TDDはスキルです •ひとりから始められる •テストやTDDはスキルです。つまり… •才能ではなく、習得可能です •量は質に転化します •写経しましょう!!
  45. 45. gihyo.jpの連載 『[動画で解説]和田卓人の“テスト駆動開発”講座』 http://gihyo.jp/dev/serial/01/tdd/ 全20回すべて動画付き解説 ニコニコ動画でも見れます WEB+DB過去記事の特設サイトと動画も
  46. 46. ご清聴ありがとうございました

×