Jasst16 tokyo 参加報告

1

JaSST Tokyo 2016 報告会★ 紹介セッション★

テストプロセス改善

テスト自動化エンジニアやそのキャリアパスってなんだろう？

テストコンテスト

3/27/2016©NaITE （長崎 IT 技術者会）

2

アジェンダJaSST Tokyo 2016 報告会１．テストプロセス改善　　　　　　　　　　　　　　　　　　　　　 by 角田　俊

　　～プロセス改善でテストエンジニア総活躍社会へ～

２．パネル　　　　　　　　　　　　　　　　　　　　　　　　　　　　 by 氏田孝幸

　　～テスト自動化エンジニアやそのキャリアパスってなんだろう？～

３．テスト設計コンテスト’ 16 　決勝戦　　　　　　　　　　　　　　　 by 岡野麻子

　　～我々のテス都構想に清き一票を！～

• 藤沢君の内容


3

テストプロセス改善　～プロセス改善でテストエンジニア総活躍社会へ～

角田　俊


4

• 2015 年 9 月に TPI NEXT の日本語翻訳版書籍が発売になり、国内においてテストプロセス改善技術への関心が高まっています。

• テストプロセス改善技術については過去の JaSST 東京や JSTQB カンファレンスにて TMMi や TPI についての発表がなされており、先進的な企業においてチャレンジされてきました。現在は TMMi が Release1 を、 TPI は次版である TPI NEXT がリリース、加えて ISO/IEC 33063 も 8 月に発行という状況で、海外を中心に技術発展と普及が進んでいます。しかしながら、これまで国内では TQM などによりテスト改善という言葉を使わずともテストに関する改善に取り組んできました。

• 本パネルディスカッションでは、これらテストプロセス改善に関する技術や取り組みを技術を切り口として「テストにおける改善」について議論します。最初に簡単にそれぞれの技術比較や動向を紹介し、モデルを活用した（活用しない場合も含めた）プロセス改善の難しさ、フォーカスすべきこと、進める上での注意事項などを関係者や実践者などの識者により議論します。


テストプロセス改善～プロセス改善でテストエンジニア総活躍社会へ。～

5

テストプロセス改善～プロセス改善でテストエンジニア総活躍社会へ。～

• セッションの流れ


パネリストとテストプロセス改善技術の紹介

テストプロセス改善技術の違い

参加者のテストプロセスの悩みについて

6

3 つのテストプロセス改善技術

• TPI NEXT• 自己評価とそれに伴う自己改善

• キーエリアが定義されており、今出来ていること、出来ていないことが簡単に分かる

• ISO/IEC 33063• 国際標準規格であり、簡単に文句は付けられない

• テストプロセスを説明しているのが ISO/IEC 29119−2 であり、その適応性を説明したのが ISO/IEC 33063

• TQM （ Total Quality Management)• 人の数、会社の数だけ TQM がある

• 組織が常に改善し続けることで品質を上げていくというプロセス

• 会社なりにプロセスを進化させていく


7

ディスカッション内容

• 組織に最善なテストプロセスとは、型に嵌めることではないのではないか？現場で不満に感じていることを常に改善していけばプロセスは改善される。そもそも、 TPI NEXT はプロセスなのか？（西康晴さん）

• TPI NEXT も”キーエリア”として定義しており、型に嵌める改善方法ではない。現場によって上手く適用できるようにキーエリアなどを修正することを推奨している。ただし、最初から修正するのは難しいので、キーエリアは改善の方向性をしてしている。（薮田和夫さん）

• ISO/IEC 33063 は国際標準規格であり、誰からも文句を付けられないというメリットがある。（増田聡さん）


8

参加者のテストプロセスの悩み

• 付箋紙が全員に配られ、現在の抱えている悩みを記入し、それを集計した。• 「現場に改善意識、問題意識がない」という悩みが多かった。


→　テストプロセス以前の問題のような気がする　　現場の人が課題と感じていないのであれば無理に改善する　　必要もないのではないか？

他の悩みはメモを取っていませんでした。。。

9

聴講してみての感想

• 会場は満員（立ち見あり）な状態。テストプロセス改善技術への注目の高さを感じた。

• ISO/IEC/IEEE 29119 　は WACATE でも簡単なセッションがあったが、機会があったら勉強してみたいと思った。

• テストプロセス改善技術もいろいろなものがあるため、違いを理解してあったものを使う必要があると感じた。

• 悩みとして出た現場の他の人に改善意識がないというのは、確かにテストプロセス改善以前の問題であるが、その部分が一番難しいのではないかと思った。



パネルディスカッション　～テスト自動化エンジニアや　　　　そのキャリアパスって　　　　なんだろう？～

氏田　孝幸

11

• テスト自動化というキーワードにおいては、自動化に必要なスキルやツールといったところの議論は活発に行われています。

• しかし、どういった人材がテスト自動化エンジニアに向いているのか、また、いざ自動化エンジニアになったとして、その後の将来像などの議論は決して多くはありません。

• このセッションでは、自動化エンジニアのキャリアパスについて、自動化に深く関わっている方をお招きしてパネルディスカッションを行いたいと思います。



12


• セッションの流れ


パネリストと自動化との関わり方の紹介

自動化エンジニア像について語る

自動化担当者の悩みへの質疑応答

13

ディスカッション内容

• 自動化エンジニアとは、どんなスキルを持つ人？• どんな事が自動化できるか抽出した上で、設計できる人。

• 作って終わりではなく、廻し続けるための CI 的な知識も必要。

• どういうキャリアパスで自動化エンジニアになれるのか？• スクリプト書くだけならそんなにかからない。半年もあればできる。

• 手動テストとかテスト設計も知らないとなので、 1 年くらいでそこそこ形になる。

• 自動化エンジニアになった後のキャリアパスとは？• 自動化の尖ったところを突き詰め、その後基本に立ち返ってスーパーコンサルを目指すとか。

• 全体を統括するジェネラリスト的な立ち位置。テストだけじゃなくて、全体の自動化ができるようになっていけば。


14

参加からの質問


• 「マインド」を持っていない人はどうやって育てる？→前を進んでいる人の背中を見せる。大変なことも多いけど、成果が出たときに得られるものも多い。その辺を感じ取ってもらう。

• 「テストコードが書ける」ってどの程度のスキルが必要？→フレームワークを使って何か作れるとか、そういうレベル。キャプチャ＆リプレイツールは使わず 1 から作れる。

• 特定の着眼点 ( セキュリティ等 ) に特化したエンジニアは居た方が良いか？→スペシャリティがあることは良いことだけど、そこだけにならず全体を見られるような人になってほしい。

15


• 自動化エンジニア＝スキル的に尖がっている人。という先入観を持っていたが、プロジェクト全体を見るスキルも重要視される、かなり難しい立ち位置のロールであると感じた。

• 自動化は品質を上げるための手段であり、すべてを自動化する方向には考えない。ときには自動化を諦める ( 切り捨てる )マインドも必要というのは驚きだった。

• プロジェクト全体を見るスキルは、数年スパンで習得していくものなので、自動化も学びながら色々なところに顔を出して自身のスキルアップを図っていきたいと思う。



テスト設計コンテスト決勝’ 16 　

岡野　麻子

17

• テスコンの目的• ソフトウェアテストを分析設計から行うことを周知し、ソフトウェアテストエンジニアに対する教育の機会を提供する

• コンテストという形式をとることにより、ソフトウェアテストが創造的な作業であり、楽しいということを経験してもらい、若年層及び初級テストエンジニアからベテランテストエンジニアまでテストへの興味を高める

• ソフトウェアテスト業界における技術開発を競技を通じ、促進する

• 出場チーム

　しなてす、てすにゃん、 FSTWG 、 SASADAN Go 、北のテストマン

• テスト設計対象は、カラオケシステム

　 http://aster.or.jp/business/contest.html• テストベース

　 http://aster.or.jp/business/contest/rulebook.html#testbase3/14/2016©NaITE （長崎 IT 技術者会）

テスト設計コンテスト決勝 ‘ 16

18

テスト設計コンテスト決勝 ’ 16• セッションの流れ


各出場チームによるプレゼン

審査員・聴講者による質疑応答

クロージングで結果発表

19

プレゼン内容と特色（１／２）　個人的な観点でピックアップ

• しなてす• テストの優先順位付けで、開発者が行うテストとの順位を考慮している

• テストコンテナの中身が見えない

• てすにゃん• テスト方針としてリスクベーステスト等を上げている

• テスト手段に回帰テストとユーザストーリーテストがあった

• FSTWG• 正しいもんを作っているのか？＝システムの価値

• テストの定量的評価を試みている

• 魅力属性、夢中属性、無関心属性


20

• SASADAN Go• 仕様、観点、条件を整理→ USDM を利用

• ステークホルダー分析→マインドマップを利用

• プロダクトリスク分析において重要度・影響度により、テスト優先度を決定

• 北のテストマン• テスト要求分析にマインドマップを使ってブレストを実施する。その中で、非機能要件を抽出する。

• テストタイプごとに利用頻度とリスク影響度で優先度をつけている

　　→ SASADAN Go と同じ


プレゼン内容と特色（２／２）　個人的な観点でピックアップ

21

審査員からのコメント• しなてす• テストコンテナについて：ちょっと用途の意味が分からない。優先順位を見えやすくするた

めということならあまり意味がない。

• てすにゃん• 探索的テストとスクリプトテストが一般論と違っているところがユニーク

• そもそも、テスト設計になぜスクラム系が入っていてわかりにくい

• FSTWG• テスト観点は繰り返し分析することにより、蓄積される。定量化はおもしろい。

• SASADAN Go• 全体的にわかりやすかった

• レビューしやすくするためにマトリクスを小さくするのは違和感がある

• 北のテストマン• 発表が途中でおわってしまったため、特になし


22

自分の所感

• 一番印象が残ったのは、 FSTWG だった。テストの定量化評価という視点が、ほかにはなかった｡• プレゼン内容として、“どう設計を行ったのか”を忠実に発表していたのは

SASADAN Go だった。プロセスと、方法、その目的がわかりやすくまとめられていた。優勝チーム！

• てすにゃん。テスト方針が手段になっていたのが残念。非機能要件をどう入れ込んだのかが、プレゼンからは見えなかった。

• しなてす。テストの優先順位付けにおいて、開発者が行うテストとの順位を考慮していたのが印象深かった。審査員からのコメントでは、「時代遅れ」となっていたが、プロダクトの担当者をアサインする観点とテスト優先度の観点が混じって設計できるというメリットもあるのではないかと思った。

• 北のテストマン。非機能要件の抽出にマインドマップを使用していたが、観点漏れがありそうなのが残念だった。


23


• たのしかった＾＾ｖ

• プレゼンスキルがかなり求められるコンテスト決勝。プレゼンする内容、特にどこを重点的に発表するか、で聴講者側からの理解にばらつきがある。“設計”コンテストなので、テスト設計プロセス毎の PFD に基づいた発表内容であると、テスト設計初心者が聞いていても理解が深まるのではないだろうかと感じた。（テスコンの目的と合致する）

• プレゼンの時間配分も、設計の一部だと実感した。紹介の深さ、観点、優先度などのつけ方の参考になる。

• もう少し聴講者を増やして、テスコンの目的達成を目指すような試みがほしいところ。

　「ソフトウェアテストが創造的な作業であり、楽しいということを経験してもらい、若年層

　　及び初級テストエンジニアからベテランテストエンジニアまでテストへの興味を高める」



Thanks.NaITE

長崎 IT 技術者会

Education

Jasst16 tokyo 参加報告