IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
