テスターのテストによる開発者のためのテスト

システム業界で思ったことをそのまま言葉にしよう

ちょっと楽になる便利ツールのご紹介 windows編

なそです!

 

こんばんわ、なそです。

この記事はソフトウェアテストの小ネタの11日目の記事です。


追記:CliborのサイトのURLが変更されたので、修正しました。 
サイトには応用編などの使い方が記載されています!
参考になるので、ぜひとも見てみてください♪

今回の商品はこちら!

chigusa-web.com

 

クリップボードの履歴管理ができる常駐型のアプリケーションになります。

何が便利かっていうと、

Ctrl+Cして

Ctrl+Vを押そうとして

あ、間違えた・・・

Ctrl+Cをまた押してしまった・・・ 

って時でも大丈夫。

Ctrl,Ctrlと2回押せば、Cliborが立ち上がり履歴が表示されます。

そこからペーストしたい履歴を選ぶとあら不思議、クリップボードに保存されてすぐにペーストできるようになります。

 

また定型文を登録することもできますので、忘れやすいサーバー名やファイルパス等をあらかじめ登録しておくとより便利に使えます。

 

Cliborにはインストーラーは存在しないので、展開して起動した場所がCliborの起動場所になります。 そのため、ダウンロードフォルダではなくドキュメント等に展開することをオススメします。間違えて消しちゃったということが無いように......

 

問題点は、OSの再起動した時に合わせて手動で起動しないといけないところですが、windosではスタートアップにショートカットを入れておくだけでOSの再起動時に立ち上げてくれます。

windows10の場合

C:\Users\ユーザー名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup 

windows7の場合

C:¥Users¥ユーザー名¥AppData¥Roaming¥Microsoft¥Windows¥Start Menu¥Programs¥Startup

どちらのOSでも、「Windows」キーを押しながら「R」キーを押すと「ファイル名を指定して実行」ウィンドウが表示されます。そこで「shell:startup」を入力すると起動するようです。(調べるまで私は毎度フォルダを延々と辿っていました)

 

もちろん、スタートアップにアプリケーションを入れれば入れるほど起動した時の立ち上がりが遅くなるので、入れるものは慎重に入れてください!

 

それでは、簡単ですがなそがお送りしました。

システムを把握する3つのコツ

こんばんわ、なそです。

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

 

指摘を受けて、その通りでしたので、修正しました。

  1. システムを把握する
  1. システムの目的を把握する

 

 みなさんは、仕様書や設計書を元にテストを実施したのに、リリース後に障害発生させて、一生懸命にテストしたのに...... という経験ありませんか?

 100%防ぐことができなくても、少しでも減らしたいと思います。どうしても「仕様書」や「設計書」に記載しきれないことが多くて、『それ聞いてないよorz』ってちゃんと書いてよって思うことはしばしば。それ以外に回避するためには、テストするシステムの理解を進めるという方法が1つあります。システム全体をイメージできると機能間の矛盾や行方不明になるデータ、隠された機能を見つけやすくなります。

 今回はシステム把握する時に気にしていることを3つのコツを説明します。

  1. システムの目的を把握する
  2. 業務を理解する
  3. データの流れを意識する

システムの目的を把握する

 自分がテストするシステム全体で何をしたいのかの目的を把握し、その目的をどう実現しているのかを把握していきます。業務によって必要なシステムの構成がある程度決まります。ECサイト等は普段使用することが多いと思います。いくつかのサイトを利用しているのであれば、その経験を参考にできます。

 自分が知っている知識との差分を考えることで、どこで何をしているかを把握できてシステムの把握が進んでいきます。

 機能から徐々にボトムアップしていく方法と、システム全体から徐々にトップダウンで降りていく方法がありますが、初めて触るシステムの場合、ボトムアップの方が考えやすいかもしれません。複数のシステムを見たことがある人ならシステム全体の構成を意識することができるため、トップダウンで考えていく方が考えやすいです。最終的には両方を意識することになります。

 誰が使うのかという視点も意識してください。ECサイトでは購入者となることが多く、そこに対する意識はできると思いますが、出店者側の視点が抜けやすくなります。いろんな人が関わるシステムですので、1つの面だけではなく複数の面を意識することが必要になります。

業務を理解する

  システムを把握してくると機能と機能の繋がりが見えてきます。そうすると見落としやすいポイントが「いつ」システムを使用するのかということです。

 ルーチン:「日」「週」「月」「年」etc.....

 アクション:「購入ボタンクリックした時」「間違えた登録した時」etc......

 テスト設計していると仕様書や設計書に目がいってしまい、1週間に1回しかやらない処理、間違えた時などの処理が記載されていなくて、リリース後に運用できないとかのトラブルが発生します。書いてない仕様を探すために、システムの矛盾や想像していない業務の流れを探していく必要がトラブルを減らすコツですね。

 

 基幹システムの業務知識は、イメージしにくいと思います。下記の本である程度の知識を得ることができます。(基幹システムは普段触れることは少ないので本から得られる知識でも結構重要になります)

データの流れを意識する

 システムで使用するデータはシステムの中で流れる血のようなものです。流れ続ける場合もあれば、どこかで止まる場合もあります。

 止まるデータは、何かしらの分析に使用されることが多いです。分析には流れているデータも使用します。

 システムや業務を知っていてもデータの流れは出てこないです。特に履歴や内部で監査のために保持している等のデータは上記2つのコツからは見つけられないです。その辺を意識しないといざ使おうとした時に使えないなどのトラブル時の対応でトラブルに発生することもあります。異常系のテストであることが多く、重要度が低くくされることが多いです。

 不自然に止まるデータは、仕様の矛盾が発生していたり、同じような項目が多い場合は障害の温床になったりします。(A列を更新するはずなのに似たようなB列を更新してしまったためにステータスが更新されずにいつまでも修正できるとか)

 システム化するときに、以前は手動でやっていたやり方をそのまま取り入れられる場合があります。不思議なところにデータがあったりして、話を聞いてみると以前の業務を聞くことができ、使う人たちをさらに意識できる場合もあります。(昔話に花が咲いて藪蛇の場合もありますがw)

 

 まだまだコツはありますが、今日は3つ紹介させてもらいました。システムを広く知っておくと、レビューの時の矛盾点の指摘だったりと活躍の場面は多いです。少しずつ理解して知識を増やしていきましょう!

 

それでは、なそがお送りしました。

テストラジオを動画にしたよ

なそです。

 

タイトルを見て、なにを言っているかわからないと思いますが、内容を書きながらテストラジオを配信するというわけのわからないことをやってみました。 

 

どういうことかというと、自分の話していることをスケッチブックにまとめながら補足やまとめをしていきながらテストラジオを聞いていくということです。

グラフィックレコーディング(グラレコ)です。今回は全然グラレコできてないけど・・・

数人からグラレコやホワイトボードの使い方を質問されたことがきっかけで、実際に見てもらった方が良いかなと思い、動画化しています。

機材は下の方で紹介していますが、今回に合わせて買ってないです。

 

実際にご覧ください!!

twitcasting.tv

最初の方は全然動画が動かない(パワーワードだなぁ)ので裏で書いていたんですが、ちょっといじったら動き出しました♪

ちょいちょい止まったり、誤字ったり、絵を書いたりといろいろやっています。

 

よかったら見て見てください〜

どういう風にやっているかはテストラジオの方で紹介しようと思っています。

たまにこっちにも記事書きたかったので、今回は書いています

使ったのはElgato Cam Link と FDR-AX700 こんなスペックのビデオカメラはいらないけど、MacだとElgatoは必須。USB3.0じゃないと使えないのでご注意を!!

 

機材がね。

意味不明なスペックを買うから、またこの人何したいのかわからないとか言われるんだよね。ガジェットは趣味です!!

 

いつもこのスタイルかどうかは別にして、動画もできることを実験したなそでした!

九州ソフトウェアテスト勉強会の勉強会でワークショップの実験をしてきました!

暑い日が続いていますが、みなさまいかがお過ごしでしょうか?

なそです。7月14日(土)に福岡でワークショップを開催してきました。

 

atnd.org

 

以前に参加したことのある勉強会の題材をお借りして、初心者向けのテスト設計ワークショップを開催してきました。

nagasaki-it-engineers.connpass.com

 

 この中で、「数取器 - Wikipedia」のテスト設計をしてみようというお題がありました。ボタンが数個、処理は複雑ではないアプリケーションのテスト設計でしたが、実にシンプルで考えやすかったです。綺麗にテスト設計できたかは別問題ですが......

 

 今回のブログでは、実際にこのワークショップをやってみたいか方向けに何を思ってワークショップを作っていったか、ワークショップのシナリオやタイムテーブルを書いています。これからワークショップを作ってみようとか思っている人にも参考になるかもです。

 

テーマ:なんかすごいと呼ばれる勉強会ではなくて、参加者が明日から意識できる勉強会に。

私のゴールとしては、「なんだよ。俺でもこんなワークできるよ」って思ってもらえれば勝ち!(勝ち負けではないですが......) 

 

ワークショップ開催にあたって、意識したことは以下の通りです

簡単な情報

  • 90分のワークショップ
  • 最低参加人数は4名+1名講師(実はいなくてもいいような気がする)

人員の配置

  • なるべく同社同士、チーム同士で組んでもらって、業務に送り込む
  • 4人または6人を1つのテーブルに配置する
  • ちょっと狭いくらいがちょうど良いかも

 スライド

  • 簡単ではなく、易しくする
  • 単調ではなく、メリハリをつける
  • 2枚1組とし、印刷できるようにする
  • 印象をポジティブなアクティブにするために暖色を使用する

時間の配分

  1. 説明を受け、やってみたいことを与える時間を作る
  2. 1人で考える時間と2人でディスカッションする時間を作る
  3. 上記の繰り返しを行う

時間を意識するための施策

  • 極端すぎるほどのロールプレイ
  • 世界を狙う「数取器」
  • リリースは明日。これは必達

場所・雰囲気

  • わかったよりも楽しかったを優先
  • いつもと違う場所にきたという緊張感と高揚感を与える
  • チャレンジする場所
  • 相談に乗ってくれる先輩は隣の人

マインドマップ

  • 1回のマインドマップを書く時間は10分〜15分くらい
  • 思考の発散するための手法
  • 今回はあえて縛りを入れて、よりテスト設計に向けた思考の誘導を行う

進め方

  • 質問を受けたら負け
  • 他に集中することがないように目の前のマインドマップに集中してもらう

必要な道具

  • B3のスケッチブック
  • カラフルな色のペン
  • ふせん

スライド 

           speakerdeck.com

続きを読む

WACATE 2018夏に参加してきました。ワークショップで実験してきました。

さて、みなさまいかがお過ごしでしょうか?

いまさっき書き終わった記事が吹っ飛び、泣きそうな「なそ」です。

もう一回書く気力を私にください……

 

今回の参加レポートはいろんな方から上がると思いますので、わたしはワークショップで行ったチーム運営の実験話をしようと思います。

 

WACATEでは、夏・冬と年2回あり、夏は1つのテーマをどっぷりワークショップを行う。冬は色々なテーマをたくさんやる。そんな年2回のWACATEで「夏」です。ワークショップです!!中身は多くを語りません。他の人のレポートを見てくださいー

 

 今回のワークショップでは、「なそ」ミッションと題して(個人の暗黙的なミッション)を行いました。そのミッションは3つになります。

  1. 個人タスクは極力減らす 
  2. チーム全員が納得しながら進める
  3. 自分がいなくても、メンバーが主体的にワークショップを進められる

 チームの雰囲気と行動をどうしていきたいかを、チーム内であげました。上はやりたいこと。下は見送る項目。見事にチームのみんなで一致しました。この時点で良いチーム!!

f:id:DevTest:20180617184401j:plain

 ただし、このミッションを行うために、支配者的なリーダーシップを行うことで達成することはできないです。それは全ミッションを達成できないのですが、特に3が達成できないためです。サーバントリーダシップで進めて行くのが理想でした。

 特に進め方を決めるときも、「1回だけやってみようよ」と提案してます。もう一個の代案を提示したり、他の人にも意見を求めりもしています。トップダウンとも、ボトムアップとも言える両方が納得して進められるようにしたことで進め方の納得感が生まれました。生まれたよね……?

 個人的な評価に関しては、できたと思っています。チームメンバーもそう思ってもらえれば嬉しい限りです。

 

 最初はツイートで、パッと話をして終わりにしようと思ったんですが、なかなかな文字量になりそうなのと、繋がりがうまく表現できなかったためにブログにしようと思います。 (最初は他のチームとの違いを言いたかっただけだったので数回で終わる予定でした)

 仕様書の読み合わせ

うちの班の読み合わせは、

  1. 個人で最初から最後まで目を通す
  2. 代表者が1段落を読み上げる
  3. みんなで仕様を共有する
  4. 繰り返す

 私が普段やっている読み合わせとは違うチャレンジをさせてもらいました。普段は、各人で最初から最後まで読んだ上で、疑問点や指摘事項、気になる点をあげてもらいます。その後にチームで共有するという読み合わせをします。結構時間がかかるんですよね。

 今回変えたことで、個人の作業時間を減らすことできました。また、各人が悶々と考えがちになる時間をチームの時間にしたので、すぐにチームの議論とすることができました。共有の時間が生まれないです。議論の時間=共有の時間となります。

みんなで進める

 全員で一つのモデルをやっていきました。全員で状態遷移図を書いたので、人によって粒度が違うことがないように対策できています。

  1. 状態を各人が3分で書き出す
  2. みんなで「せーの」で共有する
  3. イベントを各人で4分半で書き出す
  4. みんなで「せーの」で共有する

f:id:DevTest:20180617155807j:plain

 そうして出来上がったのは、写真になります。濃い青は状態。水色はイベントです。重なっているのは、各人が出した項目の被りや統合によって重ねてます。こうなると全員が納得して作っていますよね。全員で話ししながら作っているので!!

 ただ、状態遷移図から状態遷移表に落とし込む時は、みんなが納得している状態である かつ 1人で作業した方が良いというチームの判断となっています。1人で作業した方が良いからだけではなく、みんなが納得している状態だからが前提条件になります。

巣立ちのとき

 状態遷移図が書き終わった段階で約1時間くらい残っていました。ここから全員で状態遷移表やテストケースを書いてもよかったのですが、どうせなら次のモデルを実施してみたい。どこまでできるのかと思い、ユースケース図を書くことを提案しました。そして、ユースケース図を書くときに、私は一歩引いてみましたが、問題なく進み始めて無事にうまくいったと思います。

 一歩引いた私は資料作りに専念しました。もう一人は状態遷移表を記載してもらいました。5人チームなので3人でした。特に何かをした訳ではないですが、ユースケース図を書くときにも、状態遷移図とやり方を一緒にしました。

  1. アクターを4分で書き出す
  2. みんなで「せーの」で共有する
  3. ユースケースを4分で書き出す
  4. みんなで「せーの」で共有する

 あとは棒人間と矢印を書いて整理しました。ほとんど、状態遷移図とやっていることは変わりません。そのため、状態遷移表を書いている人もモデルとやり方を知っていれば進められるはずです。

どんなふうになったの?

こんな感じで進めた結果がこちらになります。

順番に説明していきます。

f:id:DevTest:20180617190247j:plain

「気になること」は仕様を読んで行く中で、気になったことをあげて行く場所。

解決したら、右の「きまった!!きめた!!」に移動して赤字で記入。

f:id:DevTest:20180617190259j:plain

状態遷移図を作る際にみんなで考えた資料です。これらを元に下の状態遷移図を書いたものになります。これらをみたときに不安点が上がってきたので赤い付箋を張っています。だって不安なんだもん。チームの重要なテストにしています。チームの不安な想いを解決するのも重要な要素です。

f:id:DevTest:20180617190317j:plain

状態遷移図。途中で気になったことやイベントの間違いが書かれています。番号は状態遷移表へのトレーサビリティを確保しています。

f:id:DevTest:20180617190331j:plain

逆光で見にくいですが、上の3枚はそれぞれの進め方を書いています。その下が状態遷移表とテストケースになります。付箋を使った表という発想がすごい!!

f:id:DevTest:20180617190343j:plain

ユースケース図です。右はユースケースからテストケースです。操作手順とかはみんなで共有しているからそんなに詳しく書いていません。チーム内で共有して暗黙知になっているのは許容しています。

個人のタスクを極力減らすために

 タイムキープでも、各人のタスクは、チャレンジ時間と追加時間を3分と言っているのに2分半にしたりと鬼畜な事もしましたが、だいたい間に合ってました。1回だけ伸ばしましたが、全体的に短くて問題ありませんでした。これは普段の作業時にも無意識のバッファを積んでいるかもしれないです。そこに意識的にバッファを積んでさらに時間を見積もっている可能性があります。これが悪いことだとは思いませんし、当然だと思います。実際の現場では絶対にしません。これはワークショップだからやったことです。

チームメンバーへ ごめんなさい。 

最後に

 これは、WACATEだからではなく、普段の業務でも一緒になります。誰かと一緒に働くことで、情報共有の時間も含めて考える時間になるので、私は好きです。現場のメンバーの多くがメンバーのタスクを把握している、お互いにフォローできる、仕様がみんなで共有されている状態になることが理想だと思っています。ここでの経験を現場に活かして、さらに良いチームを作れるようにしたいと思います。

 

それでは!!

(なんとか、書き上げることができた……)

 
 
 
 
 

テストケースのないソフトウェアテストについて考えてみる

どうも、お久しぶりです。

なそです。

 

 追記:文章内で「テストケースのないソフトウェアテスト」=「アドホックテスト」と定義していましたが、JSTQBの用語との乖離があるとの指摘を頂いたので、修正しております。

 

 さてはて、ひさびさの投稿ですが、今回はこの話題について考えてみようと思います。なにかと話題に上がるテストケースのないテストの話ですが、下記の記事でも取り上げています。

tech.nikkeibp.co.jp

 

 この記事では「アドホックテスト」として、話を進めていますので、私もそれに則って、「テストケースのないソフトウェアテストアドホックテスト」としていきます。行きません!!

 この記事では、アドホックテストとしていますが、JSTQBの用語集では、アドホックテストは以下のように定義されています。

 アドホックテスト:非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。

 また、他にも、探索的テストがあります。

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

 

このブログは、ほぼアドホックテストになるので、アドホックテストとして話を進めますが、JSTQBの用語と違うのは、下記の赤字部分です。

  • 非公式に実施するテスト
  • 公式なテストの準備をする場合もある
  • 実績のあるテスト設計技法をもちいない
  • テスト結果を予測する
  • 毎回、テスト方法が変わる

 

 ここで、私がアドホックテストを考えるときは2つのポイントに注目します。それは、「テストする人」と「動機」です。アドホックテストで不具合を見つけたいのはもちろんですが、何かしらの不安があるのでテストすると思います。それぞれ考えてみましょう。

1.  テストする人:どんな人がアドホックテストを行うのでしょう?

  1. とにかくたくさんの業種を問わない人たち
  2. 何度もリリースに立ち会い、いろいろな問題を解決してきた人たち
  3. テスト実施は何度も行なっているが、このシステムは未経験な人たち
  4. 新卒
  5. 上司に言われたからやる人たち
  6. よくわかんないけど、藁にもすがる思いの人たち

 とかとんとんですね。 

 

 もちろん、それぞれで一つではなく、複数のテストする人がいることもありますし、5のようになぜかやることになっているからやるということもあるでしょう。6の人たちは、テストの勉強をしてもらいたいですが、そんな時間がないくらい切羽つまっているかもしれないですね。 また、テストする人たちも様々ですね。テストする人たちをもう少し大きく分類します。それは、アドホックテストの準備がどのくらい必要かということです。

  1. 自立的に考え、アドホックテストを実施できる      → 自立型
  2. なんとなくヒントがあればアドホックテストを実施できる → 補助型
  3. 何をしたら良いかわからないが、指示があれば実施できる → 指示型

 この3パターンに分かれると

 自立型は、期間とシステムと仕様書があれば、アドホックテストを実施できます。補助型には自立型と比べると、ヒントとなるものが必要になります。それがあればアドホックテストを実施できます。指示型は具体的な確認したいことやシステムの使い方があればアドホックテストを実施できるはず。

 もちろん、どのパターンでもフォローは必要になります。

 

 なその経験では、補助型や指示型に思いがままにアドホックテストを実施してもらうと重要度の低い不具合が上がることが多いです。特に画面表示に関する不具合が多い気がしています。

例えば、とある家計簿アプリのアドホックテストをしてもらったときに

  • 家計簿アプリの金額欄に1000兆円入れたら、金額の欄の上2桁が表示されない
  • 金額入力欄に小数点が入力でき、金額が小数点を考慮した計算がされる

  一回の買い物で1000兆円使えるユーザーが家計簿アプリをアプリを使う確率は物凄く低いと思います。(っていうか、何を買えば1000兆円になるんだ!?) また、計算結果にエラーが出るのであれば大問題ですが、この場合であれば入力できるのが間違いという不具合になります。そして、このような問題は他の数値が入力できるところでも同じ問題が出る可能性が高く、不具合が大量生産されます。不具合は上がるに越したことはないかもしれませんが、このような不具合を大量に上げることによって確認で開発者の手を止めるのもまた私にとっては不本意でもあります。

 

 では、補助型や指示型のパターンにはどういう実施をフォローをしていくべきかというと。補助型には、テストで確認してほしいポイントを渡すようにしています。

  これを私が所属するところでは「テスト観点」と呼んでいます。粒度は細かいです。テストケースの一歩手前くらいの記述内容ですね。複数の業種のシステムを構成する要素を抽象化してまとめたものになります。って言っている自分が混乱しそう……。

 例を挙げると、テキストボックスだったら

  • 入力文字種(半角、全角、数値、記号等)が入力できること
  • 入力桁数が入力できること。入力桁数+1が入力できないこと
  • 禁則文字が入力できないこと。Copy&Pasteでも入力できないこと
  • ……

とかですね。もちろんシステムの表示部分だけではなく、見えないところのテスト観点もあります。 

  このテスト観点という言葉、色んな人によって考え方が違っていて曖昧な言葉でもあるので、私のテスト観点と読者のテスト観点が違うものになるかもしれません。

 テスト観点に興味のある方はぜひ、テスト観点を語る夕べにご参加ください! 一緒に語らいましょう♪ 次は2018年5月29日(火)です。語る夕べの雰囲気をお知らせしますね

togetter.com

togetter.com

 

 指示型には、自立型の人と一緒にテストを体験してもらうのが良いと考えます。(その人が何も知らない状態でシステムを触ることで見えてくる課題があるとも思いますが、それはアドホックテストで確認することではなく、ユーザビリティテストで計画した上で実施するのが望ましいです。望ましいんですよ!!)
 一緒にテストやってもらうといろんなことが起こるんです。テスト設計等の話でペアテストをやってもらったときのことをまとめてますので、よかったら参考にしてください。

devtest.hatenablog.com

 

 補助型や指示型の人を参画させると余計な工数が取られてしまい、十分なアドホックテストができないと思う方もいらっしゃいますが、後続を育てる意味でも参画させる必要があると思います。(この辺も語りだすと止まらなさそうで本筋から外れるのであまり語りません)

 

次に動機について考えていきましょう。

2.  動機:なぜ、アドホックテストを行うのでしょう?

  1. アドホックテスト以外のテストでは詳細な手順を記載するが、記載しきれない仕様の不具合を見つけたい?
  2. 仕様に書かれたテストは十分だが、人の感覚や経験に基づく不具合を見つけたいから?
  3. 過去の不具合を参考にテストをしたいが、過去の不具合が資料として残っておらず経験者にも診断してもらいたいから?
  4. テストした環境とリリースする環境の不一致があり、不一致部分の不具合を見つけたいから?
  5. テストケースを作る工数がなく、なんでも良いから不具合を見つけたい?
  6. 気が進まないが、上司からやれと言われたから?
  7. なんかやればよいことがあるらしいから?

 何をしたいのかはプロジェクトによって異なりますが、 それが定まっていないプロジェクトもありそうですね。何をしたいのかはしっかりと定めて不具合を狙いに行きたいです。

 仕様書から作っただけのテストケースでは、当たり前品質の確認しかできないかもしれない。魅力的品質も含めて考えた場合、それはテストケースにも現れてくる。何を魅力的品質とするのかは組織やチーム、個人によって異なるので、ここではあまり触れない(というか触れたくない((((;゚Д゚))))ガクガクブルブル)

 1は仕様書を中心にテストしていく確認作業に近いですね。2はフローやデータのつながりを考えながら実施したほうが良さそうです。3は経験者や第三者検証に依頼したほうがよいです。4は以前やったテストを使いまわしても良さそうですね。5はそう思っているなら今すぐテストケースを書くための努力をしてくださいToT 6や7はアドホックテストで何がしたいのかをもう一度熟考してもらいたいです。何かしらの不安点があってこそのテストなので。会社に決めているからと言っても無駄な工数を使うためではなく、一番最初にはなにかの課題をクリアしたかったはずです。

 

 で、こういうことを言っていると、「あ、じゃ、アドホックテストだけでよくない?」とか言う人がいるんですけど、ドキッとしたそこのあなた!その考え方は危険です。どうしてもアドホックテストだと、テストケースを使用したテストに比べて情報が残りにくいということがあります。残りにくいのは品質の測定のための情報です。この情報がないと次に繋がる一歩に繋げることができません。なぜかというと、どうしても直近のよかったことや困ったことはよく覚えているのに、数週間前や数ヶ月前の記憶は曖昧、もしくは忘却されてしまうからです。不具合として残る情報以外が闇に葬られてしまいます。

 なその所属するテストチームは2週間単位で振り返りをしていますが、それでも直近数日の話が振り返りに上がることが多いですという経験則もありますし、皆さんはどうでしょうか?(チームの話は語り出すと止まらないので、別途記事にしたいと思います)

 

 最後に第三者検証会社にいるとどうしても思った以上に品質が悪いという状況になってから参画することが多いです。「予定したテストを行ったが……」その状態から入ったときはアドホックテストを行うことが大半です。しかし、最初はアドホックテストを行い、並行でテスト設計を行ったうえでアドホックテストの比率を落としていく等の対策はもちろん行っています。ゼロにはならないんですけどね。

 アドホックテストだけではなく、テスト設計をしたテストを行うことでお互いの良いところを掛け合わせて品質を高めていけます。アドホックテストと言う名前のテストを設けたからと品質が高まるわけではなく、それで何がしたいかどんな人をアサインできるかとかまで考えないともったいない工数になってしまいますねということで今回は締めさせてもらいます!

 

それでは、今回はテストケースのないソフトウェアテストについてお送りしました!

 

 

参考資料
JSTQBの用語集「ソフトウェアテスト標準用語集」

http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf

 
 

アジャイルの勉強について、なそのおすすめのアジャイル本

今年もよろしくお願いします!なそです。

 

今週のテストラジオで、アジャイルの勉強方法を話したところ、ワニさんからおすすめ本をまとめて欲しいとリクエストいただいたので、まとめてみます!

ssl.twitcasting.tv

アジャイルの話をするときは、なそは相手の前提条件を元におすすめの本を用意します。大体は上から順番になります。 

という訳で、簡単な説明とともに紹介していきますm(_ _)m

 

アジャイル初心者の方へ

 SCRUM BOOT CAMPです。

この本はなんと!作中に漫画が書かれており、各章の進行は漫画ベースで進みます。

スクラム(アジャイルの一つ)の進め方を知って前提をつくれるおすすめの本です。文章は読まなくても良いので、まずは漫画を読んでみてください。その後に文章を含めてもう一回読むと内容を理解しやすいと思います。

 

 アジャイルのプロジェクトの流れを知っている人へ

 アジャイルでやっている各作業について知りたい方にはこちらをおすすめします。

上記の本で流れを知った上でこの本を読むと単品で読むより吸収率がよくなると思います。文章も軽く読みやすいです。この本の作者は「初めての自動テスト」を書いたJanathan Rasmussonさんです。本の中の絵が可愛いです。

 

ここから役割によって変わっていきます。「アジャイルサムライ」を読み終わった後にそれぞれきになる分野から読むと良いです。

 

 アジャイルの中でテストを専門にしたい人へ

高いですが、アジャイルの中でテストを進めていく話が記載されています。量も多いですが、得られる知識は多義にわたるので、しっかり読んでみてください。自動テストのことも書かれていて、「初めての自動テスト」とかぶる部分がありますが、アジャイル×テストを知るにはこれ以上良い本はありません。 

 

 アジャイルの中でメンバーを育てたいしたい人へ

 チームの中でメンバーを育てたりコーチングについて書かれています。

教育に興味ある方はぜひ!実践したら効果が高いものも書かれているので、何処かのタイミングでは読んでおいた方が良い本です。「作者の言葉」というコラムが多く、学びも多いです!

  

アジャイルの中で自動テストをやりたい人へ

 アジャイルだけに特化した訳ではないですが、自動テストってなに?を知るためにはこれは最強の本です! 上記に記載しましたが、「アジャイルサムライ」の作者が一緒でどちらか読んだことある人はぜひとも読んでみてください。

さらに自動テストを知りたい人へ

 初めての自動テストを読んだ後におすすめなのが、システムテスト自動化標準ガイドです。より実践的な内容です。

 

アジャイルの中で小さく作ってチームを分けていきたい人へ

マイクロサービスが書かれている本になります。安定のオライリーさんですね。

本編中では触れていなかったですが、これも知っているとチームの分け方とかを考えるいい知識になります。

 

アジャイルを学んでいくことでおすすめの本を紹介でした。

それでは、なそがお送りしました!