このもやもやがかなりあって、それについて（話題は「プロセス改善」でした）オンライン飲み会で話を聞いてもらいました。
そのなかで、「レビューアの机の上にこの本置いてみたら？」とアドバイスをもらいました。
タイトルと「机上にそっと置く」から察するところはありましたが、実行するにもまだ読んだことがなかったのでとりあえず読んでみることにしました。

読んだタイトル『間違いだらけの設計レビュー』

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

間違いだらけの設計レビュー改訂版なぜ重大な問題を見逃すのか？ [ 森崎修司 ]
価格：3024円（税込、送料無料) (2018/11/30時点)

本の内容

簡単にいうと、
間違ったレビューをしていませんか？しかも間違ったやり方をそのままにしていませんか？
どうしたらレビューを改善できるのでしょうか、という内容だと理解しています。

1章では現場で起こりがちな「間違い」の例を、
2章ではその対策として効果的なレビューの手順を準備から問題検出まで、
3章ではその続きの問題指摘から修正まで
4章でレビュー自体の改善、見直し方法

が書いてありました。

読んでみて

もう1章からめちゃくちゃ刺さりました。
ここであげられている間違いレビューの例が、わたしのもやもやと似ている気がしたのです。
例えば、典型的な間違いレビュー「思いつき」「数字合わせ」「つるし上げ」について。
↓

【思いつき】
レビューアーごとに観点がバラバラ。誤字脱字のような軽微な問題が多くなる
→重要な問題の指摘が少なくなる

【数字合わせ】
問題の指摘件数ばかりに注意がいく、指摘件数でのみ管理する
→重要な問題の検出が疎かになる

【つるし上げ】
指摘するうちに作成者への人格攻撃へエスカレートする
→つらい

ここで言われていたのはどれも、レビューの目的を見失っているということでした。

もやもやへの光（振り返り）

レビューアの名誉のためにも断っておきたいのですが、
内容にわかりみが深いというだけで、実際に（このようなつらい思いを）経験したわけではありません。
この本を読んで響いたのは、レビューの目的を見失ってはいけないな、ということです。
もやもやを振り返ってみると、

たくさんコメントついちゃった。。
　　→大きなヌケモレがないか、「ざっくり」みてほしいとのの vs 「きちんとしたドキュメントであるべき」レビューア
内容は理解できるけど、なんか納得できないなぁ…
　　→レビュー目的の認識がお互いに合っていない。とののからきちんと共有できていなかった。
これ全部なおさないといけないのかな
　　→認識がズレたまま無理やりレビューの流れだけ進んでいっている。。
細かいとこなおすよりテストはじめたい。。
　　→時間が短いからサクッと終わらせたいことも共有してない。大事なことはなんだっけ？？

他プロジェクトで「レビュー→なおす」のある程度決まった流れがあったからこそ、なにも考えずその流れに乗せてしまっていました。

どうしたらよかったんだろう？（反省）

まずは、目的の共有をすべきだったと思います。

背景や状況（期間短い、サクッとやりたい）
いつもと違う（形式はゆるくていい）
ここを見てほしい！（ヌケモレがないかチェックしてほしい）

目的の認識合わせをしたうえでそれでもズレてしまうなら、こういう意図だったんですが、という説明もできたなぁと思います。
（今回はズレていることもわからずもやもやという形で残ってしまいました。）

まとめ

これを読んで、わたしなりの学びは以下のようになりました。

レビューの目的を見失うと、つらいレビューになる
悲しいけど目的喪失はよく起こる
見失っていないか常に気をつけよう！！

この本には他にも目的を見失ってしまった失敗例や、
失敗を起こさないための効果的な手順がのっていたりします。
「問題検出」と「問題指摘」は別、とか
ネガティブなマインドを持たないことは「心がけ」ではなく、レビューアに必要な「スキル」です。とかとか
納得できる内容盛りだくさんでした。

レビューでつらい思いをしたことがある方
レビューがうまくいっていない自覚があるレビューアさん
レビューにネガティブな感情を連想してしまう方

ぜひ読んでみてはいかがでしょうか。

間違いだらけの設計レビュー改訂版なぜ重大な問題を見逃すのか？ [ 森崎修司 ]
価格：3024円（税込、送料無料) (2018/11/30時点)

さいごに

本は机へ置かずに済みました、ありがとうございました。
アドベントカレンダー3日目へつづく…
ぷったーさんお願いします〜(^o^)ﾉ http://yoshikiito.net/blog/

qiita.com

2018-10-18

iPhoneで通信環境をわざと悪くしたいときのこと

再投稿記事 QANote

発掘記事です。
わざと接続環境を悪くしたいとき、iPhoneの「デベロッパ」の機能をつかうとその環境をつくりだせます。
わざわざ電波の悪い場所を探さなくてもOK！
Developer＞NETWORKING_Network Link Conditioner＞EnableをONにする

2016/11/07

iPhoneの通信速度を変更する iPhoneで通信速度をあえて遅くしたいとき！

方法

この記事がわかりやすいです https://www.lancork.net/2014/04/ios-dev-how-to-change-network-condition/

「デベロッパ」が設定にないときは？

まとめ

設定 →デベロッパ →NETWORK LINK CONDITIONER 　→Status 　→EnableをON（緑）　→速さを選ぶ

注意

検証し終わったら必ずもとに戻すこと！！！

2018-10-15

テストマスターへの道第3回狩野モデル

再投稿記事ソフトウェアテスト学習

過去記事の再投稿です。

2016/10/06
テストマスターへの道第3回狩野モデル
テストマスターになりたいとののが勉強した記録です。
9/15のチーム会で発表した内容になります。

今回のテーマ：狩野モデル

『ソフトウェアテストの教科書』のPART1 ソフトウェアテストの基礎のところを読んでいて、
前回の第2回ビューティフルなテストに通じる考え方だなと思いチーム会で発表共有しました。

狩野モデル

テストに限らず、商品企画などものの品質を考えるときに使われる考え方
狩野さんが考えた
ユーザーの要求に応じて品質を分類するという考え方：大きく3つ→当たり前品質、一元的品質、魅力的品質

■例えば：携帯電話

当たり前品質→電話ができる（できて当たり前）
一元的品質→バッテリーの持ち（長ければうれしい、短いと不満）
魅力的品質→音声がめっちゃきれい（あるとうれしい）

このように分類して考えてみることで、検証の力の入れどころや、検証の質としてもどうだったのかを捉えられて
→ビューティフルなテストになる！とわたしは解釈しました。

チーム会より

テストにも当てはまる：大事なところがわかるので、「木を見て森を見ず」のようなことが防げる
経済の勉強とかでも出てくる
ラーメンつけ麺狩野さんはイケメン？（親しみやすさ）

出典

マーケティングのキーコンセプト http://macs.mainichi.co.jp/space/web/063/marke.html
狩野モデルと商品企画 https://www.juse.or.jp/departmental/point02/08.html
チーム会発表資料

あまりうまく伝えられなかったのですが、個人的には「狩野モデル」しっくりきています。
テストマスターへの道のりはつづく。。。

2018-10-14

テストマスターへの道第2回「ビューティフルなテスト」

再投稿記事ソフトウェアテスト学習

過去記事の再投稿です。

テストマスターへの道第2回「ビューティフルなテスト」
テストマスターになりたいとののが勉強した記録です。
2016年7月5日

今回のテーマ：ビューティフルなテスト

図書館でタイトルに惹かれ『ビューティフルテスティングーソフトウェアテストの美しい実践』という本を読みました。

本の概要
2章「ビューティフルテスティングは、ステークホルダーを満足させる」
まとめ
出典

本の概要

この本は、テストのプロフェッショナルたちが編み出したテストの極意、「美しいテスト」について語るものです。

豊富な経験やユニークな見解をもつ人物に焦点を当てた「テスター」、試行錯誤の末に到達した「プロセス」、すばやく効率的に行うための「ツール」という3部構成で、書き手自らが確率したテストの極意を実例を上げてわかりやすく解説します。

と裏表紙に書いてありました。
眺めるとわかるのですが、2部と3部は特にエンジニア向けという感じで、私は正直ほぼ意味がわかりませんでした。（諦めた）
その中でも意味が理解できて、なるほど〜と思った、
第1部2章「ビューティフルテスティングは、ステークホルダーを満足させる」
についてまとめます。

2章「ビューティフルテスティングは、ステークホルダーを満足させる」

この章では、「ビューティフル」を「満足」だとして、それはどのようなテストであればよいか、的なことが書いてありました。

「誰が」満足するかを明らかにする。誰＝テストステークホルダー

ビューティフルなテストをするためにまずは、誰に対するテストなのかを明らかにしましょう。
筆者は満足させる人々を、テストステークホルダーと呼んでいます。
テストステークホルダーとは、テスティングと、その最終的な成果物の質に対して、利害、関心、影響力などを持つすべての人々のこと。
例えば、テスター本人、開発メンバー、プロジェクトマネージャー、ユーザ、スポンサー、など。

「何が」満足させるのかを知る

それぞれのステークホルダーは、テスティングをする目的と、期待するものを持っています。
誰が満足するかがわかったら、その人のテストの目的と期待を明確化しましょう。
これが不明確だと、ビューティフルなテストになるかは運任せになり、ごくわずかなステークホルダーしか満足させることができません。
ステークホルダーと合意形成ができていれば、「有効で、効率がよく、エレガントなテストとは何か」がわかり、美しいテストが実施できるのです。
有効に：各ステークホルダーの目的と期待を満足させること。
効率よく：投資したリソースから最大限の価値を生み出す方法を通じて、目的と期待を達成すること。
エレガントに：有効さと効率を、手際よく実行すること。

外面的な美しさ

誰が何に満足するかを明確にしたら、具体的にどのくらいやれば満足なのか、を考えます。

　- 存在しているバグのうち、実際に検出したバグの割合は？ - バグ全体における重要なバグの割合は？ - バグ1件あたりの検出・修正に要するコストは本番環境で障害が1件発生する場合と比べてどの程度か？

例えば上記のような質問に答えるために、指標をつくります。
(((計算式が書かれていましたが、よくわかりませんでした)))
また、コストを測定する方法として、CoQ（Cost of Quality：品質コスト）があります。
これにより、テストや品質に関する以下の3つの主要コストを明らかにできます。

検出コスト　- バグの検出がゼロだとしても発生するテスト費用。
内的障害コスト　- バグ検出のみに起因して発生する、テストおよび開発コスト。バグ報告の作成、バグ修正、修正の確認テストなど
外的障害コスト　- 提供した製品にバグが存在することに起因するコスト。テクニカルサポート、保守、維持のための費用

こうした指標によって、ステークホルダーの満足を達成する方法と、達成度を測定する方法をしめすことができます。

内面的な美しさ

ビューティフルテスティングについてもうひとつ検討するべき要素が、内面的な美しさです。
例えば、テスト工数のかなりの割合を手動での回帰テストに費やすと決めたとします。

　○自動化した回帰テストの割合は？　○回帰関連の品質リストのうち、網羅できた割合は？　○自動化によって、手動よりどの程度早く回帰テストを実行できるのか？

(((これを指標にする計算はやっぱり意味わかりませんでした)))

ここでは、テスティングの目的と期待を内部の観点から設定することで、仕事をよりよく、速く安く賢く行うためにテスティングを測る方法を示します。

まとめ

ステークホルダーが満足するビューティフルなテストをするにはどうすればよいか！

ステークホルダーを知ります。
ステークホルダーにとっての、テスティングの目的と期待を知ります。
ステークホルダーの目的と期待を達成するための、メトリクスと目標を設定します。（外面的な美しさ）
テスティングの目的と期待を達成するための、メトリクスと目標を設定します。（内面的な美しさ）

いままで考えたことはありませんでしたが、
この検証は成功だった！と言えるとすれば、たしかにこんなふうに誰にとってどのくらい達成した、と言えれば確実に成功なのかなと思いました。

出典（読んだ本）

『ビューティフルテスティングーソフトウェアテストの美しい実践』
Tim Riley,Adam Goucher
大西健児(監訳),児島修(訳者)
オライリー･ジャパン,オーム社
2010年10月25日

2018-10-13

テストマスターへの道第1回：テスターの適性

ソフトウェアテスト学習再投稿記事

社内Qiitaに投稿したりした記事をあつめてきています。
ちょっと直しながら再投稿しています。

2016/05/13
テストマスターへの道第1回：テスターの適性
テストマスターになりたいとののが勉強した記録です。

今回のテーマ：テスターの適性について

まずは
くわしく
まとめ
出典、参考

まずは

診断チャートをつくってみたので、やってみてください！

くわしく

『ソフトウェアテスト実践ガイド』によると、

テスターの素質については、

その1：体力に自信があること

テストは長丁場になることが多く、時間がかかり、単純な作業も多いため。

その2：忍耐強いこと

同じ理由で、メンタルの体力（忍耐）も必要

その3：素直だが、ひねくれてもいること

事実は事実として客観的に素直に受け入れた上で、その事実が真実なのかどうかをきっちり見極める目をもつこと。
不具合がみつかったとき、その背景を含めどういった現象なのかを観察し、特性を把握しなければならない。
その上でそれが表出している現象だけなのか、ほかに影響がないかなど、いろんな角度から検証できるかどうか。「鼻が利くかどうか」これには経験が必要。

その4：好奇心旺盛なこと

不具合の臭いに敏感な鼻をもつために、経験を積むためにも必要。
「どうなっているの？」「こうすれば、どうなるのだろう？」「分からないといらいらする。くやしい！」ただしほどほどに。熱中し過ぎると効率がよくない。

だそうです。

次に適性については、

細かいところまで目配りができる
ダメなものはダメとはっきり言える
時として大胆
複数の角度で物事をとらえられる
横同士のコミュニケーションが上手

といったことが挙げられるようです。
テストエンジニアの国内の男女構成比は男性が多く、IT産業全体とかわらず、ほぼ3:1。
国外の、テストエンジニアという職種が確率している米国ではほぼイーブン、もしくは女性が多いそうですよ！

『基本から学ぶソフトウェアテスト』による優秀なテスト要員のもつ素質や能力

誠実さ、そして品質に対する責任感
理論よりも経験をもとに根拠を見つける能力
教育（高いほどよいそうです）
プログラミングの経験
コンピュータやソフトウェアの豊富な利用経験
組合せ論についての知識
優れたコミュニケーション能力や高い文章能力

『基本から学ぶテストプロセス管理』による良いテスト技術者の条件

プロフェッショナルな悲観主義
バランスの取れた好奇心
熱中型の人はダメ
見当違いの野心を持っている人はダメ
怠け者はダメ：ある程度怠け者でないと効率のよいテスト実装、実行をしようとしないのでほどほどに
臆病者はダメ：ある程度臆病でないと入念なテスト設計や実行にはつながらない

まとめ

テスターの適性を知ることで、テスターとして必要なことがわかってきました。わたしは熱中しすぎてしまうことがあるので、ほどほどに、客観的に、というところも身につけていきたいなと思います。知識もあればあるほどよいようなので、まずはこの本を読破するところからはじめていきます！

出典・参考

『ステップアップのためのソフトウェアテスト実践ガイド』 p.135〜第3章テストマスターになろう大西健児/日経BP社

2018-06-18

WACATE 2日目終わった！

WACATE ソフトウェアテスト勉強会

WACATE 2018夏の2日目が終わりました！！

WACATE2018 夏プログラム内容 - WACATE （ソフトウェアテストワークショップ）

しおしおになったので後夜祭を泣く泣く見送りましたが、ちょっと休んで復活してきたのと、きのうはその日のうちに記事アップできたから今日もできる！と思ってかきはじめました。
加速！！！ﾋﾞｭﾝ

早起きの思い出

WACATEは1日で終わらない。2度めの早起きの試練。。。
起きれた！えらい！！！！！

f:id:tonono:20180617215156j:plain:w400 — おむすび

がっつりワークの思い出

今日はとにかくとにかく班でワークをやりました。

お題発表
成果物はこれ出してね
スタート！！！

（あっはじまった）

具体的にやったことはすでになそさんがまとめていらっしゃいました、ありがとうございます。

devtest.hatenablog.com

ワークしつつ思ったことは、

1回自分で仕様を読んだつもりでも、他の人の「気になる」ところを聞くとまた自分でも「気になる」ところが出てくる
気になるところの全部を解決しなくても、先にすすむことはできる
必要な角度で、必要な分だけ区切って見る（捉える）のができていない？
0スイッチカバレッジ！！！！！
やっぱり頭のなかだけではわからないことだらけだな

具体的にどういうことかっていうと、

1回自分で仕様を読んだつもりでも、他の人の「気になる」ところを聞くとまた自分でも「気になる」ところが出てくる

ワークのはじめにもメンバーにはちょっと言ったのですが、わたしは端から端まで仕様書を読むみたいのは要らないと思っているフシがあります。
「必要になったタイミングで、必要なところだけ読めばいいのでは？」と…
あまり深く考えずに言ったら、「状態遷移図を書いたりするには、やっぱり1回全部読まないと書けないよ」と言われて、
たしかに図とかを書こうと思ったら、いちいち仕様書と照らし合わせるよりも全部を読むほうが早いか〜〜となって、全部読もうと思いました。
（伝わらないかもしれないですけど、めちゃくちゃ納得して全部読んでますよ？！）
各自で読む→みんなで丁寧に読む、と続くなかで、仕様はしっかり頭に入った！と思っていたのに他の人の「気になる」点からどんどん（あ、そっか）（ならこれは？）（？？？）みたいにどんどん気になってしまって、
（全然仕様把握してないやんけ！！！）とあわあわしました。

ただ、仕様把握のために端から丁寧によみ続けて、全〜〜部気になることを出しきればいい！とはなりませんでした。

気になるところの全部を解決しなくても、先にすすむことはできる

あとからわかったのですが、これです。
気になることはたくさんあがった中で、「決め」が発生してテストにつかったのはごく一部でした。
ひとつずつ解決しないとテストできないと勝手に思ってしまっていたので「決めなくてもいい」ことがわかったのは気づきでした。
論理的ではないかもしれないしうまく言えるかわからないんですが、
全体を読まないとつくりはじめられないんだけど、切り口によってはどうでもいい（考えなくてもよい）仕様があって、不明点がたくさんあるから仕様わかってない→モデル作成もテスト作成も無理→ではなくて、不明点に全部付き合わなくてもいい、というか。。
だめです、書いても整理できないという悲しい能力を発揮してしまいました。さらなる気付きがくるまでそっとしておいてください。。

強引に次へ

必要な角度で、必要な分だけ区切って見る（捉える）のができていない？

状態遷移図でイベントをみんなで出し合ったときに、わたしの考えたイベントは必要ないものばかり揃ってしまいました。（オフライン、とかメアド取得、とか）
システムの内部？外部？のことを考えすぎててまた「それはいま考えなくていい」状態でした。
同じお題で2種類の状態遷移図を描いた班もありました。同じモデルでも要るものといらないものもあるし、モデルが別だから要るものいらないものもあるっぽいので、完全に自分のなかでそれらがとっちらかって区別できてないことがわかりました。
これって単に練習あるのみなんでしょうか？
まだ解決できてない問題があるのでしょうか？
これについてもひきつづき考える必要がありそうです。

0スイッチカバレッジ！！！！！

前日の話の中で、「Nスイッチカバレッジ」の話で急になんのこっちゃわからんになってしまっていました。
なので基準を決めよう、という段階になったときはハラハラしました。わからないんですもの〜〜
ループがある場所はNスイッチを検討したほうがよい？
隣り合う状態が問題ないことをぜんぶたしかめるのが0スイッチカバレッジ
「なんのためにその基準を選ぶか」を考えたほうがいい
など説明してもらいつつ進めていて、
「このテストで大事なところ」と「その状態同士が隣り合ってる」が重なったとき、0スイッチカバレッジだけはほんのちょっとわかった気がします！！！たしかにピンときた瞬間があったんです！Nスイッチはもうちょっとかかります！！

やっぱり頭のなかだけではわからないことだらけだな

そして、ワークで気づいたことはつまりこれなんですが、
意見出し合ったり、モデルを描こうとしたりたくさんして、形にしようとして初めて気づくことがあったのでこう思いました
ただブログとしてモヤりを言語化してもわからないことだらけなので、
今日のこの記事とかを振り返りつつまた考える時間が必要です。

今回ですが完全にまわりに影響されて無理やりにでも2日目のことを公開せねばならぬと思い公開しました！！！！！
書けてないこともあるし、またぼちぼちやっていきます。
まず2日間お疲れさまでした。

2018-06-17

WACATE1日目はじまった！

ソフトウェアテスト WACATE 勉強会

WACATE初日はじまりました！！

WACATE2018 夏プログラム内容 - WACATE （ソフトウェアテストワークショップ）

早起きめちゃくちゃ心配でしたが無事起きられました。えらい！！！

f:id:tonono:20180616235822j:plain — 海だー！！！！！

各セッションの内容は先輩方がきれいにまとめてくれるようなので、
わたしからは思い出を公開していきます。アルバムを眺める感覚でお付き合いください。

ポジペの思い出

参加の必須条件として、「ポジションペーパー」の提出があります。
これかくのめちゃくちゃ苦労しました（物理的な意味で）。。（これ前も言ったかも）
どうやらわーどがあるとサクッといけたようなのですが、今後参加する方でわーど環境ない方はほんとにはやめの着手をおすすめいたします。時間かかります。
苦労はしたものの心は込めて書いたので、今日のセッションではたくさん話す時間をいただけたのでうれしかったです。
みなさんからもバックグラウンドがわかったり、いろんなお気持ちを知ることができたので楽しい時間でした。

ユースケース図&アクティビティ図の思い出

ユースケース図、アクティビティ図の基本的な描き方を教えてもらったあと、実際にワークを通して書いてみる＋テストケースを考える、ところまでやりました。

ユースケース図

ユースケースを入れるとき、前後関係をどう描いたらよいかよくわからず手が止まる
→「前後関係はいったん考えなくてOK」と教えてもらいました。ユースケースどうしは並列でよさげ？
「メールを受け取る」みたいな受動的な内容がうまくハマらない
→受動だとハマらないので、主人公（アクター）を中心にして「〜〜する」みたいな能動的な形で捉えたほうがいい。（この場合は主人公を別の人/システムに移して「メールを送る」にするとハマる）

状態遷移図

挙げたはいいもののしっくりハマらないイベントがある
→別のイベントともしかしたら同じなのでは？と回答例を見て解決しました
「元の状態に戻る」という仕様は要注意

なんでモデリングなのか？セッションの思い出

いろんなモデリング観点/記法があるよ
UMLはそのなかのひとつの記法だよ
PlantUMLっていうツールあるよ
この話はじめにやってくれてよかった〜〜〜〜〜〜
→「モデリング」という単語に目が眩んでいましたが、この話を聴いて整理されて、自分の中で構えができた感じがしました。

そのほか初日の思い出

起きれてよかった（なお、明日もがんばらねばならぬ）
JaSST全部まわるとおいしいごはんが食べられるらしい
海鮮丼を食べた
おひる
みんなやさしい
ガチ勢が集まっている
ToDo↓

ToDo：30秒経つとラーメンが食べたくなる人の状態遷移図を写経
#WACATE
— tonono (@tonono2587) June 16, 2018

取り急ぎ現場からは以上です。
あしたもがんばる