徹夜のご利用は計画的に皆さんは進捗管理をしていますか。納期に向けてなんとなく仕事を進めていたりしませんか。なんとなく仕事を進めていると,他の仕事に時間を取られて直前で徹夜したりしていませんか。恥ずかしながら筆者もその一人です。昔だったら2日や3日の徹夜をこなして飲み会に参加したりしたのですが,年齢のせいか無理がきかなくなってきました。体の無理もきかなくなってきたし,部下に徹夜させるのも酷な話です。そこで,徹夜を回避するための方策を考えました。時間的な余裕を持ったスケジュールを組むことです。予定を余裕なく組んだ場合にアクシデントにが発生して予定から遅れると,予定に間に合わせるために徹夜や休日出勤をしなければなりません。最初からアクシデントに耐えうるようにスケジュールが組めれば,徹夜の回数を減らすことができます。心の余裕と一緒にスケジュールの余裕もいかがでしょうか。|2005年08月22日テスト項目の作り方テスト項目を作成するといっても,テストの種類ごとに作り方があります。単体テスト結合テスト統合テスト回帰テスト人や会社によって定義が違うとは思いますが,筆者の定義はテストの種類で書いていますので省略します。最初に断っておきますが,筆者はいわゆるV字モデルという考え方の信者です。要求仕様と統合テスト,機能仕様と結合テスト,詳細仕様と単体テストが,それぞれ対応しており,各する仕様でチェックリストを作成するべきだと考えています。一つずつ見ていきましょう。単体テスト詳細仕様書とソースコードを基準としてテスト項目を作成します。ソースコードのすべての行とすべての分岐を実行するように単体テストの項目を作成してください。言い換えるとC0,C1カバレッジは100%にしなさいということです。C0:命令網羅率(ステートメントカバレッジ):全ての行を最低1回は実行C1:分岐網羅率(ブランチカバレッジ)全ての分岐を最低1回は実行C0,C1カバレッジが100%を満たすことと,詳細仕様書に記載のある内容に対するテストをすべて行うことが,単体テストにおける必須条件です。単体テストは手間もそれなりにかかるので単体テストをする現場は少ないのですが,単体テストを実施しない現場では統合テストあたりのメモリリークやメモリ破壊のバグに泣かされて単体テスト分の工数以上を浪費していたりもします。2.結合テスト機能仕様書を基準としてテスト項目を作成します。普通にシステムを使用した場合をチェックするためのテスト項目も重要ですが,結合テストでは機能仕様書に記載のある限界値,境界値あたりのテストがメインとなります。100人しか登録できない名簿登録システムのテストでは次の3点は必ずチェックします。1人目を登録した場合100人目を登録した場合101人目を登録した場合この場合は,1人目と100人目を登録した場合が仕様書の限界なので限界条件,101人目が限界条件を超えた条件なので境界条件となります。え?50人目を登録した場合のテストですか?別の要因で50人目前後のデータに特徴がなければチェックしません。そんなこと言い出すとすべての値でチェックしなきゃいけなくなるんで。3.統合テスト...本来なら要求仕様書に基づいたテスト項目を作成するはずですが,要求仕様書はあいまいなことしか書いてないんでテスト項目の作成には使えません。統合テストではシステムの想定するシナリオ,実行時の多重度を上げた場合,実運用データを用いた場合といったテスト項目を作成します。あと,工数が足りなくて顧客には統合テストと偽って結合テストをやってることもよくありますが,これはテスト項目というよりテスト消化の話ですね。4.回帰テスト実は回帰テストに対応する仕様書というのはありません。言うなら以前のバージョンの仕様書が回帰テストのベースでしょうか。回帰テストでは以前のバージョンで作成したテストプログラムを実行するのが基本です。そのため以前のバージョンで作成した結合テストや統合テストのテスト項目が回帰テストの項目となります。優秀なSEの捕まえ方@ITの会議室で,協力会社さんとの上手なつきあい方を聞いてみました。そのときに私なりにまとめた意見を載せてみます。1.簡単な作業から依頼する雇用契約を結んだら最後まで面倒を見なくちゃいけない自社の社員と違う短期契約の特色を活かした手法です。発注する側には技術力があるかとか,変な人じゃないかとか不安があるわけですし,発注される側にも見下したりしないかとか,契約外の作業を強制してこないかとか不安があるので,簡単な作業を一緒にすることでお互いにうまくやっていけるかを確認する,と。2.育成する優秀なSEが少なく,ハズレのSEがあふている現状では正攻法でしょう。短期契約の特徴である「すぐに逃げられる」という影響を減らすため,長期的におつきあいできると判断したSEにのみとどめておくべきです。3.定着してもらう努力をする協力会社のSEさんを見下さないといった基本的なところから,難度の高い作業を依頼して仕事のやりがいを考慮するとか継続して仕事を発注するといったところでしょうか。個人的な意見としては最後にモノをいうのはお金です。・継続して仕事を発注できる体制どれにしてもお金が必要なので,やっぱり大きな会社はいいなーと感じる今日このごろです。大規模システム開発では多くのSEやプログラマがプロジェクトに参加します。この場合に問題となりやすいのがエラー処理です。基本的はユーザに近いインタフェース層でのチェックです。ユーザから離れてプログラムの深い場所でエラーを検出するほど,エラーとユーザの入力の関連性が分かりにくくなるからです。巨大なファイルを指定されるとタイムアウトとなる関数foo()を使用するプログラムがあるとして,ファイルサイズの上限値をあらかじめ仕様で決めている場合と決めていない場合を考えてみます。ファイルサイズの上限値が仕様で決まっていれば,ファイルが指定された時点でチェックできます。ファイルサイズの上限値が仕様で決まっていなければ,問題の関数foo()を実行し,foo()がタイムアウトエラーを返却した時点でファイルサイズの上限値を越えていることが判明します。タイムアウトエラーの原因がファイルサイズの上限値を超えた場合だけであれば簡単ですが,他にもエラーの原因が考えられる場合は原因は分かりません。分かるのは関数foo()がタイムアウトしたという事実だけです。エラー原因が不明であればユーザに適切なエラーの原因を教えることなんてできません。ユーザに親切であろうとすれば,仕様の検討時点で入力値の制限範囲を明確にし,ユーザの入力に近い場所でエラーチェックをするようにしましょう。...というのはあくまで原則論です。じっさいに仕様書とプログラムを書けばイヤでもわかるでしょうが,仕様書を書く時点で入力値のチェックをかけれる範囲なんてたかが知れてます。だいたいはプログラムを書いているうちに,プログラム上の理由からユーザの入力値に制限をかける必要がでてきます。ユーザの入力値に制限をかけた場合のユーザのデメリットよりも,プログラマが楽をすることで節約できる工数(=開発費用)のほうが魅力的な場合なんていくらでもあります。徹夜するかしないかの瀬戸際にいるときには,ユーザに少々不都合でも我慢してもらおうかなーという気分になります。いってこっそり実装すると,納品段階で顧客や品質保証部門からチクられて課長から「おまえ,サボったな!」とカミナリを落とされるわけですが。コーディング工程以降で入力値を制限する場合は,仕様書に追記し入力チェックを増やすようにしましょう。間違っても関数がエラーになった時点でユーザに理解できないエラーメッセージを出して顧客から怒鳴り込まれないように。|2005年08月01日ひとりよがりになってませんか前回の仕様書の問題ではないですが,プログラマはとかく目の前のプログラムに集中しがちです。仕様書に全体の方針は書いてあるのですが,コーディングに入るとどうしても目の前のプログラムのロジックだけを追ってしまいます。その結果,その関数のエラーとしては正しいのですが,プログラム全体から見るとおかしなエラーとなることがあります。次のようなAPIを考えます。バイナリデータを読み,メモリに展開する。メモリに展開されたデータはbar()を実行して取得する。成功した場合,bar()で使用するハンドルを返却する。エラーの場合はNULLになる。指定したファイルをメモリに展開できなかった場合。foo()でETIMEOUTが発生した場合,プログラムの呼び出し元にはなんと返すべきでしょう。プログラムの呼び出し元にタイムアウトを返すのは簡単ですが,タイムアウトとする前に少しは考えてほしいところです。後で先輩が泣きながらソースファイルを見直してるかもしれないんで。指定したファイルを30秒以内にメモリに展開できなかった場合です。指定したファイルが大きすぎるのです。指定したファイルが大きすぎると通知するのが適当です。自分のコーディングしている箇所だけで考えるのではなく,呼び出し元はどのように判断するか,エラーがユーザーにとってどのような意味を持つかを考えながらコーディングしたいところです。ChipsSeesaaブログ広告この広告は60日以上更新がないブログに表示がされております。以下のいずれかの方法で非表示にすることが可能です。「広告を表示しない」にチェックを入れて保存する。ブログ×この広告は180日以上新しい記事の投稿がないブログに表示されております。