# タイトルコール ようこそ、世界を広げるソフトウェア品質へ。 このチャンネルでは、エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # 機能テストだけではない、ソフトウェアテストの話(テストタイプ) こんにちは、サミーです。ご機嫌いかがですか? 今日はですね、私は11月18日クラウドネイティブ・デイズの登壇があって、多分今頃緊張しているんじゃないかなと思います。 これの収録は事前に収録しているんですけどね。 タイトルというか、クラウドネイティブ時代の開発プロセス再設計、早さと品質を両立するには、というタイトルでお話ししていますので、ぜひご応援をよろしくお願いします。 はい、ということで今回はですね、機能テストだけではないソフトウェアテストの種類についてお話をしていきます。 昨日の次回予告の時に私間違えてテストレベルって言っちゃったんですけど、正しくはテスタタイプですね。 今日はテスタタイプの話をしていきます。 今日の放送は初心者向けに頑張って丁寧に説明しようと思っているんですけど、内容としてはですね、 テストの種類っていろいろあるんだよっていうものを知っていただくっていうところですね。 あと、そこ頑張りんかな一言で言うと。 ソフトウェアテストを、なんだろうな、かじり始めっていうと言い方が悪いですね。 始めたばかりだったりとか、あるいは実装、プロダクトコードを実装されている方、開発者の方、 あとですね、テストって言うとどんなイメージを持っていますでしょうか。 どんな内容っていうのかな。 おそらくなんですけれど、大体機能テストのことを指してるんじゃないかなというふうに思います。 ファンクショナルテストですね。 ここで改めてクイズと言いますか、質問なんですけれど、 じゃあこの機能テスト、ファンクショナルテスティング以外にはどういうテストの種類があると思いますか。 ちょっと考えてみてください。 今回、JST-QBのシラバスからお参照にお話をしているんですけれど、 ファンデーションレベルのシラバスにもテストタイプ、代表的な典型的なテストタイプというものが4つ紹介されているんですけれど、 1つが先ほどお話しした機能テスト。 そして2つ目が非機能テストですね。 ノンファンクショナルテスティングです。 例えば、セキュリティ系とかですかね。 あとパフォーマンステストですかね。 そういうのが非機能テストに入ってきますけれど。 3つ目がブラックボックステストですね。 4つ目がホワイトボックステストなんですけれど、 ちょっと改めて機能テスト、非機能テスト、ブラックボックステスト、ホワイトボックステストの話をしていこうかなと思います。 そもそもテストタイプって何ぞやというところから話をしていくんですけど、 これもJST-DBのファウンデーションレベルに書いてあるんですけれど、 テストタイプというのはテストの焦点、どこに標準を当てるかですね。 焦点や目的を区別するために用いられる分類ですと。 そしてテスト対象のシステムの特定の特性だったり側面に焦点を当てます。 ということなんですけど、分かりますかね。 テストをしていくとき、テスト分析、テスト設計、一番イメージしやすいところ、 テストケースを作るぞっていったときに何をテストしますかっていうのを考えていくんですけど、 その何をっていうのがテスト対象システム、システムのどういう特性を確認しますかっていう意味での 何をテストしますかっていうものをうまく分類したのはこのテストタイプになるんですよね。 よく何をテストしますかっていうふうに聞くと、対象の機能の話をしちゃうことがあるんですよね。 例えばログインのテストします、作りますみたいな感じで言っちゃうんですけど、 ログインの機能は対象ですね。 そのログインの機能のどんな特性とかどんな側面をテストするんですかっていう意味でも、 どんなテストしますかっていう質問になるんですよね。 じゃあ典型的なテストタイプ4つありましたね。 機能テスト一つ目いこうかな。 機能テストっていうのは何かというと、コンポーネントだったりシステムが実行する機能を評価します。 これはテストが何をすべきかに焦点を当てますね。 何をすべきかなので、例えばログインの例だと、メールアドレスとパスワードを入力する。 ログインボタンを押したら、正しいメールアドレスと正しいパスワードの組み合わせだったら、 ログインが成功してホーム画面に遷移するみたいな、 何をすべきかに焦点を当てたこの機能テストっていうのがありますよね。 これはとてもイメージしやすいものかなと思うんですけれど、 じゃあ一方で非機能テスト2つ目のノンファクショナルテスティングはどうかというと、 非機能テストっていうのはコンポーネントやシステムが実行する機能性、機能の特性以外の属性を評価しますということなんですけど、 言い換えるとこれはシステムがどのようにうまく振る舞うかをテストするのが非機能テストなんですよね。 なのでまたログインの機能の例に戻ってくると、 例えばパフォーマンスとかですかね、どのようにうまく振る舞うかなので、 ログインボタンを押したときに、例えば10秒以上待つ必要があるという場合だったら、 もしグルグルグルってプログレスなんですかね、今読み込み中ですよみたいなのが出たりするじゃないですか、 もしああいうのが出なかったら、ユーザーとしてはどういう状態か分からなかったりしますよね。 今2つの話しちゃった。 ユーザビリティという観点も、使用性テストというのも非機能テストの1項だったりするんですけれど、 グルグルグルってのがもし出てなかったら、今ユーザーの体験としてはどういう状況なのか、 ログインボタンを押したんだけど、よく分からない10秒が経っちゃうわけですね。 それだと使用性の観点では良くないので、グルグルグルって入れましょうという話になるかもしれないし、 パフォーマンスのテストという意味だと、そもそもそんなにログインで10秒もかかって大丈夫なんだっけ、 妥当なんだっけというところが評価がパフォーマンステストに入ってくるのかなと思います。 ちょっと雑な説明になってしまいました。 補足としてISO、IEC25110の標準に書いてある非機能の品質特性にはいくつかありまして、 性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性というのがあります。 今ちょろっと話をしたのが性能効率性というところですね。 どのくらいのリソースを使っているのか、あとはスピードというのがすごく多くないかな、 レスポンスがどのくらいで返ってくるのかという性能効率性というものが非機能の品質特性として挙げられています。 ここまでが機能性、テストタイプの機能テストと非機能テストという話をして、 この2つがセットになっていて、残りの2つのブラックボックステストとホワイトボックステストというのがまた対になっているわけなんですけれども、 ブラックボックステストというのは何かというと、テスト対象の内部の構造というものを見ずに、 わからない状態で参照せずに、使用としてどうなるべきか、どういう振る舞いになるべきかというところを分析をして、 そこからテストを作っていくというのがブラックボックステストの特徴になります。 例えばブラックボックステストのテスト設計技法としていくつかあって、 例えば状態遷移テストというのがあるんですけれど、ログインの例でいうと、 ログイン前の状態、未ログインという状態と、ログイン中、ログイン済みという状態があって、 未ログインからログイン済みに状態が遷移するにはどういうオペレーションというか、アクションがあるかというのを考える。 そういうふうに分析をしながら、ログインをするテストも必要だし、逆にログイン済みから未ログインに戻る状態が変わるときには、 きっとログアウトというアクションが必要になってくるので、 そっちのテストも必要だよねみたいな感じで考えていくという、 仕様としてどういう振る舞いが行われるかというのを分析して、テストを設計する、作っていくというのがブラックボックステストになります。 もう一つがホワイトボックステストなんですけれど、 ホワイトボックステストのほうは、テスト対象の実装だったりとか、内部構造というものをそこから分析をして、 どういうテストが必要かというのを考えていく、設計して実行していくのがホワイトボックステストになります。 なのでよくカバレッジとかも呼ばれたりするんですけれど、 今回作ったクラス、ロジックというものを網羅させるためにはどういうテストが必要かなとか、 データのフローを考えてそこからこういうデータパターンが必要だよねというふうにテストを作っていくのがホワイトボックステストになります。 このブラックボックスとホワイトボックステストはどっちが良いとか悪いとかはなくて、 それぞれ強みと弱みがあるので両方必須なわけなんですけれど、 よくあるのが開発者がホワイトボックステストを行って、 QAチームだったりテストチームのほうでブラックボックステストをやるみたいなのはよくあるパターンかなというふうに思ったりします。 ということで今回はテストタイプについてお話をしました。 テストって機能テストだけじゃないんだよというところが少しでも伝わったら嬉しいです。 # #335のコメント返し🥰 コメント開始のコーナーです。今回は335話目。テストは縦、Q&Aは横のコメントを開始します。 コメントは3件頂いております。 ヨスさんと松さんと水源さんから頂いております。ありがとうございます。 まず1件目ヨスさんですね。初コメありがとうございます。 気になったので初めてコメントさせてください。 少し前まではインフルエンジンにしてました。最初縦横の意味が分かりませんでしたが、深さと幅と言われたらなんとなくイメージは分かりました。 私の中ではテストは想定外が何か見る。品質保証は一定の質を保つために標準化、見直すなど、持ち場立場でやれることをやる活動だと思います。 例えるなら橋を渡る前に叩くのがテスト。橋を安全感的に渡るために準備計画、フィードバックが品質保証活動だと思います。 ということで、ご丁寧にコメントありがとうございます。 今回はわざと分かりづらく縦と横という表現をしてみたんですよね。 あと橋の例えも非常に面白いですね。渡る前に叩くと、壊れるか壊れないかを確認するのがテストで、 橋を安全に快適に渡るという、安全だったり快適というところも含めて、いろいろ準備だったり計画だったり、 確認してフィードバックを得たりというところですかね。品質保証活動ということで、とても面白い観点だなというふうに思いました。 ありがとうございます。コメント2件目は松さんです。 QAとテスターという役割名とは合わないかもですが、品質保証が目的でテストは一手手段という解釈をしています。 イメージで言うと、便図の方眼関係が浮かんでいました。 だからか、小さな機能にとにかくテストを流そうと思考停止に陥っているのを見ると、もやもやします。 品質保証というより、説明的にも果たしやすい、エビデンス作りが強くなりがちなのかな。 それも大事ではあるんですけどね。ということで、ありがとうございます。 本質をついていると思います。 そうですね。品質保証を目的でテストは一手手段というか、便図の方眼関係というのはその通りです。 一般的にQA、いわゆる品質保証というところの中の一個の手段がテストなので、本当に書いてくださっている通りですね。 今回はちょっと何ですかね、斜めにというか、わざと一般的に言われているところからずらして、 自分が定義、自分の言葉で説明するならどういう表現になるかなという観点で今回の放送は作ってみました。 おっしゃる通りですよね、マイクロサービスだったりとか、どんどん小さく小さく、 小さい括りで、アジャイルという文脈もそうなのかな、小さい括りで、小さい機能でそれぞれの単位に対してテストを回していこう。 もちろんそれも大事。プラスアルファしてというか、全体感としてどうなんだっけみたいなところを、 もっと広い視野でまた見る、検証するというのも非常に大事になっていきますよね。ありがとうございます。 そして最後3件目はみずけんさんです。QAとテストだと、テストはQA活動の一つと考えています。 QAは品質保証ですから、品質を担保するためのあらゆる活動で、開発時の品質指標を定めたり、 指標通りの進捗になっているかを確認して是正したり、レビュー方針と実行だったり、さまざまな活動があるかと思います。 テストもその品質保証活動の一つという考えですね。ありがとうございます。 いい意味で教科書通りというか、一般的な定義かなと思います。 もしかしたらちょっと私自信ないまま言うんですけど、品質管理に近いかもしれないですね。 どういうことかというと、開発時の品質の指標を定めたり、指標通りの進捗になっているかを確認して是正したりという部分か、 品質管理、品質マネジメントという部分に近いかなというふうに感じたというお話でした。 ということで、よっさんさん、松さんみつけんさん、丁寧にコメントありがとうございました。 今回の一個放送の反省としてはですね、一般的なISTQBとかGSTQBだとこういうふうな定義だよねみたいな話も入れるべきだったかなというふうに反省しております。 コメントありがとうございました。以上コメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、誰のための技術発信なのかについてお話をしていきます。 あなたは技術発信をしてますか?誰のためにしていますか?というところですね。 私なりの考えをお話ししていきます。 今回の放送を聞いて、なるほどな、確かにな、学びになったな、 そして今日も聞きに来たような合図でぜひいいねを押していただけると、とっても励みになります。 最近いいねを押してくださった方のお名前を呼ばせていただきます。 よしおさん、あさみけいさん、げんまさん、小泉たけひとさん、川崎まなさん、積木のひろさん、 いいねありがとうございます。見てますよ。 それではまた明日。お会いしましょう。ごきげんよう。