Dreamland-夢と想いと小さな工夫

自分の中にある想いだったり日々の工夫だったりをすこしずつ書いていこうかなぁって思ってます。

仕様記述やUIにとらわれずにテストを考えるために使っている図

この記事は、ソフトウェアテストの小ネタ Advent Calendar 2019 の参加投稿です。
https://qiita.com/advent-calendar/2019/software-testing-koneta

昨日は、全部テストをやってって言われてまともにやったら死んじゃうから早い段階でちゃんと開発者にフィードバックしながら必要なテストを考えましょうという話(と受け取りましたがそういうつもりじゃなかったらすみません;)。大事ですね。今日のこの記事は、もうすこし視野を広げて仕様にとらわれずに考えるための小さな工夫です。

(今年最初の投稿・・・やばいです。超絶やばい。来年はちゃんとアウトプットしよう。)

テストを考えるときに、たいていの人は仕様書から考えると思うんです。例えば3色ボールペンを使って読み解くところから始めるとか、そういうケースは多いんじゃないかな?最近は印刷制限がある職場も多いから、3色ボールペンが使えなくて困っている人もいるかもしれないですね。
私は普段どうしているかというと、たいてい読みながらテキストにいろいろ書いていきます。自分なりの解釈とか、気づいたこととか、感じたことととか・・・ひとりで考えるときはこれで十分だったりします。頭の中でイメージできちゃうから。
だけど誰かに見せても文章だと伝わりにくいなぁと感じています。(そもそも私は話し言葉で書くから「人様にお見せできません;」となるんですけどね・・・笑)

図にすることで、興味を持ってもらいやすくなります。状態遷移図を作成したり、ユースケース図を作成したり、シーケンス図を作成したり・・・必要だと思ったら作成しています。

だけど、慣れていない人には一般的な図はちょっとハードルが高い。うん、高いんですよ・・・図のお作法を気にしちゃうこともあって、これでいいのかな?っていう雑念が入っちゃう。考えたいのはテストなんですよ。なのに違うことが気になっちゃう。
・・・もったいなーい;もっと気軽に図を描きたい!

私はネットワークサービスのテストをしてきたので、いつも「サーバーとクライアントとネットワーク」を意識していましたし、テスト環境も自分で構築する必要があったので、通信のシーケンス図以外に環境図をつくることがありました。その結果、人に説明するときに、登場するモノを挙げて図にすることが何度かありました。このシステムってどんな環境なんだっけ?を把握するためなので、即興で描くときは登場するモノを雑に□で描いちゃう。伝わりゃいいんです伝われば。
こんな感じで図を描いて、そこに、観点を挙げていっちゃうの。これはCacooできれいに描いたけれど、考えるときはノートに描くし、みんなで考えるときはホワイトボードや模造紙に描く。実際はかなーり雑に描く!f:id:shiozi:20191215011154p:plain
イメージできることが目的なので、雑で構わないし、
いろいろメモしたり付箋を貼ったりできるようにレイアウトするのがおすすめです。

最初はクライアントとサーバーとネットワークだけのシンプルなものでしたが、そのうち、データベースも考慮したほうがよいね、クライアントもUIと内部を考慮したほうがよいね、マイクロサービスだとサーバー複数あるね、自社のサーバーだけでなく、外部とも連携するよね、デバイスもあるよね、IoT機器もあるよね・・・そして人の思考も気にしたほうがよいね・・・ということで図もだんだんと登場するモノが増えていきました。

もう一つ、こちらは入出力と処理などの仕組みを把握してテストを考えるときに使います。数年前に勉強会でファイルシステムのテストを考えたときのやつ。

f:id:shiozi:20191215012107j:plain
ちょっと進化させたテンプレート。(ね、雑でしょ。笑)

f:id:shiozi:20191215012153j:plain


私が関わってきたテスターの方々は、真っ先に仕様書とUIに目がいってしまい、システムの全体像をイメージしないでテストを考えるケースが多いんです。なので、テスト設計のサポートをする機会があると、まず全体像をイメージさせるためにこの図を使うことがあります。この図を使うと、ちゃんと振る舞いを考慮するようになって、仕様書の枠にとらわれずに必要なことが出せるんですよね・・・

ドキュメントから観点だすよりもイメージしやすいので、いいなーと思ったらぜひ試してみてください。

マニュアルテストでテストケースとテスト実行を管理するときのお困りごと

ソフトウェアテスト #2 Advent Calendar 2018 への参加投稿です。

ソフトウェアテスト #2 Advent Calendar 2018 - Qiita

昨日はJaSST東海に関する記事でしたね。私も参加しましたが、基調講演も特別講演もアジャイル井戸端会議もどれも予想以上に楽しんできました♪

 

さて本題。
11月2日にテスト管理を語る夕べというものが開催されました。

テスト管理を語る夕べ - connpass

テストケースのデータモデルについて語られましたが、ところで、なんでテストケースのデータモデルを考えているんでしょう?
この答えは様々だと思いますが、私の考えとしては、テストケースやテスト実行結果の管理をするうえで起こる困りごとに対して、解決策を導くための準備だと思っています。
みなさんはテストケース、あるいはテストの実行結果を管理するときに困っていることはありますか?この記事では、私が経験してきた現場のありがちなテストケースやテスト実行の項目と、その項目に対して困っていることを列挙してみます。自動実行だとテストスクリプトの管理やテスト実行の管理が異なるので、とりあえずここではマニュアルテストに絞り込みます。また、主にスプレッドシートタイプのファイルで管理するケースで考えてみます。

 まずは項目について。現場だったりネット上でよく見かけるテストケースと称している成果物を見ると、だいたいこんな項目があるかなーと思っています。テストケースとテスト実行結果が一体となることが多いかな。。。

 

[手順が含まれたテストケースに関する項目]

・テストケースID

・いわゆるテスト観点と呼ばれるようなキーワードや条件の記載
    (「大中小項目」形式がやはり多いかなぁ・・・)

・仕様書の記載箇所

・テストケース名

・事前条件 (「前提条件」と記載されることがよくある)

・テスト手順

・期待結果

・テストケースに対する備考

 

[テストの実行に関する項目]

・テスト実行年月日

・テスト実行時のテスト対象バージョン

・テスト実行者

・テスト実行結果

・インシデントチケットID

・テスト実行に対する備考


上記の項目があるという前提で、このテストケースを運用するときに困ることを挙げてみます。

[テストケースそのものに対する困りごと]

  • テスト観点と呼ばれるようなキーワードや条件の記載項目に対して
    →大中小項目のように、観点に該当するキーワードを入れたいが、シートで管理しようとすると、カラム単位の粒度がバラバラになったり整理ができなくなるし、ツリーで管理しようとすると、重複したりどこにぶら下げてよいのかわからなくなることがある
    →とにかく再利用の仕組みをつくるのが難しい(コピペ祭りになる)
  • 仕様の記載箇所に対して
    →どのような記載をしても変更が起こるため、そのうち追従できなくなる
  • テストケース名に対して
    →テストケース名からテスト要件が理解できないことがある、もしくは、テスト要件とテストケースの関係を見せようとしてカラムが増えすぎてメンテナンスがしにくくなる
    →そもそもテストケース名をつける意図が共有されず、適当な名前をつけてしまい、ケース名の存在価値がなくなる
  • 事前条件・テスト手順・期待結果に対して
    →変更が入ったときの記載ルールが定まらない
     →そして訂正箇所や変更前を残そうとして見た目も可読性も悪くなる
     (以下のような変更が入るため、それぞれ対応しなければならない)
     ・テストの事前条件を一時的に変更する必要がある
     ・テスト手順を一時的に変更する必要がある
     ・期待結果を一時的に変更する必要がある(政治上の都合とか)
     ・テストの事前条件を恒久的に変更する必要がある
     ・テスト手順を恒久的に変更する必要がある
     ・期待結果を恒久的に変更する必要がある(仕様変更とか)
    →ケース展開後なので修正箇所が飛び散っていて反映させるのが大変
    →マニュアルテストだと、データ駆動やキーワード駆動ができなくてコピペ祭りになる

 

[テスト実行時に関する困りごと]

  • 実行に関する項目全体に対して
    →実行結果をケースと分離して管理することができない
    (毎日結果データがファイル単位で増えていくことがありますね・・・)
  • インシデントチケットIDに対して
    →実行結果からチケットにアクセスするのは容易だが、チケットから実行結果にアクセスすることが容易ではない
    →実行結果に複数のチケットが関連すると、修正確認の管理が難しくなる
  • テスト結果に対して
    →テストケース単位で、どの段階でステータスが変わったのかをたどるのが面倒になる

 

[共通する困りごと]

  • 困りごとに対応するときに、なんでもかんでも「備考」に逃げる!!!(笑)

 


これらの問題に対して「これなら解決できる」という唯一の案があるわけではないです。具体的に言えば「テスト管理ツールを使えばよい」という簡単なものではなく、上記の問題にすべて対応可能なツールをつくったとしても、導入にあたってルールを決めたり、カスタマイズを行ったりする必要はあります。そして、どのような解決策をとるにしても、データモデルを意識しているほうが、より納得がいく解決策を見つけやすくなります。私はデータモデルの作成に慣れていないので、うまく作成できるようになれたらいいな、とは思っています・・・でもまだ学べていないです;あぁぁ;
テストケースの管理って難しいしめんどくさいです(笑)。だけどどうやったら最適解を出せるかなぁってツールと格闘するのは結構楽しいなぁって思っています。

時刻の境界値に対するUI入力値

11月22日に長崎美術館にてJaSST九州が開催されました。

JaSSTソフトウェアテストシンポジウム-JaSST'18 Kyushu

ソフトウェアテストの活動の中で基本となる技術と技術を活用するために必要なことについて学ぶ一日になりました。こういうテーマはスルメ的な魅力があって、誰もがそれぞれ異なる学びを得ることができるんですよね。

 

で、午後の境界値ワークショップのときに、ちょっとした気付きをいただきました。

お題が会議室利用可否判定のシステムで、
・時刻を入力すると会議室の利用可否を判定する
・会議室の利用可能時間は9:00から23:00までとする
このときの境界値を考える演習がありました。

この演習の解説で、一般的には「9:00〜10:00」「10:00〜11:00」という書き方をする。という話がありました。だから23:00は含むのか?という疑問が出るという話だったのですが・・・

そうか、たしかに。終了時刻をわざわざ9:59とは書かない。10:00って書きたい。
もしも9:59と書けっていわれたら、面倒だなもう#って思う。

でも普段テストを考えている立場としては、終了時刻10:00という文言に対して、もやっとしてしまう。なんで9:59じゃないんだろう?って思う。

たしかにスケジュール管理機能を持つシステムのUIは、たいてい終了時刻は次の開始時刻とかぶるような書き方になっている。
つまり、UI上ではそういう刻みをしないで、裏で終了時刻ならば1秒引くという対応をしているんだ。(たとえばレコーダーの予約録画とかだと前の録画終了処理と次の録画準備処理で20秒前に終了したりするのだけれど、そういう裏処理があるかどうかにかかわらず終了時刻の扱いはどうするのがよいか考える必要があるのね。)

仮に分刻みで設定できるとしたら、勝手に1秒引かれることのほうが不都合になるかもしれない。だけど会議室予約などのスケジュールなら15分単位とかになりますよね。


テストを考える頭で仕様を考えると、境界値を意識しすぎて、UI入力を面倒なことにしそうだなぁ。と感じたのでした。そして入力値どおりにシステムに設定することが必ずしも正ではないよな、ということも改めて感じました。

ConcernとAspectとKnowledgeの関係

実は内容はInSTAからそんなに経っていない頃に書いたのですが、諸事情で塩漬けになっていました;あぁぁ;

4月に開催されたICST本会議に加えて、InSTAというテストアーキテクチャに関するワークショップに参加しました。どちらかというとコチラが目当てでした。ここに今回智美塾のメンバーで投稿したから。InSTAは初回以来でしたが、だいーぶ国際色豊かになりましたね。。。

どんな内容の論文を発表してきたかの詳細は↓コチラをどうぞ!
http://aster.or.jp/activities/investigation/insta2018.html

今回論文というカタチにはしましたが、メンバーそれぞれにそれぞれの考えがあり、すべて一致しているわけではないので、ここでは、私が考えていることを書こうと思います。あくまで「私はこう考えている」という話です。

 

背景としてさらっと論文の概要を書くと、開発者が作成するモデル(仕様)は、プロダクトをつくるための情報にフォーカスして作成されるため、テストに必要な情報や品質を確保するために必要な情報というものは抜けがちになる。テストエンジニアはその不足している部分を「気がかり」を抱くことで補っていく。この「気がかり」という概念(Test RequirementともTest ObjevtiveともTest Caseとも違う、それらを導き出すための要素)について、UTPではまだ定義が無いので、UTPの拡張として定義や記法を提案するよ、という内容です。
私達はこの「気がかり」を「Concern」としました。だから「TestConcern」という用語を提案したのですが、査読者全員から「それはTestAspectなんじゃないの??」という突っ込みを入れられ、最終的には「TestAspect」と呼ぶことにしました。

まぁ用語自体はどっちでもいいやと個人的には思っています。
だけど、ConcernとAspectは一緒か?と言われると、それは違うよなぁ、という考えを私は持っています。なのでConcernかAspectか?!という議論のときに、自分はこう考えるな、という絵を描きました。ただ、もうカメラレディ提出期限間近で今この図をだして物議をかもすのも適切じゃないな、と思って自分の中にしまっておいたのでした。
最終的には発表者の中岫さんが似たような図を作成してくれたので、そんなに認識はずれていないなぁと安心しました。

で、ここでは、私が考えた図について話そうと思います。

f:id:shiozi:20180430222705p:plain

私としては、やはり「気がかり」は「Concern」だと思います。人の思考により生じるもの。
Aspectは、テスト対象(開発モデル)に対するひとつの意図を持った側面だと考えています。

Concernが先かAspectが先か?ということについては、私はどちらもあると思っています。ConcernからAspectをSetすることもあれば、AspectをSetしたときにそのAspectを見てConcernを抱くこともある。だからConcernとAspectは一致するわけではない。最終的にはAspectの属性(かな?)として含まれるのだと思うけれど、テスト分析をしているときは一致しないなぁと考えます。
そしてもうひとつキーになる要素があります。それはKnowledgeです。テストエンジニアが持っている情報。私はConcernとAspectとKnowledgeの3つがあって初めてテストエンジニアはテストを考えることができるし、テストスイートアーキテクチャを作成するための要素を揃えたり選択したりすることができる、と考えています。

ここまで考えて、実はこれって私が昨年盛岡で話してきたことなんだよなぁって思いました。
勘と経験っていうけどね、つまり勘がConcernで経験がKnowledgeなんじゃないかなぁ?経験って結局本人の中で情報が蓄積されるってことでしょ?という話をしたつもり。でもってそれ単体ではダメで、上手く情報をつなげて活用することが必要だよ(側面も適切に定めなきゃだめだし「気がかり」を抱けなきゃだめだよ)、と。

 

あ、そうそう。
今年も盛岡勉強会開催されるそうです。根本さんによる探索的テストの講座&ワークは、実際に探索的テスト体験ができる本格的な内容で、正直2000円はめっちゃ安いです。盛岡近辺のエンジニアさんや盛岡に行ってみたいエンジニアさんに是非おすすめです♪ 詳しくは↓こちらをどうぞ。

第4回 盛岡ソフトウェアテスト勉強会 2018年11月17日(岩手県) - こくちーずプロ(告知'sプロ)

状態というと何を思い浮かべるのか

先週、組み込み系と業務システム系との違いについて考える機会がありました。・・・といっても先週だけでなくここ最近組み込み系で育ってきた人が業務システムの世界の人と話をすると、なんかよくわからないのだけれども気にしているところがズレている、意識の違いを感じるというのを体験する機会があり・・・それは何なんだろう?と思っていたところにTwitterのやりとりでコメントいただいて、自分でも悶々と考えて、あぁなるほどこういうことなんだなぁ、と思ったことを図にしてみました。

f:id:shiozi:20180722221115p:plain

組み込み系の場合、状態というと「予約録画待機中」「録画中」「再生中」のように、処理そのものに着目するのです。トリガーとなるイベントによって処理が変わるイメージ。テストにおいても処理とイベントとタイミングを気にすることが多いです。

一方の業務システム系では、処理そのものにはあまり関心がなく、データに着目しています。そのデータは(業務の中で)いまどんな状態なのか?申請中なのか?利用中なのか?利用停止中なのか?・・・だからテストにおいてもデータのバリエーションを意識する。必要なデータを準備しなきゃという話が出る。

そしてもうひとつ、独立したアプリだったり、組み込みだろうがシステムだろうがUIだけを見てテストをする人は状態としてなにを意識するかというと、やはり画面なんですよね。いまどんな画面が表示されているのか?操作をすることによってどの画面に遷移するのか?・・・画面に着目する場合は、入力や操作というところを意識する。入力の仕方はキーボード入力なのかコピペなのか?操作はマウスなのかタッチパッドなのかキーボードなのか?・・・という感じ。

 

もちろん、組み込み系だってデータを意識する必要はあるし、業務システム系だってアプリだって処理を意識する必要はある。入力値や入力方法なども意識する必要がある。

だけど、どこを重点的に考えるのか?ということには差がでるもんだなぁと思うし、とくに「状態」という言葉に対する考え方には違いがあるよなぁ、と感じたのでした。

ICST 2018に行ってきた!

4月に開催されたICST(IEEE International Conference on Software Testing)に参加してきました。
http://www.es.mdh.se/icst2018/
スウェーデンのヴェステロースというところで開催されました。北欧は町並みが素敵で、食事もおいしくて、ホテルの朝食は乳製品天国で、ホントに満喫してきました・・・ってこれじゃ観光のレポートじゃん(笑)

 

基調講演・パネルについては今でも動画で見ることができます。素晴らしい!
http://www.es.mdh.se/icst2018/live/

とにかく自動化は当たり前だし、それはテストレベルをしっかり考慮したうえでの話が当たり前だし、そこからさらに効果的なテストにするにはどうしたらいいんだろう?楽しくないことをやらずにすむにはどうしたらいいんだろう?って考えているのが世界的な動向なんだなって感じました。私の周りはまだスタートラインに立っていないから、解決しなきゃいけない課題が異なるなぁって感じ。

投稿されているPaperも自動化前提な内容が多くて、自動化を行ったうえでの問題点の解決や、ツールを使ってこういう工夫をした!という事例紹介のようなものが多かったかな、という印象です。もっとも私がIndustry Trackを好んで聴講したからというのもあります。Search Based Approachesとか、Mutationとかは、私の守備範囲ではないので・・・orz
個人的に興味深かったのはVisual Testingのセッションでした。私があまりに無知というのもありますが(;・∀・)あー!たしかに表示崩れの問題とかをツールで解決したいと思うし、Sikuliとかは画像認識を利用して操作を自動化するんじゃなくて、画像認識を利用して見た目の問題を検出するために使うんだなっていう気づきを得られました。いやはや気づいたときは恥ずかしかった;

ICSTは昨年東京で開催されたので、今回が2回目でした。
前回も予習不足ではありましたが、日本語に頼りすぎていたなぁと感じました。
今回は「すこしでも理解しなきゃ!」という思いもあり、日本語には絶対に頼れないのもあり、それが多少は効果的にはたらいた気がします。ただやはりPaperは1週間前には見たかったなぁぁ・・・スウェーデンに行ってから見ることができたので、当日Google翻訳に頼りながりPaperも見てスライドも見て・・・という状態になってしまいました。

そんな中で、大学に通ったこともなく、論文なんて共同執筆で2回しか関わったことがなく、論文に馴染みが無いうえに英語力も残念な私が聴講するために試したこと。

  • Paperはまず「CONCLUSION」を読んでみる
  • 概要を把握したら、スライドを見て発表を出来る限り聴き取ろうとする

まずはAbstractを読むとよいのかな?と思ったのですが、Conclusionの記述を読んだほうが、なにをしたくてどうなったのか?が把握しやすいと思いました。なんとなーくでも把握しておいたら、発表を聴くことで自分の中でこういうことを言いたいんだなってつながりやすくなった気がします。。。まぁ英語力がアレなんで私が正しく理解できているかの保証はないのですが(;・∀・)それでもゼロより+になっているからいいかなって♪

あとはもう、ただひたすらに、英語がもっと聞き取れて、もっと話せて、自分の言いたいことを言えるようになりたいと思いました。自分が話したいことを話せるというのが一番の課題だなぁ、と。特に国際カンファレンスだと、聴講者も含めてその場全体でディスカッションするし、休憩のときも意見交換が活発だし、みなさん気軽に話しかけてくださるので、その楽しい雰囲気に入っていけないのはとても残念だなぁと思いました。英語を日常的に訓練していくことはこれからも続けていこうと思いますが、日本で日常的に英会話ができるのが本当はいいんだよなぁと思っています。時間を優先するとどうしても日本語になってしまう。だから日本語と英語をまぜたとしてもお互い馬鹿にしないことから始めないといけないのかもしれません。気軽に一言だけでも英語で話すということがしたいなぁ。

TOCfEシンポジウムに参加してみました

昨日はTOCfEシンポジウムに参加していました。
「教育のための」ってつきますが、対象は教育者に限らないです。
むしろ日本は教育関係者より企業人のほうが圧倒的に多い・・・笑
(それはそれでいかがなものかとも思ったりはしますがぁぁ・・・
教育関係の方々にも興味をもってほしいなぁと思います。)

第7回教育のためのTOCシンポジウム
http://tocforeducation.org/info/symposium-7/

 

基調講演はMarta Piernikowska-Hewelt さん。
ポーランドで教師・カウンセラーとして10年にわたり重度の脳性麻痺自閉症などの症状や特性を抱えるの子ども達とのコニュニケーションを改善するためにTOCfEを活用していて、今回は事例を交えて普段の活動についてのお話が聴けました。

何らかの特性によってコミュニケーションがうまくできない方々に対して、お互い誤解したまま諦めてしまうのではなく、その人の可能な手段で時間を設けてその人の考えていることを見せてもらうことの大切さが伝わる素敵な内容だったと思います。

懇親会のときにMartaさんに質問ができる機会をいただけたので、「ポーランドの学校では、世間で健常者と呼ばれる子どもたちと障害者と呼ばれる子どもたちが半分づつクラスに存在している状態で授業を受けている」という現状に対して、日本ではそのようなことが実現できていないので、なぜうまく実現できたのか?を質問してみました。
ポーランドでも以前は日本のように普通クラスと特別クラスとで分離していたそうです。そこから小さい規模で活動していき、「子どもの頃から様々な子どもと一緒に学ぶほうがよい」ということを親も子どもも実感するようになったので、現状に違和感を感じなくなったそうです。なぜそのほうがよいと感じるようになったかについては、いずれにせよ子どもたちが大人になり働くようにれば、そこには健常者も障害者も様々な人が一緒に存在していて、一緒に仕事をしていく必要がある。それならば子どもの頃から同じ状態で学んでいくほうがよい。例えば数学の進みが悪くなるとかいうことがあるかもしれない。だけど社会で生きていくために必要なこととしては学校の教科で得ることなんて一部にすぎない。学校の教科よりも様々な人との関わりのほうが学びは大きい。ということを大人も子どもも実感したからだそうです。
そして、短い期間で変化できたわけではなく、現状になるまでには20年かかったそうです。諦めないことって本当に大事だと思いました。

午後の事例発表も家庭や職場や恋愛など(笑)様々な取り組みを聴けて面白かったです。
親子で発表することもあるのがこのシンポジウムの魅力ですね。

あとはワークショップが何人いても楽しめるし学べるし無理やり知らない人と話せるしという仕掛けが入っていて面白かったです。私は暑さ負けしていたから参加できなかったけれども(;・∀・)

今の日本の学校教育にTOCfEを導入するためにはトップを動かさないといけないから簡単には実現できないということを前夜に若林先生から伺いました。だったら学校以外の場で子どもたちに体験してもらうのがよいのだろうなぁと思いました。家庭でも使えるし宿題をするときにも使えるので、親世代に普及させていくのがよさそう。個人的には企業研修に導入したらいいのになぁって思っています。うまく考えられないことで損しているよなぁということは職場でもたくさん起こっているし・・・

大人も子どももいまより上手く考えられるようになって納得のいく選択ができるようになるといいなぁと思うし、自分も鍛えていきたいしサポートしていきたいと思っています。