テストの立場になってみてわかること

テスト専門の部署を立ち上げてから早いもので、もうすぐ3年が経過します。
自分で一からテストのことを勉強して、どういったことが必要かやどういった技法があるかなどを独学で学んできて、ようやく社内にも色々なことが浸透してきたなと思います。

実際にテストしていると、修正が追いついてこないと修正する側に回ることもあったりして、いわゆるスパゲッティプログラミングや読みにくいコードを見ていると、このブログで何度も書いていますが、読みやすいコードを書くことは本当に重要です。

何が重要かというと、やはりその後のメンテナンスや開発中のバグフィックスの速度に、ものすごく影響してきます。

今回ある2つのプロジェクトがあり、その修正に回ることがありました。
一方は修正しやすいので、私が突然修正に回ってもすぐにコードを読みことができましたし、もう一方はスパゲティなので、ちょっと影響がどこに及ぼしているのかが非常にわかりずらいと思いました。

このように違う例を実際に見てみると、読みやすいコードを書くことは重要であると思いました。

長時間労働は効率を下げる

長時間労働が続くと、どうしても眠気や体の不調を訴えて効率が下がってきます。

特に、思考を働かせて物事を考えたりする場合には、思考が働かなくなったり、目の痛みなどの体調不良を起こす場合があります。

一番効率がいいのは、残業しても3時間程度で、帰宅するのが一番効率です。
時には、徹夜などをしなくてはならないときがありますが、万年そのような状態が続くと、効率が悪くなるし、仕事を長く続けることができなくなります。

やはり、このような労働環境をいかにしてなくしていくか、無駄を排除して手戻りや無駄な作業をしないようにして、仕事をしていかなければなりません。

全ては仕様分析による

様々なテスト技法がありますが、やはり全ては仕様分析がいかに出来るかに関わってくると思います。

例えば、マインドマップを使用してテスト設計をしたり、原因結果グラフ等を用いて、デシジョンテーブルを作成してもその前に対象のソフトウェアの仕様分析がきっちりと出来ていないと、どのようなテストケースが必要かがわからなかったり、ケースが漏れてしまい、テストが属人化してしまいます。

では、仕様分析をきっちりと行うためにはどのようにしたらいいかですが、仕様書があれば、仕様書を読んでいけばある程度わかります。

最も困る場合は、仕様書もない・動くソフトウェアもない作成しているプロジェクトリーダーの頭の中にあるときです。
これが一番困るパターンで、ではどうするかというと簡単なものでも構わないので、仕様がわかるものを作成してもらうのが一番です。それがドキュメントでも動くソフトウェアでも構わないです。

やはり仕様分析がきっちりと出来ていないと、テストケースが漏れてしまうので、ここがうまくいくかどうかで、テストが成功するかどうかが決まるのではないかと最近になってようやくわかってきました。

プログラマの労働環境

プログラマの仕事は、夜遅くまで仕事をしていたり、休日に出勤したり、お菓子を食べながら仕事をしているというイメージが強いと思います。事実そういったこともあります。

多くの仕事は、Slerのイメージからそういった納期が厳しいなどの話が雑誌の記事などに取り上げられているので、そういったイメージが強いと思います。

しかし、日本の中小企業においてそういったことだけではないと思います。
やはり根本の原因は、経営者にあると思います。

私たちが必死で納期を間に合わせようとしているのに、まだお菓子ばかり食べているから余裕があるだろうなど的な発言をする経営者が中にはいます。

いくらその周辺のプロセスを変更したとしても根本の経営者自身の考え方を変更しないと何も変わらないと思います。

やったことがないので、わからない部分はあるにしても、つまり現場を見ようとしていないということ（現場を知ろうとしない）ではないかと思います。

C#におけるフォームの一覧取得

C#で、現在開いているフォームの一覧を取得する場合にはApplication.OpenFormsを使用します。サンプルプログラムは以下のようになります。

foreach(Form frm in Application.OpenForms)
{
ListBox.Items.Add(frm.Name);
}

意外と簡単に取得できます。

これとは別の話になりますが、Excelのブックやシートを印刷するPrintOutメソッドがvoidだったので、なんの例外が発生しているかがわからないので、ちょっと使いづらいなと思いました。PDFやMicrosoft Office Document Image Writerを使用して印刷するときに、最後の引数、PrintDialog.PrinterSettings.PrintFileNameにポート名が入ってくるので、エラーになることがありますんので、注意してください。

ようやく見えてきた

ある案件の関係で、深夜まで作業が続き、最近はブログの更新が、ままならない状態でしたが、今日ようやく終わりが見えてきました。
期間的には、後1ヶ月ほどありますが、修正の速度も上がり、起票件数に追いついてきたので、ようやく終わりが見えてきたというか先の見通しが立ってきました。

私も修正に入りましたが、入ったばかりだったので、内部構造がどのようになっているかを知るのに時間がかかりましたが、今日からようやくエンジンがかかってきたので、どんどん修正をしていけると思います。

ただ、もうひとヤマあるので、気が抜けない状態ですが、なんとかリリースできるのではないかと思います。

残り期間が少ないですが、あと少しなので、がんばろうと思います。

作成者と実施者は同一人物がいい

ある程度コアの部分を実装する人がアーキテクチャを考えるように、テストにおいてもある程度コアの部分をテスト実施をする人が、テストケースを作成したほうがいいと思います。

なぜなら、テストケースを作成する人とテスト実施者が別々になっていると、どうしても実際に動かしたソフトウェアがどのような箇所でバグが発生するかや匂いがする箇所というのがわからないからです。ある程度、バグの起票の内容や対策を読んでいれば、わかることですが、どうしても感覚的なことになってしまいますが、判らなくなったりします。

その他にも不要なテストケースや無駄なテストケースというのはどうしても実際に自分の手で動作させて見ないと、わからない場合があります。

テストケース作成者とテスト実施者は、極力分けないで進めるのがいいのではないかと最近感じます。

気がつけば1年だ

最近、俗にいう火が噴いたプロジェクトにアサインされたので、連日深夜に及ぶ作業・休日出勤だったので、気がつかなかったことですが、ブログを始めて1年がたっていたことに今日気がつきました。

このブログのタイトルの『ただいま修行中』も一生勉強していかなくては、技術についていけなくなる事・ある人と出会って、まだまだ技術力が足りないなと思ってつけました。

この1年を振り返ってみると、色々なことがあったなと思います。ちょうど1年前も火の噴いたプロジェクトにアサインされ、色々と改善が行われ、なんとかリリースすることができました。

そして現在も火の噴いたプロジェクトにアサインされ、テストケースを作成しながら、テストが制約条件でなくなり、修正作業が制約条件になると、修正作業をするといった「なんでも屋」状態になっています。

プライベートも子供が2歳になり色々な言葉を話すようになったりして、本当に可愛いさかりです。知らない間に大きくなっていて、妻が本当に大きくしてくれたなと感謝しています。

C#におけるExcelファイルを開くときの注意

C#において、Excelファイルを開く実装は以下の通りになります。

Excel.Application xls = new Excel.Application();
Excel.Workbooks wbs = xls.Workbooks;
Excel.Workbook wb = wbs.Open(ファイル名, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);

wb.Close(false, Type.Missing, Type.Missing);
ReleaseComObject(wb);
ReleaseComObject(wbs);
xls.Quit();
ReleaseComObject(xls);
System.GC.Collet(); //念のため

こんなに簡単なサンプルプログラムを作成していたら、タスクマネージャを起動すると、Excel.exeが残っていました。

詳細な原因はつかめていませんが、どうもwbs.Openの行が悪いことがわかりました。
なぜReleaseComObejctをしているのに残っているかが不明です。

ちなみにOSはXPで、Officeは2003でこの現象が発生しています。
ちょっと使用する人は注意が必要だと思います。

最後は覚悟が必要

Office2007を使用してみて、慣れるまで今まであったボタンはどこにいってしまったのかと思うくらいにユーザーインターフェースが変更されているので、当初は操作するのに非常に困りました。

例えば、保存するのに、ボタンがどこを探しても見つからず、画面左上のボタンをクリックすると、表示されるということがわかるまでにかなりの時間を要しました。

その他にも、マクロのセキュリティの設定もどこかなどを色々と探していると、まったく使いにくいユーザーインターフェースになったなと思いました。
しかし、操作に慣れてくると、メニューをクリックするよりもタブをクリックしてすぐにボタンが表示されるので、操作は早くなり、今では快適に使用することができています。

製品開発において、ユーザーインターフェースや操作性を変更することはかなりの勇気が要ります。
しかし、変更してもそれが操作をしていくうちに、簡単になったなと思ってくれれば、成功であるといえます。

ここまで大幅な変更を行うには、社内外の合意が得られないと進められないと思いますが、最後は覚悟を決めて説得をするしかないのかとOffice2007を操作して感じました。