テスト分析とテスト設計勉強会に参加しました！（後編）

こんにちは！テストチームとのの（TW:@tono2587）です。
先日2017/02/03、「テスト分析とテスト設計勉強会」に参加してきました！
内容もりだくさんに思えたので、前編と後編で参加レポートをまとめました。
（前編のシェアありがとうございます！）

gtech.hatenablog.com

こちらは後編として、もう少しお付き合いください。

…。。。（テスト設計）

■勉強会の内容（後編）

□湯本さん：ゆもつよメソッドにおけるテスト分析とテスト設計
□河野さん：テスコン優勝事例におけるテスト分析・設計の解説
□まりまりさん：大学祭の模擬店でデザインの力を感じた話

□湯本さん：ゆもつよメソッドにおけるテスト分析とテスト設計

分析とは？
対象をよく理解すること。
知りたいことに沿って対象をわけて、再整理する

設計とは？
・仕様をもとにして対象物の骨組みを決めること
・構築するにあたっての課題を解決すること
・発明（創意工夫）すること

例：家の設計
①家の仕様：予算、2階にトイレ、など。
②家の設計：①を元にして設計図ができる。→家の骨組みができる。
＊ここにトイレを配置する場合、どんな配線（水道の）にするか？予算内でおさまるか？（課題解決）
③家の実装：大工さんが建てる

分析と設計を分けるのはなぜか？

◇全体像の理解が容易になるから。
「これをテストしてください」と言われたとする。
→なにをテストすればよいのか？？？となる。＊ここで分析が必要になってくる
→分析をすることで、必要なことがわかる（要件を理解する）
→それをどうすれば実現できるか考える…つまり、設計

◇分析と設計は求められるスキルがちがうから。
分析スキル：ドメイン知識が必要。
設計スキル：その問題についてはこういうカバーのしかたがあります、などの「引き出し」
カバー方法をいろいろ知ってる必要がある。

◇分析と設計の成果物も分けたほうがよい
仕様変更による修正から、テストのやり直しとかがやりやすいため。

「分析しなくていいならやらなくていい。それは難しいからやる。やったほうが効率がよい。」

□河野さん：テスコン優勝事例におけるテスト分析・設計の解説

◇このプレゼン自体も分析/設計をしました。それの例も出しながら解説
流れ：分析→設計→実装
何の集まりなのか、聴講者の人数は、会場の大きさは？→それに対する答え（分析）
分析結果をもとに、話の内容、その順番を決める（設計）

◇分析と設計とは？
・考えて、何かしらの成果物を出す行為
・知的変換の大きさが分析と設計では違う（分析は材料あつめ、設計は料理くらい違う）
・分析は世界の整理、設計は課題解決

◇わかりやすい例とわかりにくい例で、分析と設計を考える
・わかりやすい例：家を建てるとき
・わかりにくい例：テスコン事例

お家を建てるとき
分析：住む人の周りの世界を整理する（営業の仕事）
・両親と同居するか？自宅で仕事をするか？休日は何をするか？生活の導線は？和風/洋風？
・制約（土地の場所、予算、建築基準法）
聞き出して整理する

設計：お家の図面を書く（設計士の仕事）
・分析結果を満たすようなお家の構造を設計する

テスコンの場合
・テスト要求分析
・テストアーキテクチャ設計
・テスト詳細設計

まとめ
分析するために材料を用意する。その集めた材料で設計していく！

□まりまりさん：大学祭の模擬店でデザインの力を感じた話

模擬店でりんごあめと芋タルトを売りました
1日目：りんごあめ→2本で120円、芋タルト→大きいお皿に小さい芋タルトが1個で120円…
お客さんの声（え、りんごあめ2個なの？！い、芋タルトちっさい…）
＊売れない…

対策（このあたりが「分析」だったのでは？）
☆金額を下げる
☆りんごあめ2個問題
→「2個」だとちゃんと言おう！
☆芋タルト（ぼったくり）問題
・この大きなお皿に何個なら満足するのか？？
→在庫も捌けたいので、まとめ買いしてもらおう！

ーー看板のテーマを担当者に伝え、看板を描いてもらったーー

結果

大学祭の模擬店でデザインの力を感じた話 // Speaker Deck

資料の25〜
すごくわかりやすい看板になった！
→売上がのびた！！！！！

■参加後の気持ち

◇テスト分析、テスト設計ってなんだろう
　分析は、テスト設計するための材料あつめ。これからテストする対象について知る、整理すること
　設計は、それを実現するための方法を考えて形にすること
◇今まで項目書作成に時間がかかっていたのはなぜか？
　材料が十分に集まっていなかった。何をテストするかなど、整理できていなかった。
　なので抜け漏れが出て、その修正にまた時間がかかっていた。
　設計のスキルがそもそも足りない。…引き出しがまだ少ない。
◇わたしは何をすればいいのか
　やり方を変える：まず分析をする。
　知識を増やす：引き出しが必要なことがわかったので、仕様に対するカバー方法を知っていこう。

■感想/前後編のまとめ

　前編でもやもやしていた「分析」と「設計」がわかってきました。お家の例はすごくわかりやすかったです。
わたしは最近設計士の仕事が増えてきていたが、やっていることはいろいろすっ飛ばして大工に近かった、ということがわかりました。
現状が理解できてきたので、何をすればいいかもだんだんわかってきました。（上記）
まりまりさんがデザインの力で問題解決したように、この分析→設計の流れをおさえておけばテストという形でなくても使えそうな考え方だと思いました。
いろんな学びがあったので、仕事がよくできそうです！！！
よいアプリへの力になれますように！応援よろしくお願いします〜〜！
やる気のアップしたとののでした。ではまた

WORKS | 株式会社ガラパゴス iPhone/iPad/Androidのスマートフォンアプリ開発

ブログの極意を教わったのでかいてみたよ

こんにちは！テストチームとのの（TW:@tonono2587）です。 先日2017/01/30,バンさん（ GitHub:@vanhuyz ）と一緒に勉強会に参加してきました！ このエンジニアブログも試行錯誤しているところなので、参考になりました。感想などまとめましたので、ぜひ読んでください。

ブログかくのも真剣（必死）ですよ…

参加した勉強会はこちら↓

「サポーターズ勉強会 エンジニアのためのブログ講座」
【学生＆若手エンジニア向け勉強会】エンジニアのためのブログ講座 - connpass

2017/01/30 19:30〜 @渋谷サポーターズオフィス
講師：田中賢治さん

■内容

エンジニアのためのブログ講座で講師をさせていただきました！ ｜ Developers.IO

ご自分のブログで、レポートをあげてくれていました。内容はこれがすべて！って感じです 笑
そのなかで、わたしが個人的にいいなと思ったところをまとめます。

［気持ち編］

■自分にとってブログを書くメリット
・自分の理解を測り、深める…知識のアウトプット先、インプット元になる
・知人が増える

■自分以外の人にとってのメリット
・ハマるところはだれしもハマる。そんなときの助けになる
・書いている人からモチベーションをもらう

［書き方編］

■習慣化の方法
・とにかく小さい単位でつづける…少しでも、やってみた→どうなったの繰り返し
・他の人とかぶっても気にしない。自分が書くことに意味がある
・書きたいときに書く！
■装飾をうまくつかう
・リンクの貼り方や文字の装飾など、意味を知って効果的につかう
■目次から書いてみる
・目次を先につくり、テンプレート化する
・それに沿って書くと書きやすい

［ということで、やってみた！］

「目次から書いてみて、テンプレート化する」
たしかにこれなら早く書けそう！！と思ったので実践してみます。

こんな目次をつくりました〜
・バンさんと行った
・日時
・内容
・やってみた
・感想

すごくざっくりしているので、「内容」のところを書きながら細かくしていった感じです。
自分のメモを読むときにも整理しやすくて、はやく書けている気がします！
（ここまでで30分かかってない）

結果：「なんかはやく書けてる！気がする！！！」

［感想］
現実的に言うと、いままでの2本は書き始めてから1日以上、3日くらいで完成だったと思います。
話を聞いて、コツみたいなものがあるのかな〜となんとなく思いました。そこから「書ける！」気分になっていきました。
これからブログを始めようとしている方々とも交流できて刺激になりました。
そのとき弊社HPを見せてドヤ顔したのですが、なんとこのブログへのリンクがないことに気がつきました∑(*`ﾛ´ﾉ)ﾉ
近々HPにリンクを貼ってもらう予定ですので、応援よろしくお願いします〜！！

ドヤ顔できるガラパゴスHPはこちら

www.glpgs.com

それでは、またお会いしましょう、とののでした〜

テスト分析とテスト設計勉強会に参加しました！（前編）

こんにちは！テストチームとのの（TW:@tono2587）です。
先日2017/02/03、「テスト分析とテスト設計勉強会」に参加してきました！
同日〜翌日のJaSSTには参加できなかったのですが、この勉強会はわたしにとってたいへん学びがありましたので、参加レポートとしてまとめたいと思います。

ふむふむふむふむ

■「テスト分析とテスト設計勉強会」

2017年2月3日（金）@日本大学駿河台キャンパス
め、めずらしいつくりの建物でしたよ（迷ってないよべつに全然）

https://connpass.com/event/47938/connpass.com

教室がけっこう埋まっていたように見えたので、参加者は多く感じました。

■参加前の気持ち

動機や興味、自分のなかでの課題や知りたかったことのイメージです。
・業務でテスト設計することが増えてきた
・あんまり上手く設計できていない気がする（レビュー戻り多い）
・絶対もっとなんかいい方法があるはずだ
・「初心者向け」←わたしのことか。呼ばれている

■勉強会の内容（前編）

□秋山さん：JSTQBのテストプロセスについて
・「プロセス」とは何か
　相互関係のある活動のセット。（活動は入力を出力に変換すること）
活動の例：＜（入力）お湯にパスタを入れる＞−［（活動）煮る］−＜（出力）柔らかくする＞
プロセスは、このような［活動］のセット
・JSTQBのいう「テストプロセス」とは何か
　基本的には、
　［①テスト計画とコントロール］−［②テスト分析と設計］−［③テスト実装と実行］−［④終了基準の評価と報告］−［⑤テスト終了作業］
によって構成される。
・これらの①〜⑤のテスト活動は、開発と整合している必要がある。
　システムテストレベルでいうと、
プロジェクト計画と同時にシステムテスト計画を始め、
要求仕様→システムおよびアーキテクチャ設計仕様→コンポーネント設計仕様と並行してシステムテスト分析および設計をおこない、
…以降も開発の活動と並行して行う。

・テスト分析、テスト設計とは？
　・テスト分析とは：テストベースを分析すること。テスト条件を識別する。
入力：テストベース…仕様書、議事録などテストをつくるもとになるもの。これはドキュメントで、レビュー済みの整ったものをつかうのがよい。
活動：テストベースとテスト目的を分析する…ユーザーはなにをしたいのか（目的）など
出力：識別されたテスト条件…いろんな粒度で定義することが望ましい。画面（粗）、画面の部品（細）、など

　・テスト設計とは：
入力：テスト条件
活動1：テスト条件をどうやって網羅していくかなどを決めていく
活動2：テストケースをつくる。どういうテスティングで確認するのか、どういう環境でどういう期待値で…
出力：テストケース

・構造化分析と構造化設計について
　開発と同じでテストも、いきなりコードを書いていたが、ループするところとかは構造化しましょう、となっていった

『構造化分析とシステム仕様』トム・デマルコ 著 によると、
　・分析とは、行動をとる前に実施する、問題の調査である
　分析の最も重要な生産物は「仕様書」である。分析をすることで具体的にしていき、それが「仕様」になる
　分析の後に続く行動とはそのシステムを構築することである。

　・設計とは、手続き的な部分（順序）と、階層的な部分を決めて、構築することである
　トップダウンで分割して順番と階層を決めて、ものをつくっていく

ーー質疑応答より
・「テストは条件次第」
　テスト対象に従って、どんな要求があるのかを確認して決めていく。
　→先にものさしを決める。

・テスト条件が様々な粒度で定義することが望ましい理由は？
　人によって（立場などによって）みているものが違うので、お互いに合意をとるためにも必要になるから。
　（共通言語みたいなもの、というイメージでしっくりきました。）

□藤沢さん：テスト分析・設計について、釈然としないところ

・テスト分析も、設計も、要するにどんなことを言うのか？→わけなくてよくない？
・仕様書のコピペはばぜだめなのか
→仕様書に書いていないことをテストに入れるべきだ
・「テスト」も「分析」も曖昧だからくっつけてもわかんないのでは？
・「分析」ってなんだ？…理解できるようにわけることなんじゃないか。
＊分析 のアウトプットが曖昧ではないか？どこまでやれば「分析」が終わっているのかわからない
・分析しないと困ることは？
　・分析しないと仕様が曖昧だから、必要なテストが漏れる
　・なにをテストしたのかわからないことになる

・藤沢さんのいまの感じの定義
分析：グループにわけてわかりやすくすること
設計：テストケースの元ネタをつくること
実装：元ネタ（設計）からテストケースを作成すること

・テスト設計をしないと困ることは？
　・仕様書のコピペでテストケースをつくると、なんでこのテストケースなのかわかりづらいし、説明が不足する
　・なんでこのテストで十分なのか説明できない

・分析と設計、どっちかが欠けるとかはなく、セットなのでは？？？
・どこからどこまでが分析/設計なの？

・結局、分析/設計はなにがしたいかようわからん！！

■前編までの気持ち

秋山さんのお話で、教科書的な「テスト分析」と「テスト設計」を知ることができました。
テスト分析やテスト設計といった言葉の意味自体ぼんやりとしていたので、お話を聞いて形がつかめてきた感じがします。
それをふまえて自分の仕事を振り返ると、テスト分析が全然できていないこと、テスト設計も上手くいっていないことがわかりました。
だからレビューの戻りが多いし、時間もかかるのだと思いました。

なんとなくつかんできたと思っていたところでしたが、藤沢さんのお話にはなんだか説得力があって、
「どこまでが分析なんだ」みたいなところはとくに（ああ…たしかに…？？）と納得してしまい
(((分析)))や(((設計)))がまたもやもやしたものに…
このお話があったお陰でこのあとすごくスッと話が頭に入ってきたのですが、この時点では正直もやもやした理解しかありませんでした。

後編へつづく