わたしはちょっと意地悪らしい。 例えば、あるテストケースを思いついたとする（しかもかなりの高確率でうまく動かなそうなやつ）。それをね、モノが出来上がって自分の目でちゃんと動くこと（気持ち的にはちゃんと動かないこと）を見届けるまで、プログラマに話さない。*1 とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ！てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。 なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。 ということは、わた
テスト作業が、開発作業の中にしっかりと組み込まれていない。こうなる と、開発の進み具合を計測することは不可能になってしまう。というのも、あ るの機能が動き始めたのはいつか、またある機能が動かなくなったのはいつか、 まったくわからなくなるからだ。 JUnit を使えば、苦労なく、しかも段階的に、テストスィートを構築 できる。このテストスィートは、進捗状況を把握したり、意図しない副次効果 を見つけだしたり、また開発で労力をかけるべき箇所を明らかにしたりする上 で役に立つだろう。 目次 問題 実例 テストする習慣（プラクティス） 結語 問題 どんなプログラマだって「コードを書いたらテストも書くべきだ」というこ とは知っている。にもかかわらず、実際に書いている人は少ない。「何で書か なかったの？」という質問に対しては、「あまりにも忙しすぎて」という同じ 答えが返ってくる。しかしこれは悪循環のはじま
オープンセミナー2014＠広島に参加しました。 懇親会LT（ライトニングトーク）の私のスライド「テスト駆動開発とアクセシビリティ（仮）」は下記の通りですが、スライドだけではわからないでしょうし、トークも言葉足らずだったので、昼間のセッションの感想をふくめて補足します。 NVDA 日本語版 の紹介。NVDA の開発には Python が使われています。 実は「NVDA日本語チーム」を立ち上げる前に、私はまず「NVDAユーザ会広島」を立ち上げて、地域コミュニティ活動を始めました。 オープンソースカンファレンス2013広島への参加の後、活動が滞っていますが、暖かくなったら再開したいです。 アクセシビリティ、Python、Windows API、テキスト音声合成、自然言語処理、バージョン管理など、NVDA の開発を語る切り口はいろいろあるので、いろいろな団体と交流が必要だと思い続けています。 NV
こんにちは。nayです。TDDと出会ったのは6年以上前ですが、最近、やっと"友達"になることができました。 テストを楽しく積極的に書く心境になれるかどうかは、気だてや価値観や根性の問題ではなく、テクニックの問題であると思います。そこで、テスト嫌いの私がどうやってTDDと友達になれたかを、３つのポイントに絞ってご紹介したいと思います。 1. 関心事だけをテストする 2. DRYにする 3. RSpec 私がテストが嫌いになった理由の一つは、コード変更時にテストが足かせになることです。出るべくして出たエラーはありがたいのですが、関係ない部分で大量にエラーが出ると直すが大変で嫌になってしまいます。また、直そうとしたときに、テストのコードが読みにくいと、難行苦行に直面することになります。最初の２つのポイントは、このようなテストの「丈夫さ」と「読みやすさ」に関わるコツです。 関心事だけをテストする
筆者が新入社員の頃は、毎日テストケースを繰り返し実施していました。夕方には、上司にテストの実施結果を報告して、1日の仕事が終了です。当時のテストログ（その日、行ったテスト実施結果のレポート）には、実施したテストケース（種類・名前等）、実施結果（OK／NG）、実施時間や発生したトラブルなどを記入していました。実施結果がNGのものは、問題管理に事象の登録を行っていました。ふと思うと、テスト結果がNGのものしか振り返りをしていないことに気付きました。 結果良ければすべて良し!! って本当？ さて、ここで少しテスト現場の会話を聞いてみましょう。 中堅社員氏： 「先週のテストの概要を報告してくれ。」 新入社員君： 「はい。先週は、延べ350件のテストケースを実施しました。」 中堅社員氏： 「それで、テスト結果はどうなった？」 新入社員君： 「全てのテスト結果はOKでした。品質には問題なかった
「テストを実施すると必ずバグを見つけることができますか？」と聞かれると、筆者の回答は“No”です。テストによるバグを検出は、実施した結果が期待値と異なる事象のときに発見されます。テストにおいての期待値とは、テスト対象が動作した「正しい結果」です。 テストケースを見ると期待値の設計はされていますが、ほとんどの場合は期待値以外の結果が記述されることはありません。テストの実施においてテストケースに記述されている期待値以外の結果は、テスト担当者の判断に委ねられます。この期待値がバグを発見する重要な鍵を握っています。 あるプロジェクトの情景 ある製品のテストを担当したTさんとテストマネージャのM氏の会話を聞いてみましょう。 M氏：「先週のテストの実施結果を報告してくれ。」 Tさん：「テストの計画通りにテストケースを実施しましたが、不具合の検出率が低いようです。」 M氏：「それは、テスト対象の品質
はじめに 筆者は、ふだんからいろんな人に「テストの仕事をどう思う？」と聞いています。多い回答は、「大切だと思う」や「難しそう」です。テストの重要性や高度な技術が必要であるという認識はもたれているようです。別の質問で「テストの仕事をしたい？」と聞くと、「ぜひやってみたい」の他に、「別に」とか「プログラムを開発をしたい」とった声も聞かれます。 ここからわかるように、テストのことが大切だと思っていても、テストの仕事には興味のない方も多いようです。本連載では、テストエンジニアに興味をもっていただくために、テストエンジニアにおけるヒューマンスキルについて解説していきたいと思います。さて、今日も元気にテストを頑張りましょう。 テストエンジニアと「人間力」の関係 みなさんのテストの現場では、どのくらいの人数でテストを実施していますが。5人、10人、いや100人。テストの現場によって規模は、バラバラ
第3回コピー＆ペーストでテスト仕様書を作っていませんか？ 鈴木三紀夫，池田暁 2008-07-14
おそらく多くのブロガーさんが話題にしておられるであろう、三菱東京UFJ銀行のシステム障害。その原因は、「本来カタカナを使うべきとことに、漢字を使ってしまったから」だそうで。 そもそも、「三菱東京UFJ銀行でシステム障害」という第一報を見たときは、「ああ、案の定」と思ったんです。マタカ、という感じ。でも、あれだけ注意を払って、お金も時間もかけてやっていたのに。実際にシステム移行に携わった方には申し訳ないんですけどね。 次のこの記事を読んだときの最初の感想は、「テストが甘いなぁ」でした。 おそらく、要件定義とか、実際のプログラミングとかはものすごく計画をたててやっていたのではないでしょうか（想像）。また、「うまくいくパターンのテスト」とか「ネットワーク遮断とかシステムのダウンとか過負荷とか、想定される範囲での障害テスト」はさんざんやったんでしょうね（こっちも想像）。問題は、「ありそうもないヒュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp： Webアプリケーションテスト手法: 水野 貴明, 石井 勇一, 新藤 愛大, 岸田 健一郎, 荻野 淳也, 安井 力, 田中 慎司: 本