ソフトウェアテスト Advent Calendar 2018 4日目担当の @ToshiManaPlus1 です。

前日(3日目)は @YoshikiIto さんによる テストチームにおけるWiki等のナレッジベースでの情報共有のコツ でした。

はじめに

状態遷移テストでは状態遷移図を用意するのが多いと思います。状態遷移図を記述するツールは多数ありますが、UML準拠のツール¹を使うことが多いのではないでしょうか。また、開発で用いていたUMLのモデルを用いて状態遷移テストを設計をする場合があるかもしれません。
しかし、UMLツールでモデルを書いて「状態遷移テストをやろう」となったときに、UMLの記法が原因で上手くテスト設計できない場合があります。
今回はUMLの記法が状態遷移テストに与える影響をいくつか説明したいと思います。

前提

本記事では状態遷移図はDFA²に基づいているものとします。
UMLにおける状態遷移図相当はステートマシン図と呼ばれています。本記事では、ガードや履歴状態といったUML特有の記法を含むものをステートマシン図、含まないものを状態遷移図として区別します。³

背景

一般的に状態遷移テストの説明で用いられるモデルは状態遷移図です。⁴
私の知る限り⁵、ステートマシン図での状態遷移テストについて説明した資料は数が少ないです。⁶⁷
そのため、どのような注意が必要かがあまり議論されていないように思います。
本記事では、ステートマシン図から状態遷移テストを設計する上で注意が必要だと感じた点を整理しています。

概要

以下のケースにおける、ステートマシン図から状態遷移テストを設計するときの注意点について説明します。

• ガードを用いたステートマシン図

• (浅い)履歴状態を用いたステートマシン図

ガードを用いたステートマシン図

題材は某国民的横スクロール型アクションゲーム⁸とします。ガードを含んだステートマシン図と等価の状態遷移図を比較します。

検討

ガードを含んだステートマシン図から状態遷移図へ変換していく過程を示します。

ステートマシン図(ガードあり、直交合成状態あり)

ガードを含んだ以下のようなステートマシン図を扱います。ガードを含む遷移を赤字で示します。直交合成状態を含んだ表現は状態遷移図／ステートマシン図の整理を容易にします。しかし直交合成状態を含んだ表現から直接Nカバレッジテストを設計することは困難です。

ステートマシン図(ガードあり、直交合成状態なし)

上記のステートマシン図(ガードあり、直交合成状態あり)では「ゲーム中」が直交合成状態として表現されています。2つの領域を1つの領域に変換すると、以下のようなステートマシン図になります。ガードを含む遷移は「ガード条件を満たす遷移」と「ガード条件を満たさない遷移」を2つを検討する必要があります。そのため、Nカバレッジテストの際は、見た目以上に多くの遷移をテストする必要があります。

状態遷移図(ガードなし、直交合成状態なし)

上記のステートマシン図(ガードあり、直交合成状態なし)のガード条件が状態に依存しています。そのため、ガードをなくして表現すると以下のような状態遷移図になります。上記のステートマシン図(ガードあり、直交合成状態なし)から遷移先が変わった遷移を青字で示します。

状態遷移図(ガードなし、直交合成状態あり)

状態遷移図(ガードなし)の場合、直交合成状態として領域を分割することができません。

検討結果から考えられる注意点

検討から以下のことが注意点として挙げられます。

• ガードを含む遷移は「ガード条件を満たす遷移」と「ガード条件を満たさない遷移」の2つを検討する必要がある。ガードを含む遷移はステートマシンの見かけ上では1つの遷移で表現されているため、Nカバレッジテストを行う際に抜けが発生するかもしれない。

• ガードを含んだステートマシン図だと直交合成状態で表現できて、ガードのない状態遷移図では直交合成状態で表現できない場合がある。直交合成状態は各領域が並行に動作しても正しく機能する(入力に対して期待結果が一位に定まる)ことが期待される。しかし、ステートマシン図での直交合成状態の各領域が並行に動作した場合、正しく機能しない(入力に対して期待結果が一意に定まらない)可能性がある。

	直交合成状態あり	直交合成状態なし
ステートマシン図(ガードあり)
状態遷移図(ガードなし)	×表現不可

(浅い)履歴状態を用いたステートマシン図

題材は単純化したオーディオプレーヤーとします。履歴状態のなし／ありを比較します。

検討

履歴状態のない状態遷移図を検討した後に、履歴状態のあるステートマシン図を検討します。

履歴状態なしの状態遷移図

以下のような直交合成状態を含む履歴状態のない状態遷移図を扱います。

上記の状態遷移図から、状態の粒度を揃えた状態遷移図を以下に示します。

履歴状態ありのステートマシン図

「再生モード」について、電源断後に電源投入しても前回の再生モードが維持できるように履歴状態を導入します。履歴状態のない状態遷移図(直交合成状態あり)と比較をしても、履歴状態以外は差異がなく、見た目上の影響が小さいことが分かります。

上記ステートマシン図から、状態の粒度を揃えて、かつ履歴状態があるステートマシン図と等価になる状態遷移図を検討した結果を以下に示します。履歴状態を持っていた「電源ON」の状態は履歴状態を持たない状態遷移図(直交合成状態ない)と相違ありません。しかし、履歴状態を持っていない「電源OFF」が「再生モード」の状態を保持するようになりました。

検討結果から考えられる注意点

検討から以下のことが注意点として挙げられます。

• 履歴状態ありのステートマシン図を履歴状態なしの状態遷移図に変換する場合、履歴状態を持っていなかった状態の数が増える。

• 履歴状態あり／なしがステートマシン図／状態遷移図の見た目に与える影響が小さい場合がある。しかし、状態遷移テストへの影響が小さいとは限らない。

	直交合成状態あり	直交合成状態なし
履歴なし
履歴あり

おわりに

ステートマシン図を用いた状態遷移テストの注意点を挙げてみました。
ステートマシン図では複雑な状態遷移をできるだけ簡潔に記述するための様々な記法があります。UMLの記法を駆使することで、設計者は実現したい機能を容易に／簡潔にモデリングできます。
ステートマシン図は状態遷移図よりも情報の密度が高いです。そのため、UMLの記法を意識して、ステートマシン図の振る舞いを正しく理解することで効率の良いテストの実現を目指していきましょう。

ソフトウェアテスト Advent Calendar 2018 の明日(5日目)は @____rina____ さんの 受託開発テスターと受託リモートワークテスターとWebサービステスターは何が違ったのか です。

　ソフトウェアテストアドベントカレンダーの10日目です。
　本記事では、未経験からRailsエンジニアになり、入社３ヶ月で決済や請求書発行などお金に関係する実装を任された経験を元に、新人エンジニアに送る即戦力になるための最短の方法としてソフトウェアテストのスキルの重要性について記述します。
　ソフトウェアエンジニアに必要なスキルとは何でしょうか。私は、主に３つを考えています。

1. 技術力
2. 業務の理解力
3. トラブル時の対応力

　1.の技術力とは使っている技術に対してどこまで深い理解があるか、保守性の高い実装ができるか、高負荷にならないような実装は何かなど、技術に関するスキルです。これは経験がものをいう分野でもあるので、ベテランエンジニアと比較して、新人エンジニアが一番劣っている部分だと思います。

　今回のテーマであるソフトウェアテストに関するスキルは、2の「業務の理解力」の全ておよび、3の「トラブル時の対応力」の一部に関わってくると思っています。ソフトウェアテストをするためには業務の理解が必要不可欠ですし、業務を理解して入ればトラブル時の対応もスムーズにできます。

　そこで、本記事では業務の理解の仕方から、実際にエンジニアが自分の実装を自動テストで担保するまでの概観を記述したいと思います。

業務を理解しょう

　すでにあるシステムの業務を理解するためには、大まかには以下の手順を踏めば良いでしょう。

1. 仕様書を熟読する
2. コードリーディングをした上で実際に動かして見て挙動を把握する
3. 不明点や違和感がある場合は、業務がわかる人（エンジニアだけでなく、営業やCS、ディレクターなど）に聞く

　まず、仕様書の熟読ですが、SIerなどの従来型のシステム開発では仕様書が整備されている場合は、要件定義書、外部設計書、内部設計書などが存在すると思いますので、それを熟読します。基本的には上流の工程から読んでいけばいいと思います。概要を掴んで全体像を理解した上で細かなところを理解したほうが自分のタスクの意義が明確になり、設計書の不備を明らかにすることもできるからです。

　Web系のスタートアップですと、仕様書が存在しない場合もあるでしょう。そういう場合でもサービスの概要を記載したスライド程度はあると思いますので、それを読み、サービスを理解することから始めます。検証環境（ステージング）などがあって、自由に操作できる場合は、実際に自分で触ってみるのがいいと思います。ありとあらゆるボタンをクリックし、フォームがある場合は入力し、条件分岐がある場合は試していきます。チーム参画当初は比較的時間に余裕があると思いますので、早い段階でサービスの全容を把握することが重要です。

　特に新人エンジニアの場合、技術力がないことに焦りを感じている人も多く、技術力（主に知識）の習得に時間を使いがちですが、その組織で早い段階でValuableな人材となるためには、技術力よりも仕様の把握力の方が重要度は高いです。仕様を把握できている人ほど、仕事が任されやすく、仕事が任されれば実装して行く中で技術力は自ずと向上するからです。

　仕様の把握ができたら次に行うのが次にコードリーディングです。コードリーディングでは、仕様書や触って見るだけでは読み解けなかった条件分岐や、一見して不思議に思う仕様などを発見することができます。例えば、ある商品の申し込み機能があるのであれば、実際に申し込みを行うところから、オペレータが申し込みの処理をして、商品が発送され消し込みが行われるまでの一連の業務がソースコード上でどう実装されているかを追ってみましょう。その中には、Web上だけでは完結しない、バッチ処理もあるでしょう。データベースは同じでも違うアプリケーションになっているかもしれません。そういうのを一つ一つ追っていき、一つ一つの分岐をチェックしていきます。

　私の経験上、コードリーディングがきちんとできる新人エンジニアは非常に少ないです。これは、会社に入るまで、すでにあるシステムをメンテナンスしてきた経験がないからだと思います。学校では主に新規にアプリケーションを作ることを学ぶことが多く、既存のアプリケーションへの対峙の仕方などは学ばないのでしょう。しかし、現場では、既存のシステムを修正することも多いです。
「プログラマはコードを書く時間よりも、読む時間の方が長い」とは言い尽くされた言葉です。自分が書いたコードじゃないから分からないとは決して言わないようにしましょう。優秀なエンジニアは他人が書いたコードを読み、理解することができます。

　こうして仕様書を読んだり、実際に動かしてみたり、コードを読んだりして一人でできうるありとあらゆる手段を使って仕様を把握していきます。それでも仕様が不明なところや、違和感を感じるということは良くあります。そういう時は業務がわかる人に聞くしかありません。そのためには、その業務に長く携わっているエンジニアやディレクター、営業、CS、経理などそのシステムを利用している人が誰かを把握しておくことが必要です。

テスト設計をしよう

　さて、このようにして業務を理解したら次はテスト設計です。本記事では、詳細なテスト設計技法について述べることはしません。本格的にテストを学びたい人は、ソフトウェアテストに関する専門書を読んでください。ここでは、簡単に概略だけ紹介します。

　私はテスト設計に重要なのはいかにケースを網羅できるかということに尽きると思っています。　私は電力関係のシステムを作った経験がありますが、電気の申込みフォームのWebシステムをイメージしてみましょう。

　電力にはエリアという概念があり、北海道から沖縄まで１０個のエリアがあります。エリアという視点では１０個のケースがあるということになります。さらに、各エリアには低圧ですと、従量電灯A、従量電灯B、従量電灯C、低圧電力（動力）、低圧高負荷などのプランがあり、プランという視点では５つになります¹。まずは、こうしたケースを抜け漏れなく列挙できるかというのがファーストステップだと思います。

　勘のいい方はお気づきだと思いますが、ケースを考えだすとキリがありません。契約アンペアであれば10アンペアから60アンペアまでありますし、今契約している電気の切り替えなのか、引越し先の申込み²なのかなど考えるべきことはいくつもあります。エリアとプランを考慮しただけでも掛け算して50個のパターンが考えられるわけです。

　ソフトウェアテストの世界では、ここでいう電力エリアやプラン（項目）を因子、北海道電力エリア・東北電力エリア・・・や従量電灯A、従量電灯B・・・（値）を水準と言ったりします。ここで全ての因子の全ての水準にたいしてテストをすることは現実的ではありません。因子が増えれば増えるほど、水準が増えれば増えるほど、テストケースの数は指数関数的に増大していきます。そこで、ソフトウェアテストの世界では、ペアワイズ法や直交表などを利用してテストケースの数を減らしていきます。そのためのツールも存在します³。ペアワイズ法に関する詳細は「テストの数を減らそう！プリキュアで学ぶPICT」が詳しいですのでそちらをお読みください。

　ソフトウェアテストについての全体像を学びたい方は、「知識ゼロから学ぶソフトウェアテスト【改訂版】」もおすすめです。また、ソフトウェアテストアドベントカレンダーの17日目で紹介されていたJSTQB TA テスト技法の紹介のスライドも大変勉強になります。

　私は、開発者の観点からのテスト設計はひとまずはテストケースの洗い出しまででいいと思っています。結果の期待値まではこの段階では考える必要はないでしょう。なぜなら、開発者であれば自動テスト（JUnit、RSpec、unittestなど）を必ず書くことになります。期待値はテストを書きながら考えても遅くはないでしょう。もし自分が洗い出したテストケースに自信がない場合は、本当に十分かどうかをこのタイミングで先輩エンジニアにレビューしてもらうと良いでしょう。

自動テストを書こう

　このようにしてテスト設計（テストケースの洗い出し）ができたら、あとは、自動テストを書くだけです。私は普段Railsを使っているので、RSpecを書きますが、現場のフレームワークに合わせたテスティングフレームワークを利用すればいいと思います。

　一部のエンジニアにとってテストを書くことに対して億劫に感じるかもしれません。テストはエンジニアたる自分がやるべきことではないと思う人もいるようです。しかし、エンジニアとはいえ人間ですから、実装に間違いはあるものです。社会人になる前、学校のテストで満点しかとったことない人は皆無でしょう。答えが明確にわかっている学校のテストですら間違うのですから、より複雑怪奇な業務の焼き写しであるシステムを実装して間違わないわけはありません。自動テストは言ってみれば学校のテストの見直しにあたります。見直しをするとケアレスミスに気付けたり、時間をおいて改めて考えることで最初に解いた時には気づかなかったことに気づくことができます。自動テストも同じです。自動テストをするためには、時には事前にデータを用意しないといけないことがあります。データを用意する過程で、想定していなかったデータが入ってくることもあるでしょう。テストケースをきちんと書き出しておくことで、実装時に気付けなかった実装漏れも気付けるかもしれません。

　そして、もっと大事なのは、自動テストを書いておくことで、そ後から見た人がそのコードがどのような挙動を想定しているのかをより理解しやすくなります。私は、エンジニアにとって大切なことの一つは思いやりだと思っていますが、自動テストを書くことは思いやりの一つだと思います。

ソフトウェアテストスキルはいつの時代も必要とされる技術

　最後に、ソフトウェアテストのスキルというのはいつの時代も色褪せないスキルだということです。この世にシステムがある以上、テストをせずに世に出すことはありません。程度の差こそあれ、必ずテストをしてからリリースされるでしょう。つまり、ソフトウェアテストのスキルはいつの時代も必要とされると言うことです。

　エンジニアをしていると、どんどん新しい技術が出てきて、あれも学ばなければ行けない、これも学ばなければいけないと言う強迫観念に襲われる時があります。新しい技術は面白いので学んでいくのは良いことだと思いますが、同時に、息の長い技術を学ぶことでエンジニアとしての土台ができると思います。今回のメインテーマであるソフトウェアテストもそうですし、例えばリレーショナルデータベースもそうでしょう。

　エンジニアとしては、テストを書くことを嫌がらずに書き続けることで堅牢なシステムをつくれますし、その結果、周りからの信頼も得ることができます。これは、新人エンジニアでも今すぐに始められることです。そして驚くべきことに、ベテランのエンジニアであってもソフトウェアテストに関する理解がないという方もいます。そういうエンジニアと同じチームになれば、ソフトウェアテストは新人エンジニアがリードしていける分野となりえます。

最後に

　　本記事では、会社に新人エンジニアが入ってきた時に伝えたことを改めて文字に起こして見ました。テストに関しては私も勉強中の日々です。バグも生み出してしまいます。エンジニアとして仕事をしていると失敗ばかりの方が多く感じます。何事もなく動くのが当たり前という世界だからです。私の地元出身の野球選手（投手）に金田正一さんという方がいます。金田さんは通算で400勝していますが、同時に298敗もしています。43%も失敗しているのです。バグを生み出してしまったときには毎回これを思い出し、自分が今まで開発してきたシステムも、時折不具合は見つかるけど、きちんと稼働して、お金を生み出している。十分に勝ち越してると思って日々精進していこうと思います。

　この記事を書き終えてから、前日の担当の @hiroyuki3gou さんがシステムを把握する3つのコツというタイトルで業務理解について記事を書かれていました。テストを行うにあたっての業務理解の重要だということの現れなのではないかと思います。

ソフトウェアテスト Advent Calendar 2018 - Qiita の12日目の記事です。

IntelliJ IDEAを利用して、コメントからソースコードにある問題のありそうな箇所を見つける方法について，紹介します．

TODOコメント

TODOコメントは，下記のような例です．

//TODO:処理速度を早くするために，アルゴリズムを改善する

よくありますよね．

このようなコメントは，TODOコメントと呼ばれたり，開発中のコメントと呼ばれたり，
Self-Admitted Technical Debtと呼ばれたりします．
日本語でいうならば、技術負債を表すコメントといってもよいでしょう．

このようなコメントの周辺には，ソースコードに問題が存在しています．
このようなコメントを見つけることで，ソースコードにある問題のありそうな箇所を見つけることができます．

統合開発環境の一つであるIntelliJ IDEAには，TODOコメントを見つける機能があります。
https://pleiades.io/help/idea/using-todo.html

TODOとFixmeのタグのついたコメントであれば，そのままでも見つけることができます．
しかし，TODOの他にも，XXXやHACKやOPTIMIZEなどのタグが使われて記述されます．
また，知識不足により開発者によっては，コメントにタグを付けない人がいます．
他にも，自分独自の言葉でタグを付けていることがあります．
これらのコメントを見つけるためには，カスタマイズしたパターンを追加する必要があります．

パターンの追加方法

IntelliJ IDEAでは，カスタマイズしたパターンを追加する機能があります．
https://pleiades.io/help/idea/using-todo.html

パターンには，正規表現を利用して追加できます．
正規表現については，以下をご覧になってください．
https://pleiades.io/help/idea/regular-expression-syntax-reference.html

日本語で検出したいパターンは，下記のようなものがあると思います．

//これ必要?
//これいる？
//今は使ってない
//なぜか動く？
//暫定的な処理
//今後対応する
//将来対応する
//改善すべき
//暫定的な処理
//仮の処理
//修正開始
//修正完了

このようなコメントを見つけるパターンを，記述して追加しましょう．
以下は例です．

必要\?
いる\?
今\?
今後\?
使っていない
なぜか
暫定的な
将来
改善
仮の
修正の
？

これくらいのであれば，正規表現を利用せずとも引っかかりますね．
ゴミも出てきたりするので，正規表現を工夫する必要があります．

このように，見つけてきてくれますね．

最後に

他のIDEでも同様な機能があるため，同様にパターンを追加すると，コメントを見つけることができます．
ただし，正規表現の記述方法は，IDEごとに違うので，IDEごとの正規表現を調べて従う必要があります．

grepコマンドを利用しても，正規表現を利用して見つけることはできます．
また，それなりに工夫が必要です．grepを利用した方法については，そのうち書くかもしれません．

チームでよく書かれるような，このようなコメントのパターンを追加してみてください．
正規表現を工夫するとゴミが減っていきます．

ソフトウェアテスト Advent Calendar 2018の14日目です。

今日はJaSST'18 ShikokuとJaSST Review'18が同時開催という、前代未聞の豪華な一日でしたね。

はじめに

2018年は主に自動テストの要件定義ゃーをやらせていただいているのですが、スポットで入らせていただいた業務システムのテストリーダーのお仕事は近年稀にみる学びがありま、テスト技術者もプロセス設計や要件定義といった上流工程の技術を学ぶべきとしみじみ感じた1年でした。
今日はそんなしみじみ感じた内容をだらだらと書いてみようと思います。¹「上流工程は上流工程の人に任せておけばいいんじゃ？」って人も「上流工程のことわからないで何をテストしてるの？」って人も²、駄文に少々お付き合いいただければと思います。

テスト担当者も上流工程の技術を学ぶべき3つの理由

2018年の出来事から、上流工程技術が必要だと痛感したことを3つ挙げます。

1. 計画を立てるため
2. 現場で使えるシステムを納品して受入れテストですんなりOKをもらうため
3. 業務を改善するため

1. 計画を立てるため

計画というのは、テスト計画だったり目標達成への計画だったり、テスト担当者にとっても身近な存在です。

計画を立てるためには、成果物を定義する必要があります。成果物の内容によってタスクが決まります。裏を返せば、成果物が決まらないとタスクが明確になりません。タスクが決まったら、依存関係とリソースを調整してスケジュールを作成します。

成果物に何を含むのか、要件を定義しないと、タスクがあやふやになります。後からタスクが漏れていることが分かるとスケジュールが押しますし、タスクが曖昧だと見積もりと合わなくなってやっぱりスケジュールが押します。
計画通りに物事が進まない方は、要件定義を学びましょう。いい計画はいい要件定義から。テスト担当者も要件定義を学びましょう。

2. 現場で使えるシステムを納品して受入れテストですんなりOKをもらうため

テストに寄せたくて受入テストってキーワードを使いましたが、テスト担当者はシステム開発チームの一員ですので、いいシステム（現場に定着するシステム）を提供するためには全力投球したいところです。

業務系システムの受入テストでは、システムが実業務にマッチするかどうかを見ていきます。すなわち、「現場で使い物になる」システムかどうかを見極めるテストをしていきます。最後の最後でひっくり返されないよう、テスト担当者として業務シナリオをレビューしたり、シナリオテストを実施しなければなりません。

シナリオテストのインプットはユーザーシナリオで、本来であれば要件定義の成果物に含まれているべきものですが、機能先行で開発が進んだ場合、ユーザーシナリオが存在しないことがあります。プロジェクトの一員としてテストに参画している場合、「ユーザーシナリオがないのでテストしません」と突っぱねるのはテスト担当者として仕事を放棄しているようなものです。
ユーザーシナリオがあったとしても、それが十分かどうか検証する必要がありますし、結局、ユーザーシナリオが作れるだけのスキルはあるに越したことはありません。

登場人物は誰なのか、業務の目的はなんなのか。システムが業務で使い物になるかどうかはそこからです。ヒアリング力と妄想力を駆使して、お客さまの業務を理解し、お客さまがすんなりシステムを導入できるよう検証しましょう。
それから、ユーザーシナリオが定義されていないような開発現場がこの世からなくなるよう、促しましょう。要件定義、マジだいじ。

3. 業務を改善するため

業務というのは、材料（入力）と活動と成果物（出力）の連鎖でできています。これを、プロセスと呼びます。プロセスは目に見えないので、書き出してみることで無駄が見えたり暗黙知が共有できたりします。もちろん、テストにもプロセスがあります。

プロセスについては私は、ボクらのプロセスにきづこう #wacateで学びました。形式としては、PFD（プロセスフローダイアグラム）³を使うと簡潔にまとめることができます。PFDは私がの周りのテスト技術者の中で広く広まっている手法です。
​もっと細かいプロセスを書くなら、マジカが使えます。IT屋さんではない人に業務フローを定義してもらうときに活躍しているツールです。以前、自分が暗黙でやってたいろんなタスクを引き継ぐときにマジカを使ってみたら、スムーズに定義ができて感動ものでした。
「可愛いは正義」が口癖の羽生さん⁴が作っているだけあって、可愛いくてとっつきやすい反面、現場に持ち込みにくいのが若干の難点。とりあえず社内で付箋とゴミ袋のスタイル⁵に抵抗がなくなってきているので、次はマジカの普及を狙っていたりします。

業務を楽にするためにも、業務プロセスが見えないと始まりません。
テスト担当者も業務プロセスを書けるようになりましょう。

まとめ

テスト担当者も、武器は多いほうがいい。

テストと要件定義の関係についてはもうちょっと掘り下げたいところですが⁶、忘年会の時間が迫っているので今日はここまで。

今週末はWACATEやPHP Conferenceがあるみたいですね。参加される方は、いろんな方々とたくさん交流をされるとよいかと思います。それでは、忘年会に行ってきます！​⁷

これまでのお話

この物語の設定については一昨年のAdventCalendarをお読みください。

あれから“RINA”と“まりまり”は、どのくらい成長したのでしょうか。
それではさっそく、二人の様子をのぞいてみましょう。

シーン1. （わたし転職します！）12:25

まりまり「RINA先輩！　まりまり、もう、おなかいっぱいです！！！！！」
(；´・`)=3

ここは、天神の地鶏居酒屋『おも屋』のカウンター席。

午前中のミーティングが早く終わった関係で、いつもは混んでいて入れない人気店に、フライング気味に二人はやってきた。

狙いは『炙り親子丼ランチ』である。濃厚でコクがある“若宮の地黄卵”と備長炭で炙った“宮崎県産の刀根どり”を使用した親子丼は、あつあつ・ふわとろで絶品なのである。

ベタベタした甘いタレではないものの、丼物は味が単調になりがちである。サラダとキムチで舌をリセットしつつ、食べ進めること10分。気がつけばあと少し。
ラストスパートに向けて山椒（おも屋では七味や一味ではなく粉山椒が付いてくる）をパラパラ振りながらRINAはつぶやく。

RINA「サイドオーダーに唐揚げも頼めばよかったかしら？」

まりまり「いやいやいやいや。🙌先輩、それは食べすぎです。」

RINA「あれ？　まりまり、どうしたの？　食欲なくない？」

まりまり「なくないことはないんですが、、、。」

RINA「なくなくないですが？？」

まりまり「先輩！　実は、わたし来月転職します！！！」(๑•̀ㅁ•́ฅ✧
※ まりまりは、座っていたカウンターチェアーをガバっとRINAに向け、真剣な顔でそう告げた。

RINA「えっえっ。待ってまって。話についていけない。」Σ(ﾟ◇ﾟﾉ)ﾉ

まりまり「テストはとても面白い仕事だと思うのですが、『作るところに直接役立ちたい』という気持ちがムクムクと。」

RINA「湧いてきたってわけか。」o(｀・_・´)o ウン！

まりまり「はい。すみません。私自身がバリバリと設計してプログラミングしたいわけではないのですが、“作り手（開発チーム）の思いとユーザー（お客様）の気持ちをつなぐ仕事”をしたくって。ごめんなさい。こんなによくしてもらってるのに。」
※ 『それは自分が作るよりも大変な仕事となるだろうなあ。』とRINAは思ったが、口にはしなかった。『まりまりなら、苦労はしてもきっとなれるよ。』と思ったからだ。

RINA「謝らなくっていいよー。実は私もなんだ。」

まりまり「えっえっ。待ってまって。話についていけない。」(　 ﾟ ▽ ﾟ ;)ｴｯ!!

RINA「こらこら。」( 艸｀*)
※ RINAは、口に入れた三つ葉をプッっと噴き出しそうになる。

まりまり「先輩もデザイナー志望だったんですか？」

RINA「ちゃうちゃう。私はテストガール。テストが好きよ。」

まりまり「ですよね。それではいずこに。」

RINA「今の会社を辞めて在宅勤務にしようかなと思って。あ。もう12:40だわ。オフィスに戻らなくっちゃ。」

まりまり「今日の夜、ラーメン食べに行きません？」🍜

RINA「いいね。リナは美味しいラーメンが食べたいです！」

シーン2. （竹乃家）19:10

まりまり「“たけのいえ”って長浜ラーメンじゃないんですね。太麺だし。
アッ、あそこに“昔なつかしの味　支那そば”って書いてあるわ。“昔なつかしの味”って言ったって、平成生まれに昭和21年の話を書かれてもねえ。朝ドラの“まんぷく”でしか見たこと無いわ！！」
※ まりまりは、いつも観察眼が鋭い。一分一秒も無駄にしない生き方のようだ。

RINA「私ねー。実はとんこつラーメン、そんなに好きじゃないんだよね。」

まりまり「えっ？　でも、この間、東京から来た人を“一双”に案内していましたが……。」

RINA「そりゃ、博多にいらして、『博多ラーメンが食べたい』って言ってる人を『肉肉うどん』に連れて行くわけにはいかないじゃない。」

まりまり「そりゃそうか。」

RINA「リナも気遣いするのだ。」(୨୧•͈ᴗ•͈)

まりまり「はい。知っています。」

RINA・まりまり同時に　「ところで！」

まりまり「どうぞ。先輩から。」

RINA「じゃあ。ズバッと聞くけど、どちらに転職するの？」

まりまり「A社です。」🏢

RINA「A社って、、、東京の、、、有名な、あのA社！？」

まりまり「はい。先輩は？」

RINA「私はB社よ。」

まりまり「B社も東京じゃないですか！？　東京でまたキャッキャ・ウフフできますね！！！」

RINA「それはできないわ。だって、私はリモートオフィス、つまり、会社は東京にあるけど、今の福岡のおうちで働くから。」

まりまり「へー。すごーい！　自宅にネットを引いて仕事するなんて、近未来的ですね！！！！！　そういうの『ハタラキカタ改革』っていうんでしたっけ？」

RINA「うーん。どうなんだろう？　私は電車通勤がなくなるのがうれしいかな。」

まりまり「先輩は乗り物に弱かったですものね。｣

RINA「そうなのよー。自宅の方が集中して効率よくテストできると思うの。それに、いつでもおやつ食べられるしね。えへへ。」

シーン3. （RINAのおうち）16:00

RINAがリモートワークを始めてから3ヶ月が経った。お気に入りの壁紙に囲まれ、ウッドブラインドから柔らかな蜜柑色の夕日が差し込んでくる午後4時のこと。

RINAお気に入りのウォールナットの一枚板の机の上には24インチのPCモニターが2台並んでいる。いわゆるデュアルモニターである。近ごろ、RINAは、「ウェブのテストをするなら絶対にデュアルモニターよっ！　24インチが2つで48インチよ！（※）」と言うが、実はちょっと前まではデュアルモニターが苦手だったらしい。

※ ディスプレイの大きさは対角線の長さなので、24インチの横並べデュアルは43インチと呼ぶべきであろう。

PCモニターの壁紙はRINA自身が撮った娘の写真が1分おきに切り替わるようになっている。仕事に疲れたときに見る娘の笑顔は大いなる癒しになるからだ。でも、良いことばかりではない。（何百枚もの写真がランダムで切り替わるため）『次はどの写真かなー？』と、ついつい仕事を忘れて見続けてしまうところが難点である。ときにはデュアルモニターの片方がフォトフレームと化してしまうことさえあるのだ。

気分転換しようとRINAはスマートスピーカーに話しかける。

RINA「OK Google、レキシの曲をかけて。」

Google Home「ジャズ100ネンの、歴史を、サイセイ、します。」

『そうじゃないだろー』、『“きらきら武士”流せ〜。』
スマートスピーカーがイマイチ期待に応えてくれない程度にはリモートワークに不便を感じることもあるけれど、RINAは、この新しい生活パターンが結構気に入っている。

送別会のときに、「みんなの目がなかったら、私なら怠けちゃう。」っていう後輩もいたけど、“会社でも怠ける人は怠けていたし、勤勉な人は誰も居ない早朝でも働いていたっけ……”とRINAは思う。要するに『時間給（Pay for time）』から『成果給（Pay for performance）』に変わっただけ。だらだらと働こうが、チャッチャと働こうが関係ないのである。

RINAはこの3ヶ月で、自然と『生産性良く働いて、早く家族との時間を取りたい』と思うようになっていた。
『リモートワーク、私に合ってる！』とRINAは思った。

ただ、仕事の効率とは全く別に、人寂しい気持ちになることもある。いつもおしゃべりしていた、まりまりがいないからだ。

「ああ、そうだ。」
RINAは思った。

「まりまりは、ここにはいない。否。天神にすらいないのである。」

「たそがれてんなよ！」と、
あさこ先輩の声が聞こえた気がした。

12月の夕空に、あさこ先輩の笑顔が大きく浮かんで見えた。
※注　あさこ先輩は生きています。

シーン4. （探索的テスト？）10:00

リモートワークを始めるようになってから、「口頭ではなく文書でテストの仕方を後輩のヨシタケ君に指導してほしい。」と言われるようになった。
これまでRINAは、数え切れないほどのテストを実施してきたが、テスト仕様書はほとんど書いてこなかった。それでも重要なバグはテストで見逃していないに違いないとRINAは思っている。
（こうみえてRINAはリリース後に、『見逃したバグはないだろうか？』と、しっかりと振り返りをおこなっていたからである。）

次から次へと『これをテストしてほしい』と仕事が舞い込んで来るのでテスト仕様書を書く時間が取れなかったというのも本当のことだが、『明日テストすることを書いて、それを読みながら書いた本人がテストする』ことに何の意味があるのか？　•́ε•̀٥
と、疑問だったからである。ダニエル・カーネマンも、“人はできるだけ損失を回避したいという心理状態をもつ傾向にある”と言ったらしい。

でも、後輩や社外コミュニティのテスト勉強会でテスト技法を教えるときに、

テスト技法を使って、テスト設計を行い、テストケースを作ります。
テストケースには、入力値、実行事前条件、期待結果、そして、実行事後条件を書いてください。特に【入力】と【期待結果】は大切です。

と説明している手前、『言ってることとやっていることが違う』という引け目も感じていた。それでも、『言行不一致だけど、私の環境ではこの方法がベスト』とRINAは信じている。

というのは、以前、東京のテストシンポジウムに参加したときに、“探索的テスト”という『テストのエキスパートのみに実施することが許された奥義』があると聞いていたからだ。探索的テストでは、テスト仕様書を書くことはないという。さらに、どうやら、探索的テストは、Agileでも採用されている“イケてる方法”らしい。

それ以降、RINAは、『私は、テストケースを書いていないのではなく、リナ風探索的テストを実施しているのだ。』と思うことにした。実際にシンポジウムで聞いたやり方はRINAのやり方にそっくりだったのだ。

そこで、RINAは後輩に向けて、テスト仕様書を書くのではなく、自分がいつもおこなっていることを書き出してみることにした。

RINA「ええと。まずは、テスト対象の『出来』の感触をつかむため、本格的にテストを始める前に、ブラウザを起動するところから最後まで、一通りさわってどんなことができるのか、ざっと確認するわね。
そのときにバグがみつかっちゃうこともあるけど、そういうときは“ちゃんと作ってから持って来い！”って叩き返したくなるよね。あまりにバグが見つかるようならテストをやめて、仕切りなおすこともあるわ。」
※ リモートワークを始めてからひとり言が増えたRINAである。

RINA「次に画面ごとにテストするよね。特に［戻る］ボタンは“画面の飛び越し”や“入力した値が保存されるべきかクリアされるべきか”に着目して色々なパターンを丁寧にテストするわ。それから、ブラウザのウィンドウサイズを変えてみたり、タブで入力位置が正しく移動するか、入力後［Enter］キーを押したらボタンを押したことになるかとか、システムフォントや画面解像度を変えてレイアウト崩れが起こらないかどうかも見るよね？　うん、見るみる！」

RINA「そうそう。データベースに文字列を渡していそうなテキスト入力フィールドに対しては、データベースを操作する“SQL文”が入力されても大丈夫かどうか……セキュリティ対策が取られているかどうか……もテストしているわ。新人さんが作ったページは特に念入りにね。」

RINA「最後はエラー処理の確認。入力対象外の文字である絵文字やコントロールコードやタブをCopy＆Pasteで入力してみたり。そうそう、何も入力せずに次の画面に進むのもよくバグるポイントよね。それからそれから。気になるところは全部ガンガンにテストするなあ。」

RINA「えーっと。でも、これって本当に探索的テストっていうんだっけ？　後輩には正しい知識を伝えたいなあ。」
※ 水出しコーヒーを淹れて一休みだ。☕️

シーン5. （探索的テストの学習）13:00

不安になったRINAは探索的テストについて勉強してみることにした。

手始めに、JSTQBの用語集を読んでみた。RINAは、ソフトウェアテストについて疑問に思うことがあれば、JSTQBのシラバスや用語集を調べることにしている。

探索的テスト（exploratory testing）： 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。[After Bach]

（出典：　ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02）

『テスト実施情報を活用しながらテスト設計をコントロール』って具体的にどうすることなんだろう？　私がやっているテストと、どう違うんだろう？　これだけじゃわからないやとRINAは思った。

そこで、昔のツテで、YUMO先輩にSlackで聞いてみたところ、秒で返信が届いた。「高橋寿一さんの資料が良いのでは？」という・・・よし。読んでみるか。
（YUMO先輩は、旧職場のRINAの先輩で、職歴20年のベテランテストエンジニアである）

RINA「なになに、Googleでは毎日65,000回のビルド、だ・と・・・。そして、コード変更ごとに自動テストが行われる、、、と。凄い会社だなあ。」
※ RINAは、“2010年にはすでに、そんなことまで実現されていたのか”と驚いた。でも、今は“探索的テスト”の勉強が先である。テスト自動化も気になるが、今は読み飛ばそう。

RINA「『クラウド・アジャイルの新しいテストには、“早い”、“安い”、“そこそこの品質”が求められ、そのためには軽い“探索的テスト”が最適』。
そうそう。これよ、これ。私が求めていた情報はこれなのよ。さすがYUMO先輩！　ところで、やり方は？？」
※ RINAは夢中になってスライドの先を追った。

RINA「探索テストのやり方は、、、『① ソフトウェアを理解する、② テスト設計を行う、③ テストケースを実行する。この3つを同時に行う』・・・。
えっ。えー。これだけ？？？
これってリナの『① どんなことができるのか、ざっと確認する、② 気になるところは全部ガンガンにテストする。』と同じくらい雑な説明じゃない！？」

※ 資料に失望し、YUMO先輩を恨んだRINAであったが、高橋氏の資料は、まだ始めの15ページを読んだところだ。『57ページもあるのだから、この先に、きっと良いことが書いてあるはず。』と、気を取り直してRINAはスライドを読み進めた。

RINA「『一つ一つの細かいテストケースは書かない!』のか、粗い何かは書くのかな？
『テストケースを書く暇があったら実際にテストしようぜ！』、、、うん賛成。
仕様書を読み込めってよく聞くけど、現物を触った方がテストしなくちゃならないことがいくつも思い浮かぶし。やってみるとバグ見つかるし。
はっ。これが、“テスト設計とテスト実行を同時に行う”ってことなのかな。でもこんなこと普通だよね。」

24ページを開いたところで、RINAの手が止まった。

テストプロセス

• 製品の目的を明確にする(Identify the purpose of the product)
• 機能を明確にする(Identify functions)
• 弱いエリアを叩く(Identify areas of potential instability.)
• テスト実行及びバグを記録(Test each function and record problems.)
• 上記を継続的に実行する(Design and record a consistency verification test.)

RINA「ふぅ。探索的テストにもテストプロセスがあるのか。」
※ 高橋氏の資料は12ページを割いて探索的テストのテストプロセスについて説明している。特に“機能を明確にする”と、“弱いエリアを叩く”に力を入れて説明している。

RINA「高橋さんはこの2つを伝えたかったのかも。
高橋さんの言う、『製品がどういった機能を有しているかを知り、重要な機能を理解すること』は、リナの“① どんなことができるのか、ざっと確認する”に対応しそう。
そして、『弱いエリアを叩く』方はきっと“② 気になるところは全部ガンガンにテストする”のと同じだわ。」

RINA「でも、待ってまって。35ページの《タスクシート》って何？」

※ 表の2項目め、“探索アプローチガイド(Heuristics)”の説明は上記に加え「やるべきタスクを羅列するのではなく、どういう考え方でテストするかを記述する。例えば動詞を全部羅列するとかもアイディアです。」と書かれていた。

RINA「これは作っていなかったなあ。今度試してみよう。」

シーン6. （後輩と）14:00

RINA「よしぺん、タスクシート、メールしたよー。」
※ “よしぺん”とは、RINAの新しい会社の後輩で、リモートワークをしているRINAとZoomなどでTV会議をしながら業務を進めているモチベーションが高く有能な新人のヨシタケくん（シーン4で名前だけ登場）のことである。

よしぺん「はい。届きました。ありがとうございます。これまでは、『［戻る］ボタンは色々なパターンを丁寧に。』とか『ブラウザのウィンドウサイズを変えてみた？』とかZoomで言われて、そのたびに何でそうするのか分からず、ただただロボットのように操作しただけで、バグがほとんどみつからなかったんだけど、このシート凄いです。もちろん、RINAさんのようにはできないんだけれど、どういう結果を得るために何をしているのか、どこまでやれば良いのかが分かるのでバグが見つかるし、テストが上達した気がします。」

RINA「えー。前だって、『意味わかんない』って質問してくれたら、いくらでも答えたのに。」

よしぺん「大先輩にそんなことできませんって。こっそり勉強して、『いつかはRINAさんみたいなテスターになるんだ』と思うのが精一杯です。」

RINA「えっ。私って、そんな怖い？」

よしぺん「怖いというのとは違います。コウテイペンギンの雄はブリザードに晒されながらも、何も食べないで、足の上に卵を置いて暖め、そして生まれた雛を守り続ける忍耐力を持っているのです。」🐧

RINA「ごめん。その喩え、わかんないや。」

おしまい。

長文、お読みくださってありがとうございます。
もしも、この物語を、少しでも気に入っていただけましたなら、昨年のAdventCalendar　続 テストガールRINA（指教編）も読んでいただけるとうれしいです。

※ ソフトウェアテスト Advent Calendar 2018に戻る。

はじめに

本投稿はソフトウェアテスト Advent Calendar 2018の最終日、25日目の記事です。昨日はokauchiwaniさんのソフトバンクの通信障害がヤバかったそうなので、SUPER FRIDAYのテストを考えます。でした。

昨年に続き、今年もイキって「テスト観点エディタつくるぜ！」と豪語しておりましたが、案の定間に合わず（言い訳すると、先週Eclipseのリリーストレイン4.10が出たタイミングで、思い立って開発基盤をSiriusからGraphitiに変更してごにょごにょしてたらタイムアップしました。。。来年1/23までには形にします、すみません。。。 > OpTeMI各位）、今年も昨年に続き、Seleniumネタで急場をしのがせていただきます。
昨年は[コラム] 最近のSeleniumIDE事情ということで、Firefoxのアーキテクチャ変更に端を発したSelenium IDE系ツールの変遷について記事を書きました。今年は「続」ということで、昨年からちょうど1年、その間にSelenium IDE界隈でどのような変化があったかを簡単にまとめてみようかと思います。

各ツールの変遷

本記事は昨年紹介したもの＋αで、以下の3つのツールを扱います。

1. SideeX
2. Katalon Recorder
3. Selenium IDE 3.x（以下、Selenium IDE）

まずはこの1年、それぞれのツールがどのような変遷をとげたかを簡単に見ていきましょう。

SideeX

まず、後ほど扱うKatalon RecorderでもSelenium IDEでも、内部的にベースとして利用されているSideeXですが、残念ながら今年の1月に最新のv2.3.4がリリースされて以来、公式のリリースもgithubの開発も停滞しているようです。本家のSelenium IDEのベースとなったことで、開発を本家を移管したのかなーと想像しますが、開発者のUren YOUさんの動向をネットストーキングしてみてもこれだという情報が得られなかったので、真相は分からずです。こちらはもう少し動向をおってみようかと思います。

Katalon Recorder

次に、Katalon Recorderです。昨年の記事では紹介をさぼってしまったのですが、筆者の体感（周り？）で現在最も利用されているSelenium IDE系のツールがこちらとなります。
Katalon RecorderもSideeXベースということで、Selenium IDE同様、いわゆるWeb Extentionとして実装されているので、FirefoxとGoogle Chromeの両方で動作するようになっています。また、本日時点でSelenium IDEにはないKatalon Recorderのキラー機能として、 記録したテストスクリプトを、各種プログラミング言語のWebDriverテストコードへエクスポートできる が挙げられるでしょう。

こちらにKatalon Recorderのリリースノートがありますが、今年の1月にv3にメジャーバージョンアップし、その後派手ではないものの順調に機能追加・改善を重ね、現在の最新版は9月にリリースされたv3.6.11となります。9月まではかなりの高頻度でアップデータがはいっていた一方、10月以降の3ヶ月間はぱっとアップデートが止まったのが少し気になりますが、まだ開発は活発であると言って差し支えはないかと思います。ただ、Katalon RecorderはKatalon社によって無償で公開されているだけでOSSというわけでないので、そのへんの開発状況の透明性は決して高くはない（Github等で状況がわからない）のが少し難点かもしれません。

Selenium IDE

さて、最後に本家のSelenium IDEです。こちら昨年末時点ではまだβ段階でしたが、今年の4月にめでたく2.xからの正式なメジャーアップデートということでv3.0.0がリリースされました。その後もKatalon Studioと同様、順調に機能追加・改善を重ね、現在の最新版は先月リリースされたv3.4.5となります。
筆者の体感として、後発なれど、いわゆるキャプチャ＆リプレイの機能についてはもはやKatalon Recorderとなんら遜色ないと思います。しかし、前節でも述べた通り、本日時点でSelenium IDEにはまだテストスクリプトのテストコードへのエクスポート機能が開発されていないので、WebDriverテストコード開発のサポートとしては使えないのが筆者的にはイタいところです。

では、エクスポート機能の開発状況はどうかというと、3月にIssueが切られて以降、なかなか味わい深いレスの応酬が9ヶ月にわたり続いております。いちおうメインコミッターの方の最新のレスでは以下のように書かれており、「JavaScriptエクスポートのスレで、Javaからなのか？！」という気持ちはあれど、今月から開発が本格化するということで、来年前半には出てくるのではと淡い期待をしております。

We're going to start work on it later this month, starting with Java and working our way through the other languages after that.

また、公式ツールとして、保存したSelenium IDEスクリプトをFirefoxやGoogle ChromeのIDE画面からではなく、コマンドラインから実行可能としたSelenium SIDE RunnerがNode.jsプログラムとして開発されており、Selenium IDE資産を継続的インテグレーション等で使いたい人は、つなぎとしてこれを使うようガイダンスがなされております。

どのツールを使うべきか

筆者の私見として、Selenium IDE系のツールには以下の2つのユースケースがあると考えます。

1. 非エンジニアによるローカルで完結する動作確認の実施
2. エンジニアによる回帰テストとして実行するWebDriverテストスクリプトの雛形生成

まず、SideeXは前述のとおり、現状継続的なメンテナンスが期待できる状況ではないため、どちらのユースケースの選択肢からも外れるでしょう。

前者のユースケースについては、Katalon RecorderでもSelenium IDEでもどちらでも問題なく実現できます。その場合、選ぶ基準としては二次的な要素ではありますが「業界デファクトスタンダードである」という点で、Selenium IDEを採用するのが無難と考えます。

一方、後者のユースケースにはKatalon Recorder一択でしょう。前節でSelenium SIDE Runnerなるツールを紹介しましたが、このツールは「WebDriverテストコードを生成する」のではなく、「WebDriverテストコードではないSelenium IDE資産をコマンドラインから実行する」だけです。したがって、テスト資産自体を編集したい場合は改めてSelenium IDEから開いて編集しなければならないため、エンジニア向けのメンテナンスのライフサイクルとしては極めて煩雑で非効率的です。

（というか、Selenium SIDE Runnerが有効なユースケースってあるんですかね？各汎用プログラミング言語のテスト実行フレームワークのエコシステムにのっかれずに、ただSelenium IDEのテストスクリプトをコマンドラインで実行できても、それで得られるメリットってほぼないような。。。ローカルでSelenium IDEから実行すればよくないっすかね？テストの事前条件を実現するための何かしらのジョブ実行と連携できる、というケースも考えましたが、だったらテストコードも最初からWebDriverでテスコード書いたほうがいい気がします。）

まとめ

さて、微妙にぼやきが出てしまったところで、最後にまとめます。

• SideeXはメンテが期待できなさげ
• ローカルで完結するキャプチャ＆リプレイにはSelenium IDEがよさげ
• WebDriverテストコード生成にはKatalon Recorderがよさげ
• Selenium SIDE Runnerのいいユースケース誰か教えて

以上です。

それではみなさん、メリークリスマス！！！