状態遷移図・表の書き方&考え方

はじめに

状態遷移図の話を書こうと思いながら前回のブログから1ヶ月経ってしまっているので徒然と書くことにする。

状態遷移図とは

本を読んだ内で一番分かりやすかったのはテスト会社がやっていた有償のセミナーでエッセンスを聞いたのが非常に分かりやすかったんだが色々問題が歩きがするので、今回もwikipedia先生に解説していただく。

状態遷移図 - Wikipedia

Wikipediaを読んで分かったが自分が知っている状態遷移図というのはUML図におけるステートマシン図(state machine diagram、状態機械図)というものがルーツにあってそれを簡略化しているということが分かった。
今回はふんわり分かれば良いので簡略した書き事を書く。

書き方のルール

正しいお作法についてはwiki参照(UML)
今回はふんわり分かれば良いので下記のルールで書いた。(差分は赤文字)

  • 塗りつぶされた円が START(開始)を意味する。必須ではない。
  • 中抜きの円は STOP(停止)を意味する。必須ではない。
  • で状態を表す。
  • 矢印が操作・振る舞いを表す。

実際に書いてみる

テーマ

腕時計のストップウォッチ機能

f:id:riririusei99:20180921005935p:plain
※便宜的に上のボタンをA、下のボタンをBとする。

振る舞い(仕様)

  • 初期状態は針が0を指している状態
  • 初期状態でAボタンを押すと針が動き出し、計測開始する
  • 計測開始状態でAボタンを押すと針が止まり、一時停止する
  • 一時停止状態でAボタンを押すと針が再度動き出し、計測開始する
  • 一時停止状態でBボタンを押すと針が0を指し、初期状態へリセットされる

状態遷移図

振る舞いに書かれた情報を元に、状態遷移図を書くと下記のような図になるはず。
この時計にはAボタンには3つの機能があることがわかる。(計測開始、一時停止、計測再開)

f:id:riririusei99:20180921014221p:plain

状態遷移表とは

状態遷移図をもとに今度は操作の一覧を表に落とし込むのが状態遷移表である。 もしかしてこれもwikiありそう…と思ったらやっぱりあった。

状態遷移表 - Wikipedia

すご~くざっくり書くと

書き方のルール

  • 縦軸に現在の状態
  • 横軸に操作
  • 交わる場所に操作後の状態を書く

実際に書いてみる

STEP1:図から表に落とし込む

書き方のルールに基づいて図を表に落とし込むと下記の様になる。

状態/操作 Aボタン Bボタン
初期状態 計測開始
計測開始 一時停止
一時停止 計測開始 初期状態

交わったセルが状態遷移テストにおける一つのテストケースになる。
表では空白が2つできているため、想定結果がわからない状態(もしくは仕様が決まっていない状態)なのできちんと仕様を確認することが重要。
ここらへんの考慮漏れとかを早い段階で指摘するのがテスト設計での腕の見せどころかもしれない。

STEP2:足りない部分を落とし込む

足りない部分を追記したバージョン

状態/操作 Aボタン Bボタン
初期状態 計測開始 初期状態※1
計測開始 一時停止 計測開始※2
一時停止 計測開始 初期状態

※1: ボタンは押せるが、状態遷移しない
※2: ボタンがロックされるため、状態遷移しない

この状態で初めてすべての表が埋まりテス実施できるようになった。
今回は物理的な時計の話なのでどの状態でも常に2つのボタンを押すことができたが、そもそも操作ができない場合などは「N/A(not available)」と書いたりする。

まとめ

状態遷移図・表の書き方を書いてみた。
実際の業務では操作が複数の状態を起因にして違ったり、操作の数が多いとかあるので図や表が複雑になりがち。
本当はNスイッチの話もしたかったんだけどまた次の機会かなぁ。

おわり

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 + "を掛けて3で割る!");
  }
}

命令網羅 (statement coverage) (C0)

「命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい。」とのこと。(by wiki)
テストケースは下記になりそう。

  • x=2,y=3,z=4(面積、体積の表示)
  • x=0,y=0,z=0(例外)

分岐網羅 (branch coverage) (C1)

「分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい。」とのこと。
なるほどわからんな状態なので改めて整理する

最初の分岐 2個めの分岐 テストデータ例
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

感想

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

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

Jenkins pipelineを触ってみた

はじめに

最近の仕事でJenkinsのデプロイジョブとE2Eのジョブの2つを作ったので、ここらへんでpipelineを使って2つのジョブをつなげて一目で確認できるようにと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)

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

おわり

最近見た映画

1ヶ月ぶりに記事を書くのですが…ネタが思いつかず…。

趣味の話をします😋

 

週末にレイトショーを見るのが最近のマイブームで、色々考えたり、テンション上げたりしてます。

 

ということで最近見た映画の紹介(3月、4月)

 

グレイテストショーマン

ヒュー・ジャックマン演じるジャン・バル…じゃなくてP.T.バーナムの半生を描いた映画。

ミュージカル映画なので音楽が良い、すごく良い。

見た翌週はSpotifyでサントラ聞いて仕事してました。

本当に大切なものはなんだっけと問いかけてくれる楽しめる映画です。

 

レッドスパロー

ロシアの才能あるバレリーナだったドミニカは怪我をきっかけに怪しい叔父さんの仕事をきっかけにスパイになる映画。

スパイとして望まないながらも成長していく姿はなんだか、考えさせられるよね。

騙し合いの騙し合いで、最後までどうなるか分からない映画でした。

 

ヴァレリアン

気分が凹んでいたので観たらスッキリするだろうとポスターで選んだSF映画

思った通り、シンプルなストーリーで楽しく見れました。構成がぶつ切り感があったのでいくらでも続編作れそう。

 

パシフィック・リム アップライジング

前作をみてテンション上がったので観た。ロボットアクション、燃えるよねみたいな方は是非。吹き替えがオススメです。

 

…という感じで月2本位のペースで映画館に通うのも結構面白かったので、オススメの映画あったら教えて欲しいなぁ。

 

おわり

 

 

 

転職を決意した話

はじめに

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

自分の話(当時)

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

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

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

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

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

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

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

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

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

転職を決意する

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

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

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

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

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

まとめ

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