ソフトウェアの欠陥ってなんだろう？

こんにちは！なそです。

1週間ぶりです。

12月は寒い日が続くと思ってましたが、どちらかというと11月の方が寒かった気がする今日この頃です。しかし、油断すると崩れそうなので、皆さんも体調を崩さないように気をつけてくださいね。

さて、前回に引き続き、JSTQBを読み進めて行きましょう。

ところで、「ソフトウェアの欠陥」って何を示すんでしょうか？ ひとえに欠陥といっても、自分の思った通りに動かない。エラーが発生する。設計書通りに動かない……等々とあると思います。その原因をよく考えないと修正時に間違った方向に行ってしまう可能性もあります。

それに自分がどういう欠陥を発見したのかを説明するときにうまく説明できますか？一括りに障害やバグ(以降「障害」に統一します)という言葉で片付けてしまうこともあると思います。

しかし、その障害がどういった要因によるものかを分類することも必要です。

その「ソフトウェアの欠陥」の分類はJSTQBでは以下で定義しています。

• エラー
• フォールト　
• 故障

エラーは「間違った結果を生み出す人間の行為」3×2と入力した時に5と結果が返されると、これは欠陥ですね。掛け算と足し算を間違えている可能性大です。この間違えた行為がエラーです。

フォールトは「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」先ほどの例で言うならば、3×2と入力した時に5と結果が返されるという事象がフォールトです。

故障は「コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと」

3×2と入力した時に5と結果が返されるということはシステムとして、計算をするという機能を提供できなくなります。この事象が故障です。

これはプログラムのエラーでもそうですが、ハードウェアを含めています。カラオケに行って、マイクが全て使えない状態になっていたら、サービスが提供できません。これも故障ですよね。

そして、それらの管理はインシデントと言い、意味は「発生した事象の中で、調査が必要なもの」となっています。

ただし、インシデント ≠ 故障ということだけ覚えたおいてください。テスターのオペミスということもあります。実は×だと思ったんだけど＋を押していた。マイクの電源を入れ忘れた。マイクの充電が切れていたとか考えつくので、発見した事象を調査してもらい、故障かどうかを確認していくためにインシデントを発行します。

最近だとチケットという名前で浸透していると思います。ひと昔（今もやってると思いますが）エクセルでインシデントを管理していた時の分かりにくさったらありゃしません。個票と一覧表を用意して、それぞれの同期は手動なんて時代もありましたね。そう考えるとシステム化しただけで当時からやりたいことは変わってないですね（笑）

さて、インシデントにどういう情報があれば良いか等JSTQBでも定義されています。今から説明し始めるとさらに長くなってしまうので、今回はここで終わろうと思います。

今回は「ソフトウェアの欠陥」について考えてみました！

次回は「インシデントってどうすれば良いの？」と考えてみましょう♪

テストってなんだろう？「ソフトウェアシステムの状況」ってなに？

こんにちは！なそです。

1週間ぶりです。

先週は水曜日が祝日だったのに、体調を崩してしまいドタバタな一週間でした。

12月目前で寒い日が続くので皆さんも体調を崩さないように気をつけてくださいね。

さて、前回で「7つの原則」を説明終わったので、次に進んでみましょう。

今回からはJSTQBのシラバスに沿って解説をしていきましょう。なぜ「7つの原則」から始めたかというと、ちょっとかっこいいじゃないですか（笑）かっこいいのもありますが、この原則は何を説明するときにも前提として影響を及ぼします。

今回は「1.1テストの必要性」の「1.1.1ソフトウェアシステムの状況」についてです。

ソフトウェアシステムと世界はもはや切り離す事ができないくらいに融合しています。

銀行や自動車、食品、生産現場でシステムを使用しています。業務中にパソコンを使わない事が今まで以上になくなっていくでしょう。最近はさらにIoTの成長は著しく、生活により浸透していくでしょう。

システムが不都合な動きをすることで社会に影響を与えます。大きく分けて4つあります。

• 経済的な損失
• 時間の浪費
• 信頼の失墜
• 損害や死亡事故

どれも想像つくと思いますが、ひとつずつ見ていきましょう。

・経済的な損失

昨今のシステムはリアルタイムで動く事が多いです。そのためトラブルで発生したシステムで止まる時間は取引が停止または減少するので、その影響は経済的な損失につながります。

・時間の浪費

経済的な損失はそのまま時間という損失を発生させます。システムを修正する時間は、時間の浪費という形で現れます。

・信頼の失墜

品質の低下は信用の失墜という形で現れます。これは製品の競争力の低下につながり、会社のブランドイメージを低下していきます。これはソフトウェアシステムだけではなく、どの業界でも同じだと思います。

・障害や死亡事故

 車を例に話をしましょう。車に自動運転や緊急停止など少し前よりも機能が追加されはじめています。車の大部分をソフトウェアシステムが制御ようになりました。そのソフトウェアが不都合な動作をすると事故が発生する可能性があります。最悪乗客が死亡することもあるでしょう。

しかしながら、ソフトウェアの欠陥は全て取り除くことができません。(7つの原則を参照)

テストを行う際は様々な状況を想定して、ソフトウェアの動作をテストしていく必要があります。現状ではこれをやれば正解というテストはありません。無数に広がるテストから状況に応じたテストを選び抜く必要があります。そのお手伝いができれば嬉しい限りです。

今回は 「1.1テストの必要性」の「1.1.1ソフトウェアシステムの状況」について説明しました。社会に浸透したソフトウェアシステムはどかまで成長するのでしょうね。

 さて、次回は「1.1.2 ソフトウェアの欠陥の原因」です。

それでは！

テストってなんだろう？第7回「バグゼロの落とし穴」

あれから5日。「なそ」です。

定期的な更新を心がけ1週間くらいのサイクルで更新を目指してます。

とりあえず3回目。これで三日坊主になれる。続けることに意義がありますね。

7つの原則も最後。今回は「バグゼロの落とし穴」です。

簡単に説明すると、全部テストしたからって安心しないでねって言うことです。

ここでバグゼロって無理だよって説明してたくせに何を言い出すんだと思ったあなた！

鋭いですね。ここは原則6「テストは条件次第」を使って絞り込んだ状態のテストをすべて確認が終わった状態だと思ってください。

当然すべてのテストが一回で確認終わると思いません。障害として報告され、修正されることがあります。その中で修正した結果、報告したAは修正できたけど、Bが新たに発生しているということがありますよね。いわゆるデグレート、デグレですね。他のテストで確認できればよいのですが、仕様外のものは見つけにくいですね。Aの修正結果で動作が重くなったり、セキュリティに穴を開けてしまったりとなり、他の障害になっては目も当てられません。Aを直したけど、今までできたCができなくなるっていうものありますね。

そうなるとお客さんからのクレームにつながります。結果的に自分達の信用を傷つけてしまうということがあります。

しかし、決められたテストはすべてパスしているという矛盾。修正を行う際は、Aができるだけではなく他の機能に影響しないかという視点でものを見ていく必要があります。

ちょっとめんどくさいと思いますが、これも重要な作業になるでしょう。

そういう意味では、リリース前のテストを決めておくべきでしょう。機能テストとシナリオテストを用意しておけば大丈夫でしょう。そして、できることなら自動化できていると作業が楽になるでしょう（毎度、ほぼおなじテストになるはずので手動でやるよりも断然効率がよいです）

でも、自動化したらOKというわけでなく、原則5の「殺虫剤のパラドックス」に注意してくださいね！

バグゼロと言うのは原則6の「テストは条件次第」で、テストする部分を絞り込んでいます。絶対的に原則2の「全数テストは不可能」がありますので、バグゼロなんてありえないんですよね。原則1の「テストは「欠陥がある」ことしか示せない」ですので、漏れていたら残念ですが見つけられないですね。

なんか原則の復習もできたのでいい感じですね。

それでは、今回は原則7の「バグゼロの落とし穴」でした。

次回からJSTQBの違うものを見ていきましょう。

テストってなんだろう？第6回「テストは条件次第」

あれから1週間。「なそ」です。

定期的な更新を心掛け、1週間というサイクルで再び投稿できたことを人類にとっては小さな投稿だが、「なそ」にとっては大きな投稿です。

だいたい2回目までは続くんです。三日坊主にすらなりきれない残念状態の「なそ」ですが、今回はやるぞー！

というわけで、残すところ7つの原則も2つ。今回は6つ目の「テストは条件次第」です。もう少し具体的に言えば、「前提条件としてプロジェクトが何を優先するか次第で、テストが異なる」ということです。

その答えはすべてのものが有限であるからです。例えばですが、QCDをメインに考えるとわかりやすいでしょうか？　QCDはQuality(品質)、Cost(資金)、Delivery(納期)の3つですね。これも語り始めると時間がかかるので、スルーさせてもらいます。いつか書きたいものです。

Quality(品質)を優先すると、Cost(資金)、Delivery(納期)は大きくなります。

ここでステータスであるQuality(品質)を前回にしなければいけないのは、主に人の命を預かるシステムになります。医療をはじめとするシステムですね。Quality(品質)を優先するので、細部まで見て安全性を高めるのでCost(資金)は高くなり、Delivery(納期)は遅くなります。開発サイクルは長くなる傾向にあるといっても過言ではないでしょう。

では、Delivery(納期)が優先されるのはどういった場合でしょう？これはスマホアプリが該当します。多少のQuality(品質)を落としても早く出すことで市場を押さえることができます。またネットにつながる利点を活かして更新頻度を高め、少しずつQuality(品質)を高めていくことができますが、基本的にDelivery(納期)が優先されると思います。そうなるとテストできる範囲が狭くなるので、当然Quality(品質)は下がります。

しかし、Delivery(納期)が早くなる ≠ Cost(資金)が安いは同義ではないです。メンバーの生産性が高い場合結果的に安くなることはありますが、大人数で開発を行う場合、Cost(資金)は高くなるでしょう。

最後にCost(資金)を優先する場合は、そもそもテストするかなって感じがしないでもないですが、スモールスタートを行うことが多いです。機能の全部を開発せずに一部だけ開発して使ってみて少しずつ機能拡張していく。そうすると少ない機能を少しずつテストしていくので、先の2つの条件とはまた違ったテストが必要になると思います。

って、QCDメインで話が進んでるじゃないですか……

たとえにQCDを出した時点でこうなりますよね。いつかじゃなくて今日書くことになるとは！

「前提条件としてプロジェクトが何を優先するか次第で、テストが異なる」ということがわかっていただけたでしょうか？

最後に全部大事という強者な上司に出くわしたときはプロジェクトの失敗を覚悟して大いにぶつかっていくべきだと持論を述べておきます。(最終的には火を噴くはずなので、失敗覚悟でやると大いなる経験をすることができます)

今回は7つの原則の「テストは条件次第」でした。

次回は7つの原則の最後「バグゼロの落とし穴」です。お楽しみに～ノシ

テストってなんだろう？第5回「殺虫剤のパラドックス」

あれから5か月ぶりになる「なそ」です。

WACATEに参加したり、テストコンテストに参加したり、お仕事がガチで忙しくなったりで時間をうまく作れなかったのが原因です。

定期的な更新を心がけていきたい。来年の目標ですね。

今回は7つの原則の5つ目「殺虫剤のパラドックス」です。

同じテストの繰り返しは、範囲外のバグを見つける可能性を低くしてしまいます。

ISTQBのシラバスでは「Pesticide paradox(農薬のパラドックス)」です。

Pesticideで調べると農薬がトップに来ます。insecticideが殺虫剤ですね。

同じ農薬(テストケース)を使い続けると、対象の害虫や雑草(バグ)を駆除することができますが、農薬に対応した害虫や雑草(バグ)や、別の場所からやってきた害虫や雑草(バグ)は駆除することができないですよね。

農薬が効かない害虫や雑草(バグ)が、今育てている作物(プログラムやシステム)に影響しないかというとそうではないですよね。対象の害虫や雑草(バグ)には対応できましたが、作物(プログラムやシステム)が全滅しました。なんてことになったら目も当てれないです。そこで、一定期間ごとに見直しを行い、改修していくことで改善していきましょうといいことです。

農薬の歴史は古く、農薬の起源は慶長 5 年(1600年)ほど関ヶ原の戦いをしていたころに遡るそうです。そこから400年とちょっと改善を加えながら今の農薬ができていると思います。その他には「虫追い」という祈祷を行っていたそうです。(確かに今でもリリース後に祈ることがあるけど。。。)

同じテストケースを使うことで、使ったテストケースと同じ動作は保証できます。しかし、それ以外の使い方をして障害が発生したらなんとも言えないですよね。

同じテストケースを使いまわすことが多いのはシナリオテストでしょうか？製品サイクルがあり、なおかつ機能面では大きく変更がないシステムの場合には使い回しは有効ですね。昨今話題の自動テストでのテストケースも同じように使いまわしが多そうです。

どこまでカバーできていて、何がカバーできていないのか。これを機に見直してみてはいかがでしょうか？

はて？自動テストはスクリプトしかない？聞こえませんねぇ。そのあたりは今後どうするのがいいのか考えてみたいものです。

それでは、今回は7つの原則「殺虫剤のパラドックス」でした。

テストってなんだろう？ 第4回「欠陥の偏在」

2日連続の「なそ」です。

ちょっと最近品質ってなんだっけ？状態に舞い戻ってきているので、勉強を兼ねてFLの復習を行ってます！

さてはて、7つの原則も4つ目「欠陥の偏在」です！ とうとう折り返し地点ですね♪

これは、皆々様も経験あるのではないでしょうか？

人によって得意・不得意があるようにプログラミングにも癖が出ます。

プロジェクトや組織によっても癖が出ます。要はQCDのどこに重点を置くかという問題なのでは無いでしょうか？

本当は癖など出さずに万人向けのプログラムを書くべきなのでしょう。しかし、膨大なルールやその時のトレンドを反映したプログラムは現に沢山存在するのです！(言い切ってしまってますが、本当にちゃんとしている所もあります)

そういうことで、バグの発現にはある程度予測できます。できることならチケットをいい感じに分類して傾向のメトリクスをとって見るものいいと思います。

プロダクトの特性だったり、プログラム固有の問題。はたまた個人の癖だったりします。それは秘伝のタレとなって、誰も触ることができない魔物と化します。「汝ら、リファクタリングを禁ず」とか看板(コメント)が残っているかも知れません。魔窟に住むドラゴンのごとくですね。勇者が現れるまで、そこには立ち入ることができません。。。

とまぁ、そんな壮大なものではないです(笑)

たいていの場合、過去の実績を元に知見がある人達をアサインして、属人性を持ってプロジェクトを運営したりしますね。過去のチケットから傾向を洗い出すって言うプロジェクトもあるでしょう。

過去に結合テストで失敗したプロジェクトがあれば、そこに重点を置くのも手です。

そうやっていろんな人の知見を得ながら少しずつ成長するべきだと私は思っています。

それが歴史を積み重ねるということで、老舗のSIerにしかできないことだと思ってました。今も思ってます。だからこそ、あの不甲斐なさには心底がっかりしたんです。

案件数で稼ぐ方法もあります。しかし、これにはその人達の知見をまとめにくいという問題もあります。

語り継ぐべきことは、過去の栄光ではなく過去の失敗談です。そういうものほど傾向が似ていたりします。でも、恥ずかしくて人に言いにくいんですよね。これ。。。(笑)

欠陥はまんべんなくプログラムに入り込むわけではなく、仕様が甘い所、作りが複雑な所に入り込みます。そういった所を開発者とコミュニケーションをとって、品質は問題無いということを宣言できるテストエンジニアに私はなりたい。

それでは、今日はこんなところで。

テストってなんだろう？ 第3回「初期テスト」

テストエンジニアとして、半年が経過したわたしこと「なそ」です。

さてはて、7つの原則の3つ目「初期テスト」です。

早い時期からテストしましょうということですね。

V字モデルでは、製作以降でテストを実施します。テスト分析やテスト設計はできますけどね。

しかし、設計書に作り込まれるバグはテストしてしまう前に潰してしまうべきです。

そういう意味では、早い段階からテストエンジニアが参画するのは意義のあることです。

設計書に全てを記載するべきではありますがそれは不可能ですし、やるべきでもないでしょう。設計書の構成管理は辛くなるだけです。

どこまで設計書でフォローするかはプロジェクトや会社で決めることです。

わたしが知る限りでは、開発者が製作とテストは兼任することが多いです。といいつつも製作が押すことは基本ですよね！！（製作やってた自分は押さなかったことが…）そうなった時になにが削られるかというとテストですよね。テストの工数は確保してても、人員を確保していない場合は綺麗に削られるかだけですね。

テストエンジニアは別にテストだけをしているわけではありません。

品質は製作後につくり込むものではなく、プロジェクトの最初からテストの視点でレビューできればテストで障害を出さずに品質を作り込め流のではないでしょうか？そうしたら、みんな幸せになれるのではなれるでしょう？