QA、QCとテストエンジニアの違い

日本語訳が正しいかどうかは不安だが。

The difference between QA, QC, and Test Engineering by Google Testing Blog

We use the QC process to verify a product does what we think it does, and we use the QA process to give us confidence that the product will meet the needs of customers. To that end the QA process can be considered a meta process that includes aspects of the QC process.

我々は"QC"プロセスを「プロダクトが我々の想定した動作をするかどうかを検証する」こと、"QA"プロセスを「プロダクトが顧客の要求を満足できるかどうかの確証を得る」こと、というように使っている。その意味では"QA"プロセスは"QC"プロセスのメタプロセスと捉えることができる。

僕の会社では「テストエンジニア」はもとより「QC」といった言葉もあまり耳にしない。品質保証部門があるので、実質的には「QA」という言葉は暗に存在するのだが、上記のような定義づけはされていないと思う。なので、それら全部を「テスト」という１つの言葉で済ませちゃってる。ちなみにこのブログでは「QC＝Verification」「QA＝Validation」と位置づけている。

以前、品質の社内コンテストで受賞していたあるプロダクトがあった。品質保証部門のスコアは確かに高得点であったし、ドキュメントもきちんとされていたのだろう。でも、そのサービスはイマイチ使われていない。会社全体が「テスト」→「QA」＋「QC」と認識できるようになると、いいなあ。

属人化させないためのソフトウェアテスト技術

来週は社内のエンジニア向け勉強会開催。とりあえず30分くらいの時間でコツや技法を紹介してみようかと。

==

僕の上司はそんなことは思っていないが、どうやら一般的にはテスト技術者というのはあまり地位が確立されていないのが現状のようだ。個人的にはかなり高度な知識や能力をもったテスト技術者はそれなりの人財だと思うし、手放すべきではない。

日本におけるソフトウェアテストの位置づけ by ただいま修行中...

実は、テストというのは非常にセンスがいる作業である。

（中略）

これに関してはどうしても属人化してしまう。そこをいかに属人化しないで、ナレッジとして蓄積していくことが企業における財産になる。

単にテストケースを作成したり、テストを実施したりすることに技術はさほど必要はない。が、「効率的」とか「効果的」といった側面で考えると、それは専門的な知識も必要。無駄なテストケースを作らず、限られたコストでどれだけの不具合を検出でき、どれだけの範囲の品質を保証できるか、その品質レベルがプロジェクトの意義に適応したものかどうかの判断、そしてその評価結果をプロジェクトリーダや主要な利害関係者に納得させられるか。まさにプロジェクト管理にかかわる能力がフルに活用されるドメインじゃないか。

この著者のご指摘の通り、そのノウハウをどうやって社内へ（あるいは業界全体へ）ナレッジとして蓄積させるかも重要な任務なんだな、と改めて感じました。

直交表は「有効」であっても「万能」ではない(2)

最近は直交表というキーワードでこのブログにたどり着く方も多いかと思います。僕も同じく徘徊している一人ですから。

==

HAYST法／直交表に関する教育や実践での問題 by つれづれなる技術屋日記

HAYST法の推進者からは、更に数の多い因子への対応法の話が出る。つまり、そのままだとより大きなサイズの直交表を小さなサイズの表にする手法の話。頭では理解できるものの、上記の抵抗感と同様にふと疑問が湧いてしまう。抵抗感は何かと以前から考えていたが、”直交性”が保てるかとの疑問かもと思うようになった。
”直交性”は相関の逆数で、大きければ大きいほど直交表としてはいいと言える。ただし、具体的な算出方法が思いつかない。２つの因子で、各因子の水準が数値なら出来なくはない。が、因子が増えると計算が面倒。まして、水準が離散的とかOn/Offのようなケースをどう考えたらいいのか？？？

直交表を組み合わせで利用するときのメリットは2因子間、3因子間といった多因子間の組み合せ網羅率100%な組み合わせを効率的に作成できる、といったことだと思っています。なので、「直交表としてよい」という指標としては例えば「2因子間網羅率」だとか「3因子間網羅率」でいいのかな、と。もちろん、網羅率だけを品質の指標として使うのは危険であり、直交表やHAYST法が万能ではないというのはそのためである。

６）HAYST法を救世主・絶対視する人達の存在。 HAYST法の推進者がそうだとは思わないが、HAYST法や直交表でテスト件数が相当減るとか品質が上がると思っている人達がいる。従来のテストを行う事自体を否定する事すらある。

直交表やHAYST法という名前だけが一人歩きしてしまったり、「直交」といういかにも数学的な用語がついていることから、ブログの著者が指摘するような危惧はぬぐえない。僕の認識としては、勘や経験だけで考えるよりも効率的に、効果的にテストケースが作成できる、といったイメージは持っています。品質が上がるというのはどちらかというと間接的な効果くらいかな、と。

よし。これからも、ブログのタイトル通り、日々勉強と反芻を繰り返していくぞ。そして実務にも活かしたい！

プログラマーとテスターのコミュニケーションをベースにした品質向上について

各方面でソフトウェアテストについてのブログ記事が登場してて、それを読むだけでも勉強になりますね。

==

テスティング -テスティングの勘所- by 今日思うこと

ソフトウェアも人間がくみ上げるものであるから、バグの出方にも当然個性が出てくる。あるプログラマーは偉ー処理を軽視する。別なプログラマーはルーチン処理でよく無限ループにはまってしまう。などなど。

（中略）

話を戻そう。バグのくせを見つけるためには、まずプログラマーの性格を知ることが重要となる。そのために私はよくプログラマーに話を聞きにいった。仕様をどう理解しているのか、その理解をどういうアルゴリズムで実装しようとしているのか、自分でも自信がないところ、などなど。雑談を織り交ぜながら、しょっちゅう話を聞きにいった。

ソフトウェアテストの原則「欠陥の偏在」にも似たところがあるが、不具合は特定の箇所に集中しやすい。それは一般論として不具合を生みやすい要因があるのかもしれないが、実装を行ったプログラマーの癖や特性というのも大きく関わっていると思う。例えば、グローバル変数を使いやすい人もいれば、極力使わずに実装しようとする人もいる。構造体を多用したり、低水準のシステムコールを使用したり、様々である。

そういった癖や特性については主に静的レビューである程度把握することができると思うが、それはたいてい同じプロジェクトメンバーであり、開発する側の人間がレビュアーとなるのではないかと思う。マストさんの手法は、テスト担当者がその担い手となるというアプローチであり、より進んだ手法ではないかと思う。直接ヒアリングする、というところまではいかなくても、まずは癖や特性をデータベース化（見える化？）するなどのひと工夫によって、少しは効果が得られるのではないかな。

そうやって、担当プログラマの性格＝実装パターンが見えてくればしめたものである。某超有名アニメの腐海
に遊びにいく主人公が風が見えるように、目の前のソフトウェアにバグが見えるようになってくる。

この境地に達したテスト技術者はかなりすごいね。まさに救世主。青き衣のもの。

テストケースの「正常系/異常系」というカテゴライズについて

ソフトウェアテストには7つの原則(*)があって、そのひとつに「テストは欠陥があることしか示せない」という原則がある。これはどういうことかというと、テストというプロセスでは「不具合がない」ことは示せない、示せるのは「不具合がある」ことだけだ、ということを意味している。つまり、テストの目的＝不具合を見つけ出すことなので、より多くの不具合を見つけられるテストケースが優秀といえる。

テスト仕様書に「正常系/異常系」のカテゴライズは必要？ by クライングドーベルマン

第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させる危険があると思う。

（中略）

非常に極端な例ですが

5万ページを端から端まで印刷する正常系

パスワード欄に「' OR 1=1--」と入力する異常系

システム運用上、一般的に言って後者の優先度のほうが高いと思う。

極端な例ではあるが、まさにその通りだと思う。僕も一昔前は「正常系/異常系」というカテゴリーを使ってテストケースを分類していたし、今でももしかしたらそういったカテゴライズを念頭に考えているときも、あるかもしれない。もちろん、このカテゴリ分けが正しい場面もあるだろうが、テスト実施の優先度をきちんと分析する、という癖をつけないと、上で挙げられているような本末転倒的なテストをしてしまうかもしれません。

いうまでもないが「正常系には不具合がないからサボっちゃえ」という意味ではないです。5万ページの印刷は
極端な例ですが、10000件登録可能なアドレス帳についてはきちんと10000件登録でき、利用できることを試す
必要はあります。（CSV形式ファイルのインポート機能がついてたりするので）

このブログはあとでもっとみておこうっと。

(*) テスト技術者資格制度 シラバス（学習事項）

テスターの条件

先日みつけた今日思うことより。

テスティング -テスターの条件- by 今日思うこと

次に大切なこと、それは 『ものの見方が柔軟である』 こと。「マウスはマックのように１ボタンでなければならない」 といったように 「ＯＯＯ は ＸＸＸ でなければならない」 的な発想では質の高いテスティングは望めない。ユーザーは時に、開発者がまったく想定していない使い方をするものである。想定をしていない ＝ 作りこみをしていない ＝ テストもしていない ＝ バグが発生する、という構図になる。

会社に入った当初、僕のトレーナー役だった先輩からよく「テストをするときは天邪鬼になってやろう」とアドバイスしてくれたことを思い出す。普通に使っていては不具合は見つからず、単に消化したテスト項目数を増やすだけ。当時は感覚的にはわかった気がしたけれど、ソフトウェアテストの勉強をして、エラー推測・境界値分析というキーワードを目にするまで具体的に自分の手法としては確立していなかったと思う。

マストさんがおっしゃっているテスターに必要なこの能力は、エラー推測や境界値分析の観点に近い考え方かも、と僕は捉えています。何年もシステム開発に携わっている方からすれば、そんな手法勉強しなくても経験上やってたよ、という意見が出てくる気がする。でも、こうやって誰かの口から、どこかのサイトでひとつの手法として目にすることで、より一層自分の中の確固たる技術として根付くんじゃないかと僕は考えています。ソフトウェアテストについての勉強にはそういった意義があると信じています。

僕がもうひとつテスター（＝テスト技術者）に必要な能力を挙げるとしたら、それは妥当性検証力、かな。世の中にはいろいろな統計情報やメトリクスがあります。網羅率○○％、ステップ数あたりの不具合数、工数あたりのテストケース数、などなど。その中で、今自分が扱っているプロジェクトにはどの指標が適切なのかを見極める能力です。自分にその能力がなくても、誰と検証をすれば見極められるかがわかれば、それもＯＫ。そこらへんの能力は一言で「バランス感覚」という言葉にも帰着するのかも。

みなさんはどんな能力が必要だと思いますか？

直交表は「有効」であっても「万能」ではない

東京地方は大雨な一日になりそうです。

==

直交表という組み合せテストの手法を勉強していて、以下のようなブログ記事に遭遇。

直交表の功罪 by つれづれなる技術屋日記

その人は、ソフトウェアでの組み合わせテストを直交表で作る事になっているんだが、成果としてもう○ヶ月近くモノが出ない。たった一つの直交表すら出来てこない。そもそもどんな組み合わせテストをするかで、細かい部分とおおざっぱな部分とで粒度がいい加減。因子と水準はそれなりに抽出しているが、機能のための因子が相当足りない。

(中略)

直交表の功罪かもと思った１日。ソフトウェアテストでの直交表の利用自体は、喜ばしい事だが、人によってはそれによって万事解決と思う人もいるみたい。

ソフトウェアにおける統合テスト・機能テストは、さまざまな条件を変えてシステム動作が仕様どおりに動作するかを確認する必要がある。単純に「条件の個数×条件の振り幅」で組み合わせを考えると非現実的な組み合わせをテストケースとして考慮しなくてはならない。でも、一般的には1条件、2条件〜3条件の組み合わせが網羅されているだけで、ソフトウェア内の不具合のほとんどが検出できると言われている。（何条件まで検証が必要かはそのプロジェクトの特製、コストや要求される品質によって変わる）

ソフトウェアテストで直交表を利用するというのは、2条件、あるいは3条件の組み合せ表をなるべく少ないテストケースで網羅しよう、というアプローチのことで、このブログの著者がいっているように「万能」な道具というわけではない。適切な因子と水準の抽出ができなければ不具合の検出が少なくなるだろうし、直交表を適用できない場合もなくはない。

今作成しているツールでも直交表を利用した組み合せテストケースが登場するが、やはりツール利用者の経験量・知識量などが因子と水準の抽出に影響するので、アウトプットに品質のブレが発生する可能性がある。「テストケース作成における生産性」は向上しても品質が追いつかないとまずいな。この問題の解決手段としては、今のところ「サジェスト機能」くらいか。もう少し工夫が必要かも。

また、直交表の話になってしまったが、とりあえず今朝邂逅したブログ記事についてでした。

テスティングの役割、インスペクションの役割

インスペクションとは、「不具合を作らない手法」で、テストは「不具合は見つけ出す手法」だと僕は思って
いて、【松尾谷徹が語る】現場力を高めるテスト(1)でも同様の考え方が掲載されている。

テスティング -ソフトウェア・テスティングとは？- by 今日思うこと

私がソフトウェア製作を説明する上でよく使う例えが “三権分立” である。“仕様の策定（スペック）”＝立法、“仕様の実装（プログラミング）”＝行政、“仕様の検証（テスト）”＝司法となる。つまりテスティングとは、裁判所の仕事に当たる。

この三権分立の例えは、なるほど、と思った。仕様というテストにおける「法律」が存在し、裁判、すなわちテストはその「法律」を基準にして実施され、裁かれる。この例えを使えば、インスペクションというアプローチは法律を制定するところで実施される手法、ということになりそうだ。品質という数値化しづらいことを扱うのでテスト完了の見極めが難しいと言われるが、このブログでいう上流工程でのテスティング（≒インスペクション）の評価も意外に難しいんじゃないかな、と最近思ってます。

次回以降もこちらのブログは期待してます。

最近はこういったソフトウェア品質向上関連のブログがけっこう目立つようになってきて、勉強しやすくなってきたな。