タグ

テストとソフトウェア開発に関するkawachoのブックマーク (11)

  • 品質に厳しい組織で、なぜ品質が劣化するのか? - 現場のためのソフトウェア開発プロセス - たかのり日記

    このエントリーは「Software Test & Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる/苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG(Software Engineering Process Group)という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない

    品質に厳しい組織で、なぜ品質が劣化するのか? - 現場のためのソフトウェア開発プロセス - たかのり日記
  • クオリティエンジニアの役割とは「お客様の視点を提供すること」 ~ セールスフォース・ドットコムの作り方(後編)

    クラウド上に構築した企業向けアプリケーションを提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、サービス開発を行っています。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」が行ったセッションの内容を紹介します。 (記事は「大規模アジャイル開発の実態~ セールスフォース・ドットコムの作り方(前編)」の後編です) クオリティエンジニアの役割について 開発においてクオリティエンジニアが果たす役割は結構大きい。スクラムチーム内のコミュニケーションのハブとして積極的に働いている。デベロッパは

    クオリティエンジニアの役割とは「お客様の視点を提供すること」 ~ セールスフォース・ドットコムの作り方(後編)
  • TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ

    TDD Boot Camp 北陸行ってきました。 TDDはテストドリブンデベロップメントの略で、自働テストを書いてから実装を書くというスタイル。ここでよく誤解されるのだけど、業務でおなじみ単体テストや結合テストといった網羅的なテストを記述してから実装を書くわけではない。目の前の1歩分、ひとつだけテストを書き、すぐさま実装を書いて自働テストをグリーンにする、というやり方をするのだ。こればかりは実際にやってみないと誤解は解けないかもしれない。 さて、深夜のテストTL - Togetterや、TDDはテスト手法か否か - Togetterで議論されている「TDDは品質保証の手法ではない」という部分に関する議論。ここでいう「品質保証」はバグがないこと、ソフトウェア品質の12の属性でいう信頼性(reliability)が高いことを指す。 TDDのスタイルには網羅的な検査をしてバグをあぶりだすようなフ

    TDDはテスタビリティの保証をしてくれるのかも - プログラマーの脳みそ
  • そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記

    会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその

    そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
  • テスト駆動開発の効果はどのくらいある?

    ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」(Test-Driven Development:TDD)。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ

    テスト駆動開発の効果はどのくらいある?
  • TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等) - 千里霧中

    先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基的にKent Beckや和田さんが使われているQAテストの定義によるもの(http://gihyo.jp/dev/serial/01/tdd/0003)。 この定義で「品質保証のための単体テスト

    TDD談義への反応に対する雑感(テスト駆動開発を取り巻く誤解等) - 千里霧中
  • なぜUnitTestは理解されない?

    TwitterでこんなTweetが流れた… エビデンスとしてNUnitGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに? 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの(ex. テスト設計書、テスト仕様書、...) テスト結果の証拠(ex. 画面ハードコピー、DBスナップショット、...) UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの = テストコード テスト結果の証拠 = 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使

    なぜUnitTestは理解されない?
  • 書籍「基本から学ぶソフトウェアテスト」を元にした講義資料 — ありえるえりあ

    対象読者 ソフトウェアテストを勉強したい人 を読むのが面倒で、手っ取り早くポイントだけ知りたい人 アリエル固有のことは書いていないので、テスト技術者の教育担当者は、講義資料として使ってください 1. テストの進め方 テストの前に対象ソフトウェアを理解すること バグ1件ごとにバグ報告を書くこと(複数のバグを同じレポート内に書かないこと) 正しく動かないはず、と思ってテストすること 境界条件を意識すること 最小限の再現条件を探す努力をすること 普通の使い方(正常系)でまともに動作しない場合、テストの中断も考慮すること(時間の無駄かもしれないので) wontfix(修正しない)の返答に対して、その判断を無批判に受け入れないこと(プログラマはwontfixの判断をよく間違えるので) リリース間際の場合、修正しない判断には高度に政治的な背景があるかもしれないので、こだわりすぎないこと 格言:優秀な

  • UIオートメーションによる自動UIテストの実践 ― @IT

    特集:UIオートメーションによる自動UIテストの実践 WindowsアプリのUIテストを自動化しよう クロノス 亀野 弘嗣 2008/06/03 読者の方々は、UI(ユーザー・インターフェイス)にかかわるテスト(以下UIテスト)を自動化できているだろうか? UIテストを自動化しようとしても、UIテストのコードは記述しにくく、記述方法に一貫性がない、などの理由から、自動化をあきらめる場合が多いのではないだろうか。 .NETの開発においても単体テストの自動化は一般的に行われるようになってきているものの、UIテストの自動化はそういった理由で実現が難しく、あまり行われていないのが現状だ。 そこで稿では、標準的で一貫性のある記述ができるMicrosoft UIオートメーション(以下UIオートメーション。詳細後述)と、テスト・ツールであるNUnitを使用して、UIテストを自動化する方法を紹介する(N

  • CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance:レグレッション・テストに逆ギレ

    どうも更新が滞りがちですが、いよいよ新サービスのリリース・カウントダウンが始まりました。寝ても覚めても開発とバグ取りにいそしむ中毒状態で、メールにさえろくに返事ができておらず、ゴメンなさい!いましばらくご辛抱下さい! 近況としては、IRS(米国税局)から「キミはちゃんと確定申告を期日までに行わなかったからペナルティじゃ」という、折り目正しくきちんと納税した人間に対してありえない通告があったので、先方が真っ先に小切手を振り出した記録をこれでもかと全部コピーして送りつけて、お前たちはドロボーかと詰問して謝罪をとりつけたり、相棒のダニーが唐突に投票権を持つ米国民の義務であるJury Duty(陪審員義務)に駆り出されて一週間まるまる留守になったり、歯医者に行ってチェックアップしてもらったら$800/月もの医療保険に加入しているにもかかわらず$4,000という高額な治療費の見積もりをもらって開いた

  • マイクロソフト、従業員に懸賞金:「バグ修正1件ごとに100ドル」

    MicrosoftのトップエンジニアWindows Vistaチームに週末用の課題を出した。コードからバグを見つけ出し、これを修正したエンジニアは、100ドルを獲得できるというものだ。 さらに、Vistaの最新ビルドを自宅のマシンにインストールし、月曜日までに最も多くのバグを修正した社員には、さらに500ドルが支払われるという。 Brian Valentine氏は米国時間12日、次期WindowsであるVistaの開発チームメンバーに電子メールでこの課題を告知した。 このような課題が出されたのは、Vistaの大規模なテスト版の開発が終了に向かっているためである。Windows観測筋の多くは、次のテスト版が5月中にリリースされるものと予想している。Microsoftは今四半期、予定通りおよそ200万人のユーザーにテストバージョンを配布するという。 Microsoftは、年内に無事開発を終了

    マイクロソフト、従業員に懸賞金:「バグ修正1件ごとに100ドル」
  • 1