- テスト設計コンテスト のチュートリアルのチュートリアル
- テキスト
- 鈴木三紀夫 さんとか YasuharuNishi さんとかいた
しゃべる人がいないのでテキスト解説で繋ぎ
テスト要求分析 -> テストアーキテクチャ設計 -> テスト詳細設計 -> テスト実装 -> テスト実施
テストの配置、段取り（順番）、構造をどうとるか決めるのが、テストアーキテクチャ設計
その前段階のどういうテストをするのか、というのがテスト要求分析
ソフトウェアの開発とテストの開発を対応させて考える
要求の源泉は裏付けがある、誰かがそう言った、根拠（言質？）がある、追跡できる
経験はそうではない、誰かが「経験上〜〜です」って言うとそれ以上どうしようもない
要求工学が分けてそうやって考えているので、テスト要求分析も踏襲している
テストすべき事洗い出す中で、過去のバグを使ったりもする（って言った？）
全部はやれないので、どこを厚くするかなんてのを考えたりもする
こういうのってどうやって集めるの？
-> 業務知識やドメイン知識って言ってるけど、開発会社からテスト要求があるときに一緒に業務知識をインプットしてもらう
例えば介護業界だと以上と以下の定義が違うんだけど、常識
有識者ってだれ？
-> 察したり辿ったりもするので、コミュニケーション大事
バグトラッキングシステムとか見に行ったりもするなー
どういうのが出たとか、どう捌いたとか
テスト対象が製品化されるものなら自分で買ってみたりする
似てる物を調達していじめてみたり
ここで人が来て流れが変わる
変更に強いテストとか言うフレーズあるんだ- 派生開発が多かったんだけど、そういう場合は基本設計をすっ飛ばして「今回リリースの〜〜だけテストして欲しい」って言われたんだけど、みんなしっかりテスト設計やり直してる？
- 糞みたいなテスト会社は「承りました」って言うけど、「要件とやらないといけないことがずれてないですか？」って切り返して欲しい
- 結局その場合どこテストすんの？
- 依存する処理の性能や品質が悪いなら、そこも対象にする
- ってことは派生要求仕様が必要なんだけど、それを引き出すにはどう動けば良いの？発注者は頼んでない範疇でしょ？
- 「どう良くしたいんですか、どういうシステムにしたいんですか」って聞いて、その上で派生要求に繋げていく
- インフラどうなってんのって聞いたりとかもする
- 改修前のリリース版のテスト仕様書とかくれって言う
- 営業が味方の場合、「派生要求仕様や既存のドキュメントがないとバグでちゃうなーこちらで作りましょうかー？お高くなっちゃいますけどー」って言う攻め方があるｗ
- どういうテストがしたいかの要求がはっきりしている場合、どういう資料が必要かが逆算でわかる
- 関係を続けるなら、そういう資料が必要だってフィードバックを入れていく
- バグ表に「機能名だけを羅列していたり、事象ばっかり書いてあるとヤバなって思う」
- そうすると時間丁寧に分析する
- きっとバグが多すぎてひとつひとつのバグを捌くのをさっさとやろうとしているんだろうねｗ
- 経歴書で人の判断はできないけど、「過去のバグを何か教えて」って言うとビジネス知識からシステム知識まで理解度を丸裸にできる
- 不具合報告研修ってで「不具合の報告の仕方を見ると人がわかる」って話をしたなー
- 営業段階で納品物として定義しておく方に持って行こう
- 無駄に圧が強い人とはどう関係すれば良いのか
- 営業に「うちはちゃんとしてるので納品物も多いし単価も高いです、けど質が良いです ユーザも開発も幸せにします」って言い切らせる
- 圧が強いけど中身のわからない人はそれで倒せる
- 資料を無駄に分割したりして厚さだけ稼いだりするとそういうのは満足するｗ
- 圧が強いけど中身のわからない人はそれで倒せる
- 営業に「うちはちゃんとしてるので納品物も多いし単価も高いです、けど質が良いです ユーザも開発も幸せにします」って言い切らせる
- 100 点取れてから居客に提供、とは考えすに 10 点 20 点の状態で提示していきフィードバックして良くしていく
- エンジニアとして姿勢は評価するところもあるけど、100 点取れないんじゃあ仕事にならないでは価値はない
- 2w で定期的にリリースとかやり出すと、だんだんテストが適当になっていく
- 良くも悪くも暗黙知でやったりして、質が下がったりする
- チェックリストがあったりすると良いのかも
- セキュリティとか性能とか、絶対外しちゃいけないやつのチェックリストがあったりすると良いかも
- 違うだろ、グランドイメージってのがあって、スプリントで部分的な価値を出しているので、チェックリストで機械的に楽するなんてしちゃだめだろ
- そういうのは宗教的アジャイルって呼んでる
- 「僕は資格を持っているのでアジャイルができてます」みたいな胡散臭い奴がいたり
- プラクティスやってるだけ、とか
- 小さく回したりしてれば良いんです、とか
- 区切ってふりかえりしてればスクラム、とか
- でかい価値を小さい価値にしてスプリントで実現するので、ちゃんとしてればアジャイルのイテレーションはやってる時点でスプリントの目標（価値）もざっくりのテスト要求もあるはずだろ、適当にアジャイル（とテスト）すんな
- 定期的にチェックリストやってればシステムが作れるわけねーだろ（それをチェックリストを作ることで安心すんな、それは宗教だ）
- 宗教的アジャイルは「そういう計画立案とか受入をイチイチしなくて良いのがアジャイルでしょ」とか言う奴ら
- そういうのは宗教的アジャイルって呼んでる
- selenium は rpa のツールですか？ｗ
- 違いますｗ
匿名質問ツールを使って
- 開発からテスト会社に転職した同機やモチベってなんなの？（by ほげ）
- テスト面白いから
- 面白いからもっとやりたい、100 % テストやれる会社があるらしいので転職した
- テストのこと考えてると色んな事を考えないといけないので、やることが狭まるわけではなくむしろ広がった（なるほど！けど聞いているとそうなんだろうなって感じがする）
- テスト要求分析はいつからやってるの？
- 別にテストは実装が終わるまで始まらないことではない
- テスト設計においておかしいところとかを開発者にフィードバックしたりするのが正しい在り方
- （余談だけど）説明したりする時は便宜上順を追って話すけど、順を付けて話すとたいていの人はウォーターフォールだと勘違いしてしまう
- 何が言いたいかというと、最初に話した「テスト要求分析」を最初に一回やるわけではなくて、「テスト要求分析」はやり続けるもの
- 気付いたことのフィードバックとかやる以上、そうでしょ？
- その場合のデメリットは
- トレーサビリティを求める糞客との相性
- そんなテストと気付いたことをベースとするテストどちらにするか、最初に戦略を決めたりする
- すさまじい機能のエクセルを作っていると、フィードバックを入れづらかったりする
- トレーサビリティを求める糞客との相性
- ので、変えやすい資料を作る、変更をしやすいツールを使う > これが変更に強いテストってやつか
- 何が言いたいかというと、最初に話した「テスト要求分析」を最初に一回やるわけではなくて、「テスト要求分析」はやり続けるもの
- テスト要求分析やってる人どれくらいいるの？
- 明示的にやってる、実はやってたんだなって感じ、やってない、でそれぞれ等分くらい
- テスト要求分析の書籍や資料があれば知りたい
- ワインバーグとか
- 技術的なのとマインド的なのをバランス良く読むと良いよ
- 体験談を知りたい、テクニックを知りたい、事実を知りたい、シンキング系、みたいな自分の好みを知っておかないと、読書は進まない
- ロジカルシンキングとデザインシンキング
- エンジニアは整理が苦手、とにかく苦手、変なのを一緒にカテゴライズしたり包含関係にしたりするのがとても多いと見える
- 要求仕様の探検学
- 実線ソフトウェア要求ハンドブック
- ソフトウェア要求のためのビジュアルモデル
- ソフトウェア要求 これは基本、知ってるよね的な
- 高いなと思ったらみっきーにメンションして聞いてｗ
- 感想を返す bot だと思って使ってｗ
- 要求分析の完成度ってどう測るの？
- 100 点病
- 開発の完成度測ってんのか？
- 小っちゃく回して改善するってのを納期までずっとやり続けるだけ
- それでも漏れたなら技術力が足りてない、銀の弾丸ではないので仕事が嫌いになるくらいなら諦めるのもアリ
- それでもある程度のメトリクスにしたいなら、プロセスと技法に分けて考えるとまぁ良いかも
- リリース優先で仕様書を書いてくれない文化が強いサービスをテストしないといけない、どうしたら書いてもらえるか
- 必要があるなら必要があると示す、暗黙知で迷ってるなら書く必要ないのでは？
- なんでリリースを優先しているのかを知りたい
- 品質をどう捉えているかとか、リリースってのが修正リリースばっかりなら問題の根は別の話だったり、打ち合わせでどんどん進んじゃうなら混ぜてって言うとか
- 時間切れでふわっと
特に面白かったのはこれとこれ（本題から逸れてた流れの時だけど）
- 経歴書で人の判断はできないけど、「過去のバグを何か教えて」って言うとビジネス知識からシステム知識まで理解度を丸裸にできる
- アジャイルのイテレーションはやってる時点でスプリントの目標（価値）もざっくりのテスト要求もあるはずだろ、適当にアジャイル（とテスト）すんな
宗教的アジャイルという侮蔑をうちの組織で流行らせたい
ずっと感じてたもやもやをこうも端的に言い切れるものだとは...
当初の目的の「空気を知りたい」「人を知りたい」はとりあえず達成
テスト会社目線での発言が主だったけど、アジャイルの話も出たり技法と情熱でテストをしたりを考えてるってのがわかってなんか親近感がわいた
発言する隙がなかったけど、また行こう
あとメガネ忘れて辛かった
#語る夕べ