タイトル未定

品質や趣味について語りたいブログ

探索的テストで やっていること・意識していること

 

どうも、halspringです。時というのは早いもので とうとう2年目になりました。 

こうして楽しく仕事したりテストについて考えたり発信できるのは読んでくださっているみなさまのおかげです。いつもありがとうございます。

 

selenium confが迫っているのに目が冴えてしまってこんなものを書いていますが、果して起きれるのでしょうか。

（追記 : 起きれました。）

 

さて、今回は探索的テストについて書いてみます。

Webサービスを扱う会社の経験しかないため、現場によってここで述べる内容に合う合わない等あるかもしれませんがご容赦下さい。

 

毎度の如く書いておりますが、

あくまで個人的な見解であり、独自の解釈や考えを述べておりますので、鵜呑みにせず 調べたり試したり自身の経験・考えと比較して見てください。

興味を持っていただき、テストを学ぶきっかけとなれれば幸いです。

 

 

 

探索的テストとは

 探索的テストとはテストのスタイルのひとつで、

テストケースを作らず、状況に応じて学習を繰り返し 頭の中でテスト設計をしながらテストを行います。(簡単なドキュメントは用意したりします。)

テストケースを起こさずに実施できるため、効率的にテストを行うことが可能です。

しかし、テストの再現性が低いことや、担当者によってテストの結果が変わること、マネジメントやスケジューリングが難しいといった特徴も挙げられます。

 

ここでの説明はこれくらいにしておきますが、

興味のある方、詳しく知りたい方のために 参考資料を置いておきます。

 

そして、ここだけは誤解せずに しっかりと使い分けてほしいのですが、

探索的テストはモンキーテストやアドホックテストではありません。

現場からは以上です。

 

どんな運用をしている？

「探索的テストはアジャイルに向いている」といった説明を目にします。

確かに効率的なテストでスピード感があり、その意見は正しいと感じています。

しかし、だからといってそれだけではダメで 個人的には他の基本的なテストプロセスに加えて実施するべきだと思っています。

 探索的テストは網羅性には乏しいですし、

先ほど挙げた『探索的テストってなんですか？ アジャイル時代のソフトウェアテスト』にも注意点として "探索的テストに100％頼らない" と述べられています。

 

 

どんな準備をしている？

自分が探索的テストを実施するときに準備するもの、あった方が良いと思うものは以下の通りです。

ディスプレイ

書くまでもないかもしれませんが、画面は多い方が良いです。

すぐにログを残せるようにしたり、仕様書を横で開いておいたりします。

 

バグの情報

ここまでのテストプロセスで見つかったバグのリストを用意して、事前に概要だけでもいいのですべて見ておきます。

件数が多い場合はざっと どの機能や画面にバグが多いかあたりをつけ、頭の片隅に入れておきます。

件数が少ない場合は拾える情報は可能な限り拾っておきます。

ここで軽くでも見ておくと、後々 テストをしているときに違和感に反応しやすくなると思います。

 

仕様書・テストオラクル

自分は用意したサブのディスプレイに表示させておきます。

手間をかけずに正しいかどうか比較できるもの（現行版の画面など）を用意しています。

違和感を感じたところや 仕様にそぐわない箇所、画面からはわかりにくい処理の多い箇所や複雑な箇所を確認しながらテストしています。

 

メモ

紙のメモをそばに置いています。

どこを見ようと思ったか、どんな違和感を感じたかのログ用です。

ログを残す方法として紙にこだわる必要はないので、残しやすい形で残せばよいと思います。

自分はちょっとしたリフレッシュがてらアナログを挟んでいます。

 

イヤホン

思考に集中するために、外部の音を遮断します。

音があると集中できない方はノイズキャンセリング機能だけを使うと良いと思います。自分はがっつり音楽をかけて精神を隔離しています。

また、イヤホンを着けていれば「あ、なんか話しかけるの忍びねぇな...」といった雰囲気が生まれるので急ぎの用事でない場合 話しかけられるリスクを軽減することができます。

 他にも思考を妨げる要因に通知が考えられますので、ブラウザのタブからslackを排除し、カレンダーには【BLOCK】とスケジュールを入れてしまいましょう。

 

お菓子・飲み物

テスト中、テスト後、疲れます。

また、「喉が渇いたな」という雑念で思考が止まることを避けるためにも、

そばに水分や糖分を確保しておきます。

 

 

どんな流れ？

探索的テストをどんな流れで行っているかを説明します。

自分の場合は、

事前にスケジュールに何か追加されないようにタスクをセットし、

調べたバグのリストとオラクルになる資料や情報を別のディスプレイに表示、

どんな箇所を見るか・どんな操作がしたいか 事前にまとめたメモをそばに置き、

イヤホンを装着、ガンガンに音楽を掛けたらようやく準備完了です。

 

探索的テストを開始してからは、

メモを基に試す内容をざっくりと決定し、操作をしていきます。

UIに違和感を感じたら大体はそこにバグが潜んでいるので、徹底的に叩きます。

オラクルと比較し、なにに違和感を感じたのか正体を探ります。

勘違いであってもメモに残し、その違和感は思い出せる状態にしておきます。(変だと感じた場所には仕様漏れがあったりするので)

 

基本的にはこの作業の繰り返しになるのですが、

「あ、今なんも考えてなかったな」とか「あれ、さっきと同じことやってるな」と思ったら一度中断しています。時間的・精神的・肉体的な限界を迎えています。

長時間ひたすらだらだらと続けていても効率的とは言えず むしろコスパが悪いので、

短期間しか持たなくても、その短期間を集中して成果を出せばいいんです。

 

休憩ついでに実施した内容や見つけたものをログにまとめ、頭を整理するとより良いと思います。

探索的テストは学習をしながら進めていくテストなので、このサイクルが大事だと思っています。

(ノリノリの状態が続いていればそのまま続けても良いと思いますが、キリがないので時間で終了のタイミングを決めておくと良いです。)

 

 

具体的にはどんなことしてる？

ログ

見つけたバグの内容は紙に書いています。

特別に理由があるわけではありません。

デスクにガラスペンだとか良いペンを置いているのですが、使うとモチベーション上がるからです。(紙のほうが関係性など書きやすいということもありますが)

  

XSS、SQLインジェクション、ファイルアップロードなどを簡単に

セキュリティを考慮して実装していたり、ツールなどを使って脆弱性診断を行ったりすることが一般的だと思いますが、万が一があったら嫌なので確認しています。

画像ファイルに偽装してスクリプトファイルをアップしようとしてみたりすると結構楽しいです。

 

異常値

変な文字列を入力できないかをよく見てます。

仕様書に書いてある内容はテストケースでカバーしているのですが、仕様書に書かれていないけれど必要なバリデーションがあるといったことは良くあることだと思います。

 

他にもフロントで制御するバリデーションだけでは怖いので、異常値を無理矢理POSTしたりもします。

漏れを見つけられる可能性があるほかにも、フロント側とサーバー側でバリデーションが違ったりすることもあるので、そのへんも見ちゃいます。

主に、どんな実装をしてるのか、自分ならどの辺の実装が面倒だと感じるかを考え、ミスをしそうな機能を狙います。

 

一度の文字列に大量の変な文字混ぜ過ぎると結果から分析しにくかったりもしますが、ひとつひとつやっても効率悪いですし 網羅的な内容はテストケースで見れば良いと思うので異常がないかだけ確認できればいいと思います。

 

ただ、どの文字列がダメだったか程度ならともかく、

一斉に送ってしまってどのフォームでエラー吐いたのかわからないくらいのやり過ぎは良くないです。基本は忘れずに。

 

連打

連続でPOSTリクエストが飛ぶと大体ろくなことになりません。

しっかりと制御されていることを確認しています。

裏でたくさん処理してそうなところも連打して意地悪したりもしますが、環境によってはほどほどにしましょう。

JSで実装されている部分なんかも連打のねらい目です。

 

矛盾する組み合わせとか

結構 意地悪です。

工数や優先度から多くの場合に実装されないであろう選択の組み合わせの制御部分を見ています。

これは正直「仕様です」の返事はわかっている上での行動で、

そうなることはわかっていて、それでも「この選択肢が選べちゃうのってあまり好ましくないのでは？」「ユーザーにとって親切ではないのでは？」と今後の検討リストに追加されたらいいなぁと想いを込めてやっています。

もちろん、自分はユーザビリティの専門家でも企画のプロフェッショナルでもありません。

フィードバックを送れる位置にいることを利用して個人の意見をぶつけているだけなので、ほどほどにしておきましょう。

 

paramをいじる

URLにparamが見えたら触ってみます。

検索用のクエリが入ることが多いと思いますが、変な文字入れるとなんらかの処理を失敗させたり 攻撃できたりすることもあるので、念入りに確かめています。 

 

その他

マインド

ゲームをしている感覚でテストしています。

 

ただ、ゲームにも色んなプレイスタイルがあると思います。

自分は開発者の作品への愛やこだわりを感じながら隅々まで見たいタイプです。

具体的には「村人とは台詞がループするまで会話する」「ループしても会話するキャラや内容によっては3回くらい粘る」「装備してって言われた装備をすぐ外す」「使ってって言われたアイテムをくれた人に使ってあげる」「装備全部外してパラメータ上 全裸の状態にしてみる」「ステージの最初は必ず後ろから見る」などなど

 

「こんなことしてもなにもないだろうなぁー...お？ おおおぉぉっ！！」ってなる楽しみ方です。

 

世界観を重視してるゲームに対してよくやっています。

ゲーム性を重視してるゲームに対しては、ルールをひとつ無視できたらどうなるのか考えて「バランスの取り方うまいなぁ」と考え込まれた仕様を感じるのが好きです。

 

といった具合に、開発者がどんなところまで考慮しているかを意識するようにしています。

プロダクトに込めた想いを感じ取りましょう。

 

この手の作りこみをゲームで体験したい方は、

  • undertale, deltarune
  • Doki Doki Literature Club!
  • OCTOPATH TRAVELER
  • シルフェイド幻想譚
  • The Stanley Parable

あたりをオススメします。

※かなり個人的な趣味嗜好が入っています

 

ログどこまで書くのか問題

自分の考えとしては、どんな意図でどんなテストをしたのか説明できなきゃいけないと思っています。

これは探索的テストに限った話でなく、すべてのテストにおいてです。

 

説明ができないなら、それは探索的テストの「頭の中でテスト設計をしながら」に反しています。

説明のできないテストをしてもほとんど意味はないと思いますし、その場で偶然バグが見つかっても 今後も同じようなバグを見つけられる可能性は低いと思います。

個人の裁量が大きいテストなので、誰にでもわかるように書く必要まではないと思いますが、自分で振り返れる程度のログは残すべきだと思います。

  

 

 

 

 おしまいおしまい

と、自分が思っている・意識している探索的テストについてを述べてみました。

長々と書いてしましましたが、ここまでお読みいただきありがとうございました。

みなさんの何かしらのきっかけになれれば幸いです。

 

気になる部分、異なるご意見があればコメントなりtwitterなりで反応を頂ければと思います。

それではselenium confに備えて寝る必要があるので、このあたりで失礼いたします。

 

 

クラシフィケーションツリーを自分がどう書いているのか手順を追って説明します

 

どうも、あと1週間ちょっとで新卒一年目の肩書きを剥奪されてしまうhalspringです。

好き勝手に無責任なことを言える免罪符ともお別れです。切ない。

 

 

さて、執筆現時点で3月27日、28日にJaSST’19 Tokyoがすぐ目の前に迫っています。初のJaSST参加でドキドキワクワク過ぎてテカテカしてます。

 

こんなニッチな記事を読んでいる方達であれば申し込んでいる方も多いかと思います。 

そして 申し込んだ方なら同じことを感じたと思います。

はい、そうですね、申し込みのパターンでクラシフィケーションツリーを書きたくなりましたね。

 

 

では早速ツリーを書いていきましょう。

どう考えてツリーを書いているのか なるべく思考の痕跡を残そうと思います。(途中で疲れていると思いますが どうか温かい目で...)

今回はツリーを作成するまでを中心に綴りますので テストケースの作り方については以前の記事や、 その記事で引用している井芹さんのスライドをご参照ください。

 

書いたことのない方は はじめに仕様だけ洗い出したセクションがありますので、是非一度ご自身でツリーを書いてみて比較して頂けると より一層お楽しみいただけるかもしれません。おそらくmaybe多分きっとあるいは。

 

 

あらかじめお断りしておきますが、

クラシフィケーションツリー法に関して論文を読んだり どこかで基礎からしっかりと学んだわけではないので、書き方や考え方に誤り(よく言えば我流)が含まれている恐れがあります。

この記事を鵜呑みにしてスタンダードだとは思わず、あくまで取っ掛かりとして頂ければ幸いです。

また、クラシフィケーションとたくさん書いてあると可読性が低下するかなと思ったので、因子という言葉とクラシフィケーションが混在していますが 目をつぶっていただければと思います。

 

最後に、明らかに誤っているところがあればご指摘いただければと思います。

(「大丈夫、あってるよ！」とか「参考になった！」などと言われると喜び悶えますのでそちらもよろしくどうぞ)

 

 

 

 

仕様把握

 

JaSST Tokyoの申し込みページから仕様を吸い上げます。

 

  • チケットには参加券、チュートリアル券、情報交換会の券がある
  • 参加券は27日、28日、2日券がある
  • いずれの参加券も事前申し込みすることで安くなる
  • 2日券の事前申し込みにはさらに早割が存在する
  • チュートリアル、情報交換会のみのチケット購入はできない
  • チュートリアルは27日の前半にセッションでは1,2、後半にセッション3,4があり、28日にセッション5がある
  • チュートリアルのセッションは時間帯の被るものは同時に申し込みできない
  • チュートリアル券も事前申し込みで安くなる
  • ただし、チュートリアルのセッション5の料金は変わらない
  • 情報交換会は事前申し込みでも当日券でも料金は変わらない

 

こんな感じですかね。

学生の招待制度については申し込みのフローが異なるため、ここでは考えないものとします。

 

 

それでは書いていきます。

 

 

 クラシフィケーションツリーを書いてみる

ドメイン

 

書き方に王道や正解があるのかわかりませんが、自分は根っこから書いていきます。

 

今回考えるのはJaSSTの申し込みなので、そのまま書きます。

 前回の記事でも書きましたが、せっかくsurface proとペンを買ったので活用しないといけない衝動に駆られているため手書きです。

f:id:halspring:20190325232554j:plain

 

 

ドメイン→クラシフィケーション

 

申し込めるものは、

になります。

 

そして、参加券こそ買う必要があるものの、チュートリアル券と情報交換会に関しては任意の購入になりますので、直交しています。

 

つまり、ドメインからクラシフィケーションが3つ伸ばせます。

 

f:id:halspring:20190325232721j:plain

 

 

参加券

 

では、購入が必須 かつ 一番複雑な参加券から考えていきます。

 

参加券には1日券と2日券があります。

ですので、参加券のクラシフィケーションから「1日券」「2日券」のクラスを伸ばします。

 

f:id:halspring:20190325232750j:plain

そして、1日券、2日券のどちらも、より詳細な購入方法の選択があります。

 

  • 27日の参加で事前購入
  • 27日の参加で当日券
  • 28日の参加で事前購入
  • 28日の参加で当日券
  • 27日、28日の2日参加で早割
  • 27日、28日の2日参加で事前購入
  • 27日、28日の2日参加で当日券

 

ここで、各参加券に共通する「購入のタイミング」という因子の候補が出現しました。

枝を伸ばす前にこの「購入のタイミング」を考えてます。

 

 

まず、この「購入のタイミング」という因子がどれほど他に影響を与えるのか。

出現したタイミングだけを見ても、「参加券」の末端に位置するであろう 上記の7つのクラス候補を下記の4つに減らすことができそうです。

  • 27日
  • 28日
  • 2日早割 有
  • 2日早割 無

 

 

 

「購入のタイミング」自体は { 事前, 当日}  の2クラスで済みそうなので、合計して見ても末端となるであろうクラスを1つ削減できるため、採用しても良い感じがします。

 

さて、「購入のタイミング」は他にも影響を与えるでしょうか。

仕様を見返すと、

とありますので、この因子を足すことでチュートリアル券のクラスも減らすことができそうですね。

そして、情報交換会には影響を与えないのでドメインから伸ばすクラシフィケーションとして採用して良いと言えます。

悪い影響を与えないことも採用するかどうかの判断に使います。

(この辺はうまく言語化できないのですが、ツリーを複雑にするくらいなら少しの冗長は妥協したほうが見やすくなると思ってます。) 

 

f:id:halspring:20190325232826j:plain

 

 

チュートリアル

 

次に「チュートリアル」です。

チュートリアルは1~5まで存在し そのうち4つは27日に開催され、さらに前半・後半でわかれています。

(スペースが足らなそうなのでずらします。これがデジタルのいいところですね。)

 

f:id:halspring:20190325232915j:plain

 

ここにチュートリアル5を追加したいです。

1~4と5を隔てているのは日付です。27日・28日で価格も変わりますので、もう一段大きいところに「日付」のクラシフィケーションを作るとちょうどよさそうです。

 

 

f:id:halspring:20190325232937j:plain

 

情報交換会

 

あとは「情報交換会」に参加するかしないかのクラスを作ればツリーの出来上がりです。

情報交換会は事前購入でも当日でも料金が変わらないので、そういった情報は頭の片隅に置いておくか、近くにメモしておくと良いです。

 

 

完成！！

 

完成したクラシフィケーションツリーがこちらです。

 

f:id:halspring:20190325232951j:plain

 

 

いいですね、かわいいですね。

 

あとはこのツリーからテストケースを作成していきます。

このツリーで料金を大きく変える因子は「購入日」で、「購入日」の影響を受ける因子は「参加券」と「チュートリアル」です。

また、「参加券」と「チュートリアル」には禁則が多く存在するため、この辺りからテストケースを作っていき 残りの因子は網羅基準を満たすように配置してください。

 

網羅基準を満たした後は「テストの手間が増えるので "なし" を選択する」「処理が複雑で心配なので入念に」など、定めたアプローチや設計者・ステークホルダーの考えで選択してください。

 

 

いかがでしょうか、これで少しでもクラシフィケーションツリーが書けそうな気がして頂ければ幸いです。

クラシフィケーションツリーを書くのは楽しいですが、どんな場面にでも適応できるわけではないので、頭の片隅でその存在を覚えておいて ここぞのタイミングで思い出してあげてください。

きっとツリーも喜びます。

 

 

それでは、よい Classification Tree Method Life を。

 

 

なぜ自分が開発したソフトウェアのテストをするのは面倒なのか？

テスト 開発 ポエム

どうも、そろそろ1年目を名乗れなくなりますhalspringです。

「要件定義、仕様策定、設計から開発まで関わったシステム」に対して「自分でテストを設計して実施する」機会があったので、そこで感じたことや考えたことを踏まえて いつものようなテストのエモい話を語ります。

 

  

テストは面倒くさい？

 

この記事を読んでいる方の立場にもよって意見も別れると思います。

貴方は開発を行う立場でしょうか？

貴方はテスト設計を行う立場でしょうか？

それとも、貴方はその両方でしょうか？

 

恐らくですが、テスト設計をメインに行う立場の人ほど「テストは面倒」とは思わないのではないでしょうか。

 

そして、開発をメインに行う立場の人ほど「テストは面倒」なのではないでしょうか。

 

 

なぜ開発を行う立場に近づくとテストが面倒に感じてしまうのか、今回はそれを考えてみました。

 

 

 

開発するとき無意識にしていること

 

開発経験のない方でもイメージできると思います。

開発者はエディタを開いてプルリクを出すまでに何をしているでしょうか？

(※ 完全に私個人の見解です )

 

 

仕様を確認して、

ロジックを考えて、

コードを書いて、

コーディング規約の確認もしつつ、

動作確認をして、

問題なさそうなのでgit commitして、

プルリクを送る

 

 

これだけでしょうか？

いいえ、違います。

 

 

 

書いたコードが1発で正しく動作するなんてことは、よほど仕様がシンプルでない限り稀です。

大抵はうまくいかず、修正をしながらコードを書き進めていきます。

 

 

コーディングして、

動作を確認、

不安なところは念入りに、

あぁここclass名変えたんだった...、

コードを直して動作確認、

バリデーションは大丈夫だろうか、

変なメールアドレス入力してみよう、

よし大丈夫だ、次だ次...

 

 

概ね、こんな感じではないでしょうか？

 

 

ところでこれ、ちょっと何かに似ています。

テストに詳しい方ならお気付きかもしれません、そうです探索的テストです。

 

 

修正に当たる部分をissueやバグ票に置き換えるとあまり違いがないようにも思えます。

つまり開発者は、開発中に探索的テストに近いことをしているのです。

 

 

 

 

テストの順番

 

実施するテストには順番があります。

もちろん、プロジェクトやテスト戦略によって色々ですが、個人や会社である程度の型は経験則としても持っているかと思います。

 

 

例えば「パフォーマンステストをしてからシステムテストをするつもりです」と言われたら、耳を疑いますよね？

「探索的テストをがっつり実施してからシステムテストの設計をしてください」と言われても、気乗りしませんよね？

(スモークテスト的に行うことはありますが) 

 

テストにはそれぞれ目的があり、適したタイミングで適した不具合を見つけることが大切です。

 

 

探索的テスト

ちなみに、探索的テストはいつ行うのが良いのでしょうか。

 

もちろん絶対的な正解はありませんが、

一般に、様々なテストを行った後に補完的に行われることが多いと思います。

 

JSTQB ALTAのシラバスにも、次のように記載があります。

優れた探索的テストは、しっかりと計画されており、相互作用的で創造的である。探索的テストは、テスト対象の システムに関するドキュメントをほとんど必要としないため、ドキュメントが存在しないか、他のテスト技法では適 切でない場合に使用することが多い。また、多くの場合、他のテストを補完したり、追加のテストケースを開発す るための基準を提供したりするために使用する。

 - 2012 年度版 Advanced Level シラバス日本語版 - テストアナリスト

 

 

先程も例として書きましたが、仕事でテストをしている方であれば、

「探索的テストをがっつり実施してからシステムテストの設計をしてください」と言われるとなんとなく二度手間感があったりして、面倒臭さが出てくると思います。

( 完全に私自身の見解です )

 

 

 ところでこの状況、なにかに似てませんか？

 

 

そうです、先程の開発しているときの話をしました。その開発の後にテストが待っています。

開発者はコーディングする中で探索的テストのようなテストケースのないテストを行っているため、その後にテスト設計を行うことが億劫に感じるのです。

( ※ 完全に私個人の見解です。 )

 

 

  

では、なぜ探索的テストの後のテスト設計は億劫なのでしょうか。

 

 

 

テスト設計時に無意識にしていること

開発するときにどう考えているかを勝手に考えてみましたが、

次はテスト設計するときにどう考えているか考えてみます。

※ くどいようですが完全に私個人の見解です。

 

 

弊チームのボスからとある話を聞き、考えてみたところ、

自分はテスト設計をするときに、ソフトウェアがどう実装されているかを考えていました。

 

 機能の追加や改修があれば、どんなロジックを追加する必要があって、どんなところが複雑になるかを考え、「こんな実装をしているだろう」のイメージを作っていました。

 

 

いくつかの「こうすれば実装できる」のイメージから、

・データのやり取りがありそうだから、ここをしっかり見ておきたい

・自分だったらこのあたりでミスしそう

といった感じにリスクや観点を考えています。

 

その後、改めて仕様書を見てリスクや観点を洗い出し、先程のリスクや観点を比較して漏れがないか考えます。

 

この記事を読んでいる皆様と自分で どんな流れでテスト設計をしているか異なるとは思いますが、共通して仕様書からいろいろと要素を拾い上げることはしているはずです。

 

 

ところで開発者は...

さて、時は実装前まで戻ります。

この記事のはじめにも書きました、コードを書く前に仕様を確認していますよね。

 

そうです、実装するまでに仕様書を読み込む必要があるわけです。

また、どう実装するか、そのロジックに至るまでも頭に叩き込んであるわけですね。

 

その後にもう一度 どう実装するか考えたり 仕様書を読み込んだりしたくないわけですよ！

 一度頭に入った情報は材料にもなりますがノイズにもなり得ます。(私個人としてはこのノイズがテスト設計のときに思考の妨げになっていました。)

 

 

探索的テスト後のテスト設計の二度手間感も同様でここに起因していると思います。

二度手間「感」ではなく、本当に二度手間を掛けているわけです。

 

 

 どうすれば面倒にならないのか

 本当はここで画期的な提案ができればよいのですが、残念ながらここはまだ模索中です。

 

 現状思いつくのはテスト駆動開発です。

 ユニットテストを設計・実装しながら開発を進めることで、探索的テストライクな部分がユニットテストに置換されます。

 

ユニットテストも結局仕様を把握する必要はありますが、テストの順番として違和感が軽減されます。

単体テスト・結合テストを実施してからシステムテストを行うのは至って自然です。

 

もちろん個人・チームでのやりやすいように 納得感を持って進めていただければ良いとは思いますし、面倒に感じてしまう理由も人それぞれだと思います。

テストが面倒に感じる方は是非一度こういった観点からアプローチをかけ、少しでもテストを好きになって頂けたらと思います。

 

学んでみると テストは世間で思われているほど悪いやつじゃない と思えるかもしれません。

クラシフィケーションツリー法の自由さを活用する

テスト テスト技法 クラシフィケーションツリー

アドベントカレンダー

本記事はソフトウェアテストの小ネタ Advent Calendar 2018 24日目の記事になります。

qiita.com

前日は とろさんの記事でした。沼ダイブ、自分ももっと頑張りたいです。

testertoro.hatenablog.com

ご挨拶

ご無沙汰しております。 クリスマス前日、皆様はいかがお過ごしでしょうか？

どうも、こたつで猫を抱えながら細々と記事を書いているhalspring(@halspring_qa)です。 昨日中古で買ったモンハンワールドに時間を溶かされています。

12月はWebQA、AI4SE、wacateと盛り沢山でした。 去年のこの時期、暗い顔しながら卒論を書いていたとは思えません、今はとても楽しいです。

語りたいこと

今回、クラシフィケーションツリー法について書いてみたいと思います。

はじめにお断りとして、高々テスト歴半年程度で書いておりますので、技法や用語、考え方等に誤りがある可能性がございます。 どうか温かい目で見て頂ければと思います。ご指摘等もお待ちしております。

クラシフィケーションツリー法に関して前知識を準備しておきたい方は井芹さんのこちらの資料をどうぞ。

www.slideshare.net


それでは、クリスマスツリーの代わりにクラシフィケーションツリーを眺めながら一緒に愉快なクリスマスイブを過ごしましょう。

クラシフィケーションツリー法

クラシフィケーションツリー法はテスト対象が持つ要素を木構造でモデリングするテスト設計技法です。 今回はクラシフィケーションツリー法を用いてテストケースを作っていく際に、クラシフィケーションツリー法の利点をどう活かすかを書いていきます。

文章のいいところは、何度クラシフィケーションツリーと言っても噛むことがないところですね。つい必要以上に何度でも繰り返しちゃいます。

直交表との違い

テストケースを作成するフェーズになると、直交表と同じでは？と感じることがあるかと思います。 直交表では、主に2因子間の水準組み合わせを網羅するように使われています。ちなみに3因子間の網羅でも使えるそうです。

さて、この直交表のメリットは、組み合わせテストにおけるテストケース数の削減と各水準の組み合わせが均一に表れるところにあります。

この記事で語りたいクラシフィケーションツリー法のメリットは、後者の各水準の組み合わせ均一に表れるという縛りがないことにあります。 (wacate 2018冬にて中村さんが口頭でおっしゃっていて「ハッ！」となりました。ありがとうございます。解釈が間違っていたら申し訳ないです...)

クラシフィケーションツリー法のメリット

それでは、「各水準の組み合わせ均一に表れるという縛りがない」とはどういうことか説明したいと思います。


まず前提として、組み合わせを考える際にすべての水準の重要度や使用頻度が等しいことは稀であると思っています。(この前提が共感できなければ、おそらくこの記事で伝えたい内容は入ってこないかと思います...)
相互に作用する組み合わせと、仕様上独立している組み合わせを同様の比重でテストするだけで十分か？という観点で実施をします。 (もちろん業務であれば、要件としてどれくらい網羅するかの基準はあるかと思いますので、状況に応じて考えて頂ければと思います。)


実際に例を見ながら説明していきたいと思います。

テストケース作成の例

問題

テスト界隈ではそこそこメジャーらしい"ラーメン"をテーマに問題を作ります。

「あなたはラーメン屋めぐりにハマっています。あなたは検証が大好きなので、訪れるラーメン屋を見切るまで通い続けます。 しかし、次に訪れるラーメン屋は麺の太さや硬さ、スープの種類を好きに選べるタイプのお店です。 しかし、早く次のラーメン屋検証にも進みたいため、なるべく早く見切る必要があります。毎食食べるとして、何日で見切ったと言えるでしょうか？」


といった問題です。 ラーメン屋の詳細は以下の通りとします。
スープは味噌・醤油・塩の3種類
麺の種類は細麺・太麺・ちぢれ麺の3種類で、 バリカタ・かため・ふつう・やわらかめの4種類から硬さを選べます。
トッピングは著者の独断と偏見および簡略化のため海苔のみとします。

ツリーを書く

問題を元にツリーを書きだすとこんな感じになります。(気持ち程度に名称を加えてます。Surface買ったのでペンを使ってみたかっただけです。) f:id:halspring:20181225213301j:plain

ツリーの形が異なる方もいるかもしれませんが、今回は説明のためこのツリーを使います。 因子と水準が洗い出せたら格子を書きます。 f:id:halspring:20181224163803j:plain

テストケースの作り方

ツリーが書けたら基準を決めます。 ここでクラシフィケーションツリー法の本領発揮です。
まずこれらの水準で、相互に作用するものがあるかどうか考えてみます。

例えば、「海苔の有無」と「麺の硬さ」はそれぞれに影響があるでしょうか？ 自分はないと思います。 よって「この２つはペアワイズにする必要はない」と判断します。
では、相互に作用するものはなにか。そうです、麺の「種類」と「硬さ」です。

「相互に作用し、かつ重要度が高いためこの部分はしっかり網羅したい」のでペアワイズで考えます。 f:id:halspring:20181224165039j:plain

こんな感じです。
では、ここに先ほど触れた海苔を考えてみます。 海苔の有無は麺に影響を与えないものの、一度は食べてみないと見切ったとは言えませんね。 よって、1ワイズで網羅します。

f:id:halspring:20181224165902j:plain

海苔に関する網羅率はひとまずこれで十分ですね。

最後にスープや残りの海苔の有無について考えていきます。
クラシフィケーションツリー法では人の意思を介入させることができます。 水準が等しく表れる必要はありません。

よって一度の検証で余計な要素はなるべく減らしたいので、海苔はできるだけ「無」にしたいと考えます。 しかし、「海苔はスープとの相性もあるのでは？」と考えたりします。

そう感じたのであれば、そこはペアワイズを考えればいいわけです。 既に12ケースが作成されるのは必然なので その中で網羅し、必要な分書けたら残りを「無」にします。

f:id:halspring:20181224170949j:plain

このような具合に、テスト対象の特徴や要件に合わせて網羅基準や水準の選定基準を考えます。

  • この店の主力商品はなにか？
  • 自分が絶対に 食べる/食べない 組み合わせはあるか？
  • もう1回 海苔を入れて試してみたくなった

などなど。 例えば今回は自分のための検証なので「ちぢれ麺は味噌以外で食べることはほとんどない」といった潜在的な情報があったりします。
このように「ユーザーはほとんどが20代～40代なので、60代以降よりも重点的に見る」や「金額表示に関わる部分なので重視する」といった基準を自分達で考えることができます。

この潜在的な情報はプロダクトによって様々で、

  • 使用頻度にばらつきがあるところ
  • 開発が苦戦していたところ
  • ロジックが複雑なところ
  • 法的に問題を起こせないところ
  • 会社として守らなければいけないところ

など様々な判断軸があると思いますので、自分たちのプロダクトに合わせてテストケースを作成して下さい。


ちなみに「スープと麺の組み合わせを網羅しないとは何事だ！！」という意見は、もちろん誤りではありません。 それもまた潜在的な要件であり、今回 自分が必要としていた要件ではなかっただけのことです。

必要ならその条件を足せばいいわけですし、不要なら考えなくて良い、自由に基準を決められる利点を最大限活用してみてください。

終わりに

改めて用語や考え方に誤りや及ばない点があるかと思いますが、大目に見てくだされば幸いです。

クラシフィケーションツリー法について書かれた情報が少ないので、もう少し身近に感じてもらえればと思います。

それでは皆さん、良いクラシフィケーションツリーライフをお過ごしください。

メリークラシフィクリスマス

「QAとは」の記事に対するコメントのやり取り

例の記事

これに対してリリカルさん(@mhlyc)から頂いたコメントとやりとりをまとめたものになります。 え？記事数稼ぎ？
自分の中では語りきれなかったり、考えが及んでいなかった部分もあり、 そこを深掘りしていただけたり、伝わりにくい部分の補足が出来たような気がするのでこのようにまとめさせていただきました。


ご 本人から許可も頂いております。ありがとうございます！

結論だけ読ませろ

結論と言うようなものではありませんが、やり取りの中で私側の主張をまとめてくださいました。 正直、ここだけ読めば私の意見がどんなものかは伝わるのではないかと思います。

やりとりを順に

新人なりに ”QAとはなにか" の問いに対する自分の考えを語ってみた

QA テスト ポエム 品質

目次

前置き

筆者について

興味を持っていただいてありがとうございます、halspringと名乗っている者です。

現在、web系企業に今年4月入社、配属からようやく4カ月のひよっこQAエンジニアです。

あくまで個人的な見解、意見なので賛同・反論・助言することがあれば 是非コメント等お願い致します。


現場の環境や状況が不明瞭な状態で語るよりも、どんな環境で働いてどんな考えを持ったか、どのような立場の意見かが はっきりしていた方が良いかと思うため、

少々説明を入れます。


さっさと次！という方は読み飛ばして本題だけお読み頂ければ幸いです。

 

開発文化

弊社では開発チームが企画からテストまで行います。

各チームにQAのような立場の人がいるわけではなく、別組織に近い形で必要に応じて開発チームをサポートしています。

  もっとも近くにいる独立組織のような立ち位置だと思います。  

QAの関わり方

弊社では、ヘルプを求めてきたチームもしくはリスクの高いPJに関与します。

（その他、自動テストでデグレチェックもしていますが割愛）


関わり方も様々で、

  • 開発チームへのレクチャー

  • テスト計画書の作成（ヒアリングから）

  • 開発側が作成したテスト計画書やテスト仕様書のレビュー

  • テスト仕様書作成のために観点の洗い出し

  • 開発側が洗い出した観点のレビュー

  • テストケースの作成

  • テストケースのレビュー

  • テスト実施状況の可視化

  • バグ分析

  • メトリクスの収集・分析

  • スケジュールの設定・見直し

  • PJ進行方針の提案

  • ツールの導入

  • 探索的テスト実施

等々、いくつもパターンがあります。 (むしろ パターンがないのかもしれません。)

 

ここまでツラツラと書いておいてなんですが、

予め理解して頂きたいことは「QA ≠ テストする人」の環境で育っており、その認識で今QAをしている、ということです。

 

新人なりに考えた”品質とは”

今の業務に就き、"品質とはなにか"を考えるようになりました。

この界隈では非常にあるあるな問いですが、明確なひとつの答えをもつものではないので意見が割れるところだと思います。

 

ですので、ここで述べる意見もあくまで一個人の考えです。もちろん、人間ですから考えが変わることもありますし、考えをぶつけ合ってよりよいものにしていきたいものです。


 

少し脱線しました、"品質とは"に戻ります。

私なりの"品質"の考え方は「ユーザーが本当に求めているもの(価値)を提供できているか」という軸で成り立っています。

つまり、「Aを良くすれば品質がよくなる」だとか「Bを早くすれば～」とか「Cの故障率を～」や「Dのバグを～」のようなものではないと考えています。

 

例えばWebであれば表示が早くなれば品質が上がったと言っても もちろん間違いではありません。

しかし、「ただ早くすればいい」ではないということです。


よって、よく言われる「テストをすれば品質があがる」「バグがなければ品質が高い」というのは"品質"の本質ではないというのが私なりのスタンスになります。

 

テストは何のために行うのか

テストで品質はよくなる？

ですが上記の通り、普段 私は業務でテストに関することをしている割合が多いです。

「言ってることとやっていることが違うじゃないか！」というのは早合点で、テストを行うことで品質を高めることはできます。

ただ、テストだけが全てではないですし、テストをすれば絶対に品質がよくなるわけではないと考えています。 (まさにバグゼロの落とし穴ですね)  

品質を高めるには

テストで品質を高めるためには、「テストをする目的や意図」を理解・意識しながら行う必要があると思います。

「現場で先輩がこんな感じにやればいいって言ってた」「過去のテストケースみたらこんなこと書いてた」では

そのテストでどんな品質が保証されたのかわかりません。

テストをなぜ実施するのか、それは、

ある特定の要素に対して、それを保証するためです。

 

ここで言う特定の要素は、機能・速度・正確さ・効率・保守性・信頼性・安全性やそれ以外にも多岐に渡ります。

いずれにせよ、何かを保証したり確かめるためのテスト、すなわち、保証したいものがあってこそのテストなのです。


  テストの意図や目的を理解・意識してこそ、正しく設計・実施・保証ができるというわけです。

   

ではQAとは

「今度はテストが大事って話になってきてない？」はい、そうかもしれません。

テストが大事なのはもちろん認識として持っています。


ではQAはテストをしっかりと目的を意識して設計・実施すればよいのか？

それは少し違う気がしています。


テストに関することだけを行うのであれば、それはQAではなくテスターやテストエンジニアでいいのではないでしょうか。

QAは品質保証を行う業務です。ですので、品質を高めるためにできることをやるのが仕事だと思います。

組織の文化や体制によってできることは異なります。

しかし、そのできること郡の中からいかに品質を高めるために動くことができるか、がQAとしての腕の見せどころではないでしょうか。


テストを担うことしかできないのならテストで品質向上に努めるように、

一歩離れた位置にいるのなら客観的なレビューやプロセス改善、他にも開発が開発に専念するためにできることがあるはずで、

それを行うのがQAだと思っています。

明確に役割を定義せず、あえて曖昧さを持たせることが重要な気がしています。

どうせ正解はないので、自分の思うQAとは何か、を自分の中に持っていればいいと思います。

十人十色のQAがあるべきです。

理想的なQA組織って？

QAの在り方

QAは特に役員のような強い権限を持っているわけではなく(持っているところもあるかもしれませんが)、

企画段階から方向性に口を出せるような立場ではないことが多いと思っています。

(これは業界に詳しくないので確かではありませんが)

 

また、仮にそのような"強いQA組織"があったとしても、

「そんな初期段階から文句を言われるくらいなら、最初からあんたらが作ればいいじゃん」といった不満が出ないとも限りません。

(私が開発側なら少なくとも1回はそういった不満を漏らすでしょう)


QAはあくまでも開発チームに寄り添う存在であり最高の右腕で在ることが望ましいと私は思います。


開発が開発に専念するためにテスト設計をサポートしたり、バグの分析を行って作り込みを防止したり。

メンバーにテストや品質特性について質問されれば、真摯に向き合い全体の意識を高められるようレクチャーしたり。

プロジェクトがあらぬ方向を向き始めたら、一歩引いた冷静な立場から熱が冷めないようにそっと軌道を修正したり。


この絶妙さが難しく、しかしおもしろい。これこそがQAの在り方だと思います。

QAはいなくなるのが理想？

  最近まで、最終的にQAはいなくなるのが理想なのでは？と考えていました。

開発チームや組織全体の品質意識を高め、全員が他所でQAを名乗れるほどになれば"QA"という組織はその組織には不要ではないかと。

そして、それが理想なのではないか、と。


たしかに、これはQAの思い描く「夢」だと思います。

全員が自分達のような品質に対する思いを持って、正しくテストを理解して実施できる。

夢のような光景です。


ですが、品質に満場一致の充分はありませんし、十人十色の品質があるのではないでしょうか。

また、QAがいなければ誰が客観的な立場から品質を確かめることができるのでしょうか。


開発者は開発者であるが故に"純粋なユーザー"にはなれないのです。

だからこそ、一番近い他人のような一歩引いた立ち位置から開発側の思いを理解しつつ、

そのプロダクトやサービスを享受するユーザーのことも考えることができるQAという存在が必要だと思うようになりました。


「QAがいなくても全然やっていけるんじゃない？」と冗談交じりで言われるくらいの組織を作るのはもちろん間違いではなく、目指すべきだと思います。

しかし、本当にQAがいなくなってはいけない。

だからこそ、QAの思い描く「夢」なのだと私は思います。


全員が法律を学び正義の心を持って行動すれば警察は不要か、裁判官は不要か。

自分の答えはNoで、第三者の視点は絶対になくてはなりません。

ちなみに同じ前提で「当事者ではない全くの他人に裁いて貰えばいい」というのも誤りです。

その第三者の"本来別のことに使うはずだった時間を搾取"しています。

  そうなると、最初はうまく回っていても いつか必ず破綻すると思います。

開発チームは人の集まりであり、理想はあくまで理想のまま目指すものとして、専門の人が残っている状態くらいがちょうど良いのではないでしょうか。

 

おわりに

まとまっているような、まとまっていないような文章になってしまいました。

書き始めると熱くなってしまうので、話が脱線したり極端な方向に向いがちですね...


結果 第三者による客観的な助言が必要なのでQAはやっぱり必要ですね(強引なまとめ)


冗談はさておき、これは個人的な思いですので、読んでくださった皆様が異なる意見であっても否定するつもりはありません。

"十人十色の品質"があり、むしろそうであった方が健全な気がします。

拙い文章でしたが、ここまでお付き合い頂きありがとうございました。

少しでも皆様が改めて何かを考えるきっかきになったり、何かの後押しになれば幸いです。


皆様の感想やご意見等、お待ちしております。

本当にQAはテストだけしてればいいのだろうか？

QA ポエム 品質 テスト

ご挨拶

はじめまして、初投稿です。

都内の某Web会社でQAエンジニアになって半年足らずのひよっこで、

  • メモを残したり
  • 新たに品質関係の業務に関わることになる人の力になったり
  • 色々な方にご意見を頂きたい

と思いブログ開設に至りました。

詳細な自己紹介は、社名とかどこまで名乗っていいのか確認したり、むしろ社名を名乗るべきなのかだったり、本名にするかハンドルネームにしようか考えたりしながら別記事にする予定ですのでご了承を...。

→ halspringで行くことにしました。以後、お見知りおきを。

目次

弊社のQA業務

開発チームのサポート

弊社ではQAはプロダクトのテストすべてを担っているチームではなく、サポートの必要な開発チームにのみ介入するスタンスを取っています。
基本的にテストは各開発チームが設計から実施まで担っており、 失敗できない重要な案件に主体的に介入していったり、開発チームからの依頼で参加するような感じです。
（これ弊社のいいところだと思ってます）

テスト計画書の作成やレビュー、プロジェクトマネジメント、パフォーマンステストの相談だったり探索的テストの実施などでサポートしています。

自動テスト

日々 様々なリリースがあるため、毎日E2Eテストと画像差分を取って回帰テストを行っています。 この自動テスト用のツール開発やメンテも行っております。


とある会社の話で味わう文化の違い

最近、海外のある会社の話に衝撃を受けました。 そして「品質とはなにか」「QAはテストだけ見ればいいのか」というモヤモヤを抱えることに...

フルオートメーション

テストはなんと完全オートメーションとのことでした。 googleかよ。

（本当にすべての自動化はできないので、理論的に可能な箇所は、だと思ってます）

また、「人によるチェックが増えてしまうならば新たに人材はいらない」「自動化ができなければエンジニアではない」の意識だそうです。怖い。
これまた恐ろしいのが、QAがそう考えているのではなく、エンジニア全員であることはおろか、CEO、CTOもその考えであるとのこと。 (社員は80人でエンジニアは60人)

能力至上主義

実績・能力がなければ最短 1週間で切ってしまうとのこと。
この辺りは法的な制約もあり日本ではやりたくても出来ないことですが、やはり組織として洗礼するためには手っ取り早く有効な手段なのでしょうね...

また、「自分達は家族ではなくプロ集団である」と意識しており、 誰がどんな発言をしようと、それはサービスやプロダクトを良くしたいがための意見・発言であり、
「〇〇さんは無茶ばかり」だとか「△△さんがいると話が進まなくなる」だとか、 そういったギスギスした関係にはならず、仕事は仕事としてしっかり切り分けが出来ているそうで。

自分もそうなのですが、日本だとやはり遠慮したり言い出せずに抱えたままだったりすることが多いような気がします。 「ユーザーに高品質を届ける」ということを考えると、遠慮すべきでないのは明らかですが、どうしても難しいところ。
文化的、教育的な違いがこの違いを生んでいるのでしょうか、それとも別の背景があったりするんですかね...。

品質を高めることを強いられる環境

強制的に と言ってしまうと言葉が少し強いですが、これもまた大事な要素。

ユーザーテストの様子を会社全体に放送するそうです。やばくないですか...？？？


まず全員がユーザーテストの様子を見るほど品質意識が高いのも素晴らしい...

そしてユーザーがある操作で躓いたら、その部分を改修しないと担当チームとしては非常にカッコ悪いわけですよね。
本物のユーザーが躓いていることで、誰も悪者にならず、かつ嫌味的でもない「空気からの指摘」によってUXの改善活動が行われているんです。


これからのQAの役割

この話は自分の中のQAの概念に大きな衝撃を与えました。

QAはこのままテスト「だけ」を行っていていいのか。

Quality Assuranceを名乗るならば、テスト以外にも品質を保証する方法を見つけ、実施していく必要があるのではないか。

品質とはなにか。本当に届けなければいけない価値とはなにか。

本当にテストで品質を保証しているのか。バグがないということにしているだけではないのか。

エンジニア全体の意識改革が必要ではないか。

エンジニアだけでよいのか、企画やデザイナーにも品質に関する意識や知識を持ってもらうべきかどうか。

自分の中で何が良い選択なのか、 どこまで実現可能か、それを行うのにどれほど時間が掛るのか。

葛藤しています。モヤモヤしています。


日本では品質に対する意識が薄く、まだまだQAエンジニアの認知度も高いとは言えません。

このモヤモヤは自社だけでなく、日本のエンジニア全体までスコープを広げて考える必要があると考えております。


おわりに

共感して頂けた方や、反対意見のある方、 なにかご意見があったり事例等あればご指導いただければと思います！

（規模や内容はどうあれ、独自に文化が出来上がっている組織をこういった会社のような文化に変えていくにはどうすれば良いのか、新人なりに模索しています。何か進展があれば公開して問題のない範囲で続きの記事が上がるかもです。）

また、このことに関して何らかの活動を行いたいとも考えています。 イベントのお誘いや、近い思想の団体や活動があればお教え頂けると嬉しいです。

(むしろ、ないのなら いっそ設立したいくらいの思いはあります)

追伸

かきざきさんからのコメントを受け、熱い思いから冷静になれました。

品質意識が非常に高い組織に刺激を受け、盲目的になっていたのと主語が広がり過ぎていたことを今 自覚しました。 恥ずかしい限りです。


こうあらねば、の前に、なぜ、そう思ったのかを一度引いた立場から考え、本当にそうすべきか考え直すのが大事ですね。

今回の場合 自分は、 まずはヒアリングをして、

  • どれくらいの品質意識を持っているのか
  • 個人やチームでどんな違いがあるのか
  • 変える必要はあるのか、あるならどこなのか
  • そもそもどんな品質が求められているのか

など、様々な思考材料を集めたいと思います。



ただ、主語（目的語）は大きくなり過ぎていましたが、日本における品質意識はまだまだ向上させる余地があると感じています。（テスト界隈がまだまだ狭い）

このあたりも勉強会などで QAでないエンジニアから情報を集めて分析したいですね。


熱くなるのは悪いことではないと思っていますが、周囲をちゃんと見ずに「こうあらねばならない！」を強いるのは健全ではないので 熱くなり過ぎないように今後は注意したいです...反省。