JaSST Online Clover に参加しました

こんにちは、お久しぶりですとのの（@tonono2587）です。
今回はJaSST Online Cloverに参加してきた感想を綴ります！

今回のテーマ：JaSST Online Cloverに参加したよ

動機

Twitterにて、開催告知&募集開始しているツイートを目にしました。
テーマを見に行ってみると、「アウトプット」がテーマとのことでした。
最近ポッドキャストをはじめたり、そろそろブログ書きたいな〜と思っていたこともあり
いまのわたしにちょうどいいテーマだ！と思って参加申し込みをしました。

内容は、ガンガンアウトプットをしまくっている方のLTが聞けるとのことで
とっても楽しみにしていました！

www.jasst.jp

感想：LTとパネルディスカッション

◆習慣について

続けることを仕組みとして整備してしまうのはすごくいいなと思いました。
自分なりのしんどくないペースにすることはなかなか難しそうですが、
何も時間(期間/周期)だけが習慣ではないと思えば
カスタムしやすいかもしれないです。
というのも、わたしの場合は毎週○曜日 とか毎日○時ごろ など、
時間によって制限されるのがものすごく苦しくなることがあるので、
夜寝る前 とか○○をやったら とか行動の続きとなるようなところにきっかけを置くほうが向いてるなと思いました。
それが結局毎週とかにはなるかもしれないですが、考え方として…
こんな感じて「習慣」に思いを馳せました

◆モチベについて

どんなすごい人でも、アウトプットのモチベが下がったりすることがあるのか…(自分もそうだから)
別のサイクルと合体してモチベ低下から逸れるところでテンションが上りました
恥駆動ほどの動力はないのですが、書こうとしなければ「なんもわからんがわかる」こともないと思うので
なんもわからんことがわかった、とポジティブにまとめることにしています。
自分のため！

◆とりあえず動くこと！

ちょっとやってみっか〜→爆誕！
と繰り返される流れはアニメをみているようでおもしろかったです笑
こんなに爆誕できなくとも、まずやってみる！
土日だらだら過ごしていた、というところにとても親近感を覚えました
最近ぼーっとしがちなのでわたしもなにかぽんっっとスイッチを押して動き出したくなりました

感想：OST

OpenSpaceTechnology
受け取るだけじゃなくて、ガッツリ参加する！ができるのがJaSSTONLINEのいいところだなと思います

ブログ書けなくて結局公開やめちゃう…
という話のときに、参加しているひとがどんどん「書くぞ〜」「書くぞ！！」
ってなっていったところがすごく楽しかったです。
わたしも例に漏れず書くぞとなりました！笑
たぶんきのうまでのわたしだったら書いてなかった(最近だらだらしているので)
あとは、自分が思うほど「説明」って気にしなくていいのかなと
気づきを得ました

LTとパネルでアウトプット欲が高まっていたので、
自分からも議題を投げてみることができました。
自分のアウトプットが他のひとへ伝わるまでには、いろんな要因の組み合わせがありそうです。

(アウトプットの)

• 内容
• 媒体
• 端末(PC/スマホ/タブレット)
• 量（文の長さや時間の長さなど）
• 頻度
• 投稿時間

平日が多いのは仕事中に探すから？とか
長い文が続くと読むのをやめてしまうかもとか、
本は1ページとかでやめられるけど音声/動画はそうはいかないとか
まとめて聴くから投稿時間はそんなに関係なさそうとか、
とはいえ頻度は定期がいいかもとかとか…

様々なケースを聞くことができてとても楽しかったです！ありがとうございました！！

まとめ

決して適当にやれ/やるというわけではないけれど、
考えすぎずにアウトプットしてみよう！
(してみた！)

【JaSST'21 Tokyo】参加しました

こんにちは、お久しぶりですとのの（@tonono2587）です。

JaSST'21 Tokyo に参加してきた

2021-03-15〜16の2日間、
JaSST'21 Tokyo へ参加してきました。

JaSSTソフトウェアテストシンポジウム-JaSST'21 Tokyo-開催要項

オンライン開催で、自宅でリラックスしながら参加できました！！

参加背景

タイムテーブルをみて、
気になるセッションがいくつかあったため参加を決めました。
キーワードとしては

• カスタマーサポートエンジニア
• テストプロセス改善
• テストマネージャの話
• アジャイル

このあたりに興味がありました。
なんとなくわたしの中でJaSSTは”流行を知るところ”的な側面もあり、
どのセッションを聴きたいか考える時間も結構楽しんでいます。

聴講

アジャイルについて

はじめの基調講演、終わりの招待講演、どちらも
「パターン」というキーワードが共通していたように思います。
パターンとは、問題と解決を抽象化してまとめたもの、グッドプラクティス
具体的にして再利用できて、問題があったとき、それを解決する手段になるかもしれないもの
短い期間で問題を見直したり解決の方向性を置いたりするために、
ちょうどいい大きさのものなのだろうなと思いました。
「名前をつけたということは、コミュニケーションがとれる」という話があったのも印象的でした。

また、一昨年のJaSSTらへんでは「アジャイルは難しい」という話が多かったような気がしましたが、
最近はアジャイルをやったことのあるひとたちのほうが増えて、
どうやっていくかの話になっているなと感じました。
あとは今回、「アジャイルというのは考え方。アジャイルをやるとアジャイルになるわけではない」
ときいて、アジャイルの話のたびに発生していたもやもやが少し晴れた気がしました。
。。（ずっと「アジャイルの何が難しいんだ？」と思っていて、
アジャイルをやろうとするのが難しかっただけで、考え方自体は難しくないのでは？となりました）

アジャイルやってるとかやってみたとかは発生していませんが、
最近の情報を仕入れた感じがしました。
「アジャイルに無能はなおせない、失敗を避けられるものではない」
ということも覚えておきたいと思います。

カスタマーサポートエンジニア について

「カスタマーサポートエンジニアの品質貢献」というセッションを聴講しました。
どういうイメージをお持ちでしょうか？という問いかけがありましたが、
初めて聞いた単語だったのでわたしの中の一部イメージに「カスタマーサポートエンジニア」という名前がつきました。
しかも自分がいま担当している仕事だったので、
（わたしってサポートエンジニアだったのか〜〜）という気持ちになりました。

中でも「ファーストリリース時の品質が高くなる」という話があって、
（見た瞬間に問い合わせがめちゃくちゃ増える。。。みたいなことに気がつけるから）
自分の仕事のいいところにも気づけたので
これからも意識的に効果を発揮できたらいいなと思いました。

ほか

テストプロセス改善のお悩みや、テストマネージャのセブンルールは
「チームでどううまくやっていくか」に興味があったんだと思います。
セッションで話されていたものと全く同じお悩みを持っていたりするわけではないですが、
いくつかのパターンを手に入れたのかもしれません。
ルールについても、自分なりのセブンルールをつくってみてくださいという話がありました。
ルールとして名前をつけるのも大事なことだなと思いました。
（あと単純にルール持っててすぐ出せるのなんかかっこいいな…）

ほかは、「QAファンネル」の話が盛り上がっていたように思います。
QAファンネルが一体何なのかという説明をされるよりも、
実際に使った話をされていたところが好きでした。

まとめ

• アジャイルは考え方
• 名前をつけるということは、コミュニケーションが取れるということ
• オンライン開催心地よい

最近インプット少なかったので増やしたいな〜
ではでは〜〜

仕様を読むときはここを狙う！

こんにちは、とのの（@tonono2587）です。

本記事はソフトウェアテストの小ネタ Advent Calendar 2020 4日目の記事です。

qiita.com

今回のテーマ：仕様を読むときのポイント

仕様を読んで実装前にバグをつぶすの大好きです。
（ほんとうはあとから言われて手間がかかるのが嫌なだけです。）
書かれている仕様のなかでもとくにバグが出やすい表現があるので、
3つあげてみようと思います。

その1：以上（以下）

「○○以上」「○○以下」という表現は境界値になるのでバグが出やすいです。
以上と以下が重なってしまってどっちをとったらいいかわからなくなっていたり、
指した範囲と反対のところが定義されていなかったり、
考慮漏れが起きやすかったりもします。
仕様を書くひとは「3000円以上送料無料」と書いたら満足してしまい、
クーポンを使って0円になるときの決定を忘れてしまうのです。

その2：必ず

"必ず"は感情的な表現です。
必ず生きて帰る、絶対に勝つ、約束は必ず守る…
信頼している間柄、人付き合いにおいては信用できる言葉になるかもしれません。
一方でソフトウェアにおいて必ずという表現は不要です。
「3000円以上は必ず送料無料」は、
決定さえすればそう動くはずなのに、あえて"必ず"を使うということは
そうじゃない場合が起きてほしくないという要件が隠れています。疑いましょう
クーポンを使って割り引きされていても送料無料にしてあげたいのです。

その3：文が長い

これはまず読むのが難しく、長ければ長いほどいろんな解釈ができてしまい、
実装にブレが発生しやすくなります。
「ユーザーの注文がクーポンを使って割り引きされ注文の本体価格の合計が3000円以上になったとき、受け取り方法を店舗受け取りではなく配送に指定すると送料が無料になる」
なんて？？？？？？
その機能でやりたいことも不明瞭となるので、ユーザーに伝わらずよいサービスにはなりません。

まとめ

仕様を読むときは、以下のような表現に注目してみましょう！

1. 以上/以下
2. 必ず(絶対)
3. 文が長い

他にもありそうなのでいつか書きたいなぁ
以上、小ネタ4日目「仕様を読むときはここを狙う！」でした！

テスト計画はいいぞ

こんにちは、とのの（@tonono2587）です。

本記事はソフトウェアテスト Advent Calendar 2020 4日目の記事です。

qiita.com

今回のテーマ：テスト計画のすすめ

たとえ1時間でもテスト計画を実施するだけで動きやすくなった気がしたので、
今回はテスト計画はいいぞ！っておすすめします。

なにがいいか

テスト計画をたててよかったこと

1. 締め切りがわかる
2. いま足りないものがわかる
3. これから足りなくなるものがわかる

テスト計画を通して上記のあたりを体感したように思えました。
少しだけテストが上手くなった気がしました。
補足すると、

締め切りがわかる

"いつまでに"って意外と忘れがちな気がします。
これは体質かもしれないですが、締め切り駆動開発しがちなので
終わりが決まっているだけで動きはじめることができます。
何から手をつけていいかわからない場合はとりあえず締め切りを確認するのがいいなと思いました。
あと、さすがにスケジュールが決まっていない現場はまずいと思いました。
その他いろんなものも決まってないです絶対、いますぐ締め切り決めましょう

いま足りないものがわかる

テストの計画をたてようとすると、やるべきことをどう実現するかを考えると思います。
そのために必要なもの、例えば人員とか期間とかお金とかもっと物理的なものもあるかも？
それらがわかるので足りないものを集めます。
集めるために動き始めることができると思います。
自分で用意したり、適切なところへ依頼を出したり
先手を打てるのはいいことです！
そういうプレイスタイルが好きなのです。

これから足りなくなるものがわかる

締め切りまでに実現可能なテストが準備できたとして、
計画が完璧にいくことはないかもしれません。
特に、未熟なわたしでは計画なんて気にしてる暇もないでしょう…
それでも、計画を立てておくとどのへんから遅れそう、崩れそうとかが見えやすくなるように思います。
反対にうまくいっているなら、余りの時間で次にできる分を前倒しできるな、
とか止まらずに動きはじめることができると思います。
やっぱり先手必勝だ！

なにをしたらいいか

テストの計画を立てると先手を打てるところがいいなと思いました。
では具体的にどうやって計画を立てるかについて整理したいです。

• 締め切りを確認する
• それまでにやりたい内容を確認する
• やりたい内容にかかる時間を見積もる
• 見積もった時間が当てはまるか確認する
• 当てはまらないときはどうにかする

わたしの思うテスト計画はこのような感じです。
もっとレベルが上がればまた違うことをするかもしれません。
テスト計画工数0だったわたしが1にしたときの内容は上記のようになりました。

締め切り

はじめに書いたとおり、あとに続くあらゆる決定をするために必要なものだと思います。
決まっていないならすぐ決める

内容

ここで想定しているのはテストの内容というより、
プロジェクトの要件というか実装する機能となります。
"なんのために"も大事だと思います。

見積もり

要件を確認したら、そのためのテスト工数を見積もります。
（計画）分析/設計/実装/実行…いろいろあれど
設計工数&実装工数と、実行工数の大きく2種類にわけて見積もりをしています。
経験や知見があればもっと制度の高い見積もりができるんだろうなと思いつつ、
自分の測れる1機能にかかった時間をみて、それとやりたい機能と比較してみたりしています。
…結局わかんないのでがばっと大きめに取ります。

実現方法の検討

がばがばなのは置いておいて見積もった工数と締め切りを合わせます。
あからさまに間に合わないとかはこのへんでわかります。
間に合わない場合どうにかしないといけないです。
締め切りを伸ばしてもらう（期間で解決）（無理だったりする）、
人手を増やしてもらう（工数で解決）（無理だったりする）、
機能を減らしてもらう（要件で解決） （無理なの？）、
とりあえず間に合わないと言う（未解決）、
などなどやるべきことが変わります。
締め切りギリギリで言うと嫌な顔されるので、締め切りより前に選んでもらうのがいい。
そのときは間に合わない理由が先述の「見積もり」になってくるので、
がばがばなりに伝わる理由は必要です。

おまけ

要件とか期間が大きければ大きいほど初心者にはしんどいので、
期間が短いやつとか要件が少ないやつで慣れるのいいなと思いました。
でも計画って長期間、大規模であるほど役に立つとも思っています。
そもそも難しいんだね
でも同じ要領で見直しもできそう

まとめ

ここまできて、これをテスト計画と呼んでいいか自信がありません
テストするときの自分の作業計画…？
締め切り見て、見積もりして、考える！
できなくても困らないけどできると楽になる
上手くできるともっと前にすすめる〜〜〜
テスト計画上手くなりたいなと思いました。

以上、4日目「テスト計画はいいぞ」でした！ 小ネタのほうもよろしくお願いします！！

https://tonono.hatenablog.com/entry/20201204_konetaACtonono.hatenablog.com

わたしの仕事を快適にするツール

こんにちは、とのの（@tonono2587）です。

もくもくした！

今回のテーマ：仕事がめちゃ快適になるツール/設定

入れとくと仕事やタスクがハイパー快適になるお気に入りツールを紹介します！
わたしもいろんな先輩から教えてもらったやつ！！！特にお気に入りの3つです

1. Clipy
2. MindMap Tab
3. Gmailの「閲覧ペイン」

Clipy

2つ以上前にコピペした内容を呼び出せるツール！！

clipy-app.com

よくつかうフレーズもセットできるのでめちゃ便利
一度使ったらやめられない

MindMap Tab

マインドマップを書くツール！！

chrome.google.com

• 拡張機能なのでボタン押せばすぐ使える
• シンプルで書きやすい
• 順番の入れ替えしやすい
• エクスポートもできる

シンプルなのがとても好き、手描きよりも書き直しがしやすくて、保存できるのもいい

Gmailの「閲覧ペイン」

ツールというか設定
メールを選択すると同時に中身を読める！便利！！

設定＞受信トレイ＞閲覧ウィンドウ で設定できる
クイック設定にも出てきた！

まとめ

推しポイントだけを述べました
使い方の説明が要らないほど簡単に使えるツールでとてもおすすめです！
みなさまもよきQAライフを〜〜

【JaSST'20 Kansai】参加しました：テストのための分解と再構築

こんにちは、とのの（@tonono2587）です。
Tokyo以外のJaSSTに初めて参加したので記録します。

今回のテーマ：【JaSST'20 Kansai】に参加しました

2020年9月12日(土) ＠オンライン開催 JaSSTソフトウェアテストシンポジウム-JaSST'20 Kansai-開催要項

参加背景

開催概要を読んで、テーマにひかれました。
レビューしてもらっていたテストがレビューするテストになって、
無意識でやっていたことを言語化しないといけなくなってきました。
そのヒントになりそうかも、と思ったことが一番の参加動機です。
その他には、

• オンライン開催で移動時間ゼロ
• ゆもつよさんの講演があるー！

みたいなことが参加しようと思った理由です。

メモと思ったこと

基調講演

s1-1 見えないものと取っ組み合う

• テスト分析をするときに、文書の記述を読むとなんとなくわかったようになるが、実はイメージがつかめていないことが多い
• 見えないまま扱うのではなく、見えるようにする
• その手段のひとつとして、「テスト視点でのモデル化(視覚化)」 がある
• 視覚化することで理解が進むし、共通理解も得やすい
• ただし、モデル化はハードルが高い。。
• あまり構えずにとにかくつかってみましょうよ！

□感想

モデル化のススメ という感じでした。
読むだけでは実はイメージがつかめていないことが多いので、モデル化して可視化してみよう！
モデル化するためには、取り扱える大きさまで分解する必要がありそう
描いてみてわかることがあるので、とりあえず描いたらわかる、というのが刺さりました
何から手をつけたらいいかわからない人にこういう話はよさそうです。

s1-2 テストの視点でシステムを分析する

• ビジネス戦略からシステム要求がつくられていくから、顧客をビジネス視点で分析したらテスト要求にも繋がるはず
• 方法1：ビジネスモデルキャンバスや、PEST分析
• 方法2：USDM（要求仕様記述手法）によって整理しテストをつくる（再構築する）
• USDMの教え：要求は日本語で表現できるものではならない、「言葉で書けないものをつくってはいけない」
• 方法3：リスク分析からテストをつくっていく
• 方法4：過去の問題分析、テキストマイニングで俯瞰的に見て、主観を除いて新たな気付きをえる

□感想

知らない手法をたくさん教えてもらいました。
USDMを型通りやる時間はなさそう、と思ったものの考え方はとてもためになりそうだと思ったので調べてみよう
いままで気にしてなかったけど要求の整理はしっかりやったほうがよさそう

s1-3 テストの視点でシステムを分析する ~アジャイル開発を例に~

• 要求がテスト可能な状態になっていない現状
• 複数のシステムを組み合わせた「サービス」としての提供になった
• 従来の仕様ベースのテストだけは不十分になった
• 上流工程から「品質」を考えるようにする
• 要求の「完成」を定義して、受け入れ条件を決めて、それを整理する

□感想

上流から品質について決めておくことは大事なので、
アジャイル開発での例を見ながらその決め方を知る
決めた品質に対して、テストをつくっていく…？
自分の中での置き換えや抽象化が難しくて全然噛み砕けていません。。

招待講演

ゆもつよメソッドによるテスト分析の成り立ちと狙い

• 分析結果は客観的、「これだよね」ってなるもの。ひとつしかないし、答えは同じにならないといけない
• 設計結果は主観的、「私はこれだ」ってなる。いろんなアイデアがある
• 要求分析をして要求をちゃんと理解したあとに、それをおこしたものが仕様
• テスト設計とは、テスト条件を網羅するためのテストケース設計モデルの選択をすること
• どこを何でモデル化するのか、そのモデルを決めることが設計
• モデル化 とは、必要なものを取り出し、不要なものを削ること
• テスト分析はドメイン知識、テスト設計はテスト設計スキルが要る
• テクニックを知っているほうがテスト設計はうまくできる
• 両方100％持っている人だけを集めるのは難しいので、適性に応じて役割分担する

ーー

◆ゆもつよメソッドのメリット

• 最も大きなメリットは、（大きく捉えて）テスト対象を網羅しているかがわかりやすいこと　
  • 当たり前すぎる仕様はドキュメントに書かれないことが多いので、仕様書を細かく見ているだけだと当たり前なテストは漏れる
• 可読性アップ
  • どこに何が書いてあるかわかると読みやすい
• テスト設計技法利用度アップ
• 解釈のブレ度合いダウン
• ドキュメントフォーマットと実施順序のルール化
  • 複数人でテスト設計をするとき、記述内容をあわせる
  • 書く項目に対して何を書くかルールがある
  • お互いにレビューしやすくなる
  • 設計の守備範囲がどこからなのかわかるし、設計するときも分析結果を見ながらできる

ーー

• テストカテゴリーをつくりたいから、もう少し抽象的な示し方が「論理的機能構造」
• 自分のプロダクトはよく知ってるし、パターンはある程度決まっていた
• でもコンサルやるとなると、経験したことのないドメインに対して、これらを適用しないといけない

• 適用できるようになってないといけない

• とにかく大事なのは、何を確認したいテストなのかがわかること

• どんなテストをしたいかわからないと、レビューもできないし

ーー

◆ゆもつよメソッドの変遷

• ドキュメントフォーマットを決めた
• 論理的機能構造からテストカテゴリーをつくるようにしていった
• 仕様項目の特定パターンを研究中

ーー

• どんなテストをしたいのかわかるようにする
• どんな結果を確認したのかわかるようにする
• どれくらい広く、どのくらいのバリエーションでテストするのかわかるようにする

□感想

テストを分担するときに、テストケースはいきなりレビューできないし、
でもいきなり「設計して」とも言えなくて試行錯誤していました。
わたしが確認したかったのはテスト分析結果だったのか、と気付きました
モデル化によって認識合わせがしやすくなるのも、必要なものが取り出されているからなのだとわかりました。

（ログ型のメモを貼り付けるタイプだけどそうじゃないようにしていきたいな。参加レポの書き方知りたい）

まとめ

無意識でやっていたことの言語化のヒントになりました。

• 分析結果はバラバラにならない
• 設計はいろんなアイデア
• すり合わせにはモデル化がいい
• モデル化するには必要な情報を取り出す作業が要る
• ”分解”されるので、扱いやすくなる

テストの勉強をすすめるうちに、人類にソフトウェアは大きすぎる
と思うようになりました。
ソフトウェアというか、ソフトウェアテストをするには扱う情報が大きすぎる
大きいものを扱うためにまず小さくすること、いかにうまく小さくするかがポイントなのかなと思いました。

集中してきいたのであいだは結構つかれていましたが、
外出せずに勉強できて、黙々と聴けたのがよかったです。
おつかれさまでした。

【JaSST Online Anemone】参加しました！

こんにちは、とのの（@tonono2587）です。
JaSST Online Anemoneに参加してきました。

今回のテーマ：JaSST Online Anemone 参加レポート

2020-06-20 13:00~

www.jasst.jp

大きく2部構成になっていて、それぞれオンラインならではの内容となっていました。

• オープニング
• ライブテスト分析前半（2スプリント）
• ライブテスト分析後半（2スプリント）
• OST(Open Space Technology)：20分ずつ3セッション
• クロージング

ライブテスト分析

かんばんリストというシステムを題材に、
マインドマップを使いながらペアでテスト分析する様子を視聴しました。

■前提条件

• 開発が単体、結合テストを行ったものをQAチームがシステムテストを行う
• テストベースは仕様書のみ
• 初回リリースで、テストアイテムはまだ動作しない
• 納期短め

これらの前提のもと、深堀りしながら、次へ進みながら、課長にファシられながら、
振り返りと休憩をはさみつつテスト分析が進んでいきました。

スプリント1

• 仕様の全貌をみるため、仕様書目次を参考に枝をはやす
• かんばんリストシステムらしい機能に注目(タスク機能)
• タスク機能の表示系と操作系に分ける

• 重要と思うところからチェック(深堀り)

• 30分くらいやってみてつかめたこのスピード感で、どこまでどういう方向で進んでいく？ 　→今回は初回リリースなので全体を舐めるように見ておきたい。

• 途中「論理/物理」というキーワードが出たが、テストケースへ繋げづらいためかマインドマップから抜けてしまった
• 仕様書を見ながらやると転記したり細かい記述を追ってしまいがちだが、ふたりともあまり見すぎていなかったのでよい状態だった
• 創造的な感じがあった

MEMO

• リズムを大切にする。
• (どっかに書いてなかった？など)気になったところはいちいち確認せずに、とりあえず気になっている状態で残しておく
• 確認していると時間を取られてリズムが悪くなるため。

スプリント2

• タスクまわりがまだ検討をやり切っていない？
• かんばんリストとして重要な機能なので、このくらい深くてよい派
• その代わり他の機能を見るときはもっと浅くする

• タスク機能の表示系をチェック/検討

• はるすぷさんは仕様把握ができていて、見えていないものが見えている感じでよい

• プログラマ的視点をユーザー的視点にブレイクダウンできている
• 細かく深堀りしてしまうところをぱいんさんが止めてくれる
• 一応スプリント1で「全体を見る」という方針だったが、やりながら深堀り型へ切り替えていた
• どうして全体を見ずにこだわったか？ 　→ほかを浅く検討するより、いま検討している機能のほうが重要だと思った
  　→コアな機能を見切れていないためもっと考えたかった
  
• 「QAする」ってなんだろう？
• 大きく2種、バグを見つけること(深く)。製品が提供する価値を保証すること(全体寄り)。
• どちらを目指して、どこに向かおうとしているか決めよう？

• 「全体を見る」、「全体」ってなんだろう？

• 開発者マインドが強くバグだし能力が高いため、どうしてもそっちに寄ってしまう

• システム共通としての観点は実は出ている：負荷/ユーザービリティ/クロスブラウザ
• 機能を軸にした気になりごとではなく、気になりごとを軸にしてみるのは？

MEMO

• 客観的に見ていると、「バグを見つけにいっている」という感じが強かった
• テストしバグを出すことで品質アップすること、へは繋がりそうな検討の仕方だなと思った
• テストがもう始まっている感じ…？
• バグを出す方向だと、手段としてのテストを検討している感じとは離れてしまうんだなと思った （なんかうまくいえてない。。）

スプリント3

• 前半でちりばめられていた非機能観点をまとめたい=全体で気にすること
• 粒度がバラバラなのである程度揃えたい

• ユーザー管理や権限が気になる

• マインドマップというツール上、各枝の抽象度がそれぞれ揃ってないといけないような気がしてしまう

• 挙げることを優先してとりあえず気にせず進んでみる

• 個別の機能の仕様を見ると仕様の細かいところが気になって、どういうテストをするのかが気になってしまう

• 「全体をみる」を意識したら使っている人のイメージや風景が見えてきた◎
• ではラストスプリントどうするか。何を達成するか
• 仕事において、達成感を得られる成果物はなんだろう？
• 残り時間でできそうな簡単なことがしたいのか？それともやるべきことがしたいのか？
• 今回はテスト分析なので、全体的なバランスを見たり決めたりしたいと思う
• ゴール：この範囲に関してはテスト分析ができたね、と思えること

MEMO

• 脳みそを転記する！
• このスプリントはハイパーライブ感あってめっちゃ楽しかった
• 残り時間でできそうなこと VS やったほうがいいこと
• やったほうがいいことやってくれ〜〜〜！って思いながら見ていた
• できる範囲で、やるべきことをやるという落とし所が見ているこちらでもわかった
• 進むべき方向の納得感があった

ラストスプリント4

• 前半で挙げたタスク機能まわりについて、表示系と操作系になっているため軸を変えたい
• 今回のゴールにとって要る/いらないを削除/追加していこう
• 上から削除/追加の検討をしたけど、ゴールするにあたって何が足りないか、またこれでよいのか2人の合意がとれた状態にしたい
• 5W1Hに沿って洗い出しとかよくやる
• うまく出ない。。

スプリント全体の振り返り

• はじめから全体を見ていたらマインドマップは広がらなそうだったので、全体と局所両方を見れたのがよかった。
• 具体的なところを掘り下げることで、全体へつなげることができた
• ものをつくっている感じがした！

ーーー
SEやエンジニアはテストに対してものづくりはあまり感じない
一方でテストエンジニアはテストにものづくりと同じ脳みそをつかっている
それが今回実感できたのがよかった

■次回やるとしたら気をつけたいこと

• 全体的にゴール設定を見失いがちなので、はじめに決めて進んでいきたい
• 業務システムだから、という濃淡がつけられなかったので改善したい
• かんばんリストだから/業務システムだから気をつけなきゃいけない部分の検討が足りてなかったかも
• ユーザーの目線に立ってテストする場合、その目線で濃淡をつけて検討したほうがいいのでは？

■よかったところなど

• 全体がだんだん見えてきたところがよかった
• 借りてきた形式(今回の5W1Hレビューとか)ではうまくいかず、自分たちが納得してしっくりくるかが大事
• ペア2人はお互いに敬意をもっていた
• そのため変に気遣いすぎるなどなく、効率のよい言葉でコミュニケーションが取れていた

MEMO

• はじめから間引いた結果が出てしまうのはよくないので、「わからない」「関係なさそう」などをあえて残すのは大事
• 残しつつ、しっくりくる納得できる形で解決させる必要がある
• しっくりいかない(Red)を納得(Green)にしてRefactorする

OST

テスト分析、設計、どうやって教育する？（とろ）

• テスト分析をきちんと習ったことがある人はほとんどいなそう。
• マインドマップを描いてもらってから、それをレビューする形で教えている
• 描いてもらうときはどうやって導入する？
  　→マインドマップ自体の説明を軽くしてから、自己紹介を題材に実際に描いてもらう。慣れてからステップアップする
• 就活の企業分析の延長で、担当製品の企業を分析してもらったらうまくいった
• 趣味を整理して分析してもらったら結構よかった
• 好きなこと、身近なことからはじめてもらうと思考が広がりやすく、とっつきやすい
• やり方に正解はないから、やりやすいところから慣れてもらうのがよさそう！
• とはいえ急に「好きなもの」とかは聞きにくいので、チームビルディングを装ってすすめるのよさそう

MEMO

理想として分析のやり方や設計技法などを直接伝える/教えることをイメージしていたけれど、
慣れてから、だんだん本当にわかってほしいことへ繋げていくほうがうまくいきそうだと思いました。
テスト分析自体にも明確な「正解はない」というのはたしかに…
それなら正しい教え方なんてないのもそのとおりだなー
ほかのセッションはだいぶ力尽きてしまいあまりがっつり参加できませんでした(T_T)

全体の感想

時間で切ってこまめに振り返りがあったため、状況が見えて話が入ってきやすかったと感じました。
話が入ってきたこと、マインドマップや相談内容を聞きながら思考を追うことで
自分もやっているようなライブ感がありました。
一緒にめちゃくちゃ疲れました
ライブを体感して思ったのは、仕事でのレビューや検討は思考の結果をみることが多く、
「思考中」から時間が経ったものを見ていたためにすり合わせコストが高くなっているのかなと思いました。
「思考中」そのものや、思考から時間が短いもの(考えの範囲が狭いもの/まとまりが大きすぎないもの/小さい単位)
の段階で認識合わせするようにすれば、結果が大きく逸れてつらくなるようなことは減るのかなと思いました。
とはいえどこで切るかとか、あまり頻度多すぎてもとか、そんな時間取れないとか
いい塩梅にするのもまた大変そうだな…
暗黙知がテーマということで、なかなか見れないものを見れて/体感できて刺激的な一日となりました。
お疲れさまでした