テスコン要求分析チュートリアル前半
記事内容
完全に自分のツイートをまとめただけ。
参考資料
テスト要求分析チュートリアル資料
http://aster.or.jp/business/contest/doc/2019_TRA_1-3_V1.0.0.pdf
ザクっとした感想
テスト要求分析って、なんとなくやったつもりになってるし、なんとなくできちゃう。
これってどういうことかというと、説明はできないんだけど、長年の勘と経験でやれちゃってます、ってパターンがすごく多いってことだと思う。
そのまま同じような差分開発の評価を続けていると、うまくいったように見えていても、どこかに大きな落とし穴があったりして、でも要求分析してないし、そのあとの設計もふんわりするから、落とし穴に気づけないままはまって「なぜ…こんなことになったのか…わかりません…」みたいなことになるんだと思う。
それじゃあかんでえ、と、今回のイベントでは言ってた。
自身の所属する組織や、求められる品質や、開発規模、その他もろもろの要因によって求められる要求が違うので、そこら辺を加味しつつ、
- どういった目的でテストするか
- どこまで、どんなテストをするか
といったあたりを、きちんと根拠をもって、かつ言語化して、ステークホルダーと合意をとりつつ、トレーサビリティをもって要求分析をしましょうね、という風に理解した。
Twitterまとめ
自分のつぶやき。基本的には右矢印(→)から先がその時ふわっと思ったこと。 その手前は資料のメモだったり、講師の人が話してたこと。
— つみき (@mktk0808) 2019年3月5日
テスト要求分析
— つみき (@mktk0808) 2019年3月5日
・集める(準備含む)
・分ける(分解、分類)
・整理する(構造化)
→ 今回はここまで。
あーーーーなるほど…確かに観点出す前にそういうことやってるかも。
要求分析、なんとなくやれてることもある。
— つみき (@mktk0808) 2019年3月5日
→ つい最近までそんな感じだったな(今できてるとは言ってない)
プロセス上それなりの要求分析は行うようになってる
→ 意識的にやることが大事かー。そうだよなあ…。
テスト要求分析の説明は受け手によって深さがまちまち
— つみき (@mktk0808) 2019年3月5日
→ まちまちなのでどうしたらいいかはこれからかな。
どういった目的でテストするか
— つみき (@mktk0808) 2019年3月5日
どこまで、どんなテストをするか
→これ考えるのほんとに要求分析?パッと見観点出しと構造化しかしてないよ?観点出す段階でそこまで考えて構造化しましょうってことなのかなあ...あー私が機能の観点に寄ってしまってるからか。
どこまでどんなテストをするか、
— つみき (@mktk0808) 2019年3月5日
・なんでテスト範囲がそこでいいのか、なんで?をつきつめて考える。
機能分けるだけでいいの?
→業務フローごとに考える、っていうのは一つありな観点かな?
なぜそう考えたか?を説明できて、ステークホルダーと合意できる内容であること。
— つみき (@mktk0808) 2019年3月5日
→ 大事だ~~~~~~~~~~~~~。やっぱり明日開発のリーダーさんに週次隔週でMTGさせてもらお。
他の成果物と整合するべき
— つみき (@mktk0808) 2019年3月5日
→ これ難しいんだよな…。観点図しか出してないからか…。
集め先のところはまあいいや。大丈夫。わかる。でも一応メモ。
— つみき (@mktk0808) 2019年3月5日
• 実際の物
• 開発時に作成された文書
• 設計書
• ユーザーズマニュアル
• 想定された使われ方(≒仕様)
• 問題が起きやすいところ、考えられるリスク
テスト対象以外から得られるテスト要求を忘れる…
— つみき (@mktk0808) 2019年3月5日
→ってどういうこと?対象以外って何?規格とか?
使用者の要求
— つみき (@mktk0808) 2019年3月5日
→ これが難しいんだよな…。うーーん。聞けそうなら聞いてみたい。Summer Days に行って色々聞けるようになろう。
集めた情報を分けて俯瞰する。ロジックツリーを作って整理する。
— つみき (@mktk0808) 2019年3月5日
→ これ苦手な奴~~~。マインドマップで頑張ってる。
深堀の方向
→ なぜなぜだなー。なんで?なんで?を常に念頭に置かねば。
状況変化の情報を集め忘れないように。
→ なぜ開発メンバーが休みがちに、ってなに、、どういうこと
開発メンバーが休みがちに
— つみき (@mktk0808) 2019年3月5日
・仕様変更が多発してるとか、何かハードなことが起きている可能性がある
→ …。去年の夏を思い出す顔
集められない時:想像する
— つみき (@mktk0808) 2019年3月5日
想像できても、できれば事実を集めたほうがいい
・想像に頼りすぎると説明しにくくなる
→ 想像しすぎないようにしないとなあ…。想像だけで作ると途中で矛盾が発生したりするしなあ。
はわわ…分析手法?の話になったら急についていけなくなった…😢
— つみき (@mktk0808) 2019年3月5日
わからないことをそのままにせず、帰ったら調べます。
品質を区分して考える
— つみき (@mktk0808) 2019年3月5日
既存の区分けは便利だが、やりたいこととの相性の確認や内容の取捨選択は検討すべき
→ これにとらわれて要求を見逃さないようにしないとなー。
「常識」「一般的」
— つみき (@mktk0808) 2019年3月5日
「法律などのルール」
→ RFC は法律…?ちょっと違うか。
仕様質問して、RFCに書いてあるでしょ、って言われたんだけどそれは常識なのかな…
NG:チュートリアルで聞いたから必要かわからないがやる
— つみき (@mktk0808) 2019年3月5日
重要なのは理由や問題を理解して行うこと。やろうと思ったらいくらでもできるから、ちゃんと考えないとだめ。
分解⇔分類
— つみき (@mktk0808) 2019年3月5日
要求の種類
・テストを厚くする、しないの要求
・バグを出すのか、動作を保証するのか
・エンジニアリング要求、マネジメント的要求
→ バグを出すのか、動作を保証するのか、、動作を保証することを考えているはずなんだけど、バグも出したい…
今、まさに仕様の内容を分解する、ってやってるわ。
— つみき (@mktk0808) 2019年3月5日
行間を埋める、はやってない。印刷してやってみるかなあ...
空気読むのと同じくらい行間埋めるの苦手なんだけど。
アウトプットをイメージし、どんな切り口の情報が必要か考えながら行う
— つみき (@mktk0808) 2019年3月5日
• テスト設計などのインプットとして欲しい情報は何か?
難しいなあ…
整理はマインドマップ使ってる。
— つみき (@mktk0808) 2019年3月5日
のかな?マインドマップからのオリジナルフォーマットで整理をしているはず。
てか整理はもうアーキテクチャ設計に入るのかと思ったなあ。
集める→分ける→整理する、は、行ったり来たりする
— つみき (@mktk0808) 2019年3月5日
→ 大事なんだけど行きつ戻りつしたときに抜け落ちないようにするの難しい。