JaSST Tokyo '17に参加してきました

2/3(金)AM開催のテスト分析とテスト設計勉強会と
2/3(金)、4(土)開催の2日間開催のJaSST Tokyo '17行ってきました。

■テスト分析とテスト設計勉強会

こちらは、以前書いたWACATEでのリリカルさん(@mhlyc)の疑問から発生した勉強会です。

勉強会の詳細や資料はこちらにアップされてますので、参考にどうぞ。登壇された方はどなたも発表が面白く、色々と現状の自分の理解を整理したり考えるきっかけになりました。
https://connpass.com/event/47938/?utm_campaign=&utm_source=notifications&utm_medium=email&utm_content=title_link


勉強会を通しての理解は、
テスト分析:「何」をテストするのか、対象を理解すること
テスト設計:「どう」テストするのか、テストのやり方を考え、観点とかテストケースのひな型を作ること
と私は理解しています。

分析と設計の違いは、LTで登壇されてた河野哲也さんの説明が、すごくしっくりきました。
ソフトウェアで考えると分析、設計をやる人が同じだったり、各成果物が分かりにくかったりで分解しづらい。
そこで次のような注文住宅の例を出されていたのですが、分かりやすかったです。

 注文住宅における分析
  登場人物:住宅メーカーの営業、注文主
  やること:注文主の要望のヒアリングと整理
       要望のうち、できないことの明確化
 注文住宅にのける設計
  登場人物:設計士
  やること:住宅の設計
  アウトプット:設計図

分析でやってることって、「これからしようとしていること」への理解と整理なんですよね。だから特にこれと決まったアウトプットがなく、はたから見ると分かりにくい。
会社の上司とも、分析、設計について話したんですが、MindMapだったり、何かしらのリストであったり、やはり分析フェーズのアウトプットは明確でないよね、という話になりました。
昔は「テスト観点」まとめるのがテスト分析だと思ってました。現在は、分析した結果を受けてのどうテストするかが「テスト観点」だと思ってます。ただ、観点を考えているときのモヤモヤは分析の面も入るので、この辺分析と設計は行ったり来たりを繰り返すものかなーと。いろいろやってみて、理解が変わったらまた書いてみようかと思います。

■JaSST Tokyo 2017感想
特に印象に残ったものの感想をあげてみます。

論文発表1 : テストマネジメント
 「品質予測モデルの構築およびプロジェクト管理への適用事例」
 SEPGとして、品質予測モデルの構築して、3プロジェクトへ適用していったお話。モデルの作り方がすごくかっちりされているなーという印象を受けました。途中の予測モデルの構築のやり方は数式が出てきたあたりで脱落しました。すみません。。

 テストマネジメントツールSquashTMを利用した継続的テスト改善 」
 会社の後輩の発表でした!日本では適用事例が(たぶん)初となるテストマネジメントツール「Squash TM」を適用してみた時の話です。テストマネジメントツールの導入は、テストエンジニアの皆さん関心が高いようで、盛り上がった発表でよかったです。
 発表資料は、後日JaSST公式から公開されますが、今回登壇した後輩が、Squash TMの紹介記事を書いてますのでご参考にどうぞ。
 SquashTMことはじめ。
 http://qiita.com/miwakai/items/843c76e50eef7719ae6d

「VSTePのファーストステップ〜JaSST'16東北出張おかわり会〜」
テスト分析の技法であるVSTePのワークショップ。VSTePの詳細は、以前のJaSSTの西康晴さんの資料を参考に。
http://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf
今回のワークショップで扱った範囲は次の通りで、ワークのグループ毎に、みんなで納得できることをポイントに実施。
 <1>テスト観点出し
 <2>テスト観点図の作成
 <3>テストコンテナ(テスト観点をグルーピングしたもの)の作成

「みんなで納得できること」というのがミソで、これでグループ全員が戦力になれる、誰でも作ったテストについての質問を受けた時に答えられるという状態になります。

 <1>テスト観点出し
 ・面白い! 人と話すと自分になかった視点が出てくる。

 <2>テスト観点図の作成:出した観点をツリー上に整理していく
f:id:yuki_shiro:20170204115241j:image:w360
 ・<1>で出した観点を、うまくツリーに整理するのが難しい。
 ・なんとなく気になったからあげてみたとか、うまく階層化出来ない観点がいる。
 ・ツリー状にすると抜け漏れやまとめられるものが出てくる(InがあるけどOutがない、共通化できる奴はどれだ?)

 <3>テストコンテナの作成:ツリーにした観点をさらに整理、分割して意味のあるグループにする
f:id:yuki_shiro:20170206003435j:image:w360
 ・テスト計画ともリンクできるようにコンテナを作成
  →最初に確認したい基本的なパスを通すコンテナがないね!ということに気づく
 ・コンテナ間で依存関係のある奴はどれだ?
 ・コンテナで先にやっといたほうがいいやつどれだ(バグ出たときに手戻りがでかいやつ)

というようなことを、ワイワイ話しながらやるのでとても楽しかったです。納得感大事。

ちなみに「最初に確認したい基本的なパスを通す」ことを、うちではなんとなく「疎通テスト」と呼んでいるけど、ご一緒した他社の方のところだと「疎通テスト」はpingが通ることを指すんだそう。用語の共通認識って大事ですね。

テストと人工知能
人工知能を使ったシステムをテストする話と、人工知能ディープラーニングを使ったテストツールのお話でした。個人的にはMagic Potという画像認識などの技術を使ってる自動テストシステムが面白かったです。テスト実行は今後AIとかが活躍する分野になり、テスト設計や分析などのスキルが増す求められると、最後の方で話されてましたが、これは今後のスキルを考えるうえで重要ですね。

「品質保証活動の本質」
品質保証なんて言葉のないころから品質保証活動やってこられた方の話なので重みがあって面白かったです。最近はプロジェクトでデータを扱うことをやっているので、「データは提供してくれる人のために使うべき」って話には考えさせられました。自分は割とデータ取りっぱなしとか、取る目的整理できてなかったりは自分もやってしまいがちなアンチパターン。そこちゃんと考えないと品証も開発も苦しいだけですね。この点は、自分の課題です。

[広告]

コメント
0件
トラックバック
0件
ブックマーク
0 users

[広告]

yuki_shiro
yuki_shiro