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

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

よいものを目指すということ

今年もあと少しになりましたね・・・

相変わらずちょっとしたことというよりもポエムな感じですが、今年のふりかえり的につらつらと書いてみます。

昨年秋に、来年になったら仕様策定の仕事をやってみる?という話がありまして、そのために要件定義に関する勉強を簡単にしておいてねって言われまして・・・

今年の春に、要件定義の修行をしたいんですけど、なんかできることありますか?って訪ねた別のかたから降ってきた案件に乗った結果、

某管理システムの企画および導入支援(半分営業)という立場になりました(爆)
いや、修行にはなっている?し、お客様の声を直接伺う立場にもなっているし、間違ってはいないと思う。だけどプロダクト開発よりもサービス開発の域まで入っているし、まったく知らない業界だし、ちょっと待って待って!みたいなことがたくさんありました。

そんな中で感じたことを書こうと思います。

これまでは、プロダクト開発に関わっていて、それもQAや開発支援テスターで、更に社員ではなくパートナーとして関わっていました。
単にバグを見つけるとか出荷可能かどうかの確認という作業にとどまらず、よいプロダクトになること、プロジェクトとして嬉しくなるように振る舞うことを心がけていました。目指していたのはよいプロジェクトとよいプロダクトだったと思っています。

それが今年の活動を通して、狭い視野でしか見ていなかったんだな、と感じるようになりました。

よいプロダクトをつくったとしても、利用者がうまく使ってくれなかったら、そのプロダクトの価値は下がってしまいます。よいプロダクトの価値をできる限り最大限にすることを目指してうまく使ってもらうようにすることが必要で、そこはマニュアルで補えることもあるかもしれないし、支援サービスとして提供することもある。サービスのデザインが必要で、サービスの質が求められるんだな、というのを肌で実感しました。

さらに、よいプロダクトをうまく使ってもらえるようにしても、売れなきゃ意味が無いんだな、ということも実感しました。売れるために何を実装すべきなのか?それはプロダクトなのかサービスなのか?あるいはプロモーションなのか?・・・ここまで来ると質なのかなんなのかよくわからないけれども、ともかく、プロダクトとしては、売れて初めて価値が出せるんじゃないのかなって思ったのでした。よいものを目指すっていうのは、売れて価値を届けられるものを目指すってことなんじゃないかな。そこにたどり着くまでは、様々な立場の人たちの協力によるものなんだなって。そして、全体を俯瞰する立場だったり機会だったりが必要なんじゃないかな。

もちろん、ソフトウェアテスターとしてプロダクトの一部と向き合うのはとても大事なことだと思います。そういう役割は必要です。ただ、プロダクト開発の中だけで生きていると見えない世界っていうのがあって、それは、できるだけ積極的に見に行くほうがいいんだろうな、見せられるなら見せたほうがいいんだろうな、と思ったのでした。現実としては組織が異なると見せられないこともあるから、自分から違う世界を見に行く機会を掴むほうがよいかもしれません。

テストフレームをつくってみた

最近、スクラムチームの中でテストをする機会があり、テスト要件を挙げて、ハイレベルのテストケースを挙げて、あとは探索的にテストをするという流れを何度か経験しました。自分にとってやりやすいこととか、流れがよくないというかつながっていないところがあることに気づく、よい機会になりました。

気づきとして、テスト要件を挙げることと、いわゆる観点に該当するものを挙げることはできるのですが、それがどう関連するのか、というところがうまく見せられないことがわかりました。だから、「これで十分なのかがわからない」と言われることが多かったです。。。テスト要件だとざっくりしすぎで、テスト要件に対して観点を見せるのはなかなか難しいなぁと。。。(テスト要件単位で観点並べるのをさぼったからっていうのはわかっているんですけれど、並べたところでテストケースがイメージできる状態にならないとか。。。)

それとは別に、そういえば、テスコンチュートリアルで紹介されている「テストフレーム」をつくる演習ってあまり聞かないなぁと思い、じゃぁテストフレームを作る演習を考えるといいのかもーと考えまして・・・まずは自分で明示的にテストフレームをつくってみるかぁ・・・と思ったのでした。

テストフレーム:テストケースの構造をテスト観点で表したもの
(チュートリアル資料47ページ参照)
http://aster.or.jp/business/contest/doc/2020_OPEN_V1.0.0.pdf

 

やってみた結果、どうもテストフレームはテスト要件をまとめる過程でつくり、テスト要件単位で詳細に落とし込んでいくのがよさそう、という見解になりました。

テストフレームを形成する観点を用意する必要があるので、観点の列挙も含めると、こんなプロセスになるなぁと・・・

f:id:shiozi:20200308153040p:plain

テストフレームを用いてテスト要求分析・テスト設計を行う

試しに、一般的なLogin処理を想定してテストフレームをつくってみました。

f:id:shiozi:20200308153339p:plain

Login処理のテストフレーム

これをテスト要件ごとに展開してみました

f:id:shiozi:20200308153730p:plain
入力値に対してログイン可否を判定して判定結果を出す、というところをテストしたいときは、こうなるかな?と思いました。

一方、いろんな条件でログインに成功することを確認したいとき(組み合わせテストを想定している場合)は、↓のように変わってくるなぁと思いました。

f:id:shiozi:20200308153802p:plain

更に、エラーになる条件に対してエラーメッセージを表示することを確認したいのであれば、どこにエラーの条件があるかを洗い出して展開されます。この場合はServerの状態やNetworkの状態に注目がいくはず。

そして、テストアイテムを適切に設定する必要があることもわかってきました。テストアイテムの抽象度が高いと、テスト要件に落とし込んだときに必要ない(単一条件でも必要がない)観点が存在してしまう。そうなったらテストアイテムが適切ではないと疑ったほうがよさそうだな、と思いました。例えば画面単位でテストアイテムを設定すると、パーツが混ざっていることでごちゃごちゃしたテストフレームが出来上がってしまいます。他には、UIの処理とシステムの処理は分けたほうがよい、など。

自分の頭の中で処理していることって相当あるんだなぁというのが正直な感想です。
これを都度やるのは面倒臭いなぁ・・・でもツールを活用することで面倒臭さは解消されるかもしれないなぁ・・・と思うので、ツールを使ってうまくできないか試していこうと思います。

仕様記述や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だけを見てテストをする人は状態としてなにを意識するかというと、やはり画面なんですよね。いまどんな画面が表示されているのか?操作をすることによってどの画面に遷移するのか?・・・画面に着目する場合は、入力や操作というところを意識する。入力の仕方はキーボード入力なのかコピペなのか?操作はマウスなのかタッチパッドなのかキーボードなのか?・・・という感じ。

 

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

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