# タイトルコール テスティングジャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を探索するコンセプトに、 エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストのコツや品相性の奥深さ、ソーシティビューを考えていることをお話しします。 # ソフトウェアテストの7原則を学び直す（前半) こんにちは、さみぃです。 今日もテストしていますか? 今回はですね、基本に立ち返ってソフトウェアテストの7原則についてお話をしていきます。 7原則の話ってしたことあったっけね? ちょっと全く記憶にないんですけれど。 はい、お話ししていこうと思います。 まず前提としては、このソフトウェアテストの7原則っていうのがJSTQBですね。 ソフトウェアテストの資格試験とかを作っている団体組織があるんですけれど、 そこが出しているシラバスの一番基礎のやつですね、ファウンデーションレベルのシラバスにも書かれておりますので、 今回はそこのJSTQB資料ベースにお話をしていきます。 この7原則っていうのは、ソフトウェアテスト専門で日々仕事している人はそうだよねというか、 割と理解がしやすいところなので、どちらかというとソフトウェアテストのことを、品質とか興味を持ってくださっていて、 かつ、がっつりQAやってますじゃない方の方が今回の原則を学ぶと、 そうなんだという気づきがあるんじゃないかなと思って今回はこのテーマを選んでみました。 では本題に入っていきます。 まず最初にこの7原則全部名前を言っていって、その後に1個ずつ紹介というか話をしていきます。 ソフトウェアテストの7原則1つ目は、テストは欠陥があることは示せるが、欠陥がないことは示せない。 2つ目、全数テストは不可能。 3つ目、早期テストで時間とコストを節約。 4つ目、欠陥の偏在。 5つ目、テストの弱化。 6つ目、テストはコンテキスト次第。 7つ目、欠陥ゼロの落とし穴。 はい、ということで順番にお話ししていきます。 まず1つ目、テストは欠陥があることは示せるが、欠陥がないことは示せないです。 これはですね、全てのバグを見つけることは不可能ですと言い換えることもできるかもしれないですけど、ちょっと雑でしたね。 はい、ちゃんと説明します。 テストというのは、こういう条件下で、こういう操作をした時に、こういう期待結果である。 この期待結果に対して実際の結果が丸なのかバズなのか、みたいなところをね、チェックをしていくわけなんですけれど。 なので、この今言った、このシチュエーションでこういう操作をやった時に不具合が見つかりました、ありました、欠陥があるということは言えるんですけれど。 じゃあ、そこの条件下、オペレーションで不具合があったからといって、他の条件下で何かの操作をした時に不具合、欠陥がないとは断言できませんよね。 ここら辺がね、なかなか難しいところでもあるんですけれど。 仮に100でも1000でもいいんですけれど、テストを実行しました。 実行した結果、欠陥は見つかりませんでした。 なった時に、果たしてその状況というか結果、結果を見て、じゃあこのシステムは欠陥がないですねと言えますかということなんですけど、 それは証明はできませんということですね。 あくまで、今回テストを行ったさっきの状況、条件、オペレーションをした範囲では、欠陥は見つかりませんでしたということしか言えないんですよね。 あるいは、この範囲でテストを行った結果、こういう欠陥が見つかりましたということしか証明はできないというお話でございます。 続いて2つ目、全数テストは不可能。 この全数は全てですね。全てのテストはできないというお話になります。 例えば分析のコメント機能がありますね。 皆さんに書いていただいているコメントですけれども、あれのコメントの入力欄をまず例にとって考えてみましょう。 どんなテストをしたらよいでしょうか。 ざっと思いつくだけでも、まず文字の種類がありますね。 ひらがな、いわゆる日本語の全格、あとカタカナの全格半格、記号、英語、その他の文字、ロシア語とかでもいいんですけど、キリル文字でもいいんですけど、とかも含めて文字の種類がありますよね。 あとちょっとこう文字コードだったりとか、正式な名前がわからないんですけど、コンピューターではちょっと違う分類をしている複雑な漢字とかもありますよね。 そういうものもあるし、あと文字数の制限がありますよね。 コメントって何文字でしたっけ、上限。60文字でしたっけ、もっとでしたっけ。もっとあるか。 上限の文字数に対して、例えば0文字の状態でコメントは送信できるんだっけ。 多分できないようになっていると思うんですけど、とか、1文字だったら送信できる。 例えば100文字が上限であれば、100文字までは送れる。そして101文字になったら送れない、みたいなところも含めて。 そんな境界値、あ、切っちゃった。そういうテストも一緒ですね。 じゃあこの文字数のパターンを取ったときに、0文字、1文字、2文字、3文字、4文字、5文字、6文字、…、99文字、100文字まで全部のパターンをテストするというのがここで言っている全数テストの話です。 そんなことやってたら、普通機能リリースって1個のテキストボックス足しますだけじゃないですよね。 たくさんのことを一度にやるという中で、今言ったみたいにテキストボックス1つ取ってもいろんなことを考えなきゃいけないというか、テストする必要があるので、 そもそも全数全てをテストするということは不可能ですというのがこの2つ目の原則になります。 じゃあどうするのかというのがテスト技法ですね。さっき言っちゃったんですけど、境界値を分析して、 例えば100文字という上限があるのであれば、99と100と101をテストすれば、正常に入力できる部分の境目と、 順異常形というかちゃんと101文字を入力したらエラーになる、エラーが表示されることを確認できれば、 一番リスクの高いところは潰せるよね、テストで確認担保できるよねという話でございます。 テストケースの優先順位をしっかりつけて、リスクベースで判断をして、 どこにテストの労力を集中するべきかを考えて向き合いめる必要がありますよという原則考え方が、 この2つ目点数テストは不可能という原則です。 続いて3つ目です。早期テストで時間とコストを節約。 プロセスの早い段階で欠陥を取り除けば除くほど、その後の工程で見つけて取り除くよりも、コストがめちゃくちゃ安いですよという話ですね。 一番イメージされるのが動的テストといって、実際にシステムを操作してテストを行う、実行するというテストが一番イメージされやすいんですけれど、 システムがほぼほぼ完成している状態というのはプロセスのかなり後の方ですよね。 その状態で欠陥を見つけたときと、例えば実装に入る前の設計の段階とか、 そもそも何を作るのかという話をしている段階で同じ結果を見つけた場合だと、 コストが数十倍違うと言われています。 20倍だったか50倍だったか、そういう数字だったと思うんですけれど、 最近は数字も変わってきたのかもしれないので、数十倍という風にぼかしておきます。 10年より前とかだと、テストのフェーズでコストをかけて、 不具合を見つける結果を見つけるというのが割と多かったんですけれども、 50年ぐらいだと早期テスト、シフトレフトなんて言ったりもするんですけれど、 プロセスのなるべく左側の方、最初の方で結果を見つける、 結果の作り込みを防ぐという取り組みを結構しているQAの方も多いんじゃないかなと思います。 私もこの考え方をとても大事にしているので、 PRD要求要件を作っていくというプロセスに入っていたりはします。 4つ目です。欠陥の偏在。 これは欠陥が偏っているということなんですけれど、 よく2×8の法則というじゃないですか、 それもソフトウェアの不具合、欠陥にも言えまして、 8割の不具合は2割の場所に固まっているというふうにも言われています。 なので自分のシステムの弱みというか、どこがバグが多いのかなというのを分析していくと、 次何か機能追加するときとかもここら辺、 重点的にテストしたらいいなというふうに考えられる、 リスクベースドテストの重要なインプットとなります。 ということで、ちょっと残り時間がなくなってしまったので、 今回は前半ということにします。 また次回ですね、残り3つ。 テストの弱化、テストのコンテキスト次第、 欠陥ゼロの落とし穴について別の放送でお話をしていきます。 本編以上です。 # 伝言📢 今日はホッコリ話のコーナーの時間をいただきまして、ちょっとプレミアムリスナーさんへの伝言をさせてください。 来年の1月に熊本でボードゲームとかカードゲームとかを純粋に遊ぶ会を企画しようと思っております。 特に九州にお住まいのプレミアムリスナーさんの方々は、ぜひこのチャンネルのチャンネルチャットに入っていただきまして、 ちょっと伝言を確認していただきたいなと思っております。 別に内容はもったいぶってもそんな大した内容じゃないんですけれど、日程を決めたいので、ぜひ相手の日程を教えてくださいというお話でございます。 新都心という場所、熊本駅の徒歩3分か5分くらいのところにあるんですけれど、そこの部屋を予約したくて、 一応今空いている状態、空いている中で、かつ私の予定が空いている日にて候補を出したんですけれど、 いつ埋まっちゃうかがちょっと分からないので、ちょっと早めに相手に行って教えていただけると嬉しいなという伝言でございました。 # 次回予告 今回も最後までお聞きいただきありがとうございます。 明日の放送は、テイキング・テスティング・シリアスティの17章より印象の事々をお話ししていきます。 今回の放送が役に立った、今日も聞きに来たようなやつでハートマーク、いいねいただけますととっても励みになります。 ぜひぜひコメントもお待ちしております。 それではまた明日お会いしましょう。ごきげんよう。