2004-10

結局コアなのは、自分から変える、人の役にたつ仕事をする（その人が欲しい、かつ必要な車を正当な価格で売り、決して短期の利益に走らない）、約束を守り、自分の周りの人を全て大切にする

Fujiko Suda / ワークライフ: どんな人が本物の成功を手に入れるのかからの引用です。

ビジネスマン共通のこころ意気です。

このエントリーもとても参考になります。

未来のいつか/hyoshiokの日記-OSSに対する企業の貢献のエントリーを読んで気づいたことです。

最初にテストケースを定義し、テストを作り、そしてテストをするということである。つまり最初にSamba 3.0の国際化の問題を徹底的に洗い出す。そしてその後その問題を解決していくというアプローチをとった。こう書いてしまうと当り前すぎて身もふたもないのだが、先に国際化の実装をするのではなく、先にテストを行いバグを徹底的に洗い出すというアプローチである。流行りの言葉でいうとテストファーストである。そして発見したバグはどんどんSambaのバグデータベースに登録した。

テストプログラムは全て自動的に実行できるようにして毎晩実行することにした。シリコンバレーの常識のデイリービルドとリグレッションテストである。最初のフェーズは毎日毎日少しずつテストが増えて行くフェーズである。もちろんそれに比例して不具合(バグ)も増えて行く。厳密に言うとバグが増えるのではなく、発見されるバグが増えるのである。バグはもとから存在しているのだから。ある時点で想定したテストプログラムが全て出来上がる。そうすると既知のバグ数というのがでてくるのであとはそれを淡々と修正していく。

例えばテストケースが100個定義されているとして、それを網羅するテストをせっせと作る。その時の進捗は100個のうち何個テストプログラムができたかということになる。当然不具合が見付かる。そうするとそれをバグデータベースに登録する。全部のテストケースを網羅するテストが実施されたとすると、今度はその発見されたバグを直すというのが我々のプロジェクトのゴールとなる。例えば修正すべき30個バグがあるとすると、それをいくつ直したかが進捗である。

テストプログラムは全て自動的に実行できるようにして毎晩実行することにした。シリコンバレーの常識のデイリービルドとリグレッションテストである。最初のフェーズは毎日毎日少しずつテストが増えて行くフェーズである。もちろんそれに比例して不具合(バグ)も増えて行く。厳密に言うとバグが増えるのではなく、発見されるバグが増えるのである。バグはもとから存在しているのだから。ある時点で想定したテストプログラムが全て出来上がる。そうすると既知のバグ数というのがでてくるのであとはそれを淡々と修正していく。

引用しまくってしまいました＾＾
はてなダイアリー – 未来のいつか/hyoshiokの日記さんのエントリーで特に気になったのは
テストファースト
デイリービルドとリグレッションテスト
修正すべき30個バグがあるとすると、それをいくつ直したかが進捗である
という手法達です。この記事を読んで、今までもやもやしていたテストファーストの概念を少し自分の中で受け入れる事ができるようになりました。

テストケースを作り、そのテストケースが正常に終了すれば、進捗１ケース完了という考え方だと思います。「デイリービルドとリグレッションテスト」はそのテストケースを自動で試す為のプログラム（人の手でやると再現性が低くなる為）。「修正すべき30個バグがあるとすると、それをいくつ直したかが進捗である」という考え方もとてもわかりやすいと感じます。

じゃあ、実際のプロジェクトでもこのような手法を使えるのでしょうか？
仕様が決まればテストケースは作れます。今行っているジョブはＷＥＢシステムなのでテストの自動化は難しいかもしれませんが、テストケースは作成できます。
仕様から考えられるテストケースをすべて洗い出し、ユーザーに提出、レビューをしてもらいます。開発前の初期段階で先にテストケースを作ってしまうという方法です。

この手法の良いところは開発の終了時期が明確になることです。今までの方法だと結合テストまで終わってもどこかに漏れがあるんじゃないの？とか、もうテストが終わってるのにバグが見つかったり、しかもそこに仕様変更まで絡んできてどこでプロジェクトが終了なのかわかりにくくなる事がありました。始めにこのテストケースが完了すれば品質は保証されているというコミットをユーザーとの間でアグリーしておけば、テストケースすべてパスすればプロジェクト終了と考えられます。仕様変更は別プロジェクトとして対応できれば最高ですね。(コミットとかアグリー…)

まぁそんなに上手くはいかないと思うのですが、この手法では終わりが分かりやすくなるということはわかりました。でも、私は逆に始めが大変になってるよな、と感じています。今まで開発後の単体テスト・結合テストでひぃひぃ言っていたのが、開発前のテストケース作りでひぃひぃと言うことになります。ここでどれだけしぶとくより完全なものを作成できるかにプロジェクトの成否がかかってきます。

とはいっても最後にあがくより、最初にあがけるこの手法は前倒しという意味でも有用な方法だと、ここまで書いて感じています。

最後に
テストファースト
デイリービルド
リグレッションテスト
この3つについても少し勉強しておきましょう。

おれは頭わるいねんから人より何倍も頑張らないと駄目☆
中学ではいつも思ってました＾＾高校では思う回数が減ってきて、大学・社会人ではほとんど思わなくなりました。これはショックアブソバーのように自分に言い聞かせる為に使っていました。自分は人より劣ってるんだから努力しなければいけないと。その気持ちを思い出し、成果がでなくても出るまで頑張る、出てもそれで満足する事なくさらなる目標も目指す、そんな気持ちをもう一度思い出します。

おれは頭がわるい、だから人より努力する！！

えー、現在改装リニューアル中です。

■対応したい機能一覧
google adsence
amazon
blogtimes
about me
about site
wiki
photo
banner に画像

mdlm -bekkan-: こないだの台風

めっちゃきれいな写真をエントリーしてるサイトを見つけました。
台風のあとの虹！！
これはちょっとジーンときました、小学生のころに公園で一生懸命、虹を作っていたこととか色々思い出しました＾＾

やっぱり写真はいいですねぇ、始めてみようかな～

HINAGATA:HINAGATAテンプレートセットをダウンロード

HINAGATA SKIN

参考にさせていただきます～

自分を変える鍵はどこにあるか

posted with amazlet at 04.10.22

川上 真史
ダイヤモンド社 (2004/10/08)
売り上げランキング: 30,965
通常24時間以内に発送

Amazon.co.jp で詳細を見る

・スモールウィン
・イチロー
・星野監督
・知識として知っている、ちゃんと理解している、応用できる。

昨日で３回目の立ち読みをしました、買うか迷ってます。

冒頭からスモールウィンの考え方まではおもしろいのですが、その後が読むのが苦しい話になってきます。書いている事は正しいのですが、読む側は指摘されるだけでじゃあどうすればいいのか？まではこの本では教えてくれません。
お前のここが駄目だ！というだけ言って、それでバイバイみたいな話です。

それでも内容はとても参考になるので、家にあって欲しい本だと思って買うか迷ってます。

今日は昨日の調査結果を元に修正作業に入りました。それなりに順調に進んでいたのですが、最後にちょっと注意すればわかるような事を上司に聞いてしまいました、反省です。
まあとりあえず修正作業は終了しました。あとはテストです。

テスト方法も考えました、最低限必要なテストに絞る事にします。
共通の方法で実装した部分についてはそのうち数カ所をチェック、固有の方法で実装した部分は該当箇所すべてをチェックするという方法にします。この時全ケ所をチェックせずに品質の保証ができるのかか？という質問に対しては、できると答えます。理由はここでは書きません。

ということで明日はドキュメントをもう少し分かりやすくする作業をし、午前１１時には作業完了とします。

今日の反省はもっと自分で考えて考えて考える事。そして考えるんだけど行動は早くを意識する。
スモールウィン、小さい目標の積み重ねを意識する。私の小さな目標は何だ〜！！
今週の目標、今月の、３ヵ月の、半年の・・・
「目の前のことを精一杯やるだけです」

FrontPage – PukiWiki.org

このブログは人に見せるものではなくなってきたので（ただのメモ帳and日記になった）、更新pingは飛ばさないよう設定を変えました。

で、メモったことをまとめて残しておく為にぷきうぃきを使おうと思ったのでメモします～