オープニングと番組紹介
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
最近、このポッドキャストを続けていて、リアルに会った友人から、なんでポッドキャストをやっているの?みたいに質問されることが何回かありました。どうしてだろうな、というのを改めて考えてみると、今までテストに対する知見とか、自分の頭の中でちゃんと認識はしているつもりだし、
それこそ若手を始めとしたいろいろなところで、それを形として残していってはいるものの、それをちゃんともっと公約に形として残しておきたかったというところはあります。やっぱり自分が得た知見というのは、自分だけに残しておくのはすごいもったいないなと思っていて、なので少しでも皆さんの役に立てればなと思ってやっています。
ということで、今回は最近までやっていたテスト設計の話は一旦脇に置いておいて、テストの7原則について話していきたいと思います。ということで、今回もbtesting.fmスタートです。
テストの7原則とは
ということで、今日はテストの7原則について話していきます。今回はその前編になります。前半部分について少し解説をしていきます。
まずテストの7原則とは何かという話からしておきます。テストの7原則とはISTQBおよびそれの日本語訳として書かれているJSTQBに記載されているあらゆるテストで共通に使える一般的なガイドラインになります。
以前まではソフトウェアテストの7原則と呼ばれていました。ですが、今のシロバス上ではテストの7原則と表現されています。
テストという話を聞くと、QAエンジニアとか開発者とかが関わる話でしょって思われがちなんですけれども、それだけではなくて、マネージャーとかもしかしたら経営者とかそういうようなあらゆるロールの人に知ってほしい原則になります。
なので、今回と次回になるかわからないですけど、2回に分けてテストの7原則について話していきますので、こういうことなんだっていうのをぜひ皆さん理解していただいた上で、皆さんの会社の経営層やマネージャーの方にも伝えてもらえるといいかなと思っています。
それでは一つずつ補足を含めて説明していきます。
原則1: 欠陥があることは示せるが、ないことは示せない
まず一つ目ですね。テストは欠陥があることは示せるが、欠陥がないことは示せないです。
これは何を言っているかというと、テストによってこの製品はバグがないということは証明できないということですね。
なので、私がこのプロダクトに対してテストをしました。
なので、これはもう大丈夫です。バグがないからリリースしていいですよ、なんていうことはとてもじゃないけど言えないんですよね。
よくそれこそ経営層であったりとかから障害が発生したときとかに言われるのが、これちゃんとテストしたの?
テストしたんだから障害なんて起こるはずないよね、みたいに。
そういうふうにもしかしたら言われる経験がある人もいるかもしれませんが、そもそもそれは無理ですよと。
この製品にバグがないという証明はできません。
なので、テストをやることによってこの欠陥がありました、バグがありましたは示せるのですが、そうではなくてバグがないとは証明しきれませんと。
ただその代わりに、こういうテストをしてこのテストをした部分に関しては大丈夫でした、みたいなそういう伝え方になるかなと思っています。
原則2: 全数テストは不可能
続いて2つ目ですね。全数テストは不可能です。
これは全てのパターン数は膨大なのでテストは不可能ですよということを表しています。
例えば一例を挙げてみましょう。
例えばですね、会員登録画面とかのところの氏名の入力欄があったとしますと、
その名字の部分に入れることができる文字のパターンってどのくらいあるんでしょうと。
例えば6文字入れられるとして、その6文字っていうのは何でもいいものだとしたら、
例えば乗用漢字だけするとしますと、乗用漢字だけでもだいたい2000文字ぐらいあるわけですよね。
それが6文字はなかなかないとしても、例えば苗字で5文字をやるだけで2500の五乗になるわけですよね。
そうするとそれだけで約4000丁パターンになるわけですよね。そんなの無理ですよね。
じゃあそういう全てを組み合わせじゃなくて、日本に存在する苗字のパターン全てをテストしようって言ったとしても、
それって13万パターンぐらいあるわけですよね。それはもうパターン数は膨大なので、
テストは現実的には無理ですよっていうお話になりますと。
じゃあそれってどうするかっていうと、着目する部分をあらかじめ決めておくっていうのが大事ですよと。
例えば苗字っていう入力欄に対して、苗字っていうのは仮に10文字ぐらいまでだったら入力できるよみたいな、
そういう文字数に着目したりとかですね。
あとは文字の種類、ひらがな、カタカナ、漢字、アルファベットみたいなそういう文字の種類に着目して試すということになるかなと思っています。
これが以前にも話した動地分割法を用いて、動地パーティションを考えるっていうのが大切になってくるわけですね。
今、苗字の記入欄だけで4000兆パターンとか、苗字の種類だけで13万パターンとかっていう話をしましたが、
そこにさらに名前の入力欄とかっていうのを単純に掛け合わせたらもっとたくさんになるので、
先ほど言ったような文字の種類とか文字数であったりとか、着目する部分をあらかじめ決めておくというのがやっぱり大事なんですね。
原則3: 早期テストで時間とコストを節約
続いて3つ目です。早期テストで時間とコストを節約ということで、
これはいかに早く結果に気づけるかっていうのが重要なので、テストは後でっていう考え方はしないほうがいいですよという話です。
これはこのbtesting.fmの中でも何回か話している話ですね。
特に以前話したやつでいうと、オンリーのランテストに出すからなって事前に予告することが大事だよって言ったのもこれに当てはまりますね。
早くテストのことを考えることによって結果的に総合的なコストは節約できるよというお話でした。
原則4: 欠陥の偏在
今回のエピソードの最後4つ目ですね。欠陥の偏在です。
欠陥はまんべんなく存在はせずに局所的に発生するという話です。
これは何かっていうと、まさに境界値分析の話とかそうでしたけれども、
例えば4文字以上とかって言った時には、3文字と4文字っていう境界の部分を気にする必要がありますよ。
なぜかというと不統合のところを間違えてしまって、統合イコールを抜いてしまっているとか、
そういうところっていうのが欠陥として起こりやすいとかそういう風になるわけですよね。
4文字以上13文字以下とかっていう話になった時に、文字数が7文字とかそこら辺も含めて、
まんべんなく欠陥が存在しているわけではないよっていうお話です。
あと他の例で言えば、例えば皆さんもイメージとしてはあるかもしれません。
何かよく分からないけど、このプログラムのファイルはよく欠陥が出るんだよなみたいなものってあったりしませんかね。
要注意なクラスみたいな、そういうものがあると思います。
そういうように欠陥には偏在があるよということは、それを活用することによって、
その偏在している部分にはちゃんと注意深くテストしましょうみたいな計画を立てることができるっていうのが、
この欠陥の偏在をうまく活用する話になります。
ということで、今回は7つ原則あるうちの前半の4つについて説明してきました。
今後、次回になるか分からないですけれども、後編として残りの5番目、6番目、7番目は今度話したいと思います。
質問コーナー: QA開始時の実装遅延
それでは質問コーナーです。
これも以前のイベントでいただいた質問を拝借しました。
実装の積み残しが多くQAできる状態ではないのに、スケジュール上QA開始ってなったらどうやって切れますか?
質問ありがとうございます。
どうやって切れますかは分からないですけれども、
まずそういうふうなQA開始っていうふうにならないようにするっていうのは、
やっぱり事前のところで大事かなと思っていて、
ここでいうQA開始って、QAエンジニアの作業が開始みたいな意味合いなんですかね。
それともテスト期間が始まったよみたいな、そういう意味合いなんですかね。
ただし、やっぱりQAというのはクオリティーアッシャーランスなので、
品質保証、特に品質保証活動っていう話で言うと、
QA開始みたいに置くのがまず違うかなって個人的には思うのと、
積み残しが多い状態で、仮にテストフェーズみたいな言い方だとして、
それでテストを今から始めようっていうふうにゴテゴテに回ってる時点で、
それは実装積み残してるじゃないかっていうところの責任云々ではなくて、
そもそもそういうふうな体制で品質保証活動をしているという自分の状況が
とりあえず良くなかったんだなというふうに反省するかなと思います。
なので、少なくとも切れるということはないかなと思っています。
なので、今あとは現実的な話で言ったら、
実装の積み残しがあるっていうふうになった場合には、
これだけテストを最初やってみたんだけれども、
これぐらいバグが頻発するみたいなことがあるかなと思うので、
テスト実際に全体の進捗でまだ10%もやってないんだけれども、
ここぐらい出てるので、ちょっと一回実装の部分見つめ直してみませんか、
みたいなそういう言い方はするかなと思っています。
ということで、切れることはないけれども、
やる手立てはいくつかあるかなという感じです。
質問ありがとうございました。
エンディングとリスナーへのお便り募集
ではエンディングです。
btesting.fmはリスナーさんからのお便りを募集しています。
エピソードの感想や、私に聞いてみたい質問やテストのお悩みなど、
どんなことでも構いません。
投稿フォームは番組概要欄にあります。
また、エピソードの感想は、
ハッシュタグBテスティングでXのポストをお願いいたします。
今日の話で言えばですね、
テストの7原則について話してきましたけれども、
この部分は自分もちょっと注意したほうがいいなとか、
これちょっと経営層とかマネージャーに伝えたほうがいいなと思うような原則、
今回は1から4を紹介しましたけれども、
その中でもあったりしましたかねっていう、
そういうような感想でも全然構いませんので、
ぜひポストをお願いします。
もしもこれからも聞きたいという方は、
お手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づけます。
今回のテストの7原則はまさにですね、
今回前編でしたけれども、
この後後編も収録して公開する予定ですので、
それをすぐ気づくっていう意味でも、
ぜひフォローもお願いします。
ということで今回はここまでです。
それではまた次回。バイバイ。