テストってなんだろう？「ソフトウェアシステムの状況」ってなに？
こんにちは！なそです。
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字モデルでは、製作以降でテストを実施します。テスト分析やテスト設計はできますけどね。
しかし、設計書に作り込まれるバグはテストしてしまう前に潰してしまうべきです。
そういう意味では、早い段階からテストエンジニアが参画するのは意義のあることです。
設計書に全てを記載するべきではありますがそれは不可能ですし、やるべきでもないでしょう。設計書の構成管理は辛くなるだけです。
どこまで設計書でフォローするかはプロジェクトや会社で決めることです。
わたしが知る限りでは、開発者が製作とテストは兼任することが多いです。といいつつも製作が押すことは基本ですよね！！（製作やってた自分は押さなかったことが…）そうなった時になにが削られるかというとテストですよね。テストの工数は確保してても、人員を確保していない場合は綺麗に削られるかだけですね。
テストエンジニアは別にテストだけをしているわけではありません。
品質は製作後につくり込むものではなく、プロジェクトの最初からテストの視点でレビューできればテストで障害を出さずに品質を作り込め流のではないでしょうか？そうしたら、みんな幸せになれるのではなれるでしょう？
テストってなんだろう？ 第二回「全数テストは不可能」
転職してから6ヶ月目。
あっという間の半年でした。
いろんなことを体験しながら、これから来る「梅雨」が恐怖でしかありません( ﾟдﾟ)
北海道に住んでいたので「梅雨」の経験はありません。
さてはて、どうなることか。
さて、半年近くテストエンジニアをしていますが、いまだにテストとはなんだろうと思わない日がありません。
しかし、テストエンジニアにはJSTQBのシラバスというバイブルが存在します。
今回もシラバスを読み解いていきましょう！
前回に引き続き、7つの原則のその2です。
原則2．全数テストは不可能
これは確かに不可能です。
例えば、
計算機には「１」「２」「３」「４」「５」「６」「７」「８」「９」「０」
演算子は「＋」「－」「×」「÷」「＝」
１桁の数値を２回演算するパタ－ンのテストケースを考えてみましょう。
正常系のテストは
「数値(10パターン)」＋「演算子(4パターン)」＋「数値(10パターン)」＋「＝」＋「結果」
テストケースは10 × 4 × 10 ＝ 400ケース
はい！400 ケース
このケース数は正常系のテストです。
では、異常系は？
・
・
・
無限に考えられます。
しかも今回は「１桁の数値を２回演算するパタ－ン」です。
ということは、全数テスト＝無限のテストケースということになりますね。
ゆえに不可能です。
まぁ、世の中そこまで考えてくれる人はいないので、「組み合わせを全パターンやればできるだろ！」とか平気でいう人がいます。これマジです。
言われたことあるんです。じゃ、素直に組み合わせを持って行くと、このパターンはありえないだろと言う人。たしかにそういうこともありますけどさ(笑)
今回は、パソコンについては言及していませんが、パーツの愛称というのものあります。他にもAWSとかのインフラが落ちる場合もあります。そういった外的要因も考えると本当に全数テストは無理です。AWSに「テストしたいからサービス落としてくれ！」なんていう強者がいないことを望みます。
じゃ、どうするかというと
取捨選択するしかありません。
WEB系のシステムだとブラウザをどこまでテストするか、どういった因子や水準を設けるか。その組み合わせで不可能なパターンはケースとして除外するか。
etcetc…
ここで重要になるのはQCDでしょう。どこまでの品質を求めて、それにかけれるコストを決め、いつまでに必要かを明確にするべきでしょう。
品質は最高品質で、でもコストはかけないで、納期はなる早で！
そんな会社はブラック臭がするので、気をつけてください！
経営陣がQCDに対して決められないのなら、その会社は成長しないと言えます。
逃げることを勧めます。よっぽどのドMだったらいいかもしれませんが(笑)
それでは、今回はこの辺で！
