私は迷いの中にいる

毎日眠気しかない謎の深海魚の一言日記

【振り落とされたが】テスト設計コンテスト20 チュートリアル行ってきた②【聞いてよかった】

※振り落とされまくっているので抜けが多いです。
.テスト設計コンテストの話
・テスト設計コンテストの目的
  ソフトウェアテストエンジニアに対する教育の機会提供
  業界全体の促進
・形式
  予選、決勝の二次構成
  バグだしコンテストではない。テスト成果物の良さを競うコンテスト
・参加のメリット
  チュートリアルでテスト設計を学習できる
  予選・決勝の2回のプレゼン審査がある
・以下成果物、スケジュールの話(割愛)
 
■テスト設計チュートリアルOpen版
・昔はチュートリアルは出し惜しみしていた(出すとマネしちゃうんじゃないかと思って)
・今はレベルがあがってきたので出し惜しみしない
・全部理解すると成果物が同じになるので、振り落としていくスタイルでいきます

■テスト開発プロセス(3ページ)
・テストレベルが10,20あるプロジェクトが出てくると、
(テストベースから)いきなりExcelでテストを書いていると話にならない。
※テストレベル:具体的にインスタンス化したテストプロセス。(ISTQB GLOSSARY)←こ、これは、、
単体テストとかシステムテストとか
・プロジェクトマネージャとアーキテクトは別なのに
テストでは同じロールになっているのが問題
アジャイルなどの機敏なテスト開発に対してどうやっていくか
→テストケースを開発成果物として整備する
(4ページ)
テスト設計からテスト開発にコーディングする。
コーディングとソフトウェア開発は違う。
コーディングはアルゴリズムとプログラミングをわかっていればできるが、
開発は要求を把握していないと出来ない。
テスト開発を、ソフトウェア開発のように進められるようになるために
テストのことだけではなく、ソフトウェア開発に必要となる思考力や
モデリング能力を身に着けよう。
(たぶん5ページ)
ソフトウェア開発プロセスとテスト要求分析を紐づける。
ウォーターフォールの図を思いついたでしょーのやりとりがあった気がしますが失念)
対応図(これがウォーターフォールのことだった?)はソフトウェア開発における
抽象度を表している。
分析~設計を順番に進めていくかは、会社次第。
テストケースが何を指すのか?多くの場合は無秩序。好き勝手な抽象度で書く。
大事なのは、抽象度をコントロールして、マネジメントすること。
(6ページ)
テストプロセスを小分けにする。
なぜ小分けにするか?ドキュメントを増やしたいからではない。
分析~実施(の各プロセスは)使う頭が違う。
◇分析:
・何をテストするべきか
・テスト対象はどんなプロダクトなのか
・今までの開発から考えてどんなバグが出そうか
・どんなユーザがいるのか、考えないといけない。
◇テストアーキテクチャ設計:
・全体としてどんなテストがあって、どういう区分をしたら一番わかりやすくなるか
・単体、結合、結合に前半・後半があるかもしれない。ITA、ITBと呼んでいるかもしれない。
・どんなテストタイプがあって、それぞれ何をしていて、似ているものは何が似ているかを明確化しないといけない
アーキテクチャ設計は、多くの会社で、以前誰かが作ったテスト計画書をコピペしているケースが多い。
本当にそれでいいのか?派生として違うフィーチャが入っているかもしれないのに。
アーキテクト:抽象度を上げて、テストの全体像を考える。
◇テスト詳細設計
アルゴリズム、モデルに従って、具体的にテストの詳細設計を細かく考えていく。
◇テスト要求分析
テストのやり方を知らないといけない:アーキテクチャ、詳細
◇テスト実装
テストツールのスキルなどが必要
★各工程では、使う頭が違う。
工程を分けてあげると
ここは人間が考えないといけない、ここは自動化できる、を分けることができる。

テスト観点・テストケース・テスト手順を区別する(7ページ)
・テストケースの意図を抽象的に書いたものをテスト観点
・テストケースは必要な値を特定したもの
・テストスクリプトはテストに必要な手順がすべて書かれたもの
工程(分析~実行)を分けていないと、テスト観点を書くという工程を理解されづらい
(なに図書いてんだなどなどと言われる、みたいなやり取りがあったと思う)
テスト観点のモデリング→モデル化にいいのは絵や図
Excelとの対比)
テスト要求分析では、テスト要求モデルを作成する。
テストアーキテクチャ設計では、テスト観点をグルーピングする。
(組み込みのテスト観点例説明)9-10ページ
テスト観点はテストケースの意図を表している。
テスト観点が出てこないケースがある→目的のないテストは時間の無駄
テストケースは必ず意図を持っていないといけない。
 
■テスト要求分析(12ページ)
テスト要求の源泉の準備(仕様書、ユーザマニュアル、ユーザストーリー、ペルソナ
買っている人の姿を見たり開発の中の制約。テストしている自分たちもステークホルダに近い形になる。
開発しているメンバーの要求(おーだんさん)
(この辺かなり振り落とされました)
(14ページ)
テストケースを導くエンジニアリング的要求と
テストケースを導かないマネジメント的要求
テスト要求の源泉→開発系文書、ユーザ系文書(取説、業務プロセスを説明したもの、マネジメント系文書
自分たち自身がユーザの代わりになって要求を沢山挙げることも、テストには必要。
テストでポイントになること:開発が完璧なら、テストは概ね要らない。
開発は完璧なものを作っていない、だからテストが必要になる。
開発が完璧ならばテストがスムーズにいく。→テストが要らなくなる
でも、そうではないから、テストが必要。
テスト要求の源泉が入手できず、どうしても無い場合
自分たちでステークホルダになりきって(テスト要求を)作らないといけない。
テストは、改めて「テスト要求」を考えるべき(開発と違うから)
市場バグが出た場合、バグが流出した原因を分析して特定できないといけない。
それが特定できないと「テスト時間を増やせ」「テスト不足」など、意味のない(解決策?対策?)が増える。
このテストが抜けたのはこの観点が抜けたから、ということを突き止めないといけない。
バグが流出したのは
・観点がそもそも抜けたのか
・観点が抜けていなかったがテストケースが抜けたのか
・観点もテストケースも挙げていたが、抜粋実施でぬけたのか
・バグを観測していたが見逃したのか
(工程を分解しておくことで上記を突き止められるようになる:失念のため補足)
テスト要求の獲得と分割
エンジニアリング的テスト要求
 振り落とされたので失念
マネジメント的テスト要求(テストケースを導かない)
・スケジュール
・予算がいくら
・人数がこれくらい
・ある会社に発注する
テスト要求モデルの構築
大事なこと:絵を描くと何がうれしいか
複数のエンジニアがそれを見て話し合うことができる
Excelで同じように話し合おうとするのは難しい。図だと容易になる(俯瞰しやすくなる)
(図を描くのは?)設計しやすいモデルを作ることが目的だけれど
自分たちのテストチームやステークホルダ(開発マネージャ、エンジニア、品質保証組織の人間)
に納得してもらうのが目的。
モブテストのような方法を実施している組織もあると思うが、テストの方法について話し合うなら
モデルを使用するほうがいい
(16ページ)
テスト要求モデルの構築は、正解もゴールも定義できない。
納得度を関係者で上げることしかできない。
テクニカルで妥当な事とすることと、お仕事で納得感を得ることを
一緒にしてはいけない。
仕様書を書き写しても網羅はできない。(仕様書のコピペはテスコン即落ち)
テスト観点は多面的に挙げる。
実行結果が測定できるところ=チェックポイント
観点というものは、色々な会社で使えるように、わざと抽象度を上げている。
何かこうやったらうまくいく、は無い。
(特定の?)テスト観点で考えればうまくいく、も無い。
テスト観点を挙げただけでバグが見つかることがある。
網羅した雰囲気のテスト観点の納品物を作ろうとしないで
「多面的に考えて考えつくす」のが大事。
最初は今やっているテストをモデル化して(足りないなーと?)しみじみしるだけでいい。
できるテストは、そこにいるメンバーが考えつくしてこれ以上ない、と思ったところが技術的限界
市場バグで出たら(分析していたら?)何が悪かったか解る。
(17ページ)
テスト観点モデリングの2つのアプローチ
トップダウン:抽象的観点から考える
ボトムアップ:具体例から考える
2つのアプローチを循環して考える
テスト要求モデルの全体像
仕様書だけだと足りない。
お仕着せ(品質特性やあらかじめ用意されたモデル?)を鵜呑みにしてやるのも良くない。
第一レベルのモデルに正解はないが、第一レベルのモデリングの質(でテストの質が?)かなり左右される
(20ページ)
テスト観点モデルのリファイン
・網羅する
・整理
同じたんごだけれど、読む人によって意味が違うテスト観点が出る→同じ意味になるようにする
・剪定
プロダクトの品質を高めるためにテストしているので、プロダクトをテストしない方が
品質が高まるのならば、テスターは(プロダクトを)開発に差し戻すべき
 
■テストアーキテクチャ設計(22ページ)
テストケースが集まったものがテストスイート。
テストスイートの全体像を把握し易くしつつ、テスト観点をグルーピングしてテスト要求を整理する
・テストコンテナモデリング
テストコンテナは、テストタイプ、テストレベル、テストサイクル、テストケースを
ひとまとめにして呼んでいる。
負荷テスト、構成テスト、セキュリティテスト…何か同じようなテストをひとまとめにして呼んでいる。
何かがぐるーぴんぐされていたら、それはテストコンテナ。
テストコンテナの箱には、サブコンテナが入る。
何故そのコンテナでわけているかを、判るように図にする
・テストフレームモデリング
テスト観点が繋がったものでテストケースのもとになる
言語化すると考えやすくなるから名前をつける。
大規模なテスト設計では複数のテスト観点をグルーピングして扱いたいときがある。
テストを作るときに図を描かない(モデリングしない)と、テストを作ることが簡単な作業と思われる。
図を描かないから、ExcelとWordが使えればいいから、軽作業派遣と思われている。
皆さんはエンジニアです。エンジニアはすべからく図を描くものです。
(24ページあたり?)
俯瞰して把握しやすくするために、テストコンテナを用いる。
例.
負荷試験と性能試験は実施内容が重なりそう。
だがテスト観点を分けておくと重ならない。
テストが小規模で単純な場合…(失念)
テスト要求分析~テストアーキテクチャの順番は必ずしもこの通りではなく
テストアーキテクチャしながらテスト要求分析に気づくこともあるので
戻ることを躊躇しない方が良い。
(
コンテナは結合度が低い方(疎結合)のほうが良い
悪いコンテナの例
セキュリティテストと負荷テスト。→共通しているところがある
どちらかの実行結果がどちらかの実行結果に依存することがある。
→結合がある(コンテナの切り方がまずい)
(27ページ~28ページ)
SoR(システムオブレコード):すみません聞き逃しました
SoE(システムオブエンゲージメント):使い心地が優れているか
コンテナがSoE、SoR混在で見づらい場合はテストコンテナの粒度を自分で調整する
例.30ページのテストコンテナは
同じツールを使うというコンテナであれば適切だが、セキュリティテストと考えれば不適切
どちらも正解、不正解ではなくくそのように分担させた理由をちゃんと説明できるようにする
→責務「テストコンテナが何を意図しているか」
適切な責務の分担を行う必要がある
(32ページ)
テストには様々な設計意図があり、しばしば混在する。
あるテストのかたまりが何かを保証したいとき。あるテストのかたまりがバグをみつけたいとき
この2つのテストケースを混ぜてしまうと話が分かりにくくなるので分けたほうが良い。
テストの設計意図。自分はこのタイミングで何を意図してテストしているかを考えると
テストの精度はあがる。
コンテナの設計意図とテストケースの設計意図が食い違っているのはよくない。
テストケースを組み立てるときは頭の使い方が違うものを混ぜない方が良い
フォワードデザイン(こうしたらどうなるか、からテスト設計を考える
バックワードデザイン(ふるまいを考えてどうすればそうなるか、からテストを考える
この2つは頭の使い方が違うので混ぜないほうがいい(バックワードデザインの方が組み立て難易度が高い)
期待結果に「バグが出ないこと」があるもの:ポジティブテストデザイン
(バグがでることがあるもの):ネガティブテストデザイン
頭の使い方が違うので混ぜない方がよい
TAD(ほぼ振り落とされました。。。)
(33ページを見て話していた)
例えば、Typeという単語。
使っている人が違えば用語の意味も異なる。
人によって「シナリオテスト」という言葉の意図するところは全く異なる。
人によって「用語の意味が異なる」ことを念頭に置く。
同じ単語を違う意味で使うこと、本によっても、資格試験によっても食い違うことを
使う側(皆さん側)で違いを整理、区別する必要がある
(意味よりも)英単語の数の方が少ないから。
(34ページ)
テストスイートに求められる品質特性がある
・保守性
・単純に分割
・国際化
同じアーキテクチャでも(何を重視するかによって)テストコンテナが変わる
(35ページ)
探索的テスト
・ラーニングと探索は同じ人に実施させてはいけない
・チャータ:テスト観点のようなもの
探索的テストは網羅するタイプのテストではない
探索的テストは学習のような位置づけがある
テストエンジニアが仲間と(探索的セッションについて)おしゃべりするといい。
(36ページ)
 
アジャイル開発におけるテストアーキテクチャ
アジャイルもドキュメントが必要
・開発用にチケットが書かれる
・開発の最初からテストエンジニアも一緒になって、テストエンジニアとしては要求分析をする
・開発の人は、どういう風に操作するか、どういう風に操作したらフィーチャに価値を与えられるか
を考える
・悪さの知識:組み合わせて使ったら、などの想定は、開発の人は気にしない傾向にある
テストエンジニアとしての要求分析を、開発の要求分析を考えるときに一緒に考える。
変化、成長しやすいダイナミックなテストであることをキープする
計画やプロダクトの変化、成長にテストの変化が追い付くために
テストコンテナを切っておいて、テストが増えたらすぐに自動化できるようにする
テスト側の技術的負債を増やさない。スピードを落とさない。
チーム全員でテストを行う。(みんなで行うとよい)
アジャイル開発の前はテスト開発の全員でみんなの脳みそで考える
アジャイル開発の場合は開発もひっくるめて考える
開発者がテストを書いたほうが幸せになることを納得してもらうように工夫する。
(ここからイテレーション型テストアーキテクチャの話だと思う。すごく振り落とされていたと思う)
(39ページ)
後回しにしていいテスト(シフトライト)のテストを検討する
運用中の方が精度が出るテストは積極的にあとに回す
運用中にテスト実施したほうがよい、よくないで観点をわけてコンテナ化する
例外的に今のイテレーションじゃないものを走らせる(イテレーションフォーク・スリップ)
意図せず発生させると大変なので発生させないようにする?(失念)
(42ページ)
アジャイルで大切なこと
・開発の技術
ドメインの技術

フルスタックの技術が必要
(説明が光速になって振り落とされる)
テスト実装(57ページ)
(ほとんど振り落とされたと思う)
集約:複数のテストケースを1つのテストスクリプトにまとめる。
1つにまとめると、バグの切り分けが大変になる
(テストをまとめると効率的になるがそれとバグの切り分けやすさが?)トレードオフになる
(テスト開発プロセスを現場に適用する際のポイントのところだと思う)
プロダクトの全体でテスト観点図を描いてはいけない。
一部だけモデリングするところから開始し、いいな、と実感出来たら続ける。
リバースエンジニアリング(現行のテストからモデルを書いて、今何をテストしているかをわかるようにする)のは、とても良い
最後にテストコンテストの話。(62ページ)
何故、がわかるように設計を明示してほしい。
説明なしに品質の保証はできない。
XXに書いてあった、という説明はやめた方がよい。
言語化を直視するあまり、直感を捨ててはならない。
テストのことだけではなく、ソフトウェア開発に必要となる思考力やモデリング力を身に着けよう。