2016-02-26

FLの次は、TMとTAのどちらを目指すべきか。

JSTQB

JSTQB FLに合格された方が、次のステップとしてTM（テストマネージャ）やTA（テストアナリスト）を目指す場合、どのように学習すればよいか悩まれることが多いようだ。TMやTAに関する市販本は国内にはないし、講習やセミナーといったものもまだ無い。シラバスを読む以外にどんな学習方法があるのか、よく問い合わせがある。その回答をまとめておきたい。

【1】FLの次は、TMとTAのどちらを目指すべきか

TMとTAの受験資格は経験が3年以上だ。それをクリアできているという前提とする。TM試験は、トライアルが2010/08から始まり第5回が2015/08に行われた。次回は第6回が2016/08に行われるだろう。TA試験は、2016/02に第1回が始まったばかりだ。JSTQBは、当面、TMとTAを半期ごとに繰り返すのではないかと推測する。次回TAは、早くて2017/02だ。ただ、試験問題を評価し、次回の試験問題を作成するのは大変な労力なので、1年以上間隔が開く場合もあるだろう。

FL--> TA--> TMの順に受けることを勧めたいが、タイミングよく試験が実施されるとは限らない。直近で実施されるTAまたはTMに照準を合わせるしかない。FLに合格した半年後の試験を狙うべきである。どちらも3か月間学習すれば、十分に間に合う。これからFLを受けられる方は、FL--> TA--> TMの順で目指してほしい。FLに合格して、半年後にTMに合格した人は結構多いことが分かっている。おそらくモチベーションが持続できるからだろう。半年以上の期間を空けると効率がよくない。

【2】半年後にTMを受ける場合

TMに関する国内の市販本はないし、FLと違って講習やセミナーも見当たらない。テスティング中級コース（マネージャ編）のみと言っても過言ではない。TMのシラバスの50％はプロジェクトマネジメントの知識と言えるので。PMBOKなどの入門書は参考になるかもしれない。

TM試験は、シラバスベースの知識問題が60％、与えられたシナリオでTMとして判断する問題が40％といった配分である。シラバスベースの問題は配点が少ないので、実質でシラバスベース50％、シナリオベース50％と考えるべきである。シナリオベースの問題は、自身の開発やテストの経験や一般論から容易に解答できるものが多い。一方、シラバスベースの問題は、シラバスを読み込んでいないと4つの選択肢を絞り込みできない。シラバスの読み込みは必須である。シラバスを十分に読み込んでおけば、シナリオベースの問題でも出題者の意向が察知できるようになる。

※以前に書いた「JSTQB Advanced第1回試験を分析してみた」も参照ください。

【2-1】シラバスで学習する場合のおすすめ

JSTQBのシラバスは、誤訳も多いのでそれを前提とする必要がある。シラバスが間違っているだけでなく、間違った知識のまま出題される可能性もある。ISTQBの原本と突き合わせて学習すべきだ。公開されたレビューメモなども参照してほしい。

私は、自身専用のシラバス解説書を作成することを推奨している。私自身も実践している。単にシラバスを読むだけでなく、シラバスに気づきを書き込んでいくのだ。誤訳の箇所を指摘して訂正したり、理解できていなかった部分に自分なりの解説を加えたり、出題されそうな部分に想定問題を作ってみたりする。ダウンロードしたPDFのシラバスからテキストを抽出（AcrobatReaderに機能あり）して、WORDのシラバスを作成するのだ。手作業も多いが紹介しておく。

(1) プレーンテキストの段階で、不要なヘッダーやフッターを削除する。削除しきれない場合は、目立つ文字列に置換して手作業で削除する。

(2) 改訂履歴、前書き、目次、参照書籍、索引は思い切って削除する。そして、この段階でWORDに貼り付ける。

(3) 見出しを整える。やっとPDFのシラバスがWORDとして体裁が整った状態となる。

(4) 箇条書きに変更できる部分を書き換える。シラバスはだらだらと文章が長い。要素が並列されている部分は、箇条書きに変更しておく。非常に読みやすくなる。英語の「x1,x2,x3 and x4」などの文章はJSTQBが係り受けを間違って訳している箇所が多い。それを箇条書きにすることは学習の第1段階と言える。JSTQBの訳がおかしい／理解しにくいと感じたら、かならずISTQBの原本に当たってみるようにしたい。

(5) 学習目標を、各節・各項に移動する。シラバスのK2,K3,K4の学習目標は非常に重要だ。それに基づいて出題される。K2,K3,K4の学習目標を各節・各項に配分しておき、各節・各項を読むときに学習目標を意識しながら読める構成に変更しておくのだ。

(6) レビューメモなどを参照して誤った箇所を修正しておく。ISTQBの原本と突き合わせる作業をゼロからやると、おそらく1か月を無駄にする。先人の情報を活用してほしい。

(7) 適宜、コメントを追記する。ここからが学習の第2段階である。コメントは、字下げしてフォントの色を変えるなどで工夫し、オリジナルのテキストをできるだけ壊さないようにする。

【2-2】サンプル問題や市販本について

JSTQBが公開しているサンプル問題は数問しかない。ISTQBが公開しているサンプル問題は40問ある。さらに海外のいくつかのサイトでは模擬問題も公開している。それらで学習するとよい。

出題者は、これらのサンプル問題を参照していることは間違いない。同じ問題は絶対に出ないが、類似した問題として出題されたものは確認できている。

※有力な市販本としては、「Advanced Software Testing - Vol. 2, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Test Manager」がある。

【2-3】TMシラバス以外のソースの利用について

JSTQB（TM）のシラバスを読み込むことは必須だが、それ以外の関連するシラバスや用語集の用い方について問い合わせがあったので追記しておく。

(1) JSTQB（FL）のシラバス：あるタイミングで復習する際に再度、眺めればよい。また、TMシラバスの内容がFLでどう書いてあったかを確認する程度で十分である。

(2) JSTQB（Advanced level 概要）：特に読む必要はない。「Advanced Levelテストマネージャ試験は、180分で65問。合格ラインは65％。単純計算では、合格には42問以上の正答が必要。65問で115点満点。配点は1問ごとに１点-3点の範囲で重みづけされている。K2問題は1問1点、K3問題は1点-3点、K4問題は2点-3点となる」ということを把握しておくだけでよい。

(3) JSTQBの用語集：特に印刷して読んだりする必要はない。不明な用語に出くわしたら、http://squaring.jp/term/ で参照ください。中級コース（マネージャ編）では必要な用語は都度取り上げている。

(4) JSTQB（TA）のシラバスやISTQB（TTA）のシラバス：TMの受験者は、あえて読む必要はない。読まなくてもTMのシラバスで完結している。TAの受験者はTMのシラバスを読んでおくと効果的だが、逆は必要ではない。

(5) 標準や技法の詳細情報：TMのシラバスで大体の概要が把握できたら、次の段階として、個々の標準や技法をもう少し深堀りして学習しておく必要がある。例えば、以下のような項目については、ネット情報などで調べて理解を深めておくこと。TMの第1回試験では、見積り計算、FMEA、TPIについて、シラバス以上に踏み込んだ内容で出題されていた。
・IEEE 829-1998　ソフトウェアテストドキュメント
・IEEE 829-2008　ソフトウェアテストドキュメント
・IEEE 1028 レビュー
・IEEE 1044 不正
・TPI Next
・STEP
・CTP
・CMMI/TMMi
・故障モード影響解析（FMEA）
・コスト便益分析（cost benefit analysis）
・3点見積り

(6) プロジェクトマネジメントの入門書：品質コストやリスクマネジメントは必須です。この辺りの知識はPMP、PMBOKの知識であり、プロジェクトマネジメントの領域になる。PMPやPMBOKの入門書など読んだことがないなら、読んでおくと理解が早い。

【3】次回TAを目指す場合

TAもTMと状況はほぼ同じで、シラバスに沿った国内の市販本はないし、講習やセミナーも見当たらない。テスティング中級コース（アナリシス編）のみと言ってよい。

TA試験は、シラバスベースの知識問題が30％、技法の適用問題（シナリオベースの問題）が70％といった配分である。シラバスベースの問題は配点が少ないので、実質でシラバスベース20％、技法80％と考えるべきである。シラバスを読まなくても技法だけ深く理解できていれば大丈夫と言える。シラバスベースの問題は、シラバスを読み込んでいないと4つの選択肢を絞り込みできないので、20％といえども捨てる訳にはいかない。シラバスでの学習では、前述のように自前のシラバス解説書を作成するとよいだろう。

TAは、TMに比べて、学習しやすい。教材や勉強会などもあり、ネット情報も豊富だ。技法の実践は、シラバスを読んだだけでは「0点」だと考えてよい。市販本やネット情報で、各技法の適用方法を理解する必要がある。技法についての市販本は、探せばいろいろあるようだが、シラバスで取り上げられる技法を1冊で網羅するようなものはまだない。また、社内や社外でのテスティングの勉強会は結構行われているようだ。それに参加するのも良いだろう。最近では、WACATE（ソフトウェアテストワークショップ）というグループでの勉強会が目立つ。ネットで検索しても彼らのPPTがやたらとヒットする。「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」というドリル本を推奨していることが分かった。

JSTQBが公開しているサンプル問題は、TAもTMと同様で、数問しかない。ISTQBが公開しているサンプル問題は40問あり、さらに海外のいくつかのサイトでは模擬問題も公開している。また有力な市販本としては、「Advanced Software Testing - Vol. 1, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Test Analyst」がある。

※以前に書いた「第1回のテストアナリスト試験を受けてきた」も参照ください。

テスティング中級コース（アナリシス編）は、シラバスの網羅性、サンプル問題の網羅性は高いので安心できる。第1回のTA試験で判断するかぎり、ほぼ十分な網羅性だった。

2016-02-18

テストアナリスト試験の難問に挑んでみた。

JSTQB

テストアナリスト試験で正解が分からなかった問題を考えてみた。試験問題をうろ覚えなので前提を間違っているかもしれないがあえて取り上げてみる。記述はシンプルだが、机上では解けなかった問題だった。

机上で解けない問題

『4つの因子（A,B,C,D）がそれぞれ4つの値をもつ。たとえば、Aの因子は、a1,a2,a3,a4の値をもつ。ペアワイズテストのテストケースを作成したい。「因子Bがb1またはb2のとき、因子Aはa1またはa2しか選択できない」という条件がある場合、最小のテストケース数は 10,12,16,20 のどれか。』といった内容の問題だ。

正解が16なのか、20なのか判断できない。ISTQBでは、3因子でそれぞれ4値の問題は出題されるが、JSTQBでは4因子でそれぞれ4値だ。2ワイズでは、因子が4個で値がそれぞれ4個であれば、最小でも4*4=16である。これは、3因子4値でも、2因子4値でも16である。3因子4値や2因子4値なら、すぐにテストケースの組み合わせは並べられる。しかし、4因子4値になると、最小でいくつになるかを机上で導くのはかなりむずかしい。ちなみにPICTツールを使って求めると、19個のテストケースが求められた。これが最適解であるかどうかは確信できない。1つのサンプルとして捉える程度のものだ。もっと最適な16個に近い解があるように思える。

※16個の最適解が求まるツールがあるという情報をいただきました。PictMasterだそうです。後述で追記しておきます。また、PictMasterを使えば、この出題の正解は20個であることが分かるとのことです。問題の作者は、PictMasterを使ったのですね。机上で解くには無理があります。
※私もPictMasterを試してみました。PictMasterは、内部的にはPICTまたはCIT-BACHのアルゴリズムを使っていて、どちらかを選択するようです。PICTだと19個の解、CIT-BACHだと16個の最適解が得られるようです。

「因子Bがb1またはb2のとき、因子Aはa1またはa2しか選択できない」という条件があったとしても、残りの3個の因子(B,C,D)には影響がないので、16個より少なくはならない。
※情報を提供いただいた方から、条件が加わると一般にテストケース数は増えるとの指摘もいただきました。

PICTを使うと19個

PICTのようなツールを使えば具体的な19個を導けるが、机上で求めるのは難解だ。私は机上で解けなかった。16個以上という推測は容易にできるが、16か20かの判断はできない。そもそも、4因子4値の問題は出題してはいけなかったのではないか。数分から数10分で解が導けるためには、せいぜい3因子4値でなければならない。ISTQBの問題をかなり探してみたが、3因子4値はいくつか出題例があるが、4因子4値は1つもない。ISTQBのサンプル問題では、たとえば CTAL-ATA _LO-3.2.6 が3因子4値の問題である。答えは、16とすぐに求まる。

4因子4値の出題は、直交表の出題と同じく、JSTQBの行き過ぎた出題だったのではないかと考える。

ちなみにPICTで求めた組み合わせは以下のようになった。

A B C D

- - - - -

a1 b1 c1 d1
a1 b2 c4 d4
a1 b3 c3 d2
a1 b4 c2 d3

a2 b1 c2 d4
a2 b2 c3 d1
a2 b3 c4 d3
a2 b4 c1 d2
a2 b4 c4 d1

a3 b1 c1 d1
a3 b2 c2 d2
a3 b3 c4 d3
a3 b4 c3 d4

a4 b1 c3 d3
a4 b1 c4 d2
a4 b2 c1 d3
a4 b3 c1 d4
a4 b3 c2 d1
a4 b4 c3 d1

「因子Bがb1またはb2のとき、因子Aはa1またはa2しか選択できない」という条件とすると、最大3個のテストケースが割愛できることが分かっている。19-3=16である。紛らわしいがPICTのサンプル結果のa1,a2,b1,b2とは異なるので注意のこと。「因子Bがb3,b4のときa1,a2しか選択できない」と置き換えると2個が重複として割愛できる。上記のサンプルでは2個に留まるが、組み合わせが最適であれば最大3個のテストケースが割愛できそうである。

だが、この問題が試験時間の数分や数10分で解けるだろうか。きっと無理である。4因子4値の問題は出題してはいけなかったと考える。四択の問題なので、16個より多いという推測ができれば、正解の選定にたどり着くことは可能だが、そういう趣旨の問題でもない。

PictMasterを使うと最適解16個

PictMasterを使うと、16個の最適解が求まるという情報をいただきました。さらに、PictMasterで与えられた条件を設定すれば、正解の20個が導出できるとのことです。問題の作者は、PictMasterを使ったのですね。条件の与え方も違和感のある表現だと思った。作者は、机上で解いたことがあるのだろうか。机上で解くことには無理があり、適切な問題とは言えない。
16個の最適解は、以下だそうです。「因子Bがb1またはb2のとき、因子Aはa1またはa2しか選択できない」の条件を設定すると20個だそうです。机上で解ける人もあるかもしれないが、私を含めてほとんどの人には解けない。

A B C D

- - - - -

1 a1 b1 c2 d4
2 a1 b2 c3 d2
3 a1 b3 c4 d1
4 a1 b4 c1 d3
5 a2 b1 c1 d2
6 a2 b2 c4 d4
7 a2 b3 c3 d3
8 a2 b4 c2 d1
9 a3 b1 c4 d3
10 a3 b2 c1 d1
11 a3 b3 c2 d2
12 a3 b4 c3 d4
13 a4 b1 c3 d1
14 a4 b2 c2 d3
15 a4 b3 c1 d4
16 a4 b4 c4 d2

2016-02-13

第1回のテストアナリスト試験を受けてきた。

JSTQB

第1回のテストアナリスト試験を受けてきた。東京会場のTOC 有明には280くらいの席があったようだ。5%くらいは空席だったろうか。

試験問題は3時間で60問。うち、シラバスからの知識ベースのもの16問、シナリオベースのもの44問だった。うまくミックスされていて、ボリュームも適切な感じだった。見直しする時間もあった。問題には素直なもの、ちょっと捻りのあるもの、サンプル問題の派生のもの、オリジナルのものもあり、総じて良くできた問題だったと思った。過去のFLやTMの試験に比べて、初回であるにも関わらず、かなり洗練された感じだ。

作者は、カメラが趣味で、ワイン好き。自動販売機をよく使っている。しかもおつりの出ない自販機だ。肥り気味なのだろう。BMIにこだわる。アジャイルだが、ユースケース記述や直交表も使いこなせるらしい。組み合わせテストに異常なまでに興味があるようだ。そんな設定だ。

合格率の予測

合格率は30%と予測する。自分の体感と周囲の情報からの判断だ。

シラバスを読んだだけでは合格できない。各技法で何個のテストケースが必要となるかが確実にカウントできないといけない。ということが体感として分かった。市販本がないとすると、セミナーや勉強会に参加して、ひととおりの技法を正確に学習しておく必要がある。私も、直交表でそこまで踏み込んだ問題が出されるとは予測できなかった。簡単化デシジョンテーブルの定義を誤解していることに気づいた。単純な同値分割や組み合わせではなく、条件付きの同値分割や組み合わせが多い。それでも、場合の数が少ない問題が多いので、指折りしてカウントしても対応できる。

スクエアリングサービスもまだまだ十分でないことに気づかされた。期待して学習していただいたのに、不合格者が出るかもしれない。

しっくりこない問題

いくつか疑問のある問題もあった。問題として適切なのか、正解できたのかどうかわからないものもあった。うろ覚えだし、見落としたのかもしれないので確信をもって言えないが、挙げておく。

(1) 問題2では、リスクレベルを発生確率と影響度からどう判定するかの定義が提示されていないので、リスクレベルを判断することはできない。どのテストから取り掛かるべきかの判断が私にはできなかった。リスクレベルの決定は、組織やプロジェクトで決めることである。その前提が漏れている。
※発生確率×影響度で計算させたかったのかな。すると、4×4のものを選択すればよかったかな。でも、それは問題として適切でない。リスクレベル＝発生確率×影響度と定義しておかないとダメだ。シラバスには、掛け合わせる場合も提示されているが、それが絶対ではない。

(2) 直交表の問題はやり過ぎだと判断する。シラバスには直交表はキーワードとしてしか登場しない。ペアワイズテストとクラシフィケーションツリーはK3レベルだが、直交表はK3ではない。
※25行、6列、5水準を選んだ。自信なし。

(3) マンションと一戸建ての融資額(?)をクラシフィケーションツリーでテストする問題で、1つだけテストケースを追加するものの正解が分からなかった。問題を持ち帰れないので確認できないが、本当に根拠のある選択肢が挙げられていたのか。1ワイズならどれでも正解だし、2ワイズだと1つのテストケースでは網羅できない。
※マンションが選択肢にあるのを選んだ。根拠も自信もなし。
※ある受験者の方から情報をいただきました。2ワイズに注目して、既存の3つのテストケースとどの因子のペアも重複していないものを選択するとのことでした。1ワイズでもなく、2ワイズで網羅することでもなく、既存の3つのテストケースと重複しないペアとなるものを選択すればよかったらしい。4つの選択肢を順に、既存の3つのテストケースで選択されたペアと一致するペアのあるものを消去していけば、１つのテストケースが残るとのこと。

(4) 境界値分析が2値とも3値とも指示されていない問題があった。少ない方ということで暗黙で2値を使わせるのか。
※少し思い出した。2値だと4個で3値だと6個だが、4個の選択肢がなかったので6個を選んだ。

2015-12-16

テスティングの用語集に120項目を追加しました。

SQUARING

テスティング中級コース（アナリシス編）に対応して、テスティングの用語集に120項目を追加しました。JSTQB用語集(Version 2.3)およびISTQB用語集(Version 3.01)を網羅し、学習に必要な独自の見出し語も追加しています。
用語集は、以下から利用できます。
http://squaring.jp/term/search.do?cid=03
テスティング中級コース（アナリシス編）については、以下を参照ください。現在、330問を提供しています。来春2016/02に始まるテストアナリスト試験の、おそらく唯一の対策コースです。
http://squaring.jp/EC14-TA/



actor (アクター)

actual outcome (実際の結果)

analytical test strategy  (分析的テスト戦略)

analytical testing (分析的テスト)

anti-pattern (アンチパターン)

api testing (API テスト)

atomic condition (不可分条件／アトミック条件)

attack-based testing (攻撃ベーステスト)

automation code defect density (自動化コード欠陥密度)

business process (ビジネスプロセス)

business process modeling notation (ビジネスプロセスモデリング表記法（BPMN）)

business process modering (ビジネスプロセスモデリング)

capture/playback (キャプチャ／プレイバック)

cli testing (CLI テスト)

code review (コードレビュー)

combinatorial testing (組み合わせテスト)

compound condition (複合条件)

condition decision coverage (条件デシジョンカバレッジ)

confidence interval (信頼期間)

consultative test strategy (コンサルテーションベーステスト戦略)

consultative testing (コンサルテーションベーステスト)

control chart (管理図)

control flow testing (制御フローテスト)

convergence metric (収束メトリック)

data quality (データ品質)

defect analysis (欠陥分析)

defect category (欠陥カテゴリ)

defect lifecycle (欠陥ライフサイクル)

defect management committee (欠陥マネジメント委員会)

defect triage committee (欠陥トリアージ委員会)

defect type (欠陥タイプ)

domain analysis (ドメイン分析)

effectiveness (利用時の有効性)

efficiency (効率性)

efficiency (利用時の効率性)

embedded iterative development model (埋め込み型イテレーティブ開発モデル)

equivalent manual test effort (emte)  (等価な手動テスト工数（EMTE）)

escaped defect (見逃された欠陥)

failover testing (フェイルオーバーテスト)

fault injection (フォールトインジェクション)

feature-driven development (フィーチャ駆動開発)

generic test automation architecture (共通テスト自動化アーキテクチャ)

gui testing (GUI テスト)

level interim test status report (レベルテストステータスレポート)

level of intrusion  (試験性対応レベル)

level test report (レベルテストレポート)

linear scripting (線形スクリプト記述)

man in the middle attack (中間者攻撃)

master test report (マスターテストレポート)

mbt model (MBT モデル)

methodical test strategy (方法的テスト戦略)

methodical testing (方法的テスト)

model coverage (モデルカバレッジ)

model-based test strategy (モデルベーステスト戦略)

model-based testing (モデルベーステスト（MBT）)

modified condition decision coverage (改良版の条件デシジョンカバレッジ（MC／DC）)

myers-briggs type indicator (マイヤーズ-ブリックスタイプ指標（MBTI）)

neighborhood integration testing (近隣統合テスト)

n-wise testing (N ワイズテスト)

off-by-one error (オフバイワンエラー)

offline mbt (オフライン MBT)

online mbt (オンライン MBT)

open source tool (オープンソースツール)

operational profiling (運用プロファイリング)

pairwise integration testing (ペアワイズ統合テスト)

plan risk (計画リスク)

planning poker (プランニングポーカー)

predicate (述語／プレディケート)

pre-meeting preparation (事前ミーティング準備)

prisma (PRISMA)

process-compliant test strategy (プロセス準拠テスト戦略)

process-compliant testing (プロセス準拠テスト)

process-driven scripting  (プロセス駆動スクリプト記述)

product risk management (プロダクトリスク管理)

quality control (品質コントロール)

quality function deployment (品質機能展開（QFD）)

quality in use (利用時品質)

quality risk (品質リスク)

questionnaire (質問表)

raci matrix (RACI マトリクス)

reactive test strategy (対処的テスト戦略)

reactive testing (対処的テスト)

regression-averse test strategy (回帰回避テスト戦略)

regression-averse testing (回帰回避テスト)

resumption requirements (再開要件)

review plan (レビュー計画)

review process (レビュープロセス)

risk assessment (リスクアセスメント)

risk coverage (リスクカバレッジ)

risk impact (リスク影響度)

risk item (リスクアイテム)

risk likelihood (リスク発生確率)

satisfaction (利用時の満足性)

semantics testing (セマンティクステスト／意味テスト)

shewhart chart (シューハート管理図)

short-circuiting (短絡評価)

smart goal methodology (SMARTゴール方法論)

software integrity level (ソフトウェア完全性レベル)

standard-compliant test strategy (標準準拠テスト戦略)

standard-compliant testing (標準準拠テスト)

stand-up meeting (スタンドアップミーティング)

system under test (テスト対象システム（SUT）)

test adaptation layer (テスト適合レイヤ)

test analysis (テスト分析)

test architect (テストアーキテクト)

test automation engineer (テスト自動化エンジニア)

test automation manager (テスト自動化マネージャ)

test automation solution (テスト自動化ソリューション)

test automation strategy (テスト自動化戦略)

test case explosion (テストケースの爆発的増加)

test case result (テストケース結果)

test data management (テストデータマネジメント)

test definition layer (テスト定義レイヤ)

test director (テストディレクタ)

test driven development (テスト駆動開発（TDD）)

test execution layer (テスト実行レイヤ)

test generation layer (テスト生成レイヤ)

test mission (テストミッション)

test model (テストモデル)

test process improvement (テストプロセス改善)

test reporting (テストレポート作業)

test selection criteria (テスト選択基準)

tpi next (TPI Next)

traceability matrix (トレーサビリティマトリクス)

usability guideline (使用性ガイドライン)

usability heuristic evaluation (使用性ヒューリスティック評価法)

user experience (ユーザーエクスペリエンス)

user story testing (ユーザーストーリーテスト)

website analysis and measurement inventory (WEBサイト解析と測定一覧表（WAMMI）)

2015-12-02

テストアナリスト試験に向けたコースを作成した。

JSTQB SQUARING

JSTQBは、来春2016/02に第1回のテストアナリスト試験（Advanced Level テストアナリスト試験）を実施する。スクエアリングサービス事務局では、この試験に対応した「テスティング中級コース（アナリシス編）」を提供している。現在、290問の模擬問題を用意している。コースは5,400円(税込)で2年間有効である。おそらく、現時点で唯一の試験対策コースである。
【追記 2015/12/16】現在、310問に増強しています。用語集も合わせて改訂しています。
【追記 2015/12/25】現在、330問に増強しています。
【追記 2016/01/30】現在、370問に増強しています。

試験対策では、まずシラバスの読み込むことが必要であり、また技法の実践が必要である。テストアナリスト試験は、180分で60問である。120満点で78点(65％)が合格ラインとされている。半分の30問は技法の実践から出題され、30問はシラバスから出題されると理解するとよい。

テストアナリストのシラバスを読む

シラバスを読むのは苦痛である。それは、シラバスの日本語訳の品質が悪いからである。実際に技法やツールを利用したことのない人が訳しているのだろうか、誤訳も多いし、係り受けを間違っていたりする。ISTQBの原本と突き合わせながら学習したい。テストアナリスト編のシラバス（バージョン2012.J01）を独自にレビューし、間違っている箇所を指摘している。http://squaring.jp/EC14-TA/20151202-TA-syllabus-review.htm を参照いただきたい。致命的な間違いもいくつかある。学習者や読者には、シラバスを読む際の参考資料として（ほとんど正誤表の位置づけとして）、利用いただけたらと思う。また、JSTQBで翻訳を手がけられている方々には、参考にしていただいて、早期にシラバスの修正・改訂を行っていただけることを期待したい。

テストアナリストというと上流のロールのように聞こえるが、実態は単なる中堅（経験3年以上）のテスターである。テストの分析・設計・実装・実行まで行う。テストの計画作業や終了作業ではテストマネージャ(TM)の支援も行う。もともとテストアナリストはドメインテストアナリストとテクニカルテストアナリストに分けられていたが、ドメインテストアナリストをテストアナリストと呼ぶようになった経緯がある。テストアナリスト(TA)とテクニカルテストアナリスト(TTA)で分担してテストの分析・設計・実装・実行を行うのである。TAが対象ドメインの知識を活かし、TTAは技術的な知識を活かすと言える。TAが顧客要件（利害関係者要件）を扱い、TTAは成果物要件（ソリューション要件）を扱うと言えるかもしれない。どちらかというと、TAは機能テストや仕様ベースのテストに偏り、TTAは非機能テストや構造べ―スのテストに偏る。ただし、ユーザビリティ（使用性）はTAが担当し、セキュリティはTTAが担当する配分となっている。

TAのシラバスは、ISO 9126(後継のISO 25000を含む):品質特性、IEEE 829-1998とIEEE 829-2008：テストドキュメント、IEEE 1044：欠陥ライフサイクルと欠陥分類などの標準がベースとなっている。

テスティング中級コース（アナリシス編）では、シラバス（バージョン2012.J01）を完全解説している。JSTQBの誤訳も加味しながら解説している。また模擬問題はシラバスの記述を網羅し、公開されたサンプル問題40問を網羅し、RexBlackの解説を網羅して構成している。参照される標準も学習者がネット上で探らなくてもいいように必要な情報を網羅している。

技法やツールを実践する

チェックリストを用いたレビュー、同値分割と境界値分析(ドメイン分析)、デシジョンテーブル、状態遷移テスト、組み合わせテスト(ペアワイズテスト)、ユースケーステスト、探索的テストについては実践が必要である。正確には、実践に適用できる知識とスキルがあればよい。試験問題では、1つのテーマについて2〜3問の小問があり、配点も異なる。おそらく1つのテーマが2ページ以上になるような大作も出題されるだろう。

テスティング中級コース（アナリシス編）では大作の模擬問題は提供できないが、抑えておかなければならないポイントを繰り返して学習できるように工夫している。

2015-09-08

VirtualBoxでHostOSとGuestOSで相互にMySQLに接続してみる。

CentOS MySQL

VirtualBox上で、GuestOS(CentOS)からHostOS(Windows)のMySQLに接続してみる。また逆にHostOS(Windows)からGuestOS(CentOS)のMySQLに接続してみたい。ネットワークは、デフォルトでNAT（Network Address Translation）になっていて、IPアドレスやポート番号の置換を行ってくれる。この設定によりGuestOSからただちにインターネットも利用できるが、この設定だけではHostOSからGuestOSへのアクセスができないようだ。NATでは、ゲートウェイ(HostOS側)が 10.0.2.2 で、DNSが 10.0.2.3、GuestOS側のアドレスが 10.0.2.15 になっている。このアドレスは固定らしい。(※変更できるのかもしれないが、触れないことにする)
WindowsからCentOSに接続するには、新たにVirtualBox Host-Only Networkを設定する必要がある。手順をメモしておく。

(1) アダプタにVirtualBox Host-Only Networkを追加する。

VirtualBoxマネージャでCentOSを選択し、設定-->ネットワークを開く。
アダプタ2タブを選択し、「ネットワークアダプターを有効化」をチェックし、「ホストオンリーアダプタ」を選択する。
VirtualBoxマネージャで、ファイル-->環境設定-->ネットワーク-->ホストオンリーネットワークタブを開く。
ホストオンリーネットワークの編集ボタンを押し、IPアドレスが確認できる。192.168.56.1 になっている。　
CentOSを起動し、root権限でログインする。
/etc/sysconfig/network-scripts/を覗いてみる。デフォルトで「ifcfg-enp0s3」というのがある。「enp0s3」はCentOS7.0から登場したものらしい。以前の「eth0」に相当するものらしい。以下のように修正しておく。



# cd /etc/sysconfig/network-scripts

# vi ifcfg-enp0s3

・・・

BOOTPROTO=static

IPV6INIT=no

ONBOOT=yes

・・・

そして配下に、ifcfg-eth1 を新規に作成する。ネット情報を参考に以下のようにした。「eth1」ではなく「enp0s8」とするのがCentOS7.0らしいのかもしれない。とりあえず「eth1」としておいた



# cd /etc/sysconfig/network-scripts

# vi ifcfg-eth1

DEVICE=eth1

TYPE=Ethernet

ONBOOT=yes

BOOTPROTO=static

HWADDR=08:00:27:21:F5:FD

NAME="Adapter2 eth1"

IPADDR=192.168.56.101

NETMASK=255.255.255.0

NETWORK=192.168.56.0
# systemctl restart network

# systemctl status network

IPADDRの101は適当に。1より大きければよさそう。
HWADDRは、VirtualBoxマネージャの「設定-->ネットワーク-->アダプタ2-->Macアドレス」で事前に確認しておく。私の環境では、08002721F5FDとなっていた。HWADDRは、08:00:27:21:F5:FDのように指定する。
Windowsでifconfigしてみる。

・・・
イーサネットアダプター VirtualBox Host-Only Network:
接続固有の DNS サフィックス . . . . .:
リンクローカル IPv6 アドレス. . . . .: fe80::dcb4:ab27:522c:9b3b%12
IPv4 アドレス . . . . . . . . . . . .: 192.168.56.1
サブネットマスク . . . . . . . . . .: 255.255.255.0
デフォルトゲートウェイ . . . . . . .:

Windows(HostOS)側からSSH接続を確認してみた。私はTeraTermをインストールしているのでそれを使った。192.168.56.101 にSSH接続して、CentOSにログインできた。

(2) ファイアウォールにMySQL用ポート=3306を設定する。

CentOSで、アプリケーション-->諸ツール-->ファイアウォールを開き、ゾーンタブをクリックして、publicゾーンのmysqlにチェックを入れる。
サービスタブでクリックして、mysqlを選択し、ポート=3306、プロトコル=tcpが設定されていることを確認する。

ここでちょっと確認しておこう。Adapter1:NATとAdapter2:VirtualBox Host-Only Networkの設定により、IPアドレスは以下のようになった。MySQLでは、これらのIPアドレスをホストとして指定して、ポート=3306でHostOSとGuestOS間でアクセスを可能にしたいのだ。



Adapter1:NAT

    Windows(HostOS) = 10.0.2.2          <-- CentOSからアクセスする際に指定する

    CentOS(GuestOS) = 10.0.2.15         <-- 明示的には利用しない

Adapter2:VirtualBox Host-Only Network

    Windows(HostOS) = 192.168.56.1      <-- CentOSからアクセスする際に指定する

    CentOS(GuestOS) = 192.168.56.101    <-- Windowsからアクセスする際に指定する

(3) WindowsのMySQLにCentOSからアクセスする。

Windows(HostOS)のMySQLには、CentOS(GuestOS)からは、NATを使って 10.0.2.2 でアクセスできる。またVirtualBox Host-Only Networkを使って 192.168.56.1 でもアクセスできる。Windows(HostOS)のMySQLに「dummy」というDBを作っているとしよう。リモートであるCentOS(GuestOS)からrootおよびdummyというユーザーで権限を設定してみよう。まずWindows側でmysqlコンソールを使う。パスワードは任意に。



# mysql -uroot -p mysql

mysql> grant all privileges              on dummy.* to  root@'10.0.2.2' identified by 'xxx' with grant option;

mysql> grant DELETE,INSERT,SELECT,UPDATE on dummy.* to dummy@'10.0.2.2' identified by 'xxx' with grant option;

mysql> grant all privileges              on dummy.* to  root@'192.168.56.1' identified by 'xxx' with grant option;

mysql> grant DELETE,INSERT,SELECT,UPDATE on dummy.* to dummy@'192.168.56.1' identified by 'xxx' with grant option;

mysql> flush privileges;

mysql> select host,user,password from user;

リモートのユーザーが登録できた。すべてのテーブルに対して、*.* を指定したり、すべてのリモートとして root@'%'や dummy@'%'のように指定してもいいはずだ。ただ私は理解を容易にするために、明示的にDBやホストを指定するようにしておく。では、CentOS(GuestOS)から接続を試みよう。



# mysql -h10.0.2.2 -uroot -p dummy

mysql> show tables;

mysql> exit;
# mysql -h192.168.56.1 -uroot -p dummy

mysql> show tables;

mysql> exit;

どちらもうまくいく。NATでもVirtualBox Host-Only NetworkでもWindows(HostOS)のMySQLにアクセスできた。

(4) CentOSのMySQLにWindowsからアクセスする。

今度は、CentOS(GuestOS)のMySQLに「dummy」というDBを作っておく。Windows(HostOS)からアクセスできるようにrootおよびdummyというユーザーで権限を設定してみる。先ほどの逆方向だ。まずCentOS側でmysqlコンソールを使う。Windows(HostOS)からはVirtualBox Host-Only Networkを使って 192.168.56.101 でアクセスできるはずだ。NATでは接続できないので、10.0.2.15 は使えない。



# mysql -uroot -p mysql

mysql> grant all privileges              on dummy.* to  root@'192.168.56.1' identified by 'xxx' with grant option;

mysql> grant DELETE,INSERT,SELECT,UPDATE on dummy.* to dummy@'192.168.56.1' identified by 'xxx' with grant option;

mysql> flush privileges;

mysql> select host,user,password from user;

リモートのユーザーが登録できた。CentOSのIPは 192.168.56.101 だが、HostOS=192.168.56.1 からのアクセスを許可する。では、Windows(HostOS)から接続を試みよう。GuestOS=192.168.56.101 に HostOS=192.168.56.1 から接続する。



# mysql -h192.168.56.101 -uroot -p dummy

mysql> show tables;

mysql> exit;

うまくいった。VirtualBox Host-Only NetworkでWindowsからCentOSのMySQLにアクセスできた。

2015-09-04

CentOS 7.0 では systemctl を使う。

CentOS

CentOS 7.0からサービスの管理が面倒になった。systemctl というコマンドを使う。従来のようにchkconfigで管理されるサービスと新しい systemd で管理されるサービスに分かれるようだ。

(1) chkconfig で確認してみる。

chkconfigコマンドでサービスの有効/無効を設定しようと実行してみても以下のものしか出ない。ほとんどのものがsystemdの管理下に移動させられたようだ。



# chkconfig --list

mysqld     0:off 1:off 2:on 3:on 4:on 5:on 6:off

netconsole 0:off 1:off 2:off 3:off 4:off 5:off 6:off

network    0:off 1:off 2:on 3:on 4:on 5:on 6:off

丁寧に「注記: この出力は SysV サービスのみであり、ネイティブな systemd のサービスは含まれていません。SysV 設定のデータはネイティブな systemd の設定によって上書きされます。systemd サービスを一覧表示するには 'systemctl list-unit-files' を使用してください。特定のターゲットにおいて有効化されているサービスを確認するには 'systemctl list-dependencies [target]' を使用してください。」とのメッセージが出る。従来のものがSysVサービスということか。

(2) systemctl list-unit-files で確認してみる。

systemctl list-unit-files を実行してみると300以上のサービスが一覧された。httpd,sshd,tomcat,NetworkManagerなどのサービスが含まてていた。



# systemctl list-unit-files

UNIT FILE                                   STATE   

abrt-ccpp.service                           enabled 

abrt-oops.service                           enabled 

abrt-vmcore.service                         enabled 

abrt-xorg.service                           enabled 

・・・(※300個以上のサービスが並ぶ)

httpd,tomcatなどのサービスは、これまで馴れ親しんできたコマンド(service xxx start や chkconfig xxx on)では開始・停止、自動起動の設定などができなくなったということか。mysqld のみ従来どおりに、service mysqld restartなどで利用することになるのか。この辺りを確認しておきたい。SysVサービスは、/etc/rc.d/init.d 配下にスクリプトを置くが、systemdサービスは、/lib/systemd/system 配下に置かれる。

(3) /etc/rc.dと/lib/systemd/systemを確認してみる。

# cd /etc/rc.d
# ls
init.d rc.local rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d
# ls rc0.d
K36mysqld K50netconsole K90network
# ls init.d
README mysqld network vboxadd-service
functions netconsole vboxadd vboxadd-x11

# cd /lib/systemd/system
# ls
・・・
httpd.service
tomcat.service
tomcat@.service
・・・

mysqldは /etc/rc.d にある。httpd、tomcat は /lib/systemd/system 配下にある。tomcat@ は何だろう。

(4) サービスのステータスを確認してみる。

systemctl statusコマンドを試してみる。httpd、tomcatのサービスはどうなっているのか。

# systemctl status httpd
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: active (running) since 2015-09-03 13:57:22 JST; 49min ago
Main PID: 4407 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
CGroup: /system.slice/httpd.service
├─4407 /usr/sbin/httpd -DFOREGROUND
├─4408 /usr/sbin/httpd -DFOREGROUND
├─4409 /usr/sbin/httpd -DFOREGROUND
├─4410 /usr/sbin/httpd -DFOREGROUND
├─4411 /usr/sbin/httpd -DFOREGROUND
└─4412 /usr/sbin/httpd -DFOREGROUND

9月 03 13:57:22 systemd[1]: Starting The Apache HTTP Server...
9月 03 13:57:22 httpd[4407]: AH00558: httpd: Could not reliably determine...ge
9月 03 13:57:22 systemd[1]: Started The Apache HTTP Server.

# systemctl status tomcat
tomcat.service - Apache Tomcat Web Application Container
Loaded: loaded (/usr/lib/systemd/system/tomcat.service; disabled)
Active: active (running) since 2015-09-03 13:58:03 JST; 48min ago
Process: 4485 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=0/SUCCESS)
Main PID: 4517 (java)
CGroup: /system.slice/tomcat.service
└─4517 java -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-...

9月 03 13:58:04 server[4517]: 9 03, 2015 1:58:04 午後 org.apache.catali...al
9月 03 13:58:04 server[4517]: 情報: サービス Catalina を起動します
9月 03 13:58:04 server[4517]: 9 03, 2015 1:58:04 午後 org.apache.catali...al
9月 03 13:58:04 server[4517]: 情報: Starting Servlet Engine: Apache Tom...54
9月 03 13:58:04 server[4517]: 9 03, 2015 1:58:04 午後 org.apache.coyote...rt

# systemctl status tomcat@
Failed to issue method call: Unit name tomcat@.service is not valid.

httpd、tomcatは、VirtualBoxからCentOSを起動した時点でサービスが開始されている。このコマンドは、ログの一部も表示してくれる。tomcat@ は何なんだろう。

(5) サービスの起動・停止・再起動を確認してみる。

サービスを再起動してみる。mysqldとhttpdで試してみた。

# service mysqld restart
Restarting mysqld (via systemctl): [ OK ]
# service httpd restart
Redirecting to /bin/systemctl restart httpd.service

# systemctl start mysqld
# systemctl start httpd
# systemctl start httpd.service
# systemctl restart mysqld
# systemctl restart httpd
# systemctl restart httpd.service

service httpd restart でhttpdを再起動してくれているようだ。リダイレクトしたと出ている。ただ、systemctlはレスポンスの文字列が全くないので、成功したのか失敗したのか全然分からないな。都度、statusを確認してみる必要がありそう。



# service httpd restart

Redirecting to /bin/systemctl restart  httpd.service

# systemctl status httpd

httpd.service - The Apache HTTP Server

   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)

   Active: active (running) since 2015-09-03 15:03:40 JST; 13ms ago

  Process: 6919 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=0/SUCCESS)

 Main PID: 6923 (httpd)

   Status: "Processing requests..."

   CGroup: /system.slice/httpd.service

           ├─6923 /usr/sbin/httpd -DFOREGROUND

           ├─6925 /usr/sbin/httpd -DFOREGROUND

           ├─6926 /usr/sbin/httpd -DFOREGROUND

           ├─6927 /usr/sbin/httpd -DFOREGROUND

           ├─6928 /usr/sbin/httpd -DFOREGROUND

           └─6929 /usr/sbin/httpd -DFOREGROUND

・・・

# systemctl restart mysqld

# systemctl status mysqld

mysqld.service - SYSV: MySQL database server.

   Loaded: loaded (/etc/rc.d/init.d/mysqld)

   Active: active (running) since 2015-09-03 15:03:44 JST; 1s ago

  Process: 6942 ExecStop=/etc/rc.d/init.d/mysqld stop (code=exited, status=0/SUCCESS)

  Process: 6973 ExecStart=/etc/rc.d/init.d/mysqld start (code=exited, status=0/SUCCESS)

 Main PID: 7228 (mysqld)

   CGroup: /system.slice/mysqld.service

           ├─7000 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mys...

           └─7228 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/...

・・・

SysVのサービス(mysqldなど)も、systemdのサービス(httpd,tomcatなど)も同じように扱えることが分かった。ただし、実行後のステータスは都度確認した方がよさそうだ。これからは、systemctlのコマンドに馴染むようにしよう。

どちらも service xxx restart で再起動できる。
どちらも systemctl restart xxx で再起動できる。
どちらも systemctl status xxx でステータスを確認できる。

ちなみに、サービスの自動起動の設定は以下のようにenable/disableで行う。httpdの場合、サービス名は、"httpd"でも"httpd.service"でもいいようだ。



# systemctl enable httpd

# systemctl disable httpd