テンプレートから学ぶ 受注する開発者のためのテスト仕様書
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
Excelマクロによる、seleniumテストケースの自動生成（1）：CodeZine
はじめに seleniumについての基本的な内容は、以下を参照してください。 Selenium 0.7利用手順書（前編） Selenium 0.7利用手順書（後編） seleniumを利用するメリットとデメリット メリット seleniumを利用する最大のメリットは、「再テスト」が容易になることです。 不具合発生時 テスト担当者と修正担当者の伝達が容易 再テストが容易 仕様変更後 リグレッション（デグレード確認）テストが容易 筆者が特にメリットを感じるのは、テスト担当者と修正担当者の伝達が容易になる点です。テスト期間中は、テスト担当者も修正担当者も作業に追われています。通常、不具合発生時は、テスト実施担当者から修正担当者へ不具合内容を伝達するために、不具合管理ツールなどに、ケース番号や再現手順の詳細を記述、デバッグログの添付などを行い、修正担当者はそれを読み解く必要
CodeZine：PHPにおける日付と時刻の混乱（ユリウス日, DateTime, PEAR Date, エポックタイムスタンプ）
はじめに 作成しているプログラムの中で、ある日付の翌日を取得したいという状況を想像してください。一見単純そうなタスクですが、自分で実装するとなると、かなり面倒だということは容易に想像できます。「日」が27以下の場合は単に1を加えればいいのですが（実はこれは間違いです）、「日」が28以上になると、日数は月によって異なるため、まず、それが何月なのかを調べなければなりません。さらに、もし2月だったら閏年なのかどうかをチェックする必要もあります。「『年』が4の倍数なら閏年」というような単純な話ではないことはご存じでしょう。 幸運なことに、現在広く使われているプログラミング言語の多くは、日付や時刻の計算のためのライブラリやクラスを持っているので、暦の詳細を知らなくても、日時を扱うことができるようになっています。 PHPにも日付や時刻を扱うための手段が用意されていて、簡単に使うことができます。困ったこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
