2018-08-27

c0,c1,c2カバレッジってなんだっけな話

はじめに

c0,c1カバレッジと状態遷移図のnスイッチの話が自分の中でごっちゃになってたので調べて自分の中で整理する話です。
※状態遷移図テストとnスイッチの話もしようと思ったが、長くなりそうなので今回はc0,c1カバレッジを

教えてwiki先生！！

Wikipediaがいろいろ書いててとてもわかり易かった。

ソフトウェアテスト - 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)

また静的解析でのカバレッジについては若干ニュアンスが違うので注意されたし。

コード網羅率 - Wikipedia

感想

プログラム的には体積の表示は最初のエラーが出た時点で計算ができないから表示させたくなかったのだけれど、意図的に変な書き方になっています。
テストデータに文字列とかを入れると結果がエラー内容が変わって来ちゃったりするのですがいろいろややこしくなるので今回は簡素にこんな形にしました。理解はしていたつもりだったけど実際に書いて確かめるって大事だと改めて思いました。

2018-06-08

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

こんな感じで出力される f:id:riririusei99:20180608202737p:plain

おわりに

環境の準備は割とさっくりできた。
テストの書き方とかが大事なんだろうなぁというかんじなので、次回はもう少し複雑なコードに対してテストを書いてみるみたいなのをやってみたい。
CTFで作ったお遊びスクリプトとかがちょうど良さそう。

今回できたもの

github.com

2018-06-05

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だけど技術やりたいブログ

Jenkins2のPipline参考リンク集

【Jenkins】パイプラインからジョブを呼び出す際、パラメータを指定する - 自分の速さで

ParameterValue (Jenkins core 2.125 API)

2018-05-15

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のパラメータ付きビルドで同じ事を出来ることに気づいてしまった…。
何事も経験ですよね！ということでお茶を濁すことにします。。。。

おわり

2018-05-02

転職を決意した話

はじめに

2017年の9月に転職して半年が経ち、そろそろ振り返っておく意味でブログを書こうと思います。今回の話は転職を決意するまでの2016年の夏から2017年の冬の半年くらいの内容になります。

自分の話（当時）

パートナーのQA(Quality Assurance)として1年半くらいスクラムチームに在籍
自社では初めてのQAなのでキャリアパスとかフォロー体制とかはない
スクラムチームを横断したQAチームのリーダー
業務内容は自動テストのメンテやテストプロセスの改善
手動テストは作り直しによる速度改善とかパフォーマンスアップのテストがメイン（軽めの案件は別のQAが担当で、計画会でやばい案件は自分みたいな感じ）

ちなみに、前回ブログで書いたチームを離れる時の話が今回のスタート地点です。
riririusei99.hatenadiary.jp

当時のスクラムチームの話

（自分から見れば）チームは成熟していて、離れる人は新しいチームを作る時のコアメンバーとしてチームを離れ、入る人は経験を積ませるために参画する…みたいな結構影響がありそうな体制変更もなんだかんだ受け入れられるチームでした。メンバー変更のインパクトを残ったメンバーが覚醒することでチーム力を維持する…みたいなチームになっていました。（当時のスクラムマスターの心境をお察しします…。）
自動テストの師匠が抜ける時は本当に大変でしたが、裏側まで見られるようになったので結果的に自分の成長になったのでいい経験でした。

前職(SIer)のアジャイルQA事情

運用をメインでやっていたSEがQAとして開発チームに参画するといった展開は上層部に偉く魅力的に映ったらしく、「QAを増やすにはどうすればいいのか」みたいなことを毎週毎週、根掘り葉掘り聞かれ、新しい案件の引き合いがあれば候補の中には大抵自分の名前が上がっているような状態でした。
なのでJSTQBの資格取得を目指すとか、オススメ書籍の購入をお願いしたりとか、自動テストのリポジトリ・開発規約を作って業務を受けられるようにするとかQAをキャリアパスに乗せる環境づくりについていろいろ提案・実施しました。
QAメンバー自体は引き合いがあるので多い時は５人まで増えましたが、どれも中途半端な状態で止まってしまっていた印象です。

白羽の矢が立ったその裏で…

そんなこんなで、同じ現場で肝入りのプロジェクトがテストフェーズに入る前にQAとしてテスト全般の舵取りをお願いしたいということで最初のスクラムチームを離れることになります。リリース後には保守案件のスクラムチームが発足するのでそこのQAプロセスもお願いするかもみたいなオプション付きでした。
ここでは結合テストから受け入れテストを一手に引き受けるテストマネージャみたいな仕事をしつつテストを実施したり、強化テスト用のスポットで発足したテストチームのマネジメントしたり、品質評価のインシデント分析したり貴重な経験ができました。なんだかんだお客さんに気に入られ、大変そうなリーダーのサポートもお願いされるなどそれなりには貢献できたのかなと思います。

…その裏で、「QAを増やすにはどうすればいいのか」といったアプローチを着々と決めている様子で、どうも今のプロジェクトが終わった際にはスクラムチームには合流しないで別の現場でQAとして働きQAチームを作るみたいな流れになっていました。

転職を決意する

育ててくれたチームに恩を返したい。

慣れない新しい仕事ができるようになるのは、自身の頑張りももちろんですがその時一緒に働いた人のフォローがあってやり遂げられたと思っていて、できるようになった領域の仕事はその場所に還元したいと思っていました。
還元できると思う頃には次の現場が決まってしまうので、今の働き方では大切にしたかったことは実践できないなと思いました。
新しいスクラムチームのテストプロセスを考えながらも、未来のチームに自分はいないのが分かっていうのも思い返してもつらい仕事だなと思いました。

現場の人間を大切にして欲しい。

もう一点はネガティブな話になるのですが、改善してほしいと意味を込めてきちんと書いておこうと思います。これまで「QAを増やすにはどうすればいいのか」と言われ続けていましたが、本当に言いたかったことはきっとこんな感じだったのかなと思います。
「（お金をかけず、余った人材で、かつ短い期間で）QA（の契約）を増やすにはどうすればいいのか」だったのかなと。そこにいる人にはあまり関心がなかったのかなと思っています。自分自身も同じ環境で育っているのであまり強くは言えないですが、契約を優先して交代だったり増員のメンバーがQAの仕事に対して興味や関心がない人、極端にスキルが劣る人を補充するのは本当にやめてほしいと思っています。育ててくれたチームに対して後任のメンバーがトラブルを起こし、リーダーとして以前所属したチームにトラブルを解決しに行く時は恩を仇で返しているような気持ちになりました。

…と言う状況で、別の現場に移動して同じことを繰り返すというのは個人的にも耐えられないなと思い転職を決意するのでした…。

まとめ

つらつらと書いてみたものの転職を決意しただけでこんなに長くなるとは思わなかったですが、こんな感じで転職を決意しました。
ここら辺の考えがベースになっているので転職エントリーでは活動の内容にクローズアップしてかければと思います。

2018-02-21

QAエンジニアとしてのスタート地点を振り返ってみる

はじめに

なんだかんだスクラムチームでのQAエンジニアとしてのキャリアが4年目になったので今回のエントリーを書きました。
そういえばブログを書いているけど、自己紹介すらままならないのでこの辺で自分語りの記事も入れておくって側面もありつつ、これからQAになる人に向けて、話すことを今のうちから貯めておこうっていう企画です。

QAエンジニアになったきっかけ

2014年の末、それ以前は常駐してBPOサービスを提供するSEとして運用業務・受け入れテストなどを2年半ほど業務に従事していました。
そんなところにスクラム開発でQAを探しているというお誘いがありました。
プロダクトオーナーがテスト＆受け入れを行って、多忙ゆえに十分なテストが行うことができないことに課題感を持っていたっていうのが始まりです。

・・・

~~若くて勢いがあったのと、~~テスト＆運用業務を通してドメイン知識のあるということで自分に白羽の矢が立ちQAとしてのキャリアが始まりました。
今思うとマネジメントな人が多い会社だったのもあり、運用プロジェクトのリーダーになるかなぁとか漠然と思っていたけど、テストで生きていくようになるなんて思ってもいなかったなぁという感じです。

最初のミッション

当時の自分に課せられたミッションをまとめると下記だったような気がします（チャレンジも含む）

受け入れテストの実施
テストプロセスの改善
品質の向上
テスト自動化

一番最初のMTGで「アジャイルテストの４象限」と「テスト自動化のピラミッド」の図を見せてもらったことについては今でも覚えています。
これから先、アジャイルQAを育成する機会があれば、まずこれを見せてあげようかなぁとか思います。

役割分担

f:id:riririusei99:20180221020826p:plain

これは実践アジャイルテストの図に方針を書き足したもの。
まずは最初に「受け入れテストの実施」など手動の領域を担当するのが最初のミッション。
将来は手動と自動の左上の領域もQAに任せていきたいという内容だった（と思う）。

それぞれの４象限について誰がメインで担当していくかを明示してくれたのでわかりやすかったと思う。
改めて思い返すと成長した時に期待する姿もしっかり言及しているし、心の中にこの図はいつもあります。

自動化戦略

f:id:riririusei99:20180221015949p:plain

こちらは自動化戦略の説明のために。チームの自動化戦略として山の登り方はこうやって進めるという内容でした。
最小構成で作ったピラミッドを順々に大きくしていく…という文脈でGUIテストの自動化から最初に着手する必要があり、自動テストのシナリオを作ってくれってのもQAになりたての頃にやりました。
~~…そして当時作ったケースがその時入ってきた新人君にボロクソに言われるのだった。~~

当時のチーム構成

プロダクトオーナー
スクラムマスター
エンジニア(7人)
QA(１人)

当時のチーム構成はこんな感じ。
チームの方針は「分からないからこそ、型を意識する」みたいなチームでした。
まずは型を守って、少しずつ破っていき、ある程度したら型から離れていくみたいな進め方だったので初めてのスクラム開発としては馴染みやすいチームでした。

あとはスクラム開発自体を導入する最初のチームだったので各社が肝入りのメンバーをそれぞれぶつけてきた感じのチームだったのですごい人が多かったなぁ。。。開発チームの一員で役割が違うだけという括りだったのですべてのセレモニーや会議に参加していたので本当によかった。

はじめに頑張ったこと

社内で初めてのQAだったのでモデルとなるキャリアパスがなかったので、当時が頑張ったことは下記です。

JSTQBの資格取得
界隈のスクラム・アジャイル・品質保証系の勉強会に出る

JSTQBの資格取得

テストの専任・プロなのでいろいろ調べて真っ先に取ろうと思った資格。
勉強してみると日頃の開発で使えそうな知識がたくさんあったのでオススメしたい。

界隈の勉強会の参加

テストの自動化やアジャイルテストに関わりそうなものは足を使って情報収集した。
いろいろ勉強会で分からないことを質問したら、同じような境遇の人と連絡先を交換したりしてこれはこれでよかったかも。

おわりに

当時のことを思い出していろいろ書いたので、また思いついたらここを直していきます。
そう考えるとまるまる3年はやってるのでそこらへんの整理は定期的にやるべきだと改めて思いました。
教えるのが下手くそな自覚はあるので次教える機会が来る近い未来までにはある程度形にしたいと思います。

オチ、書いた人の現在の雑な自己紹介（読み飛ばしてOKです）

私、riririusei99！QAエンジニアだよ！最近転職してきたけど、憧れて入った先輩エンジニアがどんどん偉くなっちゃって、さぁ大変！ひょんなことからスクラムマスターも兼任することになって…どうすればいいの？？次回、「ドキドキ☆スプリントプランニング」お楽しみにー！

終わり