にしさんのテスコンチュートリアル
え～、みなさんこんばんは。
決勝の審査委員長のにしやすはるです。
無差別級の審査委員長です。
このチュートリアルは、コンテストに勝つためのものではありません。
ASTERはテストの高度な技術をみなさんに伝えようとしています。
先日、ASTERでは無料でテスト研修のテキストを公開しました。
今日の内容は公開したテキストの先の話です。
皆さんが会社でいいテストをするためにこのチュートリアルがあります。
タイトルをみてください。テスト設計チュートリアルです。コンテストのチュートリアルではありません。
対象者は、ちょっとバグを出せばいいや、という人ではありません。そういう人は帰っていいです。
大規模で、高品質で、段階的に反復的に継続的にリリースしていく短納期だったり、そういうテストをしている人
テストレベルが１４ぐらいある通信系の会社がヨーロッパにありますが、そういうテストをしている人
たくさんのテストレベルを扱わないといけない人
単一のテストレベルで自動化しているけれども、本当ならば複数のテストレベル、複数のテストタイプを自動化したいと思っている人
そういう人や会社は今日の話の内容を理解していないといけません。
１０万件を超えるようなテストケースを扱うような大規模なシステムです。
ひとつのイテレーションでしたら、数百件かもしれませんが。
産業構造で言えば、みなさんの会社で事業会社ですと、自分の会社のプロダクトが複雑でしたら、今日の内容は役に立ちます。
自社で作らず、外に依頼している場合、自分たちが今日話するような内容を知っていないと、依頼先が何をやっているのか理解できなくなります。
テスト会社は今日の話を使って、テスト開発方法論を作っていただきたい。
発注する会社は、自分たちが理解して、次に発注先にこういう話をふってみて、できなければそういう会社なんだと判断していただければ。
いきなり、テストケースを書く。
大項目、中項目、小項目、仕様書を転記していく。
こういうのは、いきなりコーディングをするようなものです。
ちゃんと動くかどうかは分からないけれども、コンパイルは通るし、なんか動くし。こういう仕事はしないでしょう。
しかし、テストではこういうことがやられています。
ソフトウェア開発をするように、段階的に順序だてて、様々なノウハウを順番に投入してテストを開発していく。
テスト開発です。
自分たちが何をお客様に提供しているのか。
テストスイートです。テストスイートというのは、テストケースの集合体です。
テストスイートを提供しています。
このテストスイートのよさを確保していく、それがテスト開発です。
テスト開発というのは、インターネットで検索してもそんなにでてきません。
皆さんのなかには、JSTQBに定義されていない、ISTQBにも定義されていないという人がいますが、
ISTQBのようなシラバスは妥協の産物。
全世界でシラバスをベースに高度な話がされています。
今日はインターネットを検索してもでてこない話をします。
我々はテストをモデリングするための道具立てを提供します。
ソフトウェア開発をするようにテストも開発をします。
そうすると、工程ごとに成果物が決まります。
テストアーキテクチャ設計はテストアーキテクチャモデルが成果物になります。
テスト詳細設計の成果物がテストケースになります。
自社に展開するとき、スライドに載っているような４つの成果物が何かを決めることが必要です。自分たちで決めます。
コンサルを呼んだ所で、決めてくれません。自分たちで決める必要があります。
はい。チュートリアルなのに、こういう話をするのはどうかと思いますが、少なくとも無差別級のチュートリアルなので、どうやって技をかけるかという話はしません。
先ほどのテスト開発プロセスを横に並べると、こうなります。
みなさんが使っているガントチャートよりも細かいんじゃないでしょうか。
テストという矢羽が一本だったりしたら、やばいです。
テストのエキスパートがいいテストしているのかもしれませんが、他の人はできません。
属人化を排除するというよりも属人化する領域をどんどん高度化すると考えたほうがよいでしょう。
テスト観点というのは、U30の講師であるスターもにしさんもよく分かっていません。
抽象的に考える道具がテスト観点です。
オブジェクト指向を考えてみましょう。何がクラスで何がクラスではないかというのは、手順化できませんし、皆が合意する定義もできません。
テスト観点も同じです。
それがテスト観点かどうかを気にしてはいけません。
それよりも気になっていることを、テスト観点として書き挙げたほうがよいです
具体的なテストケースを導き出すようなテスト観点ががんがんでますけれども、オープンクラスでは、そうでないものも考えます。
テスト観点は何かというのは、オープンクラスでは自分たちで決めていいんだと思ってもらったほうがよい。
テストケースとテストスクリプトは明確に区別する必要があります。
テスト観点とテストスクリプトをまるっと一緒に考えて、一つの成果物に書こうとしますけれども、書こうとすると自然言語で書くしかなくなります。ワードやエクセルで書くことになります。
テストケースごとの関連性まで考えようとすると、自然言語で書かれていると分からなくなる。
先ほど工程の話をしましたが、ソフトウェア要求定義のような工程の時間を決めていないでただ開発としてあったら、横からとっととプログラムを書けという人がでてきます。
テストも同じです。テストという矢羽が一つだと、どこにバグがあるかなあっと考えていると、誰かが時間がないんだ、早く手を動かせという人がでてきます。
ですから、テストにも工程を分けないといけません。
また、工程ごとに使う頭が異なります。
どのような作りをするとバグがでやすいのか、などをテスト要求分析では考えます。
どのようにテストレベルやテストタイプを分けたら、脳みそを行ったりきたりしないで、仕事ができるか。
どういうツールがあるのかどういうテスト会社がいて、どのように分けると、丸ごと発注できるのか。
テスト全体の立て付けを決めていく。
テスト設計は物事を網羅的に考えることになります。
テスト実装は、操作に関する様々な知識が必要になります。
ショートカットキーがあるのか、OSがどこまでサポートしてくれるのか、
UIとかインタフェースなどの知識が必要になります。
自動化をまわしていくための知識が必要になります。
工程ごとに使う脳みそが違います。
ただドキュメントが違うのではなく、抽象度が違うこと、使う脳みそが違う、そのために分けている。
場合によっては機械に代行させられることが見えてきます。
テスト詳細設計は自動化できたりします。
世の中には、テスト開発方法論がいくつもあります。
HAYST法やゆもつよメソッドとかそういう方法論があります。
どの方法論を使われてもいいです。今日はVSTePみたいな話をしますが、説明をするときに、説明する概念がVSTePがそろっているので、VSTePの道具立てで説明します。
みなさんが社内で他の方法論を使っているのであれば、その方法論に読み替えてください。
テスト観点はテストすべきことといってもよくわからない。
俯瞰してビジュアルに捉えること。テスト観点で大切なことはこの２つ。
テスト要求モデル、テストアーキテクチャモデルを作っていきます。
テスト観点の定義はしませんが、なんとなくこんなものだなというものをテキストに挙げています。
テスト観点の議論をすると、宗教論争になってしまうので、やりません。
バグの種類も挙げていたりする。
多面的に広げて考えられるか、これがテスト設計の質になります。
テスト観点が、仕様書に紐付けられていて、それ以外に無い場合は、仕様書のコピペなのでそういうテスト観点を書く会社には発注しなくてもよいです。
テスト観点という「観」に引っ張られる。
実行結果を観測する、この観測するところを観点といっている会社があります。
観測する側と、パラメータなどのテスト条件側があります。
両方をテスト観点といってもいいし、区別してもよいです。
でも、経験上区別しないほうがいいです。
テストケースの意図を表すのがテスト観点です。
皆さんの現場には非常に大量のテストケースがあるとして、どうして無駄なことをやっているんだろうと思うかもしれませんが、これは、明示的にどんなことをテストするのか、その意図、理由、目的が分からないからです。
これを紐付けるのがテスト観点です。
テスト要求の源泉の準備
難しいことをいっているんではないです。どこを見ればいいですか？ どこに聴きに行けばいいですか？
が分かっていれば、いいですということです。
テスト要求というのは、テストが分かっていない人は、ソフトウェア要求仕様のサブセットだと思っているかもしれませんが、そうではありません。
ソフトウェア要求仕様に反映されていないものがテスト要求に入ってきたりしますので、余裕がある会社は別々に作っています。
ソフトウェア要求仕様を作った時点で、これは書かなくてもいいや、とか書くと面倒だなあとか、そういうのをテスト要求分析に使うとメモを残しておく。フロントローディングして作っていく。
そういうわけで、テスト要求分析の源泉が分かります。
よさに関する知識、プログラミングパターンとか、このあたりは凄い人が作っているとか、検証作業が足りていないところとか、進捗が滞ったところとか、
ほかに完成像の知識とか。
そのほかにテストマネージメント系の要求もあります。
テストのスキルとか、信頼度成長曲線とか、マネジメント系のテスト要求はありますが、テスト観点に入らないので、区別して扱う。
たまにテスト観点に予算と挙げる人がいますが、どうしようとするのか、ちょっと分かりません。
私は個人的に絵が好きなので、テスト観点を図で書いていますが、マトリクスで書いていてもいいですし、マインドマップが好きな人はそれを使ってもらっていいです。好みですから。
テスト要求分析の大事なことは、ある作業で完璧なテスト要求モデルを一気に作られると考えないほうがよい。
ウォーターフォールのように完璧なテスト要求モデルをかけると思わないほうがよい。
ちょっとさきに書いて、学習して、探索して、モデルを反復的に書いていく。
書いていくと、構造がゆがむので、そのとき整理する。何度も何度もリファインする。
テスト詳細設計を書いているときに気づくこともあるし、テストアーキテクチャ設計をやっていて気づくときもあるし、テスト実施してバグがでて分かることもある。
テストケースだけアドホックで増やすなんてことをしないで、必ずモデルまで戻ります。これ大事。
テスト観点のモデルは抽象化されているので、多くの場合、模造紙とかで全体像を一覧できます。
マインドマップなど、枝が閉じられる場合、枝を開きながら理解することができます。
やってはいけない話は、テスト観点を早い段階で分解して、担当者に考えさせるはダメ。
ぎりぎりまでみんなで納得するまで議論して、こんなものだねと共感させる。
何かの理論を使えば、判定できるかとかありえないから。
テスト要求モデルは、もうこれ以上いいものができないと考えたら、それがモデルになります。
どこまでのレベルのものをかけるかどうかは、自分たちの技術力次第です。
技術力を鍛えなければ、外から買ってきても定着しない。
自分たちの技術力のマックスはこうなんだということを知る。
一生懸命テスト要求分析しても、バグがでます。このバグの分析をします。
そうしてテスト観点のモデルをアップデートします。
何度も書き直して、技術力を高めていく。
テスト観点図を描いてきました、見てくださいというのでみると、
機能仕様書の目次を転機していたりします。
仕様書の単語を書き写してもテスト観点になりません。
QAの人って網羅したことにしたいらしいです。
VSTeP ではモデルの中に網羅できていないマークをつけるようにしているんですけど、そんなことをしたら要検討というマークが残っていたら、レビューが通過しないので、取ってください。といわれたりします。
不幸ですね。
できることしかできないし、できないことはできない。できないことを明示する。
レベルアップするために議論する。
整理したテスト観点図があると、開発者を引き込みやすい。
テストケースを開発者に見てもらっても、Excelシートが１００ページあったら、げんなりするでしょう。
部下からテストケースのレビューをしてくださいといわれたら、レビューしますか？
無理でしょう。
テスト観点図が無いテストケースはそもそも整理されていないし。
ここまで込み入った話はまだ早いという会社もあるでしょう。
テストケース表を並び替えて、グループ化するところから始めましょう。
ポストイットにおんなじようなことと書いておきましょう。
言っていることの中身は、皆さんのようなエキスパートがやっていることを集めているだけです。
テスト観点図を描くと、全部網羅したいと思うみたいですけど、全部は網羅しません。
網羅しようとすると、トレーサビリティという文字が気になると、テストの場合は仕様書のコピペになりやすい。
トップダウンもボトムアップも両方テスト観点を書くときには必要。
抽象の階段をいったりきたり、上げ下げを自由にする。
テスト設計コンテストでもそうですけれども、テスト要求モデルの全体像は様々です。唯一全体の解はありません。
一面的なものはいまいちです。機能ばかり書いている、画面ばかり書いている
または、正常系、異常系で書いていたります。
Aと￢Aで挙げる人もいます。
正常系、異常系で書く人は、多面的なテスト観点モデルを理解できないことがあります。
お仕着せのものを流用しようとする人もいます。
国際規格を使おうとする人もいます。
いいですか、国際規格は網羅していませんし、皆さんがやろうとしているソフトウェアをターゲットにしていません。
品質特性みたいなものを増やしていくんならいいんですけどね。
いっぱんテストタイプモデというのがありまして、
システムテストのテストタイプが列挙しています。
その会社がやっていることをテストタイプに列挙しているので悪くはありませんが、
今の皆さんの会社にあっているかどうかはわかりません。
なそさんがテスト観点を書こうとしています。
このうち、どれを採用するかではなく、考慮が十分なのかどうかが大切です。
他の人が言ったことをそのなま使ってもうまくいきません。
リファイン。
リファインのスライドを理解できるのであれば、かなり本質的なモデリングをやっています。
親子関係分析。ある親に対して具体化していない子供をつけようとしていたります。
性能の下に負荷を置く人が多いけれども、親子関係分析が十分にできていません。
負荷は別の親にします。
親子関係分析は、兄弟関係の分析もやります。
兄弟は本当に兄弟ですか？
和食の直接の子供がべったら漬けだったら、間に漬物をいれたいじゃないですか。
間のノードとか、観点とか入っていきます。
子観点は７つぐらいにしたほうがよいでしょう。
テストレベルを跨いで同じテスト観点がでてきたらどうしたらいいですか？
という質問がよくありますが、本当に同じテスト観点かどうか疑ったほうがよいでしょう。
テスト観点の組合せも、限度無くことがあります。
心配なんです。
新たに組合せを考えるのであれば、いいんですけど、
リファインしようとして、この組合せでいいかどうか疑問に思ったとしたら、正しい問いかけです。
でも、疑問に持ったことを指摘して、バグがでたらどうするんだって言われる残念な組織もあります。
なんでこの組合せが必要なのかを考えてください。
中には、組合せの背景にある、別のテスト観点が潜んでいることが多いです。経験上ですが。
入力パラメーターに無いので、入力できないので、組み合わせているというケースが多いです。
組合せをすべてやろうとすると何年もかかるとき、剪定します。
あきらめて、ズームアウトします。
カバレッジ数を減らしたりします。
やってはいけないのは、時間が無いのでやらないだろうとテスト観点を挙げないということです。
テスト観点を挙げる時間が無いという人がいますが、テスト実行に比べれば微々たるものです。
テスト実行に比べれば、たいした時間は必要ありません。
テスト観点をすべてあげきれていないｂ場合、最後の最後まで不安が残ることなります。
大事なことは、挙げてから削る。
確定、テスト観点を書きながら十分検討したなというものは確定マークを書いていきます。
確定マークが増えていくと、検討が進んでいるなと思います。
これから本題。テストアーキテクチャ設計。
ぐぐってもでてこない。テスト実行のインフラを言ってる場合もあります。
テストレベルやテストタイプって何かを考えさせること。
テストレベルやテストタイプを、このテキストではテストコンテナと読んでいます。
テストレベルもテストタイプも初心者は明確に区別できますが、
腕が上がると区別できません。
機能性テストというテストタイプがあり、機能テストというテストレベルがあり、
この区別を延々と議論したりしていて、無駄ですよね。
何をテストレベルか、テストタイプかは勝手に決めてかまいません。
このチュートリアルのテキストにテストタイプを区別して書くと、
「これってテストレベルじゃない？」って言われてうざいのでテストコンテナといっています。
テストフレームモデルというと難しいかもしれませんが、
エクセルの列見出しを考えることです。
フレームを作っていると、コンテナを分けたほうがいいなと思うこともあります。
テストコンテナはテストケースをグルーピングしたものですが、
テストケースといってしまうと、抽象度が低すぎなので、
間にテスト観点をかましています。
テストコンテナは、子コンテナをもつことができます。
テストレベルの中にテストタイプがあっても普通のことですよね。
包含関係といったりすると、ごまかせます。
大規模なテスト設計の場合、このような構造をあらわしている
これはテスト計画書に入っていますが、
テスト観点が集まったものですが、
プロジェクト計画書を作るときに、アーキテクチャを作りますか？
作りませんよね。
テスト計画を作るときに、テストアーキテクチャのことをあんまり考えずに、コピペしてします。
規模が大きくなると、そんな簡単ではありません。
単体テストのようなテストレベル、
テストタイプというのは、よく分からないです。
サイクルはおおむね同じことを繰り返す。または、時間で区切ったもの。
イテレーションごとにテストコンテナといいますでもいいんです。
みなさんは、現場でいろいろなコンテナのまとめ方をしています。
それを前半とか後半とか言っているからノウハウがたまらないのです。
全体を俯瞰して理解しやすい。
コンテナごとに役割を明確にする。
このあと責務の分担といっています。
ある会社には、負荷テストと標準に書いています。説明にストレスを書ける。
ストレステストの説明に負荷をかけると書いています。
技術が低いわけではありません。テストマネージャがいい感じで、
区別しているんです。
ワードだと適当にかけます。
いい加減な組織だと、モデリングで
負荷テストというコンテナにストレスと入れて、
ストレステストというコンテナに負荷といれるかもしれないけど。
ワードが原因じゃないか。
コンテナの順序。
テストスイートの品質特性を考える必要があります。
小規模で単純なものは、単純に考えればいいです。
複雑なものに対しては、複雑なことを考える道具立てが必要になります。
機能テスト観点に負荷テストを後回しにしたらいいですし。
同じ時期にテストしたいものをまとめる。
同じ趣旨のテストをまとめる。
負荷をかけるというものをまとめる。
性能テストは負荷をかけるというわけではないので、そのグループからはずしてもいいし。
モジュールの品質を保証したければ、UTで。
テスト観点間の関係が少なくなるようにまとめます。
負荷と性能を分けると、性能測定をどちらに入れるか悩むようになったら、
依存関係が無いようにします。
疎にします。
しれっと、テスト設計意図、テスト観点と異なる？
某所で誰かが経験で、ゲームではテストコンテナがあるんじゃなかろうかっで挙げたテストコンテナがスライドに書いています。
人によってはこれぐらいと思いますし、人によっては、これぐらい粗いほうが扱いやすいなと思うかもしれません。
このテストコンテナにはSoRとSoEを区別していてい、SoRは網羅重視とかしています。
自分のシステムはSoRだからSoRのテスト観点しかないというわけではありません。
SoEのテスト観点もあります。その区別が必要だと思います。
コンテナは自分で考えろ。
いろいろなコンテナがあるぞ。
粒度はいろいろあるぞ。
去年までのチュートリアルと、今年では変えている。
去年までは知っていることを教えていません。
でも、教えていないことを参加者ができるようになったので、全部教えてもいいじゃんになった。
コンテナの責務を考える。
結合度を低く保つ。
コンテナを跨ぐようなものを減らす。なくす。
凝集度、いいかんじでまとまっている。
テスト設計意図でまとまっている。
テスト設計は難しい。
理由は、テスト目的、テスト観点、テスト目標、おなじようなでも違うような、似たような言葉がたくさんあるから。
テスト観点は、ようするにどんなテストケースを実行するか？
テスト設計意図は、そのテストを何のために設計するか？
このように言われてもわかんないでしょう。
負荷をかけるテスト。テストかんてんん
テスト設計意図はバグを見つける、保証する。
これだけの負荷をかけても落ちませんでした。というふうに保証する。
トレーサビリティをとるためにテストする。
エビデンスが欲しいというテスト設計意図と、バグを取りたいというテスト設計意図をあわせるとろくなことがありません。
ラーニングのためのテストと、保証するテストを合わせる
リズムを合わせるテスト、
ユニットテストをどのようなテストするかによってことなる。
保証のため、あらっぽい詳細設計仕様、仕様を分析し、落とし込んでいる
設計意図が同じようなものでないと、
メンテナビリティ、自動化可能性
自動化が難しい、場合は、コンテナレベルで自動化可能性を考慮していないからというものかもしれない。
開発工程と一致したほうがよい。
記述性、ひたすら書くものと、探索的テストは分けたほうがよい。
実行結果が早い場合と、遅い場合をあわせないほうがよい。
仕様変更が多いところと少ないところは分けたほうがよい。
テストには２つの方向性があります。
こういう条件のときにこういう結果がある
条件を先に考えるタイプと、
フォワードデザインといいます。
こういう動作がでるには、どうしようか
バックワードデザイン。
順設計と逆設計を混ぜると、混乱する。
逆設計は網羅しにくいので、網羅率を高めようとするテストと合わせないほうがよい。
動かないテストは動かなそうな知識をふんだんに必要となる。
仕様どおりに動くかどうかを確認するテストと、
バグがでるかどうかをテストする場合では、
使う頭が違う。
そういうのがある。
テスト設計するとき、技術者はいろいろ考えるんですけど、
ワードに落とし込むときに書かないので、後で分からなくなるし、
他人に伝えられなくなるし、
探索的テストは、テストアーキテクチャ設計で何を探索的テストをするのかをざっくりと考えておいたほうがいいです。
テストの工程って、決められたことを生産性？ 単位時間あたりにどのくらい消化したかをマネジメントするんですけど、
探索的テストは、何かを感じたのかをおしゃべりで聞きとってあげるのが大切。
モデリングだけでは、野生の人のノウハウが落ちちゃう。
だれだれさんの勘とかのコンテナを用意して、そこにぶち込むのがいい。
できないことはできない、野生は野生って書けばよい。
感受性を高めると、言語化能力が低いとレベルが低いと見られたりする。
マネージャから理由を言えといわれて困っちゃう人がいる。
ここからは少しコンテストの話。
評価が低くなるのは、過去の成果物から切り貼りしたり、誰かの言ったことをまねしたりすることです。
モデルを書けというと、複雑なよく分からないモデルを書いてきたりします。
この複雑なモデルというのは、全部いれちゃったりしたりする。
ケースと手順の違いを区別していないとそうなったりする。
バグがでるでない、故障したいかしたくないか、
テストケースとして考えるべきものと、
テストケースに書いておかないと実行できないこと
この区分けが分からなくなってしまって、
事前条件はテスト意図ではないけれども、事前条件が無いとテスト実行できないために、テスト意図と考えてしまう。
テストモデルは４つあるとテキストでは言っていますが、他のモデルも当然あります。
基本４つは知っておけよというもの。
テスト実装は、テストケースと手順を区別しろよと。
見た目、テスト観点とあるテスト観点を一気に実行することができる。集約は。
意図の異なるものを一緒に実行しても、影響しないから一緒に実行するということを理解してやること。
大事なことは、表をうめる単純作業から、複雑なことを考えることだ。
できることから小さくやって、小さく回して、効果を得ながらやっていく。
テスト観点を整理して、１時間とか２時間とかやって、効果を感じてもらう。
テスト観点からテスト実行まで自動化することは可能だけれども、
そうではなくて、顧客とのコミュニケーションの道具として使ってもよい。
テスト観点を共有する場を用意するとか。
モデリングスキルを高める。
実際には、小さく回していくときには、リバースエンジニアリングしていくのがいいでしょう。
過去の応募作に気になっていることを書いています。
（テキスト読んでね）
最近のトピックスを取り入れたりするんですけど、取り入れ方が中途半端。
テストはエンジニアリングです。
テストモデリングは業務での熟考度を反映します。
テスト開発には、ソフトウェア開発に必要な様々な知識を知見が必要になります。