テストラジオを動画にしたよ
なそです。
タイトルを見て、なにを言っているかわからないと思いますが、内容を書きながらテストラジオを配信するというわけのわからないことをやってみました。
どういうことかというと、自分の話していることをスケッチブックにまとめながら補足やまとめをしていきながらテストラジオを聞いていくということです。
グラフィックレコーディング(グラレコ)です。今回は全然グラレコできてないけど・・・
数人からグラレコやホワイトボードの使い方を質問されたことがきっかけで、実際に見てもらった方が良いかなと思い、動画化しています。
機材は下の方で紹介していますが、今回に合わせて買ってないです。
実際にご覧ください！！
最初の方は全然動画が動かない(パワーワードだなぁ)ので裏で書いていたんですが、ちょっといじったら動き出しました♪
ちょいちょい止まったり、誤字ったり、絵を書いたりといろいろやっています。
よかったら見て見てください〜
どういう風にやっているかはテストラジオの方で紹介しようと思っています。
たまにこっちにも記事書きたかったので、今回は書いています
使ったのはElgato Cam Link と FDR-AX700 こんなスペックのビデオカメラはいらないけど、MacだとElgatoは必須。USB3.0じゃないと使えないのでご注意を！！
機材がね。
意味不明なスペックを買うから、またこの人何したいのかわからないとか言われるんだよね。ガジェットは趣味です！！
いつもこのスタイルかどうかは別にして、動画もできることを実験したなそでした！
九州ソフトウェアテスト勉強会の勉強会でワークショップの実験をしてきました！
暑い日が続いていますが、みなさまいかがお過ごしでしょうか？
なそです。7月14日(土)に福岡でワークショップを開催してきました。
以前に参加したことのある勉強会の題材をお借りして、初心者向けのテスト設計ワークショップを開催してきました。
nagasaki-it-engineers.connpass.com
この中で、「数取器 - Wikipedia」のテスト設計をしてみようというお題がありました。ボタンが数個、処理は複雑ではないアプリケーションのテスト設計でしたが、実にシンプルで考えやすかったです。綺麗にテスト設計できたかは別問題ですが......
今回のブログでは、実際にこのワークショップをやってみたいか方向けに何を思ってワークショップを作っていったか、ワークショップのシナリオやタイムテーブルを書いています。これからワークショップを作ってみようとか思っている人にも参考になるかもです。
テーマ：なんかすごいと呼ばれる勉強会ではなくて、参加者が明日から意識できる勉強会に。
私のゴールとしては、「なんだよ。俺でもこんなワークできるよ」って思ってもらえれば勝ち！(勝ち負けではないですが......)
ワークショップ開催にあたって、意識したことは以下の通りです
簡単な情報
- 90分のワークショップ
- 最低参加人数は4名＋1名講師(実はいなくてもいいような気がする)
人員の配置
- なるべく同社同士、チーム同士で組んでもらって、業務に送り込む
- 4人または6人を1つのテーブルに配置する
- ちょっと狭いくらいがちょうど良いかも
スライド
- 簡単ではなく、易しくする
- 単調ではなく、メリハリをつける
- 2枚1組とし、印刷できるようにする
- 印象をポジティブなアクティブにするために暖色を使用する
時間の配分
- 説明を受け、やってみたいことを与える時間を作る
- 1人で考える時間と2人でディスカッションする時間を作る
- 上記の繰り返しを行う
時間を意識するための施策
- 極端すぎるほどのロールプレイ
- 世界を狙う「数取器」
- リリースは明日。これは必達
場所・雰囲気
- わかったよりも楽しかったを優先
- いつもと違う場所にきたという緊張感と高揚感を与える
- チャレンジする場所
- 相談に乗ってくれる先輩は隣の人
- 1回のマインドマップを書く時間は10分〜15分くらい
- 思考の発散するための手法
- 今回はあえて縛りを入れて、よりテスト設計に向けた思考の誘導を行う
進め方
- 質問を受けたら負け
- 他に集中することがないように目の前のマインドマップに集中してもらう
必要な道具
- B3のスケッチブック
- カラフルな色のペン
- ふせん
スライド
続きを読むWACATE 2018夏に参加してきました。ワークショップで実験してきました。
さて、みなさまいかがお過ごしでしょうか？
いまさっき書き終わった記事が吹っ飛び、泣きそうな「なそ」です。
もう一回書く気力を私にください……
今回の参加レポートはいろんな方から上がると思いますので、わたしはワークショップで行ったチーム運営の実験話をしようと思います。
WACATEでは、夏・冬と年2回あり、夏は1つのテーマをどっぷりワークショップを行う。冬は色々なテーマをたくさんやる。そんな年2回のWACATEで「夏」です。ワークショップです！！中身は多くを語りません。他の人のレポートを見てくださいー
今回のワークショップでは、「なそ」ミッションと題して(個人の暗黙的なミッション)を行いました。そのミッションは3つになります。
- 個人タスクは極力減らす
- チーム全員が納得しながら進める
- 自分がいなくても、メンバーが主体的にワークショップを進められる
チームの雰囲気と行動をどうしていきたいかを、チーム内であげました。上はやりたいこと。下は見送る項目。見事にチームのみんなで一致しました。この時点で良いチーム！！
ただし、このミッションを行うために、支配者的なリーダーシップを行うことで達成することはできないです。それは全ミッションを達成できないのですが、特に3が達成できないためです。サーバントリーダシップで進めて行くのが理想でした。
特に進め方を決めるときも、「1回だけやってみようよ」と提案してます。もう一個の代案を提示したり、他の人にも意見を求めりもしています。トップダウンとも、ボトムアップとも言える両方が納得して進められるようにしたことで進め方の納得感が生まれました。生まれたよね……？
個人的な評価に関しては、できたと思っています。チームメンバーもそう思ってもらえれば嬉しい限りです。
最初はツイートで、パッと話をして終わりにしようと思ったんですが、なかなかな文字量になりそうなのと、繋がりがうまく表現できなかったためにブログにしようと思います。 (最初は他のチームとの違いを言いたかっただけだったので数回で終わる予定でした)
うちの班の読み合わせは、代表者が読み上げて、みんなで気になるところをあげて共有していくというほかの班との違いがあります。誰もなく#WACATE
— なそ@さとうひろゆき (@hiroyuki3gou) June 17, 2018
仕様書の読み合わせ
うちの班の読み合わせは、
- 個人で最初から最後まで目を通す
- 代表者が1段落を読み上げる
- みんなで仕様を共有する
- 繰り返す
私が普段やっている読み合わせとは違うチャレンジをさせてもらいました。普段は、各人で最初から最後まで読んだ上で、疑問点や指摘事項、気になる点をあげてもらいます。その後にチームで共有するという読み合わせをします。結構時間がかかるんですよね。
今回変えたことで、個人の作業時間を減らすことできました。また、各人が悶々と考えがちになる時間をチームの時間にしたので、すぐにチームの議論とすることができました。共有の時間が生まれないです。議論の時間＝共有の時間となります。
みんなで進める
全員で一つのモデルをやっていきました。全員で状態遷移図を書いたので、人によって粒度が違うことがないように対策できています。
- 状態を各人が3分で書き出す
- みんなで「せーの」で共有する
- イベントを各人で4分半で書き出す
- みんなで「せーの」で共有する
そうして出来上がったのは、写真になります。濃い青は状態。水色はイベントです。重なっているのは、各人が出した項目の被りや統合によって重ねてます。こうなると全員が納得して作っていますよね。全員で話ししながら作っているので！！
ただ、状態遷移図から状態遷移表に落とし込む時は、みんなが納得している状態である かつ 1人で作業した方が良いというチームの判断となっています。1人で作業した方が良いからだけではなく、みんなが納得している状態だからが前提条件になります。
巣立ちのとき
状態遷移図が書き終わった段階で約1時間くらい残っていました。ここから全員で状態遷移表やテストケースを書いてもよかったのですが、どうせなら次のモデルを実施してみたい。どこまでできるのかと思い、ユースケース図を書くことを提案しました。そして、ユースケース図を書くときに、私は一歩引いてみましたが、問題なく進み始めて無事にうまくいったと思います。
一歩引いた私は資料作りに専念しました。もう一人は状態遷移表を記載してもらいました。5人チームなので3人でした。特に何かをした訳ではないですが、ユースケース図を書くときにも、状態遷移図とやり方を一緒にしました。
- アクターを4分で書き出す
- みんなで「せーの」で共有する
- ユースケースを4分で書き出す
- みんなで「せーの」で共有する
あとは棒人間と矢印を書いて整理しました。ほとんど、状態遷移図とやっていることは変わりません。そのため、状態遷移表を書いている人もモデルとやり方を知っていれば進められるはずです。
どんなふうになったの？
こんな感じで進めた結果がこちらになります。
順番に説明していきます。
「気になること」は仕様を読んで行く中で、気になったことをあげて行く場所。
解決したら、右の「きまった！！きめた！！」に移動して赤字で記入。
状態遷移図を作る際にみんなで考えた資料です。これらを元に下の状態遷移図を書いたものになります。これらをみたときに不安点が上がってきたので赤い付箋を張っています。だって不安なんだもん。チームの重要なテストにしています。チームの不安な想いを解決するのも重要な要素です。
状態遷移図。途中で気になったことやイベントの間違いが書かれています。番号は状態遷移表へのトレーサビリティを確保しています。
逆光で見にくいですが、上の3枚はそれぞれの進め方を書いています。その下が状態遷移表とテストケースになります。付箋を使った表という発想がすごい！！
ユースケース図です。右はユースケースからテストケースです。操作手順とかはみんなで共有しているからそんなに詳しく書いていません。チーム内で共有して暗黙知になっているのは許容しています。
個人のタスクを極力減らすために
タイムキープでも、各人のタスクは、チャレンジ時間と追加時間を3分と言っているのに2分半にしたりと鬼畜な事もしましたが、だいたい間に合ってました。1回だけ伸ばしましたが、全体的に短くて問題ありませんでした。これは普段の作業時にも無意識のバッファを積んでいるかもしれないです。そこに意識的にバッファを積んでさらに時間を見積もっている可能性があります。これが悪いことだとは思いませんし、当然だと思います。実際の現場では絶対にしません。これはワークショップだからやったことです。
チームメンバーへ ごめんなさい。
最後に
これは、WACATEだからではなく、普段の業務でも一緒になります。誰かと一緒に働くことで、情報共有の時間も含めて考える時間になるので、私は好きです。現場のメンバーの多くがメンバーのタスクを把握している、お互いにフォローできる、仕様がみんなで共有されている状態になることが理想だと思っています。ここでの経験を現場に活かして、さらに良いチームを作れるようにしたいと思います。
それでは！！
(なんとか、書き上げることができた……)
テストケースのないソフトウェアテストについて考えてみる
どうも、お久しぶりです。
なそです。
追記：文章内で「テストケースのないソフトウェアテスト」＝「アドホックテスト」と定義していましたが、JSTQBの用語との乖離があるとの指摘を頂いたので、修正しております。
さてはて、ひさびさの投稿ですが、今回はこの話題について考えてみようと思います。なにかと話題に上がるテストケースのないテストの話ですが、下記の記事でも取り上げています。
この記事では「アドホックテスト」として、話を進めていますので、私もそれに則って、「テストケースのないソフトウェアテスト」＝「アドホックテスト」としていきます。行きません！！
この記事では、アドホックテストとしていますが、JSTQBの用語集では、アドホックテストは以下のように定義されています。
アドホックテスト：非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。
また、他にも、探索的テストがあります。
探索的テスト：非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者かテスト実施情報を活用しなからテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。
このブログは、ほぼアドホックテストになるので、アドホックテストとして話を進めますが、JSTQBの用語と違うのは、下記の赤字部分です。
- 非公式に実施するテスト
- 公式なテストの準備をする場合もある
- 実績のあるテスト設計技法をもちいない
- テスト結果を予測する
- 毎回、テスト方法が変わる
ここで、私がアドホックテストを考えるときは2つのポイントに注目します。それは、「テストする人」と「動機」です。アドホックテストで不具合を見つけたいのはもちろんですが、何かしらの不安があるのでテストすると思います。それぞれ考えてみましょう。
1. テストする人：どんな人がアドホックテストを行うのでしょう？
- とにかくたくさんの業種を問わない人たち
- 何度もリリースに立ち会い、いろいろな問題を解決してきた人たち
- テスト実施は何度も行なっているが、このシステムは未経験な人たち
- 新卒
- 上司に言われたからやる人たち
- よくわかんないけど、藁にもすがる思いの人たち
とかとんとんですね。
もちろん、それぞれで一つではなく、複数のテストする人がいることもありますし、5のようになぜかやることになっているからやるということもあるでしょう。6の人たちは、テストの勉強をしてもらいたいですが、そんな時間がないくらい切羽つまっているかもしれないですね。 また、テストする人たちも様々ですね。テストする人たちをもう少し大きく分類します。それは、アドホックテストの準備がどのくらい必要かということです。
この3パターンに分かれると
自立型は、期間とシステムと仕様書があれば、アドホックテストを実施できます。補助型には自立型と比べると、ヒントとなるものが必要になります。それがあればアドホックテストを実施できます。指示型は具体的な確認したいことやシステムの使い方があればアドホックテストを実施できるはず。
もちろん、どのパターンでもフォローは必要になります。
なその経験では、補助型や指示型に思いがままにアドホックテストを実施してもらうと重要度の低い不具合が上がることが多いです。特に画面表示に関する不具合が多い気がしています。
例えば、とある家計簿アプリのアドホックテストをしてもらったときに
- 家計簿アプリの金額欄に1000兆円入れたら、金額の欄の上2桁が表示されない
- 金額入力欄に小数点が入力でき、金額が小数点を考慮した計算がされる
一回の買い物で1000兆円使えるユーザーが家計簿アプリをアプリを使う確率は物凄く低いと思います。(っていうか、何を買えば1000兆円になるんだ！？) また、計算結果にエラーが出るのであれば大問題ですが、この場合であれば入力できるのが間違いという不具合になります。そして、このような問題は他の数値が入力できるところでも同じ問題が出る可能性が高く、不具合が大量生産されます。不具合は上がるに越したことはないかもしれませんが、このような不具合を大量に上げることによって確認で開発者の手を止めるのもまた私にとっては不本意でもあります。
では、補助型や指示型のパターンにはどういう実施をフォローをしていくべきかというと。補助型には、テストで確認してほしいポイントを渡すようにしています。
これを私が所属するところでは「テスト観点」と呼んでいます。粒度は細かいです。テストケースの一歩手前くらいの記述内容ですね。複数の業種のシステムを構成する要素を抽象化してまとめたものになります。って言っている自分が混乱しそう……。
例を挙げると、テキストボックスだったら
- 入力文字種(半角、全角、数値、記号等)が入力できること
- 入力桁数が入力できること。入力桁数＋1が入力できないこと
- 禁則文字が入力できないこと。Copy&Pasteでも入力できないこと
- ……
とかですね。もちろんシステムの表示部分だけではなく、見えないところのテスト観点もあります。
このテスト観点という言葉、色んな人によって考え方が違っていて曖昧な言葉でもあるので、私のテスト観点と読者のテスト観点が違うものになるかもしれません。
テスト観点に興味のある方はぜひ、テスト観点を語る夕べにご参加ください！ 一緒に語らいましょう♪ 次は2018年5月29日(火)です。語る夕べの雰囲気をお知らせしますね
指示型には、自立型の人と一緒にテストを体験してもらうのが良いと考えます。(その人が何も知らない状態でシステムを触ることで見えてくる課題があるとも思いますが、それはアドホックテストで確認することではなく、ユーザビリティテストで計画した上で実施するのが望ましいです。望ましいんですよ！！)
一緒にテストやってもらうといろんなことが起こるんです。テスト設計等の話でペアテストをやってもらったときのことをまとめてますので、よかったら参考にしてください。
補助型や指示型の人を参画させると余計な工数が取られてしまい、十分なアドホックテストができないと思う方もいらっしゃいますが、後続を育てる意味でも参画させる必要があると思います。(この辺も語りだすと止まらなさそうで本筋から外れるのであまり語りません)
次に動機について考えていきましょう。
2. 動機：なぜ、アドホックテストを行うのでしょう？
- アドホックテスト以外のテストでは詳細な手順を記載するが、記載しきれない仕様の不具合を見つけたい？
- 仕様に書かれたテストは十分だが、人の感覚や経験に基づく不具合を見つけたいから？
- 過去の不具合を参考にテストをしたいが、過去の不具合が資料として残っておらず経験者にも診断してもらいたいから？
- テストした環境とリリースする環境の不一致があり、不一致部分の不具合を見つけたいから？
- テストケースを作る工数がなく、なんでも良いから不具合を見つけたい？
- 気が進まないが、上司からやれと言われたから？
- なんかやればよいことがあるらしいから？
何をしたいのかはプロジェクトによって異なりますが、 それが定まっていないプロジェクトもありそうですね。何をしたいのかはしっかりと定めて不具合を狙いに行きたいです。
仕様書から作っただけのテストケースでは、当たり前品質の確認しかできないかもしれない。魅力的品質も含めて考えた場合、それはテストケースにも現れてくる。何を魅力的品質とするのかは組織やチーム、個人によって異なるので、ここではあまり触れない（というか触れたくない((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ）
1は仕様書を中心にテストしていく確認作業に近いですね。2はフローやデータのつながりを考えながら実施したほうが良さそうです。3は経験者や第三者検証に依頼したほうがよいです。4は以前やったテストを使いまわしても良さそうですね。5はそう思っているなら今すぐテストケースを書くための努力をしてくださいToT 6や7はアドホックテストで何がしたいのかをもう一度熟考してもらいたいです。何かしらの不安点があってこそのテストなので。会社に決めているからと言っても無駄な工数を使うためではなく、一番最初にはなにかの課題をクリアしたかったはずです。
で、こういうことを言っていると、「あ、じゃ、アドホックテストだけでよくない？」とか言う人がいるんですけど、ドキッとしたそこのあなた！その考え方は危険です。どうしてもアドホックテストだと、テストケースを使用したテストに比べて情報が残りにくいということがあります。残りにくいのは品質の測定のための情報です。この情報がないと次に繋がる一歩に繋げることができません。なぜかというと、どうしても直近のよかったことや困ったことはよく覚えているのに、数週間前や数ヶ月前の記憶は曖昧、もしくは忘却されてしまうからです。不具合として残る情報以外が闇に葬られてしまいます。
なその所属するテストチームは２週間単位で振り返りをしていますが、それでも直近数日の話が振り返りに上がることが多いですという経験則もありますし、皆さんはどうでしょうか？（チームの話は語り出すと止まらないので、別途記事にしたいと思います）
最後に第三者検証会社にいるとどうしても思った以上に品質が悪いという状況になってから参画することが多いです。「予定したテストを行ったが……」その状態から入ったときはアドホックテストを行うことが大半です。しかし、最初はアドホックテストを行い、並行でテスト設計を行ったうえでアドホックテストの比率を落としていく等の対策はもちろん行っています。ゼロにはならないんですけどね。
アドホックテストだけではなく、テスト設計をしたテストを行うことでお互いの良いところを掛け合わせて品質を高めていけます。アドホックテストと言う名前のテストを設けたからと品質が高まるわけではなく、それで何がしたいかどんな人をアサインできるかとかまで考えないともったいない工数になってしまいますねということで今回は締めさせてもらいます！
それでは、今回はテストケースのないソフトウェアテストについてお送りしました！
http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf
アジャイルの勉強について、なそのおすすめのアジャイル本
今年もよろしくお願いします！なそです。
今週のテストラジオで、アジャイルの勉強方法を話したところ、ワニさんからおすすめ本をまとめて欲しいとリクエストいただいたので、まとめてみます！
アジャイルの話をするときは、なそは相手の前提条件を元におすすめの本を用意します。大体は上から順番になります。
という訳で、簡単な説明とともに紹介していきますm(_ _)m
アジャイル初心者の方へ
SCRUM BOOT CAMPです。
この本はなんと！作中に漫画が書かれており、各章の進行は漫画ベースで進みます。
スクラム(アジャイルの一つ)の進め方を知って前提をつくれるおすすめの本です。文章は読まなくても良いので、まずは漫画を読んでみてください。その後に文章を含めてもう一回読むと内容を理解しやすいと思います。
アジャイルのプロジェクトの流れを知っている人へ
アジャイルでやっている各作業について知りたい方にはこちらをおすすめします。
上記の本で流れを知った上でこの本を読むと単品で読むより吸収率がよくなると思います。文章も軽く読みやすいです。この本の作者は「初めての自動テスト」を書いたJanathan Rasmussonさんです。本の中の絵が可愛いです。
ここから役割によって変わっていきます。「アジャイルサムライ」を読み終わった後にそれぞれきになる分野から読むと良いです。
アジャイルの中でテストを専門にしたい人へ
高いですが、アジャイルの中でテストを進めていく話が記載されています。量も多いですが、得られる知識は多義にわたるので、しっかり読んでみてください。自動テストのことも書かれていて、「初めての自動テスト」とかぶる部分がありますが、アジャイル×テストを知るにはこれ以上良い本はありません。
アジャイルの中でメンバーを育てたいしたい人へ
チームの中でメンバーを育てたりコーチングについて書かれています。
教育に興味ある方はぜひ！実践したら効果が高いものも書かれているので、何処かのタイミングでは読んでおいた方が良い本です。「作者の言葉」というコラムが多く、学びも多いです！
アジャイルの中で自動テストをやりたい人へ
アジャイルだけに特化した訳ではないですが、自動テストってなに？を知るためにはこれは最強の本です！ 上記に記載しましたが、「アジャイルサムライ」の作者が一緒でどちらか読んだことある人はぜひとも読んでみてください。
さらに自動テストを知りたい人へ
初めての自動テストを読んだ後におすすめなのが、システムテスト自動化標準ガイドです。より実践的な内容です。
アジャイルの中で小さく作ってチームを分けていきたい人へ
マイクロサービスが書かれている本になります。安定のオライリーさんですね。
本編中では触れていなかったですが、これも知っているとチームの分け方とかを考えるいい知識になります。
アジャイルを学んでいくことでおすすめの本を紹介でした。
それでは、なそがお送りしました！
料理を開発に例えて、テストについて考えてみる
※この記事は「ソフトウェアテスト Advent Calendar」12月25日の記事です。
家の壁に貼るホワイトボードを導入したなそです。好きなだけ書けるのはとても楽しいです。AdventCalenderの書くことをいろいろマインドマップで考えて今回はソフトウェア開発がよく例えられる料理の話を考えてみたいと思います！
何かに規模の小さなものに例えることで、大きなソフトウェア開発の全体を理解が進むと思っています。
きっかけ
さて、そもそもなぜこの話をするかというと、ソフトウェア開発におけるテストフェーズが料理における「味見」に当たるのが納得できていないということがきっかけです。ツィッターでは「味見」でした。「お毒見」とかもありました。
レシピを設計書、調理は実装となるっていうのはわかるけど、テストはどう考えればいいんだろう・・・。レシピを見ても具材わからんし、調味料とか無理だし・・・っていつも思う。
— なそ@さとうひろゆき (@hiroyuki3gou) 2017年12月17日
やっぱり味見がテストなのか？
料理と開発の工程を比べてみましょう。今回は夕食を作る場合を想定して開発に照らし合わせています。
工程(料理：開発)
- 食べたいもの：要求
- 作れるもの：要件
- 作るもの：設計
- 調理：製造
- 味見？：テスト
- 盛り付け：リリース
- 片付け：運用
こういう風に考えてみると確かに味見が該当します。そして、この味見はお惣菜(OSS)やコンビニ弁当(外部サービス)を買ってきたときには必要ないので、確かに味見がテストフェーズと言っても過言ではないでしょう。お惣菜をそのまま食べる場合は味見の必要がないですが(食べたらそれはつまみ食い)、ひと手間加えた場合、味見が必要になりますね。
QCD(料理：開発)
- おいしさ？：品質
- 夕食に使えるお金：予算
- 夕食の時間：納期
次はQCDを考えた場合、Qに当たる部分が人によって意見が分かれるような気がします。おいしさ度外視(言い過ぎ)で栄養のバランス、カロリー重視、手を汚さずに食べれる等々私が思いつく限りでも複数あるので、もっとありそうですね。予算、納期に関してはそんなに意見が分かれない気がします。
そもそもQが一つだけだとは限らないでしょう。複数の要素があるので、料理における品質特性(おいしさ、栄養のバランス、カロリー、彩り、温度等)を定義するべきでしょう。当然いま5つですが、ここに該当しないものもあるでしょう。家庭の夕食に厳格な栄養のバランスを求めていると予算と納期が大変なことになりますが、「1日30品目食べましょう」などはQCDを考える上で良いバランスに感じます。
結論？
料理におけるテストフェーズは「料理における品質特性」＋「家庭の伝統」を加味して家族が健康であることが担保できるような活動全般を指すのではないでしょうか？
その中の手法の一つが「味見」であるということです。味見は属人性を含んだテストにおける探索的テストですね。栄養のバランスとかカロリーは素材をカウントするので、テストケースで確認できるかもしれません。
余談１ 食べたいものがしっかり言えないと・・・
「今晩何食べたい？」とよく母親に聞かれたことがあり、何でもいいと答えていたのですが、よくよく考えると要求で「良しなに作ってくれ」といって丸投げしていたということですね。よくこのプロジェクトが失敗しなかったと改めて母親に感謝してますm(__)m
しかし、食べたいものが出てくる確率は低いことは確かでした。一緒に暮らしている母親でさえこうなるので、大人数がかかわるソフトウェアの開発では「ほしいもの」が完成することはまずないでしょう。「ほしいもの」を要求できなかったことでトラブルになった例はいくつもあります。この辺は有名ですね。京都市の場合は現在内容の確認中なので、何とも言えませんが可能性があると示唆されています。
余談２ 一汁三菜ってさ・・・
ご飯の基本は一汁三菜って、教えてもらいましたが、
- ご飯
- 汁物
- 主菜
- 副菜１
- 副菜２
ざっと見ただけでも、サブシステムが5つもあります。これを決められた予算と納期でしかも品質を担保しながらと考えると、無理な気がします・・・。っていうか普段料理する私も毎日は無理です。(せいぜい一汁一菜。茶色い・・・)
しかもこれらを考えながら、季節の食材や素材の数を横串で見ながら考えないといけないという。主婦はプロジェクトマネージャに向いているのではないかと本気で考えてます。
余談３ 作るもの・・・
料理のレシピは、材料と手順が書かれています。レシピがなかったら属人性を持った家庭の味になります。レシピ化することで人に教える、次に作る時にも同じ料理がつくれたりしますね。
「ぎゅーんとやって、スパッとひゅんとしてぐつぐつするとできるよ」じゃ伝わるものも伝わりませんよね。似たような話をテストラジオでも話をしています。
あとがき
余談のほうが長くなった気がしますが、ノルマ(テストラジオの広告)も達成したのでこのくらいにします！
料理の作業工程とソフトウェア開発の工程は例えとして優秀です。誰でも料理をしたことがあるので想像しやすいはず・・・。この例えは今後も使っていきたいと思います。
それでは、なそがお送りしました！
WACATE 2017 冬 ~すべてがTになる~ 参加レポート
どうも！なそです！！
ワカテーズハイという症状をご存知でしょうか？
WACATE2017 冬 ～すべてがTになる～ 開催概要 - WACATE （ソフトウェアテストワークショップ）
1泊2日で開催されるワークショップです。
ソフトウェアテストに関わる人たちが60名くらい集まる異色と言えば異色です。
そこでは２日間ずっとテストの話をし続けます。
その状態に慣れ、月曜日に会社に来ると周りよりもテンションが高くなっているのが「ワカテーズハイ」と呼ばれるハイテンション状態です！
テストラジオも今回のWACATEに触れてます。さらっと。
通常のセッションは、他の人に解説を任せて私はよりニッチな分科会をレポートします！
素晴らしく綺麗にまとめてくださっている人からリンクOKをもらったので、通常セッションを見たい方は、こちらをごらんください！！
WACATEは参加型ワークショップです。
参加者の自主性がかなり尊重されるワークショップでは、他では珍しい時間があります。
それは「夜の分科会」です。
語りたいテーマをぶら下げたオーナーの元に集まり、議論をするという形式です。ここにはWACATEの実行委員はあまり関与してません。オーナーを中心に議論をファシリテートしながら、意見をぶつけ合うのが分科会です。みんなで考える会です。
分科会のオーナーになるには、WACATE申込時に分科会のオーナーになりますと宣言するだけです！簡単！！
WACATEより引用
ディナーセッションが終わった後はその勢いのまま自分が語りたいテーマごとにグループにわかれ、フランクに議論をしていただきます。
恥ずかしがりやの方も人見知りの方も、遠慮なさらずテストについて思い切り語りあいましょう。
テーマはWACATEの参加申し込み時に募集しておりますので、語りたいテーマがある方はぜひテーマオーナーとして立候補していただければと思います！普段からの悩みや他のエンジニアに考えを聞きたいことなどを大胆に、かつ真剣に語ってみてください。きっと応えてくれる同士が見つかるはずです。
是非、想いのたけをぶつけてください！
参加者による分科会のため、WACATE毎にテーマが異なります。
その時に興味があることについて話をするので、その場限りになります。
そして、今回のテーマは5つでした。
- テストの妥当性
- 納得の提案
- BPPセッションの続き
- QAの立場
- テストの自動化についてなんでも答えます
そして、私は今回「テストの妥当性」のオーナーでした。
さて、今回なんだかんだで3回目のオーナーになりましたが、どうやってテーマを決めているかというとその時のトレンドを分科会のテーマにしています。
過去の分科会では、「教育」がテーマになってます。
今回とは別なテーマにしました。
テーマを決めた理由は、「テストの妥当性」について悩んでいる人がいたから。
そして、そのことに私自身が興味を持ったからですテーマにしました。
みんなどうやって折り合いをつけながら、テストしているのかなと。
分科会が始まると、気になるテーマごとに集まり議論スタートします。
今回はお悩み相談に近かったので、本人のヒアリングからスタートです。
ここでオーナーが注意しないと行けないことは大きく３つ
- 喋りすぎる人を止める
- 発言しない人に発言を促す
- タイムキーピング(時間は100分)
オーナーが最初の火をつけると周りから発言が出てきて、程よく火が大きくなります。
そうして、想像以上に思っていること、普段疑問に思っていること、疑問に思っていなかったけど人の意見を聞いて疑問に思ったことなどなど周りからいっぱい出てきます。
火がだんだんと大きくなってきた頃には、よく喋る人と全く喋らない人の２層に分かれます。この辺でオーナーがファシリテートしていきます。
が、今回はよく喋る人が喋らない人に発言を促してくれたおかげで、オーナーやることなくなりました。
それでも、議論を進めながらなので、届かないところもあります。
そこをフォローすれば良いだけなのです。
というわけで、議論がいい感じに進みました。
議論を進めていく中で、今回のお悩みは「テストの妥当性」「テストケースの妥当性」の２面があり、それぞれを切り分けて考えていく中で、取れる立場や状況。立ち回り方。失敗例。と教科書的な回答が出てこない！！ そこがとても面白い。
その中で、
- テストの妥当性では「テストケースによるテスト」と「探索的テスト」が必要
- テストケースの妥当性では「どこまでテストするべきか」を検討する必要
って話になったはず・・・（メモとか取ってないので思い出しながら書いてる。間違ったらフォローして！！）
テストケースだけのテストでは、カバーできる範囲が限られています。だからこそテストレベルを分けてテストすることでそれらをカバーする必要があります。
また、テストケースによるテストだけではカバーできないので、探索的テストを実施する必要がある。それもモンキーテストではなく画面の規模等で時間を割り振るタイムボックスの探索的テストとかをオススメしていました。
画面の規模等の話は何話したかを覚えていますが、ちょっとここでは割愛します。
いきなり「探索的テスト」をやりましょうでは、難しいのでまずはテストケースのテストを実施して、バグの傾向を掴む必要があります。（7原則の4：欠陥の偏在）その傾向に則って探索的テストを実施するのが理想ではと分科会メンバーでは落ち着きました。
そのためのメトリクスや情報を集めるのも重要です。的な話をして翌日のメトリクスのセッションにぶん投げた記憶があります。(ページ下部にリンクを貼っておきましたのでご覧ください。私も何やるかわかっていなかったので目的の情報が集まってなかったらごめんなさい。連絡くだされば一緒に悩みます(うぉい笑))
次にテストケースの妥当性では、どこまでテストすべきかは担当者やユーザー側にヒアリングを行い、その水準を満たすのをゴールに実施していくべきという話になりました。どこまでもテストケースは増やすことができます。（7原則の2：全数テストは不可）
その中で取捨選別を行うのは我らテストエンジニアでは決め切れません。経営判断やPMの意向等々が必要になります。100点の基準がわからないのであれば、決めるしかないです。その決め方は私たちから動いて決めてもらう。一緒に決めていく必要があります。
また、必要なケースを洗い出すためにはたくさんのテストケースをやるのではなく、効率の良いテストケースを用意する必要があります。テスト技法を使って効率を求める必要があります。ここは翌日の「直交表に触れてみよう（仮）」にぶん投げました。
（この仮はいつ取れるんだろう？これも下に貼っておきます）
他にもテスト技法があるので、ここは頑張って勉強してもらいましょう！！
オススメの本はこれ！
ただし、いきなり深く読もうとすると深淵を覗くことになるので（失礼なやつ笑）無理のない範囲で学習を進めるのが吉♪
という感じの100分を終え、どうだったんだろうな？
どこかで話を聞けたら嬉しいですね。
そんな分科会を開催しました。周りの人がどんな分科会をしたのか興味あるなぁ。
分科会のオーナーは、気になるテーマの話ができて、みんなの意見をまとめる練習がここではできます。
答えを持っている必要はないです。ニッチ過ぎても多少は大丈夫！！
飛び込んでみると世界が変わると思いますよ♪
実は、WACATEにはさらに分科会がありまして、深夜の分科会があります。
地方から来た人たちと話をする機会がないので、その集まりっぽくなりますがここでは、全国の猛者たちが暑すぎる議論を繰り広げたりします。お悩み相談もしてくれます。進路だったり、業務の悩みだったり。
（まぁ、夜の分科会の時点で0時近いので、そこから先は自己責任です笑 ただし、濃厚なテスト談話を聞けます。今回の深夜の分科会はワークショップがもう一個開催されていました）
ちなみに私はというと
いる人捕まえて、ラジオ放送をしていました。
そんな感じで夜が更けていきます。
なかなか夜の分科会のオーナーになった話というブログは見ないので、これをきっかけに分科会のオーナーが増えてくれると嬉しい限りです！
WACATEはレポートを書いてみんなでワイワイするのも一つのアウトプットになります。ワカテーズハイのうちにブログを書いて見ましょう！！
それでは、なそがお送りしました♪
WACATE セッションの資料はこちら
みんなのメトリクス 公開用 from kauji0522
