自動テストの作成・実行の習慣がないチームに、それを導入した経験がある方の経験談が知りたいです。
参考：コミットログを書く文化がないチーム https://teratail.com/questions/12542
追記 (2015-09-25)
最近、読んだ本にこんな文がありました。
https://kindle.amazon.co.jp/post/mpWzXQrCS9WpA-HTl2cIcw
学校や研修で、テストを書いてグリーン状態を保ちながら改善、拡張をしていくという経験をした人が増える(増やす)ことが大事なのかもしれません。
(シノゴノいうより経験しさえすれば...)
追記 (2015-11-07)
・11/31 時点で 評価点数が一番多かった回答をベストアンサーにしようと思います。
追記 (2015-10-04)
・teratail サイトでは機能追加、変更の際にどんなテストを実施しているのかを知りたいです。
追記 (2015-09-17)
* github のサービスで テストのコードカバレッジレポートを作ってくれるものがあります。(coverails)
レポート例： https://coveralls.io/builds/867027/source?filename=lib%2Fboard.rb
学校や新人研修でのプログラミングの課題の評価は,
テスト・カバレッジを含めることが当たり前
のことになればと思っています。
参考：コミットログを書く文化がないチーム https://teratail.com/questions/12542
追記 (2015-09-25)
最近、読んだ本にこんな文がありました。
https://kindle.amazon.co.jp/post/mpWzXQrCS9WpA-HTl2cIcw
... テストは病みつきになるという私の主張にみなさんが同意しないかもしれない唯一の理由は、みなさんが試してみたことがないということです。...
学校や研修で、テストを書いてグリーン状態を保ちながら改善、拡張をしていくという経験をした人が増える(増やす)ことが大事なのかもしれません。
(シノゴノいうより経験しさえすれば...)
追記 (2015-11-07)
・11/31 時点で 評価点数が一番多かった回答をベストアンサーにしようと思います。
追記 (2015-10-04)
・teratail サイトでは機能追加、変更の際にどんなテストを実施しているのかを知りたいです。
追記 (2015-09-17)
* github のサービスで テストのコードカバレッジレポートを作ってくれるものがあります。(coverails)
レポート例： https://coveralls.io/builds/867027/source?filename=lib%2Fboard.rb
学校や新人研修でのプログラミングの課題の評価は,
テスト・カバレッジを含めることが当たり前
のことになればと思っています。
-
クリップを取り消します
-
質問の評価を上げたことを取り消します
-
質問の評価を下げたことを取り消します
checkベストアンサー
+20
私はフリーランスという立場上、個人的に作業するか大プロジェクトの片隅で与えられたら仕事を黙々とこなす（＝郷に入っては郷に従え）という状況なので、導入経験は無いのですが･･･
少し離れた位置から 醒めた 目で眺めて見ると、自動テストの作成・実行を習慣化するのは至難の業であり、通常業務の片手間に実施出来ることではありません（と思います）。
ではまず、作成を根付かせるポイントから。
以前にどこかの質問の回答でも触れましたが、JUnitをテストツールと位置付けて、仕様変更の後追いをしている様ではまず成功しません。最初は良くても長続きする事は無いでしょう。
何故ならば、既に完成している仕様に合わせてテストクラスを書くと言うことは、まずテストクラスが仕様通りであることを テスト しなければならず、短納期かつ仕様変更の多い昨今では、納期が膨らむか、最悪、テストクラスが完成したかしないかのうちに仕様が変わりいつまで経ってもプログラム本体の実装に取り掛かれないという状況に陥りかねません。
それを打開する方策の一つとして登場したのがテスト駆動開発です。
これはテストを先にやる方法であると安直に説明される場合もありますが、それは間違いです。
そうではなく、詳細設計の成果物として、利用やメンテの難しい従来型の詳細設計書を作成するのを止めてしまい、浮いた時間で動く詳細設計書をテストクラスという形で作成するという開発手法です。
そのメリットを幾つか列挙すると
つまり、付け足し作業ではなく、開発プロセスの中で自動的に生成され、掛けた労力が十二分に報われる仕組みになっているので、その価値を理解できれば習慣化も容易になるというものです。
ただし、開発プロセスそのものの変更を余儀なくされるので、若手中心の小規模案件からパイロット的に開始して実績を積んで行くのが良いと思います。
次に、実行を根付かせるポイントについて。
実は、こちらもポイントは自動化です。
そもそも人間の脳は
更に、もし手作業で確実に実施出来たとしても、品質担保の為に
テストの自動実行の仕組みは、これらの課題を一掃する可能性を秘めた極めて有望なツールです。
以上をまとめると、
もちろん、言うは易く行うは難しですから、遠い異国へ宣教旅行へ行くような覚悟が必要だと思いますけれども。
最初の改宗者を見つけるまでは、とにかく前だけ見て頑張ってください。
少し離れた位置から 醒めた 目で眺めて見ると、自動テストの作成・実行を習慣化するのは至難の業であり、通常業務の片手間に実施出来ることではありません（と思います）。
ではまず、作成を根付かせるポイントから。
以前にどこかの質問の回答でも触れましたが、JUnitをテストツールと位置付けて、仕様変更の後追いをしている様ではまず成功しません。最初は良くても長続きする事は無いでしょう。
何故ならば、既に完成している仕様に合わせてテストクラスを書くと言うことは、まずテストクラスが仕様通りであることを テスト しなければならず、短納期かつ仕様変更の多い昨今では、納期が膨らむか、最悪、テストクラスが完成したかしないかのうちに仕様が変わりいつまで経ってもプログラム本体の実装に取り掛かれないという状況に陥りかねません。
それを打開する方策の一つとして登場したのがテスト駆動開発です。
これはテストを先にやる方法であると安直に説明される場合もありますが、それは間違いです。
そうではなく、詳細設計の成果物として、利用やメンテの難しい従来型の詳細設計書を作成するのを止めてしまい、浮いた時間で動く詳細設計書をテストクラスという形で作成するという開発手法です。
そのメリットを幾つか列挙すると
- 複雑な仕様でも、厳密に定義しやすい
- 仕様通りかどうかは、動かしてみれば一目瞭然（OK:緑、NG:赤）
- 仕様変更の度に「後追い」で設計書のメンテをしなくて良い
- 設計完了時には単体テストの自動化も完了
- 作成したテストクラスは、コーディング時から各種テスト行程での回帰テスト、更にはエンハンス期間全体を通して利用できる
つまり、付け足し作業ではなく、開発プロセスの中で自動的に生成され、掛けた労力が十二分に報われる仕組みになっているので、その価値を理解できれば習慣化も容易になるというものです。
ただし、開発プロセスそのものの変更を余儀なくされるので、若手中心の小規模案件からパイロット的に開始して実績を積んで行くのが良いと思います。
次に、実行を根付かせるポイントについて。
実は、こちらもポイントは自動化です。
Jenkinsのようなツールが作成されもてはやされているのは、ビルドやテストなど、単調で面倒だけど速く正確に実施しなければならないタスクを自動化するためです。
そもそも人間の脳は
退屈を最も嫌います。また、同じ様な事を何度もやっていると、どこまでやったかを簡単に忘れてしまいます。
更に、もし手作業で確実に実施出来たとしても、品質担保の為に
証跡を残さねばならないとすれば、それもかなりの負担です。
テストの自動実行の仕組みは、これらの課題を一掃する可能性を秘めた極めて有望なツールです。
以上をまとめると、
- 若手中心の小規模案件から
- 習慣化を強要するのではなく
- 最初は簡単なところから
- 成果が無理なく「自動的に」得られる様に手順や仕組みを整備する
もちろん、言うは易く行うは難しですから、遠い異国へ宣教旅行へ行くような覚悟が必要だと思いますけれども。
最初の改宗者を見つけるまでは、とにかく前だけ見て頑張ってください。
+17
自分の習慣を改めることでさえ至難の業なのに、他人の習慣を変える事の難しさは想像を絶するでしょう。というか、自分の場合は失敗しました。3年かけても変わらなかったので、自分がチームを変える決断をしました。失敗談でも良ければ聞いてください。
そんな言うほどやってないでしょ、と思われるかもしれませんが、結構がんばったつもりです。それでもチームメンバーの習慣を変える事はできませんでした。とった戦略が間違ったものだったのだとふりかえります。
まずは任天堂の故岩田社長の言葉を紹介します。
余程の組織でなければ、ソフトウェアをリリースする前にテストは行っているはずです。そのテストは手動で、人の目で確認しています。「その方が安心だ」派もいます。最終的な確認はもちろん人の目で行うべきですが、もっと小さなサイクルで行う事で細かなバグを防ぐのが自動テストの利点の1つです。
「全て自動でテストを行う」といった過激な事は言っていなかったつもりですが、そのように受け取られていたのかもしれません。
「自動テスト」の効果は「開発効率を上げること」ではありません。「開発効率が下がらないようにすること」です。そのため、実践した時の効果が見えづらい宿命にあるように思います。
たくさんテストケースを書いても実行時間が伸びるだけでバグの捕捉ができないかもしれません。そのため、最低限のテストを実行するように、後から間引くなどの調整が必要です。良いテストケースはどんなケースで、どんなテストケースはダメなのか、議論することも必要です。
はてさて、質問者さまの環境はどんな環境でしょうか？日々の開発についてふりかえり、チームで話ができる環境でしょうか？その環境はお互いの意見を率直に交換ができる環境でしょうか？もっと良いやり方はないか、という点において貪欲に追求しているチームでしょうか？
ただ「自動テストっていういいやり方があるんだよ」っていうのを紹介するだけでは根付かない理由はそういうところにもあるように思います。
文化を変える事に一番大事なこととして「諦めないこと」を上げる方がいます。それは否定しません。ただ、残念ながら人生の時間は有限です。文化を変えようとチャレンジしたことは、得難い経験です。ただの自己肯定ですが、その経験を糧に新たな道を歩むのも悪い選択じゃないと思ってます。
ぼくは、自動テストの導入の手前の「自分たちの開発のやり方を真摯に考えられるチーム作り」のところまではなんとかできました。後は種をまいたので、チームのみんながそれぞれ学び、芽吹いてくれることを祈りつつ次の一歩を歩みます。
参考: FEARLESS CHANGE アジャイルに効く アイデアを組織に広めるための48パターン
自動テストの導入のために3年間で行ったこと
そんな言うほどやってないでしょ、と思われるかもしれませんが、結構がんばったつもりです。それでもチームメンバーの習慣を変える事はできませんでした。とった戦略が間違ったものだったのだとふりかえります。
- レガシーコード改善ガイドの読書会
- 開発環境構築手順書にしれっとテスト用のツール導入を追加
- ユニットテスト及びテスト駆動開発導入のためのワークショップ
- Code Retreatという設計技術を磨くイベントの開催
- 日々の開発でペアプロで回し、率先してユニットテストをデモ
なぜ普及しなかったのか？
現状の否定をされて嬉しい人はいない
まずは任天堂の故岩田社長の言葉を紹介します。
成功を体験した集団を、
現状否定をして
改革すべきではないと思います。
その人たちは
善意でそれをずっとやってきて、
しかもそれで
成功してきている人たちなんですから、
現状否定では理解や共感はえられないんです。余程の組織でなければ、ソフトウェアをリリースする前にテストは行っているはずです。そのテストは手動で、人の目で確認しています。「その方が安心だ」派もいます。最終的な確認はもちろん人の目で行うべきですが、もっと小さなサイクルで行う事で細かなバグを防ぐのが自動テストの利点の1つです。
「全て自動でテストを行う」といった過激な事は言っていなかったつもりですが、そのように受け取られていたのかもしれません。
導入時の成果をうまく説明できなかった
「自動テスト」の効果は「開発効率を上げること」ではありません。「開発効率が下がらないようにすること」です。そのため、実践した時の効果が見えづらい宿命にあるように思います。
たくさんテストケースを書いても実行時間が伸びるだけでバグの捕捉ができないかもしれません。そのため、最低限のテストを実行するように、後から間引くなどの調整が必要です。良いテストケースはどんなケースで、どんなテストケースはダメなのか、議論することも必要です。
はてさて、質問者さまの環境はどんな環境でしょうか？日々の開発についてふりかえり、チームで話ができる環境でしょうか？その環境はお互いの意見を率直に交換ができる環境でしょうか？もっと良いやり方はないか、という点において貪欲に追求しているチームでしょうか？
ただ「自動テストっていういいやり方があるんだよ」っていうのを紹介するだけでは根付かない理由はそういうところにもあるように思います。
最後に
文化を変える事に一番大事なこととして「諦めないこと」を上げる方がいます。それは否定しません。ただ、残念ながら人生の時間は有限です。文化を変えようとチャレンジしたことは、得難い経験です。ただの自己肯定ですが、その経験を糧に新たな道を歩むのも悪い選択じゃないと思ってます。
ぼくは、自動テストの導入の手前の「自分たちの開発のやり方を真摯に考えられるチーム作り」のところまではなんとかできました。後は種をまいたので、チームのみんながそれぞれ学び、芽吹いてくれることを祈りつつ次の一歩を歩みます。
参考: FEARLESS CHANGE アジャイルに効く アイデアを組織に広めるための48パターン
投稿
![退会済みユーザー](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="95" height="95"><rect fill-opacity="0"/></svg>){kind=small}
退会済みユーザー
-
コメントを読んで、思ったことをつらつらと。
テストの自動化の習慣化をするため、CI環境を整備しておくことは大事ですね。実績として示すための補助的な資料を残しておきます。
「手で動作確認を行う」ことは最終的には必要なことです。ちゃんと仕事をしたいエンジニアほど手で確認する事を好みます。それはそれで大事なことに疑う余地はありません。
ただ、「手で動作確認を行う」ことの手順は下記のような感じになると思います。
1. アプリケーションを起動する
2. 確認する機能まで画面を遷移させる
3. 実際に動作確認する
これら全てを行うので、その時間は少なくとも1分、長いと10分以上かかります。これを修正と確認の流れまでざっくりと書くと下記のようなフローになります。
1. 修正する(25min作業)
2. 確認する(5min作業)
2-1. 確認してOKだったら次のタスクに移る
2-2. 確認してNGだったら1.に戻る
ざっくり時間も見積りましたが、修正を確認してNGだったら毎回0.5h使う計算です。
では、自動テストが導入されていた場合、修正にかかる時間はどの程度でしょうか？
1. バグを再現するテストケースをユニットテストとして書く(5min作業)
2. 修正する(25min作業)
3. 修正箇所を対象にしたテストを流す(数秒)
3-1. 確認してOKだったら4.に移る
3-2. 確認してNGだったら2.に戻る
4. 対象のクラス全体のテストを流す
4-1. 確認してOKだったら5.に移る
4-2. 確認してNGだったら2.に戻る
5. アプリケーションを起動し確認する(5min作業)
6-1. 確認してOKだったら次のタスクに移る
6-2. 確認してNGだったら1.に戻る
ざっくりですが、バグの修正の時間に0.5h以上かかります。テストケースをかかない時よりも長くなります。しかし、1修正あたりにアプリケーションを起動して確認するまでの回数は減るはずです。
これが、テストコードで失敗を確認する方が問題が判明するまでの時間が短くなるであろう根拠です。
注意しなければならないのは、SeleniumなどのUIの自動テストツールも手で確認するテストと同様の時間がかかることです。自動で行う分多少は高速ですが、積み上げると結構なコストになります。しかも手でテストした時は人がいい感じにエラーを拾い上げる事ができますが、UIの自動テストツールは定義された検証しかしません。Seleniumなどのツールの導入は別の話として話す必要があるということです。
あと、テストを自動化しているからと言って、人の目で確認することがなくなるわけではありません。ちゃんと仕事をするエンジニアほど「手で動作確認を行うこと」を好みます。彼らの仕事は大事ですから、自動テストを導入する課程で気にしてみてください。
(この辺りの感覚をQAを本職とする方と話してみたいです。) -
職業QAエンジニアです。
開発エンジニアの方が、テストの自動化技術や品質関連技術に知識や行動の裾野を広げられていることに敬意を表します。
QAエンジニアからの視点でコメントさせてください。
「2」の方も仰っていますが、品質エンジニアは「QCD」のうち、Qに注力します。
しかしながら、開発エンジニアやPMは主に「D」に注力し、ビジネスサイドは「C」及び収益性に注力します。
職責なので当然と言えば当然です。
この前提が成立するという仮定ではありますが、開発エンジニアとQAエンジニアが自動テストを導入する目的となる視点の主な差異は「D」と「Q」なのではないかと考えます。
開発エンジニアは開発効率を上げるために自動テストをすべきだ、
QAエンジニアは品質を上げるために自動テストを導入すべきだ、といった視点の違いです。
ですので、QAエンジニアが望むテストとは品質を向上させるうえで確実性の高い検証ができる自動テストになるのではないかというのが私の考え方です。
自動テスト自体がシンプルで保守性に富み、確実な再帰実行ができるものであれば勿論導入すべきであると判断できますが、それ自体が煩雑であり信頼性に欠けるものであれば目視検証の方が確実だといえるわけです。
あくまでこれが建前となりますが、実地のQAエンジニアの中には
・テストコードが書けない（または自信がない。コードを書くことにアレルギーがある。）
・テストを自動化されると立場がなくなることを恐れている
・フォールト攻撃（経験と勘による探索的なテスト）に生きがいを感じている
等、行動心理学的というか、至極合理的には行動しない担当者も少なからずいる気がしてなりません。（肌で感じる程度ですが）
これらの本音と建て前が「手動テスト」を肯定させている動機だと思いました。
また、開発担当者の視点として「自動化＝生産性向上」という観点に翻って見ると、
手戻りを防止すること、リリース前に不具合の有無を確認できることが生産性の向上に繋がるわけですが、
新たに発生する作業と、それらに係る保守作業、教育に掛かる時間的なコストが一般的にどの程度なのか、
一刻を争うプロジェクトに投入されている担当者が心理的な障壁を感じずに導入できるのかある程度考慮する必要があると思います。
これらについては恐らくそれは3年越しの大変なご苦労をされているかと思いますので、恐らくそこに起因する問題ではないのかなと推察します。
そこで、私なりの勝手な推察で一点引用をさせて頂ければと思います。
的外れであれば申し訳ありません。
-----------------------
※ロジャーS.プレスマンの「実践ソフトウェアエンジニアリング」からの引用です
ソフトウェアエンジニアリングは、「ツール」、「手法」、「プロセス」の階層があり、
一番底辺には「品質中心の文化」があるといいます。
[ツール]
[ 手法 ]
[ プロセス ]
[ 品質中心の文化 ]
-----------------------
事情はどうあれ、多くの商品企画や、開発速度優先の組織において、根底となるマインドセット「品質中心の文化」が無いように思えます。
これを「正」とするのであれば開発方法は品質の重要性に関する絶え間無い教育
（過去の一番炎上したプロジェクトの原因の究明とテスト自動化必要性の教育等）や、
それこそ経営に甚大な影響を与える市場不具合が発生し、トップダウンでの品質改善命令が下る、などの大きい変化が必要なのではないかと、考えます。
何はともあれ、政治的な目的や行動心理学的要素を排除して
品質や改善意識の高い開発エンジニアと、「Q」と「D」と、「理想像に近づけるための現実的な手段」を考慮できるQAエンジニアとが
仲良くタッグを組める状況を作りたいものですね。
本コメントが問題意識の高い全てのエンジニアの問題解決の一助になることを願います。 -
knightさん、コメントありがとうございます。こういう議論がしてみたかった(・∀・)
> 政治的な目的や行動心理学的要素を排除して
> 品質や改善意識の高い開発エンジニアと、「Q」と「D」と、「理想像に近づけるための現実的な手段」を考慮できるQAエンジニアとが
> 仲良くタッグを組める状況を作りたいものですね。
おっしゃるとおりです。1点お話を読んでいて感じた事を共有します。
開発速度を優先する組織において、「Q」を向上する取り組みが必要になる場面があります。いわゆる「技術的負債の問題」です。「技術的負債」が大きな組織では、だんだんと「D」が遅くなります。「D」が経営層の期待するものでなくなった時、「テストの自動化」等の取り組みを行う事で「Q」を向上し、「D」の改善を目指すのがゴールです。そういう意味では経営層からの理解は得られていました。ただ、自分、及び経営層が考えている課題感を同僚に上手く伝えられなかったのが自分の失敗の一因です。
「品質中心の文化」ではないところに「品質を文化に持ち込み、『品質中心の文化』を根付かせる」事が「自動テストを書く習慣がないチーム」に必要です。「品質中心の文化」のマインドセットがなければ「TDDなどのやり方を共有すること」をいくらやっても無駄でしょう。
結局のところ、「自動テストの習慣化」みたいな話は「文化を変えていく取り組み」ですね。
+4
自動テスト（各種ユニットテストやらSelenium、Mercuryの導入など）というのは、開発工程だけで捉えていては導入が難しい、と感じます。
少なくとも開発工程の工数を圧迫する作業なので、
・開発者にメリットとデメリットを理解してもらう
・コストを管理している人や部門にメリットとデメリットを理解してもらう
という2側面があります。導入にあたって、前者に注目してしまいがちですが、後者もかなり重要です。
おおむね、プロジェクトは
・Cost
・Quality
・Delivery
という要素で成立しており、自動テストの導入は、
・Qの担保のために投入するCの削減
・それにより同等のCを投入する場合におけるDの短縮化
であることを具体的な推定値で関係者（特にコスト管理者・部門）示すのがキモです。
また、自動テストのもうひとつの特性として、「仕様がテストケースとして凍結される」という
ことが挙げられます。仕様が未凍結、あるいは不明確な状況ではテストを作成できませんから、開発工程に入る前の上流工程で漏れがないか、運用計画が破綻していないか、といったプロジェクトのロジックの点検になります。
さらに、あまり気付いていないメリットとして、プロジェクトの成果であるプログラムとテストフレームワーク（テスト ランタイムとシナリオ）は、償却対象の資産であり、資産の価値を下げないためのテストによる点検・棚卸しが可能になる、ということが挙げられます。安全区間を立証できないプログラム資産は、たとえばローンチ後の改変や機能追加によって非安全区間が顕在化することによるサービス停止・安定性の低下・サービス リソースの枯渇といった、不良債権化することがあります。自動テストによる回帰テストで担保されるケースが多いと予想されます。自動テストの成果物は資産価値に対するリスクヘッジでもある、という側面は、経営層や株主に対して説明しやすいのではないでしょうか。
まとめますと、自動テストの導入にあたって、開発者だけを対象に説得する（あるいは布教する）というのは、あまり有効ではなく、より幅広いステークホルダーが理解できるように努める必要がある、ということです。そして、自動テストが万能なわけではない、ということも伝えておく必要がありますね。人月の神話ではありませんが、銀の弾丸などないのですから。
少なくとも開発工程の工数を圧迫する作業なので、
・開発者にメリットとデメリットを理解してもらう
・コストを管理している人や部門にメリットとデメリットを理解してもらう
という2側面があります。導入にあたって、前者に注目してしまいがちですが、後者もかなり重要です。
おおむね、プロジェクトは
・Cost
・Quality
・Delivery
という要素で成立しており、自動テストの導入は、
・Qの担保のために投入するCの削減
・それにより同等のCを投入する場合におけるDの短縮化
であることを具体的な推定値で関係者（特にコスト管理者・部門）示すのがキモです。
また、自動テストのもうひとつの特性として、「仕様がテストケースとして凍結される」という
ことが挙げられます。仕様が未凍結、あるいは不明確な状況ではテストを作成できませんから、開発工程に入る前の上流工程で漏れがないか、運用計画が破綻していないか、といったプロジェクトのロジックの点検になります。
さらに、あまり気付いていないメリットとして、プロジェクトの成果であるプログラムとテストフレームワーク（テスト ランタイムとシナリオ）は、償却対象の資産であり、資産の価値を下げないためのテストによる点検・棚卸しが可能になる、ということが挙げられます。安全区間を立証できないプログラム資産は、たとえばローンチ後の改変や機能追加によって非安全区間が顕在化することによるサービス停止・安定性の低下・サービス リソースの枯渇といった、不良債権化することがあります。自動テストによる回帰テストで担保されるケースが多いと予想されます。自動テストの成果物は資産価値に対するリスクヘッジでもある、という側面は、経営層や株主に対して説明しやすいのではないでしょうか。
まとめますと、自動テストの導入にあたって、開発者だけを対象に説得する（あるいは布教する）というのは、あまり有効ではなく、より幅広いステークホルダーが理解できるように努める必要がある、ということです。そして、自動テストが万能なわけではない、ということも伝えておく必要がありますね。人月の神話ではありませんが、銀の弾丸などないのですから。
投稿
score 47
-
私は次の講演を聞いたことがあります。
http://www.publickey1.jp/blog/12/_jasst12_tokyo.html
> マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo
テストをどう捉えるか？は組織によって大きな差があるようです。その差はどこからうまれるでしょうかね。 -
管理者からの上意下達、開発者からのボトムアップ、いずれのモデルで考えるのが適切な組織なのか、によるのではないでしょうか。上意下達の実効性能が高い組織であれば、開発者からのボトムアップを指向しても衆愚的民主主義の悪しき側面そのものになるでしょうし（質問者のケースはこれに近い気がします）、逆もまた然りなのでしょう。また、権限者はあくまで数字の管理者であるのか、それとも実態に対する指導的立場なのか、によっても異なるでしょうね。
いずれにせよ、対象となる組織や社会空間の構造をきちんと類型化することが肝要なのだと思います。
※暴力的か、融和的か、といった浸透までの手段の選択にも影響しますし。
+2
導入するためのハードルが複数あって
私の経験した範囲では、一旦リリースした後に自動テストを追加する事例が多いです。
ただ、最初から自動テストを作るプロジェクトのほうが、後々で炎上することは少ないように思います。
ちなみに、ユニークな事例として、開発時にドキュメントを廃止してTDDのテストコードが仕様書だと言い切ったものがあります。
こちらは仕様がユースケースとして明確化できたので後々の機能追加が比較的容易でした。
- 発注元が自動テストを知らない
- 開発メンバが自動テストを知らない
- 開発期間が短い
- バグ修正に時間を割いたため自動化する時間がない
- リリース後の機能追加も同じ開発メンバでやるとは限らない
私の経験した範囲では、一旦リリースした後に自動テストを追加する事例が多いです。
ただ、最初から自動テストを作るプロジェクトのほうが、後々で炎上することは少ないように思います。
ちなみに、ユニークな事例として、開発時にドキュメントを廃止してTDDのテストコードが仕様書だと言い切ったものがあります。
こちらは仕様がユースケースとして明確化できたので後々の機能追加が比較的容易でした。
投稿
score 318
-
> ... DDのテストコードが仕様書だと言い切った...
それ凄いですね。
+1
このスレッドを読んだ、思いつきなので、すでに存在しているのかも…と思いながら書いてます。
「テストコード」をもとに、「詳細設計書」と「テスト仕様書」「テスト報告書」をドバッと出力してくれるようなものあったら…テストコードを書くことが手間にならないかなと。
すみません、思いつきです。
「テストコード」をもとに、「詳細設計書」と「テスト仕様書」「テスト報告書」をドバッと出力してくれるようなものあったら…テストコードを書くことが手間にならないかなと。
すみません、思いつきです。
投稿
退会済みユーザー
-
BDDフレームワークを使って、テスト仕様書とテスト報告書を自動作成することはよくあります。テスト言語でいうと、RSpecやcucumberやJasmineなどを使います。
詳細設計はJavaDocかDoxygen相当のものを使うので、テストコード側からの紐付けはあまりしません。
+1
工学的でなく、精神論的に・・・
テストするという行為が自分の失敗をさらけ出すというマイナスイメージをもってしまっていると、嫌なものという精神的負担があるのかな？と感じます。
テストコードが、使い方のサンプル集のような位置づけで便利なものというようなプラスイメージへ転換できれば、すすんでテストコードを書いてから、コーディングする癖がつくのかなと思ったりしますが、理想論でｼｮｳｶ。
プログラムを書いていると、たとえば、道を渡る時、なかなか変わらない信号があって、たまに青ならすぐわたっちゃえるけど、ほぼ陸橋をわたった方が、かかる時間が一定で結局早く着くのに、距離や楽さ、たまにすぐ渡れた時の快感？から信号を待ってしまう、そんな気持ちに似ている気がします。
幾らマネージャ的な視点から、結局こっちの早いよといっても、陸橋を渡る事にメリットが無いと楽な方へ流れます。
陸橋をわたる(テストコードを書く)と、好きな子とすれ違える(他の人が書いた素敵なコードに出会えるかも？ちょっと違うか・・・)的な、メリットを感じれば喜んで陸橋わたります(テストコード書きます) ;-)
あとは、やってみせ、言って聞かせて、させてみせ、 ほめてやれば、人は動くかもしれません。
テストするという行為が自分の失敗をさらけ出すというマイナスイメージをもってしまっていると、嫌なものという精神的負担があるのかな？と感じます。
テストコードが、使い方のサンプル集のような位置づけで便利なものというようなプラスイメージへ転換できれば、すすんでテストコードを書いてから、コーディングする癖がつくのかなと思ったりしますが、理想論でｼｮｳｶ。
プログラムを書いていると、たとえば、道を渡る時、なかなか変わらない信号があって、たまに青ならすぐわたっちゃえるけど、ほぼ陸橋をわたった方が、かかる時間が一定で結局早く着くのに、距離や楽さ、たまにすぐ渡れた時の快感？から信号を待ってしまう、そんな気持ちに似ている気がします。
幾らマネージャ的な視点から、結局こっちの早いよといっても、陸橋を渡る事にメリットが無いと楽な方へ流れます。
陸橋をわたる(テストコードを書く)と、好きな子とすれ違える(他の人が書いた素敵なコードに出会えるかも？ちょっと違うか・・・)的な、メリットを感じれば喜んで陸橋わたります(テストコード書きます) ;-)
あとは、やってみせ、言って聞かせて、させてみせ、 ほめてやれば、人は動くかもしれません。
投稿
score 1684
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.13%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
katoy
2015/12/04 20:26
でも引き続き、回答の投稿・更新は大いに歓迎いたします。