O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Jasst16 tokyo 参加報告

1.142 visualizações

Publicada em

2016/3/8-2016/3/9にかけて開催された、JaSST'16 Tokyo の参加レポートです。
NaITEスタッフが、それぞれ1セッションずつ担当して概要説明と感想を紹介しています。

Publicada em: Educação
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Jasst16 tokyo 参加報告

  1. 1. JaSST Tokyo 2016 報告会 ★紹介セッション★ テストプロセス改善 テスト自動化エンジニアやそのキャリアパスってなんだろう? テストコンテスト 3/27/2016©NaITE(長崎IT技術者会) 1
  2. 2. アジェンダ JaSST Tokyo 2016 報告会 1.テストプロセス改善 by 角田 俊 ~プロセス改善でテストエンジニア総活躍社会へ~ 2.パネル by 氏田 孝幸 ~テスト自動化エンジニアやそのキャリアパスってなんだろう?~ 3.テスト設計コンテスト’16 決勝戦 by 岡野 麻子 ~我々のテス都構想に清き一票を!~ • 藤沢君の内容 3/27/2016©NaITE(長崎IT技術者会) 2
  3. 3. テストプロセス改善 ~プロセス改善で テストエンジニア総活躍社会へ~ 角田 俊 3/14/2016©NaITE(長崎IT技術者会) 3
  4. 4. • 2015年9月にTPI NEXT の日本語翻訳版書籍が発売になり、国内においてテ ストプロセス改善技術への関心が高まっています。 • テストプロセス改善技術については過去のJaSST東京やJSTQBカンファレン スにてTMMiやTPIについての発表がなされており、先進的な企業において チャレンジされてきました。現在はTMMiがRelease1を、TPIは次版である TPI NEXTがリリース、加えてISO/IEC 33063 も8月に発行という状況で、 海外を中心に技術発展と普及が進んでいます。しかしながら、これまで国内 ではTQMなどによりテスト改善という言葉を使わずと もテストに関する改 善に取り組んできました。 • 本パネルディスカッションでは、これらテストプロセス改善に関する技術や 取り組みを技術を切り口として「テストにおける改善」について議論します。 最初に簡単にそれぞれの技術比較や動向を紹介し、モデルを活用した(活用 しない場合も含めた)プロセス改善の難しさ、フォーカスすべきこと、進め る上での 注意事項などを関係者や実践者などの識者により議論します。 3/14/2016©NaITE(長崎IT技術者会) 4 テストプロセス改善 ~プロセス改善でテストエンジニア総活躍社会へ。~
  5. 5. テストプロセス改善 ~プロセス改善でテストエンジニア総活躍社会へ。~ • セッションの流れ 3/14/2016©NaITE(長崎IT技術者会) 5 パネリストとテストプロセス改善技術の紹介 テストプロセス改善技術の違い 参加者のテストプロセスの悩みについて
  6. 6. 3つのテストプロセス改善技術 • TPI NEXT • 自己評価とそれに伴う自己改善 • キーエリアが定義されており、今出来ていること、出来ていないことが簡単に分か る • ISO/IEC 33063 • 国際標準規格であり、簡単に文句は付けられない • テストプロセスを説明しているのがISO/IEC 29119−2であり、その適応性を説明 したのがISO/IEC 33063 • TQM(Total Quality Management) • 人の数、会社の数だけTQMがある • 組織が常に改善し続けることで品質を上げていくというプロセス • 会社なりにプロセスを進化させていく 3/14/2016©NaITE(長崎IT技術者会) 6
  7. 7. ディスカッション内容 • 組織に最善なテストプロセスとは、型に嵌めることではないのではない か?現場で不満に感じていることを常に改善していけばプロセスは改善 される。そもそも、TPI NEXTはプロセスなのか?(西 康晴さん) • TPI NEXTも”キーエリア”として定義しており、型に嵌める改善方法で はない。現場によって上手く適用できるようにキーエリアなどを修正す ることを推奨している。ただし、最初から修正するのは難しいので、 キーエリアは改善の方向性をしてしている。(薮田 和夫さん) • ISO/IEC 33063は国際標準規格であり、誰からも文句を付けられないと いうメリットがある。(増田 聡さん) 3/14/2016©NaITE(長崎IT技術者会) 7
  8. 8. 参加者のテストプロセスの悩み • 付箋紙が全員に配られ、現在の抱えている悩みを記入し、それを集計し た。 • 「現場に改善意識、問題意識がない」という悩みが多かった。 3/14/2016©NaITE(長崎IT技術者会) 8 → テストプロセス以前の問題のような気がする 現場の人が課題と感じていないのであれば無理に改善する 必要もないのではないか? 他の悩みはメモを取っていませんでした。。。
  9. 9. 聴講してみての感想 • 会場は満員(立ち見あり)な状態。テストプロセス改善技術への注目の 高さを感じた。 • ISO/IEC/IEEE 29119 はWACATEでも簡単なセッションがあったが、 機会があったら勉強してみたいと思った。 • テストプロセス改善技術もいろいろなものがあるため、違いを理解して あったものを使う必要があると感じた。 • 悩みとして出た現場の他の人に改善意識がないというのは、確かにテス トプロセス改善以前の問題であるが、その部分が一番難しいのではない かと思った。 3/14/2016©NaITE(長崎IT技術者会) 9
  10. 10. 3/14/2016©NaITE(長崎IT技術者会) 10 パネルディスカッション ~テスト自動化エンジニアや そのキャリアパスって なんだろう?~ 氏田 孝幸
  11. 11. • テスト自動化というキーワードにおいては、自動化に必要なスキルや ツールといったところの議論は活発に行われています。 • しかし、どういった人材がテスト自動化エンジニアに向いているのか、 また、いざ自動化エンジニアになったとして、その後の将来像などの議 論は決して多くはありません。 • このセッションでは、自動化エンジニアのキャリアパスについて、自動 化に深く関わっている方をお招きしてパネルディスカッションを行いた いと思います。 3/27/2016©NaITE(長崎IT技術者会) 11 テスト自動化エンジニアや そのキャリアパスってなんだろう?
  12. 12. テスト自動化エンジニアや そのキャリアパスってなんだろう? • セッションの流れ 3/27/2016©NaITE(長崎IT技術者会) 12 パネリストと自動化との関わり方の紹介 自動化エンジニア像について語る 自動化担当者の悩みへの質疑応答
  13. 13. ディスカッション内容 • 自動化エンジニアとは、どんなスキルを持つ人? • どんな事が自動化できるか抽出した上で、設計できる人。 • 作って終わりではなく、廻し続けるためのCI的な知識も必要。 • どういうキャリアパスで自動化エンジニアになれるのか? • スクリプト書くだけならそんなにかからない。半年もあればできる。 • 手動テストとかテスト設計も知らないとなので、1年くらいでそこそこ形になる。 • 自動化エンジニアになった後のキャリアパスとは? • 自動化の尖ったところを突き詰め、その後基本に立ち返ってスーパーコンサルを目 指すとか。 • 全体を統括するジェネラリスト的な立ち位置。テストだけじゃなくて、全体の自動 化ができるようになっていけば。 3/27/2016©NaITE(長崎IT技術者会) 13
  14. 14. 参加からの質問 3/27/2016©NaITE(長崎IT技術者会) 14 • 「マインド」を持っていない人はどうやって育てる? →前を進んでいる人の背中を見せる。大変なことも多いけど、成果が出 たときに得られるものも多い。その辺を感じ取ってもらう。 • 「テストコードが書ける」ってどの程度のスキルが必要? →フレームワークを使って何か作れるとか、そういうレベル。キャプ チャ&リプレイツールは使わず1から作れる。 • 特定の着眼点(セキュリティ等)に特化したエンジニアは居た方が良い か? →スペシャリティがあることは良いことだけど、そこだけにならず全体 を見られるような人になってほしい。
  15. 15. 聴講してみての感想 • 自動化エンジニア=スキル的に尖がっている人。という先入観を持って いたが、プロジェクト全体を見るスキルも重要視される、かなり難しい 立ち位置のロールであると感じた。 • 自動化は品質を上げるための手段であり、すべてを自動化する方向には 考えない。ときには自動化を諦める(切り捨てる)マインドも必要という のは驚きだった。 • プロジェクト全体を見るスキルは、数年スパンで習得していくものなの で、自動化も学びながら色々なところに顔を出して自身のスキルアップ を図っていきたいと思う。 3/27/2016©NaITE(長崎IT技術者会) 15
  16. 16. 3/14/2016©NaITE(長崎IT技術者会) 16 テスト設計コンテスト決勝’16 岡野 麻子
  17. 17. • テスコンの目的 • ソフトウェアテストを分析設計から行うことを周知し、ソフトウェアテストエンジニア に対する教育の機会を提供する • コンテストという形式をとることにより、ソフトウェアテストが創造的な作業であり、 楽しいということを経験してもらい、若年層及び初級テストエンジニアからベテランテ ストエンジニアまでテストへの興味を高める • ソフトウェアテスト業界における技術開発を競技を通じ、促進する • 出場チーム しなてす、てすにゃん、FSTWG、SASADAN Go、北のテストマン • テスト設計対象は、カラオケシステム http://aster.or.jp/business/contest.html • テストベース http://aster.or.jp/business/contest/rulebook.html#testbase 3/14/2016©NaITE(長崎IT技術者会) 17 テスト設計コンテスト決勝 ‘16
  18. 18. テスト設計コンテスト決勝 ’16 • セッションの流れ 3/14/2016©NaITE(長崎IT技術者会) 18 各出場チームによるプレゼン 審査員・聴講者による質疑応答 クロージングで結果発表
  19. 19. プレゼン内容と特色(1/2) 個人的な観点でピックアップ • しなてす • テストの優先順位付けで、開発者が行うテストとの順位を考慮している • テストコンテナの中身が見えない • てすにゃん • テスト方針としてリスクベーステスト等を上げている • テスト手段に回帰テストとユーザストーリーテストがあった • FSTWG • 正しいもんを作っているのか?=システムの価値 • テストの定量的評価を試みている • 魅力属性、夢中属性、無関心属性 3/14/2016©NaITE(長崎IT技術者会) 19
  20. 20. • SASADAN Go • 仕様、観点、条件を整理→USDMを利用 • ステークホルダー分析→マインドマップを利用 • プロダクトリスク分析において重要度・影響度により、テスト優先度を決定 • 北のテストマン • テスト要求分析にマインドマップを使ってブレストを実施する。その中で、非機能 要件を抽出する。 • テストタイプごとに利用頻度とリスク影響度で優先度をつけている →SASADAN Goと同じ 3/14/2016©NaITE(長崎IT技術者会) 20 プレゼン内容と特色(2/2) 個人的な観点でピックアップ
  21. 21. 審査員からのコメント • しなてす • テストコンテナについて:ちょっと用途の意味が分からない。優先順位を見えやすくす るためということならあまり意味がない。 • てすにゃん • 探索的テストとスクリプトテストが一般論と違っているところがユニーク • そもそも、テスト設計になぜスクラム系が入っていてわかりにくい • FSTWG • テスト観点は繰り返し分析することにより、蓄積される。定量化はおもしろい。 • SASADAN Go • 全体的にわかりやすかった • レビューしやすくするためにマトリクスを小さくするのは違和感がある • 北のテストマン • 発表が途中でおわってしまったため、特になし 3/14/2016©NaITE(長崎IT技術者会) 21
  22. 22. 自分の所感 • 一番印象が残ったのは、FSTWGだった。テストの定量化評価という視点が、 ほかにはなかった。 • プレゼン内容として、“どう設計を行ったのか”を忠実に発表していたのは SASADAN Goだった。プロセスと、方法、その目的がわかりやすくまとめ られていた。優勝チーム! • てすにゃん。テスト方針が手段になっていたのが残念。非機能要件をどう入 れ込んだのかが、プレゼンからは見えなかった。 • しなてす。テストの優先順位付けにおいて、開発者が行うテストとの順位を 考慮していたのが印象深かった。審査員からのコメントでは、「時代遅れ」 となっていたが、プロダクトの担当者をアサインする観点とテスト優先度の 観点が混じって設計できるというメリットもあるのではないかと思った。 • 北のテストマン。非機能要件の抽出にマインドマップを使用していたが、観 点漏れがありそうなのが残念だった。 3/14/2016©NaITE(長崎IT技術者会) 22
  23. 23. 聴講してみての感想 • たのしかった^^v • プレゼンスキルがかなり求められるコンテスト決勝。プレゼンする内容、 特にどこを重点的に発表するか、で聴講者側からの理解にばらつきがあ る。“設計”コンテストなので、テスト設計プロセス毎のPFDに基づいた発 表内容であると、テスト設計初心者が聞いていても理解が深まるのでは ないだろうかと感じた。(テスコンの目的と合致する) • プレゼンの時間配分も、設計の一部だと実感した。紹介の深さ、観点、 優先度などのつけ方の参考になる。 • もう少し聴講者を増やして、テスコンの目的達成を目指すような試みが ほしいところ。 「ソフトウェアテストが創造的な作業であり、楽しいということを経験してもらい、若年層 及び初級テストエンジニアからベテランテストエンジニアまでテストへの興味を高める」 3/27/2016©NaITE(長崎IT技術者会) 23
  24. 24. 3/14/2016©NaITE(長崎IT技術者会) 24 Thanks. NaITE 長崎IT技術者会

×