テストってなんだろう? 第3回「初期テスト」
テストエンジニアとして、半年が経過したわたしこと「なそ」です。
さてはて、7つの原則の3つ目「初期テスト」です。
早い時期からテストしましょうということですね。
V字モデルでは、製作以降でテストを実施します。テスト分析やテスト設計はできますけどね。
しかし、設計書に作り込まれるバグはテストしてしまう前に潰してしまうべきです。
そういう意味では、早い段階からテストエンジニアが参画するのは意義のあることです。
設計書に全てを記載するべきではありますがそれは不可能ですし、やるべきでもないでしょう。設計書の構成管理は辛くなるだけです。
どこまで設計書でフォローするかはプロジェクトや会社で決めることです。
わたしが知る限りでは、開発者が製作とテストは兼任することが多いです。といいつつも製作が押すことは基本ですよね!!(製作やってた自分は押さなかったことが…)そうなった時になにが削られるかというとテストですよね。テストの工数は確保してても、人員を確保していない場合は綺麗に削られるかだけですね。
テストエンジニアは別にテストだけをしているわけではありません。
品質は製作後につくり込むものではなく、プロジェクトの最初からテストの視点でレビューできればテストで障害を出さずに品質を作り込め流のではないでしょうか?そうしたら、みんな幸せになれるのではなれるでしょう?
テストってなんだろう? 第二回「全数テストは不可能」
転職してから6ヶ月目。
あっという間の半年でした。
いろんなことを体験しながら、これから来る「梅雨」が恐怖でしかありません( ゚д゚)
北海道に住んでいたので「梅雨」の経験はありません。
さてはて、どうなることか。
さて、半年近くテストエンジニアをしていますが、いまだにテストとはなんだろうと思わない日がありません。
しかし、テストエンジニアにはJSTQBのシラバスというバイブルが存在します。
今回もシラバスを読み解いていきましょう!
前回に引き続き、7つの原則のその2です。
原則2.全数テストは不可能
これは確かに不可能です。
例えば、
計算機には「1」「2」「3」「4」「5」「6」「7」「8」「9」「0」
演算子は「+」「-」「×」「÷」「=」
1桁の数値を2回演算するパタ-ンのテストケースを考えてみましょう。
正常系のテストは
「数値(10パターン)」+「演算子(4パターン)」+「数値(10パターン)」+「=」+「結果」
テストケースは10 × 4 × 10 = 400ケース
はい!400 ケース
このケース数は正常系のテストです。
では、異常系は?
・
・
・
無限に考えられます。
しかも今回は「1桁の数値を2回演算するパタ-ン」です。
ということは、全数テスト=無限のテストケースということになりますね。
ゆえに不可能です。
まぁ、世の中そこまで考えてくれる人はいないので、「組み合わせを全パターンやればできるだろ!」とか平気でいう人がいます。これマジです。
言われたことあるんです。じゃ、素直に組み合わせを持って行くと、このパターンはありえないだろと言う人。たしかにそういうこともありますけどさ(笑)
今回は、パソコンについては言及していませんが、パーツの愛称というのものあります。他にもAWSとかのインフラが落ちる場合もあります。そういった外的要因も考えると本当に全数テストは無理です。AWSに「テストしたいからサービス落としてくれ!」なんていう強者がいないことを望みます。
じゃ、どうするかというと
取捨選択するしかありません。
WEB系のシステムだとブラウザをどこまでテストするか、どういった因子や水準を設けるか。その組み合わせで不可能なパターンはケースとして除外するか。
etcetc…
ここで重要になるのはQCDでしょう。どこまでの品質を求めて、それにかけれるコストを決め、いつまでに必要かを明確にするべきでしょう。
品質は最高品質で、でもコストはかけないで、納期はなる早で!
そんな会社はブラック臭がするので、気をつけてください!
経営陣がQCDに対して決められないのなら、その会社は成長しないと言えます。
逃げることを勧めます。よっぽどのドMだったらいいかもしれませんが(笑)
それでは、今回はこの辺で!
テストってなんだろう? 第一回「テストは欠陥があることしか示せない」
転職してはや2ヶ月。
2016年が2ヶ月過ぎようとしてます。
私はあっという間の2ヶ月でしたが、みなさんはいかがでしたか?
東京に越してきてから、土日は勉強会に参加しています。
その中で、テストエンジニアと名乗ると興味を持ってくれる人が多いです。
まだまだひよっこのテストエンジニアですが、開発者だった前職から品質やテストについて考えることが多かったです。
そこで、今回はテストってなんだろう?と考えてみました。
JSTQBでは、「テストの7原則」として公開している原則があります。
- テストは、欠陥があることしか示せない。
- 全数テストは不可能
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- 「バグゼロ」の落とし穴
この原則が成り立つことは私も同意します。
7回に分けて、1つずつ見ていきましょう。
原則1.テストは、欠陥があることしか示せない。
「よし、テストをすべて消化したから、これで欠陥がないことが証明できたぞ」
と言って、リリースしたらお客さんから欠陥が発生したと連絡があったという経験はありませんか?
私はたくさんあります。そして、その経験があるので経験則でこの原則が成り立っていることも理解しています。多分、開発者からプロジェクトマネージャになった方も経験しているのではないでしょうか?
なぜ、欠陥が無いことは示せないのでしょうか?
これは、幾つか原因はあります。1つ目は製作したサービスがOS上で実行されるからです。当然OSもソフトウェアです。欠陥を十分に含んでいます。じゃないと月に何回かアップデートが入りませんよね(笑)
というわけで、OSの欠陥に起因するサービスの欠陥があるかもしれません。それが、OSの特定バージョンだけだったら。。。と考えると欠陥が無いことは示せませんよね。OSを例にしましたが、ブラウザだってそうですね。IEとかIEとかIEとか。
2つ目は、納期、コストが制約になる場合、優先順位をつけてテストを実行するしかありませんよね。テストが重要ということはわかっているけど。。。ということです。テストケースもこの制約を受けるので、無いことを示すまでテストを実行し続けるのは不可能です。全数テストについては「全数テストは不可能」の回で詳しくお話します。
3つ目は、デグレーションが発生する可能性があるということです。デグレですね。
欠陥を発見して、修正しましたがその修正が新たな欠陥になるデグレーションです。
欠陥を修正したときにどこまで回帰テストをやるかというと、納期、コストがここでも制約になります。
と、まだまだあると思いますが、上記を考えるだけで欠陥が無いことは示せません。
ただし、この原則を伝えると、経営者やプロジェクトマネージャの方はお怒りになるのではないでしょうか? もしくは彼らは不安で眠れない夜が続くかもしれません。
この不安を完全に解消することはできません。断言できます。(だって、欠陥が無いことは示せないんだもん) しかし、テストをすることで和らげることはできます。
そのために、テストレベルが存在します。
例えば、コンポーネントテスト(機能テスト、単体テストとも呼ばれる)、非機能テスト、統合テスト、システムテスト、受け入れテストなどレイヤーが分かれているのはそのためです。その他にも会社によって違う呼び名があるかもしれませんが、同じような内容のテストをしていると思います。いろいろなレベルのテストを実施することで細かな欠陥から、ユーザーの要件を満たしているかという仕様の欠陥を見つけ出すことができます。
「ローマは一日にして成らず」
テスターも一日にしてなりません。特に開発者と違って、経験値が必要な職種だと思います。職人技とも呼べるでしょう。
みんながゆったりと眠るために、少しずつテスト力を蓄えていきましょう!
転職 × テスト会社 × 前職
皆様、はじめまして!
東京でソフトウェアのテスト会社に転職したので、今までとこれからの経験を配信してみよう!!と思い、ポチポチとここにブログを解説しました。
転職って、ドキドキしますよね。
今は全然考えてないけど、自分の会社を去る時を考えると神妙な気持ちになる人は多いんじゃないでしょうか?
私もその一人でした。が、今思い返すと意外にあっさりした転職でした。
今回の転職は「ここに入りたい!!」という気持ちから1社のみ応募し、内示をもらうことができたせいかもしれません。(ここがダメなら転職しないつもりでした)
もともとは、北海道でSIer & パッケージ製作の会社で勤務していましたが、今回思い切って東京に出てきました。
勤務地に東京を指定した理由はいくつかありますが、
あえていうなら。。。
「一度は日本の首都で仕事してみたい!!」
という一言に尽きます。
テスト会社って、何するんだろう?と思う人が大半だと思います。簡単に説明すると単体テスト(機能テスト)が終わった後から参画し、結合テストなどを行い、ある一定の品質が確保されていることを確認するっていうのが、主な業務です。他にもあります。
テストに第3者が参画する利点は3点あります。
- エンジニアがテストから開放されて、本来の業務に集中できる。
- 発生した障害から傾向をつかみ、次期プロジェクトにフォードバックできる。
- 第3者が検証したことで品質に対する裏付けができる。
東京で勤務したいだけが転職理由ではなく目的はきちんとあります。
前職では、エンジニアが要件定義から保守まで一貫して担当することが大半でした。
それは、効率面から言っても理にかなっています。しかし、プロジェクトは火を吹くことがありました。原因は様々でした。
(要件を正しく聞き出せなかった。バグが多発し使える状態ではなかった。移行したデータが正しく移行できてない等)
その体験を繰り返すうちに、どこが悪いかわからないけど仕組みに問題がある気がしてきました。特にテストを実施する場合の仕組みに疑問を持ちました。
あわせて、自分自身のテスト設計、管理、実施等も課題にあがりました。
自分自身で勉強し、会社に広めていくというコトも考えましたが、人の気持ちと会社の
やり方を変えていくエネルギーは当時の私にはありませんでした。そんな時に今の会社の求人を見つけました。
テストのやり方を学び、実施し、その経験を活かしてシステム開発全体に貢献出来るようになりたいと思い、転職を決め、活動を開始しました。そして、このブログの開始ですね。
それでは