JSTQBテストアナリストの勉強方法を書いてみる。
はじめに
２月に受験したJSTQB Adavanced Level テストアナリスト試験の結果発表があり、見事に合格することができました。
今回の記事は合格までの道筋・勉強方法を書いていければと思っています。
JTQB Adavanced Level TA(テストアナリスト)試験とは
世界で最も普及しているソフトウェアテストの認定機関であるISTQB資格を日本で受けられるというもの。
現在日本で受けられる資格としては、Foundation試験（FL）・テストマネージャ試験（TM）・テストアナリスト試験（TA）がある。
Advanced Levelの試験については応募資格のレギュレーションがある
- JSTQB認定テスト技術者資格 Foundation Level資格の合格者、JSTQB（日本）以外のFoundation Level資格の合格者
- 業務経験3年以上（業務経歴申請書の提出あり）
Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board
Advanced Level試験／資格試験－JSTQB認定テスト技術者資格／日科技連|ソフトウェア品質|SQiP研究会
STEP0. 前回の受験
実は2018年もTA試験を受験して落ちています。
- 動機：マネージャが受けるからとりあえず受けてみた（自腹だから落ちてもいいよねマインド）
- 勉強：忙しさにかまけて、さらっとシラバスを読んだだけ
- 試験当日： さーっと進めたら30分くらい余ったので先に帰った
この時点で受かる気がなさそうですが、当日の試験はテスト技法をあてこんだり、状況に応じて対応を判断するような実例問題が中心だったので「いつもの仕事の延長だ」とか「いろんなシステムを想定して問題が面白かった」とか「ワンチャン受かるのでは…」と試験を甘く見てましたが見事に落ちました。（マネージャは見事に合格しました）
という恥ずかしい失敗経験をかき消したいというモチベーションを元に今回の資格試験に臨んでます。
STEP1. 申し込み
まずはHPをよく読み、受付している期間に申し込みを行います。（仕事が忙しくなると、試験日は大体いつか覚えてられるが申し込みの締め切り日は忘れそうになるので注意。） 申し込み時にはFL認定証の写しやFLでの認定番号が必要になるので、あらかじめ準備しておく。（職場で申し込もうとすると大抵、手元にない） 初回受験時は業務経歴申請書を提出する必要がある（メールで案内が来る）ので、募集要項からダウンロードして作成します。
STEP2. テスト当日までの勉強パート
試験問題の結果は回収されてしまうのでどの問題が間違っててどの問題があってるのか分かりませんが、試験を受けてみての自分が正解・不正解してそうな部分が分かっていたので今回は自分の弱点になっていそうな部分（自信をもって正解といえる領域以外）について重点的に勉強することにしました。
カテゴリ分け・方針決定
ざっくりいうと、テストを受けた問題の傾向をカテゴリ分けし、それぞれの理解度を3段階でつけました。（下記参照） 普段の仕事ではストーリーチケットのテスト設計（限られた時間の中で網羅的な・かつステークホルダーの要求する品質を満たせるようなテストを設計）をしています。なので、テスト技法を当て込んでテストケースを作成する問題は得意ですが、業務で取り扱っていない知識体系の引き出しが少ないこと、テストマネージャとテストアナリストとしてスクラム開発では分けて考えていないため一緒に考えてしまって、それぞれが一般的なプロジェクト開発における棲み分け・役割分担といったところが曖昧になっていることという弱点が見えてきました。 試験に向けて、理解度が低いものから優先順位を高く定め、それぞれ学習時間の重みを変えて学習します。
正解してそうな領域(自信をもって正解といえる問題)
- 普段使っているテスト技法を当て込む問題
たぶんあってると思う領域（多分これが正解！って答えた問題）
- 普段あまり使わない技法、業務ではツールに任せてしまうテスト技法の問題
- テストアナリストとしての振る舞いをこたえる問題
おそらく間違っている領域（わからない・回答の一部がわからなかった問題）
- 知識問題
- 業務の知識とシラバスの知識とで差異・言い換えながら解釈した問題
シラバスを読み込む
勉強といっても問題集等々が無いので基本はシラバスを読みこむことを行いました（読み込むといっても2周ですが）。シラバスで分からない単語・略称などについてはGoogle検索して、関係する発表やブログなどを読んで、自分の言葉で理解できるまで資料を読み、理解した内容をテキストに書き起こし、あとで読み返せるようにして学習していきます。そのため、シラバスを読み込むと言っても寄り道がほとんどなのでかなり時間がかかります。
とはいえ、時間がかかっても日々の業務改善などに使えそうな知識・考え方が入ってくるので有意義な時間なのでおススメです。
テスト技法の勉強
過去問セミナーTA
テスト技法についてですが、「問題文を読んで実際に使えるレベル」が求められている気がします。
そのため、テスト技法については読み込みに加えて、別に時間を取りました。
対象のシステムに対して複数のテスト技法を組み合わせて考えられる必要があると、当日の試験で自信をもって回答ができると思います。
おススメはJSTQBの過去問セミナーの資料を熟読することです。実際に出た問題を解説していること、資料の少ないクラシフィケーションツリーについて書いてあります。
過去問セミナーTA
http://jstqb.jp/dl/AL_Exam_Seminar_TA.pdf
技法を手になじませる
基本的なテスト技法（境界値分析・ディシジョンテーブルや状態遷移図）については試験で多くの問題が出てくるのですが、今回はシラバスを読んで自分の知識と差異がないか確認する程度にしました。
今回は優先度を下げましたが仮に勉強をするとして、テスト技法は誰か分かっている人に教えてもらう・自分のやり方を見てもらって指導を受けるのが身につく近道だと思っています。
自分の経験では以前に有料の研修に行きましたが、そこでテスト技法の使い方を学んだ経験が日々の仕事でも活きている気がしています。
最近ではテストコミュティのワークショップもたくさんあるので、そういったところに足を運んで手を動かすのもいいかもしれません。
よさげだと思うセミナーを列挙
日本全国対応のソフトウェア品質教育支援 | VALTES
JSTQB認定 ソフトウェアテスト技術者 ― Foundation Levelトレーニングコース | セミナーサイト | 日本科学技術連盟
WACATE : 若手テストエンジニア向け勉強会・ワークショップ
STEP.3 テスト当日
TA試験は180分60問の長丁場です。しっかり準備して臨んで分かりましたが、時間が足りません。計算だったり・確認に時間がかかる問題だったり、結構大変です。
ペース配分を考えながら受験するのがおすすめです。自分の場合は今回も問題を解いたタイミングで回答の自信度をカテゴリ分けしながら進めて、最後に怪しいところ・間違えてそうなところを見直すようにしました。
朝はしっかり食べないと後半考えられなくなるので、早起きしてきちんと朝食をとるのは大事だと思います。
おわりに
第4回の受験者は前回から220人増えて500人程になったということでテスト系の資格・QAという仕事も一般的になって来たのかなぁという印象です。
今回は考えられる準備をちゃんとして臨んだので落ちたときは、「分からない場所が分かっていない＝何も分かってない」なので1から勉強し直しの必要があるという不安な日もありましたが無事に合格できてよかったです。
取得していない認定資格はテストマネージャもあるので、ゆくゆくは取得できたらなぁと思ってます。ほかにもスクラムで開発しているので、英語を勉強してアジャイルテスターの資格を取りたいなぁとか思っています。
状態遷移図・表の書き方＆考え方
はじめに
状態遷移図の話を書こうと思いながら前回のブログから１ヶ月経ってしまっているので徒然と書くことにする。
状態遷移図とは
本を読んだ内で一番分かりやすかったのはテスト会社がやっていた有償のセミナーでエッセンスを聞いたのが非常に分かりやすかったんだが色々問題が歩きがするので、今回もwikipedia先生に解説していただく。
Wikipediaを読んで分かったが自分が知っている状態遷移図というのはUML図におけるステートマシン図（state machine diagram、状態機械図）というものがルーツにあってそれを簡略化しているということが分かった。
今回はふんわり分かれば良いので簡略した書き事を書く。
書き方のルール
正しいお作法についてはwiki参照(UML)
今回はふんわり分かれば良いので下記のルールで書いた。（差分は赤文字）
- 塗りつぶされた円が START（開始）を意味する。必須ではない。
- 中抜きの円は STOP（停止）を意味する。必須ではない。
- 丸で状態を表す。
- 矢印が操作・振る舞いを表す。
実際に書いてみる
テーマ
腕時計のストップウォッチ機能
※便宜的に上のボタンをA、下のボタンをBとする。
振る舞い（仕様）
- 初期状態は針が0を指している状態
- 初期状態でAボタンを押すと針が動き出し、計測開始する
- 計測開始状態でAボタンを押すと針が止まり、一時停止する
- 一時停止状態でAボタンを押すと針が再度動き出し、計測開始する
- 一時停止状態でBボタンを押すと針が0を指し、初期状態へリセットされる
状態遷移図
振る舞いに書かれた情報を元に、状態遷移図を書くと下記のような図になるはず。
この時計にはAボタンには3つの機能があることがわかる。（計測開始、一時停止、計測再開）
状態遷移表とは
状態遷移図をもとに今度は操作の一覧を表に落とし込むのが状態遷移表である。 もしかしてこれもwikiありそう…と思ったらやっぱりあった。
すご～くざっくり書くと
書き方のルール
- 縦軸に現在の状態
- 横軸に操作
- 交わる場所に操作後の状態を書く
実際に書いてみる
STEP1:図から表に落とし込む
書き方のルールに基づいて図を表に落とし込むと下記の様になる。
| 状態/操作 | Aボタン | Bボタン |
|---|---|---|
| 初期状態 | 計測開始 | |
| 計測開始 | 一時停止 | |
| 一時停止 | 計測開始 | 初期状態 |
交わったセルが状態遷移テストにおける一つのテストケースになる。
表では空白が2つできているため、想定結果がわからない状態（もしくは仕様が決まっていない状態）なのできちんと仕様を確認することが重要。
ここらへんの考慮漏れとかを早い段階で指摘するのがテスト設計での腕の見せどころかもしれない。
STEP2:足りない部分を落とし込む
足りない部分を追記したバージョン
| 状態/操作 | Aボタン | Bボタン |
|---|---|---|
| 初期状態 | 計測開始 | 初期状態※１ |
| 計測開始 | 一時停止 | 計測開始※２ |
| 一時停止 | 計測開始 | 初期状態 |
※1: ボタンは押せるが、状態遷移しない
※2: ボタンがロックされるため、状態遷移しない
この状態で初めてすべての表が埋まりテス実施できるようになった。
今回は物理的な時計の話なのでどの状態でも常に2つのボタンを押すことができたが、そもそも操作ができない場合などは「N/A(not available)」と書いたりする。
まとめ
状態遷移図・表の書き方を書いてみた。
実際の業務では操作が複数の状態を起因にして違ったり、操作の数が多いとかあるので図や表が複雑になりがち。
本当はNスイッチの話もしたかったんだけどまた次の機会かなぁ。
おわり
c0,c1,c2カバレッジってなんだっけな話
はじめに
c0,c1カバレッジと状態遷移図のnスイッチの話が自分の中でごっちゃになってたので調べて自分の中で整理する話です。
※状態遷移図テストとnスイッチの話もしようと思ったが、長くなりそうなので今回はc0,c1カバレッジを
教えてwiki先生！！
Wikipediaがいろいろ書いててとてもわかり易かった。
なるほど、c0とかのカバレッジはホワイトボックスの手法なんだなと分かった。
- 命令網羅 (statement coverage) (C0)
- 分岐網羅 (branch coverage) (C1)
- 条件網羅 (condition coverage) (C2)
自分の中で理解する
というわけでサンプルプログラムを書いてみた。
雑に書いたサンプルプログラム （Javascriptで引数は数値なイメージです。）
【追記】 二個目の分岐の中でx,yを使用していたため、後述するテストケースでは網羅できなくなるため修正しました。
function outputTriangle(x, y, z){
// 最初の分岐
if(x>0 && y>0){
var area = x * y / 2;
console.log("底面積は" + area);
}else{
console.log("おやおやなにかおかしいぞ");
}
// 二個目の分岐
if(z>0){
console.log("体積は高さ" + z + "を掛けて３で割る！");
}
}
命令網羅 (statement coverage) (C0)
「命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい。」とのこと。(by wiki)
テストケースは下記になりそう。
x=2,y=3,z=4（面積、体積の表示）x=0,y=0,z=0（例外）
分岐網羅 (branch coverage) (C1)
「分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい。」とのこと。
なるほどわからんな状態なので改めて整理する
| 最初の分岐 | ２個めの分岐 | テストデータ例 |
|---|---|---|
| true | true | x=2,y=3,z=4 |
| true | false | x=2,y=3,z=0 |
| false | true | x=2,y=0,z=4 |
| false | false | x=2,y=0,z=0 |
こんな感じか。分岐を意識するんだな！
条件網羅 (condition coverage) (C2)
「条件網羅基準を用いてテストを行う場合は、各々の個別条件について、全ての可能な結果を少なくとも1回はとるように実行すればよい。」
ということで表に落としてみる。
| No | x>0 | y>0 | z>0 | テストデータ |
|---|---|---|---|---|
| 1 | true | true | true | x=2,y=3,z=4 |
| 2 | true | true | false | x=2,y=3,z=0 |
| 3 | true | false | true | x=2,y=0,z=4 |
| 4 | true | false | false | x=2,y=0,z=-1 |
| 5 | false | true | true | x=0,y=3,z=4 |
| 6 | false | true | false | x=-1,y=3,z=-4 |
| 7 | false | false | true | x=-2,y=-3,z=4 |
| 8 | false | false | false | x=-3,y=-2,z=-4 |
補足
なお、判定結果に影響を与えない真理値に関しては省略しても良い。と書いてあったのでこちらを考慮するとこんな感じでしょうか。
短絡評価
| No | x>0 | y>0 | z>0 | テストデータ | 結果1 | 結果2 |
|---|---|---|---|---|---|---|
| 1 | true | true | true | x=2,y=3,z=4 |
面積表示 | 高さを表示 |
| 2 | true | true | false | x=2,y=3,z=0 |
面積表示 | 表示されない |
| 3 | true | false | true | x=2,y=0,z=4 |
メッセージ | 高さを表示 |
| 4 | true | false | false | x=2,y=0,z=-1 |
メッセージ | 表示されない |
| 5 | false | true | true | x=0,y=3,z=4 |
メッセージ | 高さを表示 |
| 6 | false | true | false | x=-1,y=3,z=-4 |
メッセージ | 表示されない |
| 7 | false | false | true | x=-2,y=-3,z=4 |
メッセージ | 高さを表示 |
| 8 | false | false | false | x=-3,y=-2,z=-4 |
メッセージ | 表示されない |
x>0が満たされない時点でyの値は判定結果に影響を与えないので省略できる。 なので5,7と6,8は同じテストケースと判断する事ができそうなので省略する。
短絡評価後
| No | x>0 | y>0 | z>0 | テストデータ | 結果1 | 結果2 |
|---|---|---|---|---|---|---|
| 1 | true | true | true | x=2,y=3,z=4 |
面積表示 | 高さを表示 |
| 2 | true | true | false | x=2,y=3,z=0 |
面積表示 | 表示されない |
| 3 | true | false | true | x=2,y=0,z=4 |
メッセージ | 高さを表示 |
| 4 | true | false | false | x=2,y=0,z=-1 |
メッセージ | 表示されない |
| 5 | false | (true) | true | x=0,y=3,z=4 |
メッセージ | 高さを表示 |
| 8 | false | (false) | false | x=-3,y=-2,z=-4 |
メッセージ | 表示されない |
5,6でもいいはずなんだけど個人的にこっちの方がいい気がするので5,8とした。
もっと言うと、3,4と5,8は結果が同じなので更に削ることが可能だよね！（今回はここまで）
こんな感じか。分岐の条件を意識するんだな！
その他のカバレッジ
その他にはこんなのものある様子。
- 判定条件／条件網羅 (decision/condition coverage)
- 複合条件網羅 (multiple condition coverage)
- 経路網羅 (path coverage)
また静的解析でのカバレッジについては若干ニュアンスが違うので注意されたし。
感想
プログラム的には体積の表示は最初のエラーが出た時点で計算ができないから表示させたくなかったのだけれど、意図的に変な書き方になっています。
テストデータに文字列とかを入れると結果がエラー内容が変わって来ちゃったりするのですがいろいろややこしくなるので今回は簡素にこんな形にしました。
理解はしていたつもりだったけど実際に書いて確かめるって大事だと改めて思いました。
Javascriptの単体テストを書く（power-assert）
はじめに
単体テストについてはE2Eを組む前段で用意してたことはあるのだけれど、真面目に書くことがなかったのでpower-assertを使ってテストコードを書くことに挑戦してみる。
参考
みんなのPowerAssert github.com
インストール
$ npm install mocha espower-loader intelli-espower-loader power-assert --save-dev
ディレクトリ構成
.
├── node_modules
├── package.json
├── src
│ └── Calculator.js
└── test
└── test.js
対象&テストコード
Calculator.js
module.exports = class Calculator {
constructor(name){
this.name = name;
}
plus(x, y){
return x + y;
}
minus(x, y){
return x - y;
}
divide(x, y){
return x / y;
}
};
test.js
const Calculator = require('../src/Calculator');
const calculator = new Calculator('riririusei99');
const assert = require('power-assert');
describe('Test plus', function(){
it('shoud return 3 when value is number', function(){
assert(calculator.plus(1,2) === 3);
});
it('【ERROR SAMPLE】shoud return "12"', function(){
assert(calculator.plus("1","2") === 12);
});
});
describe('Test minus', function(){
it('shoud return 3 when value is number', function(){
assert(calculator.minus(5,2) === 3);
});
it('shoud return -2 when value is number', function(){
assert(calculator.minus(3,5) === -2);
});
});
describe('Test devide', function(){
it('shuoud return 1 when value is number', function(){
assert(calculator.divide(5,5) === 1);
});
it('shuoud return error when 0 divide', function(){
assert(calculator.divide(5,0) === Infinity);
});
});
テスト実行
power-assertのREADMEを参考に実行する
$ node_modules/mocha/bin/mocha --require intelli-espower-loader test/test.js
こんな感じで出力される
おわりに
環境の準備は割とさっくりできた。
テストの書き方とかが大事なんだろうなぁというかんじなので、次回はもう少し複雑なコードに対してテストを書いてみるみたいなのをやってみたい。
CTFで作ったお遊びスクリプトとかがちょうど良さそう。
今回できたもの
Jenkins pipelineを触ってみた
はじめに
最近の仕事でJenkinsのデプロイジョブとE2Eのジョブの２つを作ったので、ここらへんでpipelineを使って２つのジョブをつなげて一目で確認できるようにとpipelineについていろいろ調査して挑戦しました。
ざっくりと書いたもの
実際はブランチの他にも組織名とかいろいろパラメータがあるのだけれど簡素に書くとこんな感じ。
ここまで実装するためにいろいろ調べて時間がかかった…もう見つけられないかもしれないと思うと怖くなったので、自分のブログに残しておく。
PipelineScrip
node {
// ステージを設定する
stage ('build') {
build job: 'build', parameters: [
// ジョブに渡すパラメータを設定する
[$class: 'StringParameterValue', name: 'BRANCH', value: 'ブランチ名']
]
}
stage ('test-setting') {
build job: 'E2E-A'
}
}
おわりに
Jenkins側のジョブを分けつつ、自動テストの粒度も小さくすることで「前のバージョンでデータを作って、最新バージョンにデプロイし直してテストする」みたいなこともできると思うといろいろ便利だと思いました。
バージョンアップテストとかってどうするのかって思っていたけれども自動化のアプローチとしてpipelineを活用するってのもありかもしれないと思いました。
参考
下記参考にしたもの
jenkinsのpipeline入門(jenkinsfile) - SIerだけど技術やりたいブログ
readコマンドを使ってスクリプトを書いてみる
はじめに
普段使ってるシェルスクリプトはユーザー＆パスワードはほぼほぼ固定なんだけど、たまに任意の入力を受け付けて実行したい時がある時の話。
調べたところreadコマンドを使うのがよさそうというのと…
shellを書く時にはたいてい記憶が空になっているので、自分のための備忘録。
read コマンドを使ってスクリプトを書いてみる
readInput.sh
#!/bin/sh
echo "ユーザー名を入力してね"
read inputUser
echo "PASSWORDを入力してね"
# -sでpass入力
read -s inputPass
echo "$inputUser にデプロイするよ? y/n"
read input
if [ $input == "yes" ] ||[ $input == "y" ]
then
echo "$inputUser で処理するよ"
# 処理を書く
else
echo "終了するよ"
exit
fi
おわりに
作り終わったタイミングで、実務ではJenkinsのパラメータ付きビルドで同じ事を出来ることに気づいてしまった…。
何事も経験ですよね！ということでお茶を濁すことにします。。。。
おわり
最近見た映画
１ヶ月ぶりに記事を書くのですが…ネタが思いつかず…。
趣味の話をします😋
週末にレイトショーを見るのが最近のマイブームで、色々考えたり、テンション上げたりしてます。
ということで最近見た映画の紹介(3月、4月)
グレイテストショーマン
ヒュー・ジャックマン演じるジャン・バル…じゃなくてP.T.バーナムの半生を描いた映画。
ミュージカル映画なので音楽が良い、すごく良い。
見た翌週はSpotifyでサントラ聞いて仕事してました。
本当に大切なものはなんだっけと問いかけてくれる楽しめる映画です。
レッドスパロー
ロシアの才能あるバレリーナだったドミニカは怪我をきっかけに怪しい叔父さんの仕事をきっかけにスパイになる映画。
スパイとして望まないながらも成長していく姿はなんだか、考えさせられるよね。
騙し合いの騙し合いで、最後までどうなるか分からない映画でした。
ヴァレリアン
気分が凹んでいたので観たらスッキリするだろうとポスターで選んだSF映画。
思った通り、シンプルなストーリーで楽しく見れました。構成がぶつ切り感があったのでいくらでも続編作れそう。
パシフィック・リム アップライジング
前作をみてテンション上がったので観た。ロボットアクション、燃えるよねみたいな方は是非。吹き替えがオススメです。
…という感じで月2本位のペースで映画館に通うのも結構面白かったので、オススメの映画あったら教えて欲しいなぁ。
おわり
