網羅率100％は不毛な議論

網羅率(パスカバレッジ)が100％を目指すことを目標にしています。
という人がいるが、これは不毛な議論である。
ステップ数が10行程度なら100％にすることはできる。
しかし、数十万ステップや数千万ステップのソースコードをみて100％にするにはいったいどれくらい期間をかけるのだろう。
永遠にリリースすることはできない。

ある程度の目安として、静的解析ツールやxUnit(C++:CPPUnit, Java:JUnit, Delphi:DUnit)などを
使用して極力100％に近づけるための努力はしなければならない。

そもそもバグがないということを証明できないのに、網羅率が100％であるということは無理だろ。
最近、気になることとして直交表を勉強してみようと思う。

野球をして疲れた

今日、久しぶりに野球をやった。先発で、8番センターで出場。
最近は、若手がピッチャーをやってくれるので、投げなくていいので割りと楽。

相変わらず、バッティングはひどかった。結果3打数ノーヒット（2三振）
まったく当たる気がしなかった。練習しないといけないなと感じた。

今日はセンターからのレーザービームを披露する機会がなかった。
その前に、ボールが飛んでこなかった。

何でもそうだけど、努力を怠ると、さびついていくなと感じた今日。
迫りくる歳の波にはそろそろ逆らえないと感じた。

新テスト工程

これからの話は、通常2ラウンドはテストを行うという前提で話を進める。
通常、どの開発モデルを採用してもテスト工程の流れは、
単体、結合、システム、受け入れ、運用テストの流れで進む。

この工程の流れに疑問を感じる。

疑問点1
システムテストにおいて、性能・負荷テストを行ったときに、予定していた性能が発揮できない・負荷に耐えられないアーキテクトが発覚した場合、納期間近であり、構造を変更できない。

疑問点2
受け入れテストで、顧客がまったく違う機能ができてきて、変更が発生し、連日徹夜の連続や納期超過を招く結果になる。通常はありえない。この前段階で必ず確認はしているはずだが、よくこの時点での仕様変更・追加がある。

以上のことより、顧客に使用されない機能・無駄な機能を作成し、顧客とって価値のないシステムが出来上ってしまう。
それでは、まったく意味がない。

新テスト工程の前提条件として、テスト駆動開発を採用する。

単体・受け入れ・システム・結合・運用テストの流れがベターであると俺は考える。
ただし、受け入れとシステムは同様にして、ユーザーストーリを元に行う。

メリットとして

1.早期に顧客に確認することで、出来上がったもののイメージが異なった場合でも早期に対応することができる。
2.アーキテクト的な問題が発生した場合でも修復が可能である。

よって、顧客にとって価値のあるシステムを提供することができ、市場へのリードタイムを短縮することができるはず。

実は色々試してみた結果、これが新テスト工程ではないかと俺は考える。

バグ管理システムについて

バグ管理システム（影舞）を導入してから3ヶ月が経った。
運用は順調に進んだ。順調に進んだのは、

1.皆が協力してくれたこと
2.業務フローを書いたこと
3.切羽詰っていたこと
4.紙ベースで文化ができていたこと

がある。

色々と細かな問題はあった。
例えば、起票日を書くのに、10/6や10/06があり1日のバグの内容を確認するのに手間取ったことなどがあった。
信頼度成長曲線も自動化され、Excelに手入力で数値を打たなくてよくなったから、作業の効率化は図れた。

バグ管理システムの導入のメリット・デメリットをあげてみた。

メリット
1.バグが共有できる。
2.開発者がすぐに情報をキャッチできるので、修正速度が速くなる。
3.データから色々なツールを作成できるので、作業を自動化でき、ミスがなくなる。

デメリット
1.テストリーダーがどのようなものが上がったか情報が集まってこないので、
自ら検索を行い、バグの内容を確認しなくてはならない。
2.最終テストで、紙で最終確認を取ったほうが早い。
3.デュアルディスプレイでないと、修正の確認が画面が重なり面倒。

その他メリット・デメリットはあげればきりがない。

要はWEBで管理しようが、紙で管理しようが手段であるので、目的を見失わないことが最重要である。
組織内で色々なことを試してみてそのときに一番いい方法(ベター)を選択することである。

一流のエンジニアを目指して

俺は、入社したときにはおちこぼれのエンジニアだ。エンジニアってよんでいいのか？
事実、営業にまわされそうになったことも一時期あった。

プログラミングを始めたときはどのように動くのかがまったく理解ができなかった。

まったくプログラミングができない俺が、火が吹いているプロジェクトにアサインされた。
そのときのリーダーは思っただろうな。厄介なやつをアサインして仕事が遅れるよって。
それから数ヶ月間、実装とデバッグの繰り返しだった。

そんなときに、上司からデバッグのコツを教えてもらった。
「これから色々なプロジェクトにかかわり、人のソースコードを見ることになると思う。
まずは、メソッドの引数の値は間違っていないか、
間違っていないのなら、どこが原因かを突き止めてくれれば、
後は修正するから大丈夫」ということで、ひたすらデバッグの繰り返し。

これがよかったんだろうな。
プログラムって、どうやって動いているのかということがわかり、何かが吹っ切れたように感じた。

そのうち、色々と経験していくうちに見たことのないソースコードや内部の構造を短時間で見ることができるようになってきた。
そこからプロジェクトの火消し役で、色々なバグをつぶしてきた。
神がかり的に修正したときには、軽微なものまで含めて1日40件修正したときもあった。

今日もあるプロジェクトのテストが進まないということで、急遽、バグフィックスをすることになり、何件かフィックスしてきた。
明日にはなんとかテストできる状態にまでなった。

デバッグって実は実装能力を向上させるためには非常に重要なことだ。

1.人のソースコードを見て、自分ならこうすると考えること。
2.バグの傾向というか、バグが潜む原因を感覚的にではあるがわかる。

などである。

一流のエンジニアになるためには、まだまだ足りないことがあるが、まずはデバッグ能力を鍛えることから始めなくてはならない。

香港に行ってました。

昨日まで香港に行ってました。
香港といえば、イメージはブルースリー、ジャッキーチェンくらいしか持っていなかった。
実際に行ってみて香港は非常にいいところだった。

料理はおいしいし、きれいな景色はあるし3泊4日だったが、堪能できた。
フリータイムの昼間にブルースリーの銅像のところに行き、携帯のカメラで激写。
そこには、ジャッキーチェン・ユンピョウ・サモハンキンポーの手形があった。
中でも熱かったのは、サモハンキンポーの手形が俺の中ではよかった。
ちょっとマイナーチックなサモハンキンポーって割といい感じ。

夜に、よくテレビで出てくる、2階建てのバスの屋根がないやつで市内観光した。
そこで、100万ドルの夜景を見えてきてキレーだった。
100万ドルって、実は1晩の電気代がその値段なんだって。知ってた？

3日目の夜に食べたおいしい料理は、茹でた上海ガニの上に、ニンニクのフライを砕いたものと唐辛子を混ぜたものがかかっていておいしかった。ビールにあう。
これは一度食べてみる価値あり。

香港って台湾と違って、クサ豆腐のにおいがしないので、かなりいい。
個人的にはかなり気に入った。もう少し物価が安ければいうことなし。

演算子が終了しました。

C言語で演算子が終了しました。
i++、++iで動作が変更することを知った。
後置演算子はループ処理でよく使用するが、++iってどんな場面で使用するのだろう。
使用場面がよくわからない。

C言語って色々と省略することができるから、バグを見つけにくいのではないかと思う。

その点、Delphiは省略することが少なかったり、型のチェックが厳密だったりして、初めてプログラミングを知る人にとっては簡単だ。
だから教育用言語だといわれているゆえんなのかもしれない。

一通りC言語が終了したら、OS自作入門の本を見ながら、OSでも作ってみるか。

日本におけるソフトウェアテストの位置づけ

日本におけるソフトウェアテストの位置づけはここ数年組み込み系を中心に盛り上がりを見せている。
セミナーや書籍などが数年前に比べれば、格段に多くなり情報を得やすくなっている。

ただ、日本企業においてのテストエンジニアの仕事はまだまだ軽視されがちである。
トレーニングしなくもテストケースがあれば、誰でもできると、経営者や開発者がいる。これは非常に問題だ。

実は、テストというのは非常にセンスがいる作業である。
テストケースとしては存在しても、テストデータによって発生するバグというものは非常に多い。
これに関してはどうしても属人化してしまう。
そこをいかに属人化しないで、ナレッジとして蓄積していくことが企業における財産になる。

誰でも可能であると考え、テストエンジニアの離職率などが高い企業は企業における無形の財産を手放してくことになる。
プログラマも同様のことがいえる。

これから、色々な壁にぶつかりながら、バグを見つけて戦い続けているテストエンジニアのために自分ができることとして、
ソフトウェアテストの重要性を訴え続けることが俺に課せられたミッションである。
そのためにも色々なところで、ソフトウェアテストの重要性を話して、テストエンジニアの地位を確立していく。
がんばれ、テストエンジニア。

「見える化」って実は

最近気がついたことで、「見える化」って、実は企業活動そのものではないかと思う。

企業活動というものはゴールがなく、改善活動の繰り返しで成長・発展していくものである。
問題を発見するために「見える化」をしている。そこから改善が行われ、企業が発展していく。

例えば、ソフトウェア開発において、信頼度成長曲線がそのひとつである。
現状のバグの状況や修正具合がどのようになっているかをグラフで確認することができる。
そこから、状況に応じて対策を講じることができる。そしてその効果の改善を確認することができる。

「見える化」とはつまり、気づき→改善→効果測定のライフサイクルをまわすためにする。

「見える化」の手段は色々とあり、その状況・企業によって変化するものである。
トヨタを真似して、星取表やアンドンをそのまま取り入れただけ気づきが生まれない。ただのパクリである。
見える化することは重要だが、見える化の本質を理解したうえで、行わないと「見えてる化」と「ただ壁に貼り付けている」だけのものになってしまうので注意しなくてはならない。

Cの勉強を再開しました

Cの勉強を再開しました。
なぜ、CなのかというとC++のテストツールを検証したときに、C++ってDelphiと違って色々とできそう。
また、Windowsの仕組みなどが色々と理解できそうだということで始めてみた。
ようやく、昨日から時間ができてきたので再開した。
その中で、疑問点があった。

このようなソースコードがあったときに、

#include <stdio.h>

int main()
{
int a;
a = 10;
printf("変数aには%dが代入されています。", a);
return 0;
}

%dの箇所を%fにすると、Runtimeエラーが発生する。
理由は型が違うからエラーが発生する。本当か？

なら

int a;
a = 10.25

はなぜ問題ないの？そんな疑問が沸いてきた。
今日考えてみたが、わからなかった。

そんな素朴な疑問って、物事の本質をつかむためには重要だ。