bbz

テストエンジニア

_
previous | next | edit
1: 05/04/05(Tue) 18:04
評価には品質向上と瑕疵がないことの確認との二つの目的がある。
瑕疵が多く見つかれば、製造あるいは設計工程に問題があることが考えられる。
当たり前であるが、重要なことはどんなに厳密に評価を行っても、
評価するだけでは品質は向上しないということである。
それは評価によって発見された瑕疵を改善するということだけを意味するのではない。
瑕疵の多発は、設計から製造工程の欠陥を意味するから、
瑕疵そのものだけでなく、工程自体を見直さなければならない。

単に設計-開発-評価という工程において上流工程にフィードバックをおこなっているのが、
ほとんどの評価のあり方であろう。
この方法ではたとえ潜在的な品質問題が発見されても開発部門からは仕様である等の理由で
正しくフィードバックが行われない。
評価部門も発見した問題が品質向上に役立たないのでやりがいを失くし、
積極的に問題を発見しようという意識が薄れていく。

設計、開発、評価の3部門は、立法、行政、司法にたとえられる。
2: 08/12/22(Mon) 16:41
私は最近はテスト屋になっている。
テストしているのはルータやスイッチなどのネットワーク機器なので、ネットワーク屋である必要もあり、そうだと自覚もしていたのだが、わたしのやっていることはネットワークエンジニアではないのだと、最近気づいた。
3: 08/12/22(Mon) 16:42
さて、テストとはなんのために実施するのだろうか。
答えは大きく分けると、次の二つのどちらかになるだろう。

1.バグを見つける
2.正しく動くかどうかを確かめる

同じことのように思う人もいるかもしれないが、この二つは全く違う。
目的がどちらかによって、テスト項目の作り方も変わってくる。

そして、あるフェーズのテストの役割が、時が経つにつれて変わって来る場合がある。

ソフトウェアのテストと言うのは、たいてい同じテストを何度か繰り返すことになる。
初期段階ではバグが多いので、バグを洗い出すテストになる。序盤はバグが出た方が好ましく、あまりバグが出ないとテスト項目が適切でないといわれかねない。
4: 08/12/22(Mon) 16:42
しかし、開発がある程度完成に近づいてくると、バグが出ることが問題になることがある。
もちろん、バグはいつ発見されようがバグなので修正すべきではある。しかし、今まで何度もテストしてきたのにどうして今頃こんなバグが発見されるのか、という疑問を、現場から離れた管理者は疑問に感じる。

これは、管理者は現場を知らず、テストを早くおわらせたいからケチをつけているわけではない。そういう疑問を抱く管理者は優秀ではないかもしれないが管理者としての最低限度の仕事は遂行している。ここで、バグがでた、あっそう、じゃあ直して、というようではそいつはテキトーなヤツだ。

そして、上記のようなケースはよくあるのである。理想は、バグ検出数のカーブがだんだんなだらかになっていって、最後には平らになることである。しかし、それはテスト項目とその実施方法が適切であり、ソフトウェアの品質とその修正も適切におこなわれた場合に限る。そして、そんなことは、まずありえない。
5: 08/12/22(Mon) 16:42
そしてバグ検出グラフが理想的なカーブを描かなかった場合、ソフトウェアの品質が悪いのか、テストが適切でなかったかが判断できない。そして、たいてい両方の所為である。
最悪なのは、ソフトウェアの品質が悪いのに、テスト項目が不適切なためにバグがみつからず、適当な件数だけ検出されてリリース後に火を噴くパターンだ。

ソフトウェアというのは、モノと違って、やろうと思えば何でもできてしまう。作りたければどんなものでもできる。それがソフトウェアの魅力でもあり、管理を困難にしている要因でもある。そういう極度に柔軟性の高い製品を評価する基準を作ることは、ソフトウェアを作ることと同じくらいに難しい。

そしてここにもうひとつ難しい問題がある。
テストというものは、評価であるから第三者が実施したほうがよいように思える。
私もずっとそうだと思っていた。

しかし、それが可能なのは、開発者と評価者が共有できる仕様書なり性能基準なりが存在している場合だけである。そして、その理想的な状況も、先ほどのバグ検出数の曲線と同様、まずありえない。たいていは、開発とテストと仕様の決定がほぼ同時におこなわれる。
「仕様も決定してないのに開発もテストもできるわけがない!」
と思うのは当然であるが、現場ではおそらくほとんどがそうである。

そのため、何をテストするべきかという事がわかっている開発者が自分でテストする、ということになる。
6: 08/12/22(Mon) 16:43
「デスマーチ」というのは、にっちもさっちもいかなくなって破綻したプロジェクトのことである。何日も徹夜するとか、休みがないとか、病気で倒れるとか、そこまでのデスマーチは経験したことはないが、スケジュールが遅れるのは日常茶飯事で、当たり前だった。というか、スケジュールどおりに終わることなどまずなかった。

私は、デスマーチというのは現場の事情に妥協できず、頑固に理想論に基づいた管理をしようとしたときに発生するのではないかと考えている。最初にたてるスケジュールはあくまでも仮のものであり、ある程度開発がすすんでいくうちに修正や追加がおこなわれ、
予定がせまってきたらリスケジュールをする、というのを繰り返して、徐々にシステムを育てていくのである。
7: 08/12/22(Mon) 16:43
成功するプロジェクトには、ごく少人数、多くはただひとりの、スーパーマンが存在していて、そのスーパーマンがあちこち駆けずり回っておおげさではなく文字通り百人力のパフォーマンスを発揮している。そういうひとりの独走を許さず、メンバーに均等に仕事を割り当てようとするのは愚かである。ソフトウェア開発プロジェクトは化け物である。そう簡単には手なづけられない。うまくおだてて誘導して目的の場所へ追い込んでいく必要がある。綱をつないで引っ張っていくことはまず不可能である。
8: 08/12/22(Mon) 16:44
私はたいしたプロジェクトは経験していないが、SEやプロジェクトリーダーと呼ばれている人にも、ガチガチの管理派というか理想主義者と、おっちょこちょいだが柔軟に対応する現場主義、自由主義者がいる。
どちらも極端では困るのだが、そんなにきれいに分かれるものでもない。
9: 08/12/22(Mon) 16:44
私が今までであったSEで理想主義者だったのがKさん、自由主義者だったのがSさんである。
Kさんの下で仕事をするのは楽である。要求定義書をキッチリ作って、その通りに仕上げる。
途中で変更をさせたりしない。客の要求を突っぱねるのではなく、そういう空気にしないように、事前にしっかり打ち合わせをして固めてから作る。

いっぽうSさんのときは大変だ。ろくな仕様書がない。完成したと思ったらお客さんから根本的な修正をせまられ、すべて作り直しのような状況になる。

が、私はSさんの下で仕事をしたときの方が楽しかったし、できたシステムもお客によく使われていたと思う。Kさんの設計するシステムはバグも少ないし堅牢なのではあるが、どうもお客が喜んで使っている気配がない。バグがないのではなくて、使わないからどうでもよくて修正しないのである。
10: 08/12/22(Mon) 16:44
私はSEとかソフトウェアエンジニアとかITエンジニアと呼ばれる人は、基本は自由主義的なやり方をするべきであると考えている。
11: 08/12/22(Mon) 16:45
私はあるシステムの担当になった。小規模ではあるが、一人でメンテをしていた。
PC3台がnetwareでつながれていて、ms-dos上でdbMAGICを使って作られたシステムである。
私は出来上がったもののメンテをするという立場だったのだが、バグが多くてどんどん手を入れていった。dbMAGICというのはメンテが容易である。

私が会社にいると、3日にいっぺんくらい電話がかかってくる。
そして私は電車にのって1時間くらいかけてお客のところへ行き、
ちょこちょこっといじって、直ったのを確認して帰ってくる。
コーヒーをご馳走になることも多い。

当時の常識では、リリース後の修正はあってはならないものだった。
リリース後に発生したバグの修正にかかる費用は、基本的にお客に請求できない。
つまり、やればやるほど儲けが減っていくのである。

儲けさえ考えなければこのまま直していけばどんどんシステムの品質はあがっていくんじゃないか、なんて私は暢気に考えていた。
12: 09/06/03(Wed) 05:12
私は、すくなくともネットワークエンジニアではない。
プログラマでもない。営業マンでもない。最近は評価の仕事ばかりやっているので、
客観的に見たらテストエンジニアといえるであろう。
テストエンジニアなどというカテゴリは、一般的には認知されていない。
テストというのは新人や派遣やらがやる、誰でもできる単調で考えない仕事だと考えられている。

しかし、私はエンジニアと呼ばれる人たちのアホさと頑迷さをいやというほど見てきた。
基本的に、エンジニアは視野が狭くて全体よりも細部にこだわる人たちである。
13: 09/06/03(Wed) 05:15
「神は細部に宿る」という言葉をきいたことがある。
どうやら、細部をおろそかにしてはいけないとかいう意味らしい。
まあ、こんな言葉を使っている人が神を信じていなくてもしかたがない。
それについてはとやかくは言うまい。

だが、私は細部に宿るのは神ではなく悪魔だと思う。
つまり、細部で手を抜くと悪魔が宿ってしまい後で泣きをみる、ということだ。
神というのは常に全体を見る。全体を維持するために細部を切ることがある。
神を否定する人は、神のそういう態度を見て、切られた細部にこだわって、
神は残酷だ、神は独善的だ、と眉を吊り上げるのである。
14: 09/06/03(Wed) 05:20
エンジニアの中でも、ネットワークエンジニアの性格の悪さは突出している。傑出している。
ソフトウェアの世界では、特に最近は、ネットワーク、ハードウェア、データベース、プログラミングなどの知識が広く深く要求される。どれかひとつの専門家でやっていけるのは数ヶ月だ。
ある程度仕事をしていれば、それらの分野に多少なりともかかわることになる。
NEでもあり、プログラマでもあり、SEでもあり、営業マンでもあり、サポートスタッフでもあり、
プロジェクトマネージャーでもあり、コンサルタントでもある。
それらの要素が、どういう配分で構成されているかの違いである。
15: 09/06/03(Wed) 05:23
そして、NEの要素の強さが性格の悪さに比例する。
プログラマでも、ネットワークに関連するソフトウェアを作っている人は性格が悪い。
これは因果関係も理由も証拠もないが、私の経験でイヤというほど感じたことである。
「俺はネットワークのことはわかるけどサーバーのことは知らないプログラムは書けない」
こういう奴は職場で微笑むことすらできず野良犬のように吠えたり唸ったりしている。
16: 09/06/03(Wed) 05:26
一番おおきな原因は、プログラムが書けないからNEに甘んじている、
というコンプレックスだと思う。
NEだって、ログ解析やら諸作業を自動化したりするのに、
まったくなんらかのコーディング的作業は必要なはず。
エンジニア志向の思考だと、さっき言ったように細部にこだわる。
ある細部について指摘されると、別の細部の話を持ち出して、
じゃあこれはどうなんだと相手をやりこめて喜ぶ。
それが議論だと思っている。
17: 09/06/10(Wed) 03:38
性格うんぬんの話はおいといて。

テストのフェーズによって、項目の選び方が変わってくるという話をした。
初期工程に近いほど機能重視、後期は運用重視となる。

工程の初期・後期というのは、いわゆる「単体」「結合」「システムテスト」という観点からのものと、リリース回数からの観点がある。

18: 09/06/10(Wed) 03:43
この2つの観点による工程の時期によって、試験の実施方法は変わってくる。

私が今まで見てきたいくつかの会社で共通しているのは、
「開発」部隊と、「評価」部隊が分かれていることである。
そして、開発部隊で単体・結合試験をおこない、評価部隊がユーザー観点の試験をおこなう。
19: 09/06/10(Wed) 03:48
部隊はさらに分かれる場合もあるが、大きくわけると「開発」「評価」でわかれることは共通している。
そして、どこでも同じなのが、開発者は技術はあるがユーザーの立場を理解せず、評価者は技術が足りず何が正しいのかがわからない、ということである。

20: 09/06/10(Wed) 03:52
私はもう20年くらい、ソフトウェア開発と評価にたずさわっているが、
一番のテーマは「仕様は何か」ということに尽きると感じる。
「仕様」という言葉は、実に多くの意味を含んでいる。
ユーザーの要求であったり、開発者の都合であったり、予算の都合であったり、
技術者の夢であったり、妥協点であったり、ゆずれない一線であったり、開発の目標であり、評価の基準である。
21: 09/06/10(Wed) 03:59
「仕様」というのは絶対であるが、その絶対的なものを目指す開発者や評価者が自ら創りあげていくところがある。
ソフトウェアというのは、「やろうと思えばなんでもできるモノ」である。
というか、物理的な制約がないからソフトウェアというのである。
なんでもできるということは、どこかで線を引かないとキリがないということでもある。
22: 09/06/10(Wed) 04:03
ソフトウェアの特徴を理解するために、ソフトウェアではないモノと比較してみようか。
クルマと比べてみよう。

クルマというのがどういうものかというのは、子供でも知っている。
タイヤが4つあって、運転席があってハンドルがあって、アクセル、ブレーキがあって、
助手席があり、後ろにシートがあり、ドアは二つまたは四つ、トランクがありボンネットがあり、
ヘッドライトがあり、ウインカーがあり、テールランプがあり、バンパーがあり・・・
最近ではエアコンがついているのは当然、CDやらナビやらもついている。
23: 09/06/10(Wed) 04:09
自転車にしよう。
最近私は自転車についていろいろと調べている。
自転車のフレームに使われる主な素材は、スチール、アルミ、クロモリ、カーボンである。
スチールは安価だが重い。アルミは軽いが強度に問題がある。
クロモリは柔軟性があって疲れにくい。カーボンは軽くて丈夫であるが高価である。
もしカネに糸目をつけないのなら、カーボンが一番いい。
24: 09/06/10(Wed) 04:13
自転車というモノは、戦うべき相手がはっきりしているのである。
重力、摩擦、空気抵抗、振動。
そして、それに対する策は、主に物理法則によって制限をうけており、
選択の幅が狭い。
25: 09/06/10(Wed) 04:16
自転車について、仕様が不明確であったり議論が紛糾することはあまりないだろう。
軽くて丈夫で疲れない、誰もが目指す理想がはっきりしているからだ。
議論するのはその理想に近づくための手段であって、理想そのものではない。
そこがソフトウェアと違うところだ。
テレビ、冷蔵庫、洗濯機など、その他のモノも、理想が比較的はっきりしている。
26: 09/06/10(Wed) 04:23
わたしがソフトウェアの開発者に対して一番不満を感じるのは、理想を持たない場合である。
仕事でやっている以上いろいろと制約はあるだろうが、制約をいくらかき集めてもモノは生まれない。こういうモノを作りたい、こういうことを実現したい、それを目指すうえでの制約である。

しかし最近は、「制約をかき集めれば何かモノが自然にできあがる」と考えている人がいるように思えてきた。
27: 09/06/10(Wed) 04:29
モノをつくるのは楽しいことである。創造に似た作業である。
しかし仕事でモノを作っているということは、それを買う人がいるということである。
古い職業観では、仕事というのはいやでもしなければならない、のしかかってくるものである。
つまり、「働かなくては食っていけない」という職業観であり、今でも多くの人がそう考えているだろう。
働くということは、やらねばならないことがあって、それを皆で分担するということである。
しかし、不況になると明らかになるのは、「やることがなければそれを作り出さねばならない」ということである。
28: 09/06/10(Wed) 04:37
だが、私はその「需要を生み出す」ということに対して、何か腑に落ちないものがある。
カネというのは価値の指標にすぎないのであって、指標自体には価値はないはずだ。
よく言われる、「穴を掘って埋める」ような行為に思えてならない。
それによって、誰かが生活できるようになるのかもしれない。
しかし、私はそこには絶対に誰かの犠牲が存在していると思う。
誰かが儲けるには、誰かが損をしなければならない。
モノを買うことは、損することである。
値段というのは、モノの価値よりも大きくつけられている。
何かモノを買って、それをすぐに売ってみればわかる。
29: 09/06/10(Wed) 04:40
商売では、仕入れた値段より高く売る。
それは、売れるのではなくて、売っているのである。
仕入れ値と売値の差額を負担するのは客である。
モノを買うとは、売るものに施しをすることである。
だから売るものは客に礼を言うのである。
もし客が求めるモノやサービスと等価なカネを払うなら、
むしろ客が礼をいうはずである。
30: 09/06/10(Wed) 04:43
そして、人がモノを買うためにはカネを獲得する必要がある、つまり、働く必要がある。
そして働くということは、今度は自分が人に何かを与えてその価値を超えるカネを受け取ることである。何度もいうが等価な交換をしていては利益は生まれないからだ。
利益が生まれるということは、自分が生んだものの価値を超える対価を受け取っているということである。
31: 09/06/10(Wed) 04:50
もしくは、買い物をするというのは投資のようなものである。
少なくとも私にはそういう気持ちがある。
自分が好きなモノを買うときには、それを製造している企業や販売している店に対して、
応援する意味でカネを払う。
たとえば私はMSのWindowsをほぼ全バージョン購入している。
MSにたいしては独禁法やらオープンソースでないやらとやかく言われているが、
わたしはMSの成し遂げたことはエジソン並だと思っている。
ちょっと割高かなとは思うが、それはMSへの投資と思って払っている。
32: 09/06/17(Wed) 00:09
情報の不足。

これに尽きる。と、久しぶりに良く寝て体調のよかった今日、悟った。
そしてそれを補うものは個人の勉強でも講習会でも学校教育でもなく、英語力でもなく、
誰もが読み書き可能な大容量データベースである。
33: 09/06/17(Wed) 00:11
それは、BTSとか、BBSとか、掲示板とか、ブログとか、メールクライアントとか、
WEBブラウザとか言われているようなものと似たものである。
今日、突然そのアイディアがひらめいて仕事そっちのけで原案を作った。
酒をやめて、仕事はそこそこに切り上げて、こいつを創りあげたい。
上手くいけば・・・
34: 09/06/17(Wed) 00:13
あまり詳しく書くとマネされるので、一部分だけお話しよう。
私が導入した新しい概念に、「問題発見適切性」というものがある。
これは今まで見てきた職場にはもちろんなかった言葉であり、
いまサーチしても見つからなかったが、その考え自体は誰もが持っている重要なものだった。
35: 09/06/17(Wed) 00:15
それは、問題が発見されたときに、その問題がそこで発見されるべき問題だったか、という適切性である。
たとえば前工程での見逃しであれば適切でなかったことになるし、逆に、そのテストの確認ポイントではなかったが、試験担当者がカンなり偶然なりによって発見した場合も、適切でなかったことになる。
36: 09/06/17(Wed) 00:17
従来の試験では、後者のような問題発見はファインプレーとして賞賛されたであろう。
しかし、そのような問題の発見のされ方は、試験のやり方あるいは試験項目の設定に問題があったことを示すものであり、それを改善する意味では、むしろ問題が見過ごされて、なぜそれが見つからなかったのか、という反省が促されて試験のあり方が変わったほうがいいのである。
37: 09/06/17(Wed) 00:18
だが、もっといいのは、その問題は試験をそのまま実施していれば見つからなかった、ということを発見し、改善要求を起こすことである。
38: 09/06/17(Wed) 00:23
もう一つ、私の考えた指標を紹介しよう。
バグ報告レポートに、問題発見日時、問題報告日時、問題受付日時、問題修正開始日時、修正完了日時、確認開始日時、確認完了日時、というフィールドを設けた。
そしてこれらは入力するのではなく、そのレポートの操作によって自動的に入力される。
そしてそこから、そのレポートについて、以下のような指標が算出される。
問題報告工数、問題解析工数、問題修正工数、問題確認工数、そして問題解決総工数。
今まであったものはせいぜいが修正工数程度であろう。
39: 09/06/17(Wed) 00:28
これらの工数のバランスから、問題の複雑さ、開発スケジュールに与えた影響、開発・試験体制に潜む問題などを推測することができる。
そして、工程ごと、あるいはプロジェクト全体でのこれらの平均値などを出せば、
工程やプロジェクトの性質も判断することができる。
40: 09/06/17(Wed) 00:31
また、これらの数値はソフトウェア開発で唯一かつ把握が非常に困難な工数である、
メンバーの作業時間も把握できる。
テスターはテストを実施していて想定した結果にならなかったらすぐにデータベースにその報告を登録する。
通常の試験およびバグトラッキングでは最初の「あれ?」から「バグです」までに何時間もの時間と、何人もの試行錯誤が費やされる。そして、その時間は単なる試験実施時間としか計測されていない。
41: 09/06/17(Wed) 00:33
しかし、テストをしている段階でそのような「あれ?」が発生した時点で、アウトなのである。
それは、テスターの未熟のせいかもしれないし、試験項目が不適当なせいかもしれないし、本当のバグかもしれない。バグでないのにレポートを出すのを非常におそれる職場もあるし、それほど厳密にチェックせずに、とりあえず報告させて後から切り分けてキャンセルするような職場もある。
42: 09/06/17(Wed) 00:37
わたしは問題をキャンセルすることが多い。
しかし、私はあいまいで判断がつかないようなものこそレポートすべきであると考えている。
システム停止とかあきらかな機能の不具合であれば、誰でも気づくし誰でも治せるのである。
一番深刻な問題というのは、開発者も、もっというと、顧客でさえ、気づかない、大前提の誤解のような問題である。

その大前提が誤解に基づいたものであったら、その後にどんなに緻密な作業をおこなってもムダなのである。
そういう意味では、開発経緯や事情を良く知らないテスターが、「これなんかおかしい」と言って報告する無邪気なレポートが、プロジェクトを救うことになる場合もあるのである。

43: 09/06/17(Wed) 00:46
多くの開発現場では、情報のストームを恐れて低質なレポートを発生させないように、
入念に切り分けをしたり、レポート担当者を選別したりする場合があるが、それは無駄であり、
何より情報不足という諸悪の根源を生むものである。
むしろ、低質なレポートをどんどん、大量に発生させるべきである。
低質なレポートは、宝の山である。料理のしたごしらえででてくるダシのようなものである。
44: Fri Nov 5 06:17:12 2010
テスト項目作成にあたって考慮すべき点

1.粒度
粒度というのは、項目の細かさであるが、
細かいほどいいというわけではない。

また、粒度はテストのフェーズによって変わってくる。
同じ仕様書をもとに項目を作っても粒度は人によって変わってくる。

どういう粒度で作成するかというのは非常に難しい問題である。
ほとんどの現場ではこれは経験でしか培われないのではないだろうか?

粒度を試験ごとに均一にすること、そして試験内で均一にすることが必要となる。

おそらく、試験項目を作成してそれを吟味し、実際にテストを実施して再吟味することを
何度か繰り返せば、ある程度試験項目の作成方法や粒度は固まってくるであろう。
しかしその根拠は不明確で、実際に試験してみて気づいたことを反映しているだけである。


1-1.粒度をそろえるための指針
ステップ数
ステップ数あたりの項目数を決める。1000ステップあたり10個とか。

仕様書の章立てを利用
しっかりした仕様書があるなら、それに沿って作っていけばいいが、
そういう恵まれた状況はそうあるものではない。

過去の項目、別プロジェクトの項目を参考にする。

理想は、仕様を満たしているかをテストすることであるが、
現実にはそう簡単ではない。
「仕様がないのにどうやって開発するのか」とは誰もが抱く疑問であろうが、
完璧に仕様を固めてそれに忠実に開発していくことはほとんど不可能である。
その理由はいくつかある。
1.既成のライブラリや開発済みのソフトウェアを利用するため、
仕様を把握しきれない
2.開発が大規模、階層化されているため、すべてを把握しきれない。


1-2.仕様書を満たせばいいわけでもない
バグには設計バグと製造バグがある。
製造バグは仕様書どおりにできないバグであり、ケアレスミスから
知識不足、コミュニケーション不足などから生まれる。
個数でいえば製造バグの方が多く、見つけやすくもある。
しかし、設計バグは見つかると開発済みのものまで無に戻して
やり直すハメになる。

つまり、製造バグがある状態でいくら厳密に試験をしても無駄ということである。

設計バグによる損失は非常に大きいので早期に発見する必要がある。
しかし、この手のバグが見つかるのはたいていプロジェクト終盤、
下手をすると運用が始まってから見つかったりする。

これを防ぐために、最近は開発プロセスをスパイラル化して、
徐々にシステムを育てるような開発方法がとられており、
根本的なバグやミスを早期に見つけるようにしている。


2.進捗度

項目数とその消化数で進捗を測ることが多いと思う。
しかしこれには危険が潜んでいる。1.でのべた、項目粒度が非常に不安定なためである。
まったく同じ試験を繰り返すのであれば、前回と進捗を比較することは可能であるが、
そうでない場合は比較はほとんど無理である。
バグの件数の数え方も難しい。
スペルミスもあればシステムダウンするようなバグもあるし、
ひとつの同じバグから派生した異なる現象である場合もある。
それらを正しく分類してバグの重み付けをすることも、非常に難しい。


3.単独プロジェクトの場合

ただし、1も2も、あまり気にしすぎると本末転倒となる。
粒度が均一でなくても、順調に消化すれば問題ないのであり、
無理に粒度を均一にすることに時間を割くのは無駄な場合もある。


4.観点
ユーザの観点と、開発者の観点がある。
ユーザの観点を考慮するのは当然であるが、
バグを開発者のミスであると考えれば、開発者の立場にたってどんなミスがありうるかを考えるのも有効な手段である。


こういう事をずっと突き詰めていくと、
「ある製品をテストするのに、その製品のことを知らなくてもよい」
という境地に至る。
むしろ、知らないほうが虚心坦懐に客観的に評価できる。


5.バグの原因
・先入観
・考慮漏れ
・誤解

これらは試験者にも必要なことである。
自分でもバグだとすぐに認められるバグであればよいが、
開発者が頑なに誤解して信念を持って発生させたバグの場合、
試験者がまるめこまれてしまう危険性がある。

開発したソフトウェアについての知識が要求される試験はレベルが低い。
完璧に客観的なテストは、仕様書とビルドされたソフトウェアがあれば、
なんの知識も必要としない。

仕様書がないということは、
その時点で顧客と開発者の間に誤解の発生する可能性が高いことを示す。
その誤解は開発の工程が上流から下流に移行するにつれて、
すさまじい勢いで拡散していく。


6.試験実施時に避けるべき問題

当然のことだが、試験をせずに瑕疵を見過ごすことはあってはならない。
しかし、漏れなく試験するということは不可能に近い。
「漏れなく試験しているか」ということを示す指標を「カバレッジ(coverage)」という。

特に、ソースコードの条件分岐をすべて網羅しているかなどの指標をソースコードカバレッジという。

これを評価するツールもあるようである。
プログラムを実行して、各ラインが実行された回数を表示する。
実行回数が0である行がなくなるようにテストすれば、漏れがないことになる。
また、どうやっても実行されることがない行があれば、不要な行であることになる。

この指標は、単体テストなど比較的初期のテストで使用されることが多いだろう。


7.フェーズによる観点の違い

テストは小さな単位から大きな単位へ拡張しておこなわれていくので、
通常、小さな単位内での問題は、工程がすすんだシステムテストの段階では、
無くなっているはずであり、なくなっていなければならない。

ただしそれはあくまでも「仕様通りにできているかという観点のバグ」に関する話である。
テストが後半から終盤になってくると、「この仕様でいいのか」ということが問題になってくる。
仕様が間違っていた、仕様に考慮盛れがあった、よりよい仕様があった、
などの「設計バグ」は、単体テストではなかなか見つからない。

そして恐ろしいことに、設計バグの発見はその前の工程で周到におこなわれた単体テストや
結合テストの結果はもちろんテストの実施自体も無に帰するのである。

テスト手法やツールについても、系統だった情報があるが、
それらはほとんどが工程の前半部分の単体や結合に関するもので、
絶対的な仕様書がありそれに適合するかを試験する、
という実際にはまずありえないことが前提となっている。

8.評価の評価

テストとは製品を評価することであるが、
テストも人間が、それも製品をつくっている人もしくはそれに近い人がおこなっているので、
テストが適切でない場合もある。

現在のソフトウェアのテストというのは、誰でもバグだとわかる程度のことをテストして、
それでさえバグが頻出して直すのが精一杯であるようだ。
ソフトウェアが製品としてリリース後にバグが見つかってアップデートされることは、
今ではユーザーも受け入れている。
MicrosoftのWindowsが好例である。
Windowsの場合は、サービスパックという形で、バグフィックスと機能追加を含めたものをリリースして、
品質と機能を同時に上げている
45: Fri Nov 5 06:17:26 2010
8.評価の評価

テストとは製品を評価することであるが、
テストも人間が、それも製品をつくっている人もしくはそれに近い人がおこなっているので、
テストが適切でない場合もある。

現在のソフトウェアのテストというのは、誰でもバグだとわかる程度のことをテストして、
それでさえバグが頻出して直すのが精一杯であるようだ。
ソフトウェアが製品としてリリース後にバグが見つかってアップデートされることは、
今ではユーザーも受け入れている。
MicrosoftのWindowsが好例である。
Windowsの場合は、サービスパックという形で、バグフィックスと機能追加を含めたものをリリースして、
品質と機能を同時に上げている。
これを、「MSは未完成の製品を出荷してユーザーにデバッグさせている」などと批判する人もいるが、
現在ではほとんどのソフトウェアが同様にオンラインでバグフィクスやバージョンアップをおこなっている。

9.preventive action
この言葉はIBMで知った。テストを厳密にすることは大切であるが、
それよりもバグを発生させないことが一番大事である。
そしてpreventive actionというのは単にテストやバグについてだけ言っているのではない。
製品設計の思想にもあてはまる。ユーザーが誤操作を起こさないようなインタフェース、
万一誤操作しても深刻な事態にならないように防ぐ機能、簡単で直感的なインタフェース、
そういうものを目指すことがすべてpreventive actionである。

仕事というのは、メシの種であるので、トラブルがメシの種になる場合がある。
この業界には、トラブルが好きな人がいる。はまることを喜ぶ人である。

10.バグを見つけるのは簡単

ある製品にバグがないことを証明するのは非常に難しい。
100人で3ヶ月かけて何万という項目をテストしても、
バグが絶対にないという証明にはならない。
しかし、一人が適当に操作して異常が発見されれば、
それでその製品が完璧でないことは証明できる。
ただし、バグがないことを証明するのは不可能といってよいので、
どれだけの項目をテストしたかということをもって、品質の指標とするのである。
しかし、「バグがないことの証明はほとんど不可能である」という意識は常に忘れずにいつつ、
それに近づけるような努力をしていく姿勢が必要である。


11.不明確な仕様
ソフトウェアのバグのほとんどは不明確な仕様が起こしているといってもよい。
不明確な仕様には、いくつか種類がある。

A)ユーザーの考慮漏れ
B)ユーザー要求の誤解
C)ユーザー要求を実現化する際に判明した不明点
D)開発者による実装段階での考慮漏れ

Cの不明点はさらに、ユーザーが決めるか、開発者が決めるかで二つにわかれる。


12.テストの観点

12-1.機能から
実装した機能を漏れなく確認するために必要。
初期のフェーズはこちら重視。

12-2.運用ケースから
後期のフェーズで重視される。
単体・結合では見つけられない問題が見つかることがあるが、
すべての機能を網羅するのは難しい場合がある。
シーケンスが異常終了する場合とか。



46: Fri Nov 5 06:17:35 2010
13.常に同じ構成でやるか、いろんな構成でやるか

基本は常に同じ構成・設定で試験する。
そうすればソフトウェアが更新されて問題がおきたときに、すぐにわかる。
この方法は試験者やそれを管理する人にとっては楽であり、
私がいままで携わってきた現場でもおおむねそうであった。

さらに、担当者を固定し、自動化などを導入すれば、
試験は非常に効率よく実施され、運用コストは低下するだろう。

しかし、これは品質向上という主目的からみると危険をはらんでいる。
この状態に持っていけるのは、それまでに十分な検討と検証を重ねて、
十分な試験ができていることが確認できたうえでないと、
リリース後に現場で問題が出るという最悪の事態となる。


14.フェーズ判定

ということで明らかになったことは、
テストのやり方は一様ではなく、王道もなく、万能薬もないということである。
フェーズによって、それにふさわしいテストを実施する必要があるが、
その判断が非常に難しい。「単体」「結合」「システムテスト」などの名称がつけられていても、

「テストをやってみないとどんなテストを実施すべきかわからない」
というジレンマがある。

いままで経験があるのは、定例のテストを実施したが
その後バグが多数見つかったような場合に強化試験をおこなうとうケースがあったが、
試験中に項目がふさわしくないので作り直すとか、
あまりにバグが多すぎて出荷できない、などという事態は経験がない。

最近思うのは、テストをする前におおまかなテストをしたらどうか、とういことである。
試験項目の検討・作成がそれにあたるのかもしれないが、
もっと客観的な指標がほしい。

ときどき、バグが出まくるテストをすることがある。
途中から、もうやらなくても問題が出ることがわかっているようになって
ウンザリしてくる。

しかし、テストを中断することはなく、すべて実施して、見つけたすべてのバグを報告する。
こういう場合は、ある程度バグが見つかったら中断すべきだ。
開発者のスキルが低かったのか、スケジュールがタイトだったのか、
仕様が不明確あるいは間違っていたのかわからないが、
とにかく何かが予測不能なほど具合が悪かったのである。

そうなったら、スケジュールはもちろん、開発・チェック体制まで再検討、
再構築するべきである。

そしてある程度のテストを実施して大量に発見されたバグの内容から、
バグそのものを直すのではなく、なぜそのようなバグが発生したのかを突き止めて
それを改善し、やり直す。

今までのプロジェクトでそこまでテスト部門の権限が強かったところはなかった。
建前上は出荷判定やバグ検出率・検出曲線などのチェックはあった。
しかし、どんなに品質が悪かろうと、出たバグをひとつひとつつぶしていく以外の、
根本的な改善はなされたためしがない。


どんな製品も、最近は複雑になってきていて開発もテストも分散しておこなうが
全体をとりしきれないという状況をみたり聞いたりする。
が、複雑といっても間違いなくある程度の階層ができているはずだ。

^
previous | next | edit