JaSST'17 Tokyoに参加して
2/3(金), 2/4(土)に開催されたJaSST'17 Tokyoに参加しましたので簡単に雑感を(本当に雑感ですw
2/3(金) 9:00〜 テスト分析とテスト設計勉強会
JaSST開催前、同会場で行われた勉強会です。
秋山さんの説明から始まり、リリカルさん、ゆもつよさん、河野さん、まりまりとLTが続きました。
テスト分析とテスト設計の説明が非常に分かりやすく理解できたと思います。
特に「やらなくても良いテストはやる必要はなく、やるかどうか分からないからテスト分析するんだ」はテストに対する強いモチベーションだと感じました。
今はテスト工程をあまり知らないので愚直に実施していますが、いつかはそんな風に言えるようになりたいです。テクノロジーセッション「次世代システムに求められるソフトウェア検証技術 〜 静的解析の価値と有効性 〜」「楽天トラベルの開発プロセスに関して」
「「ビジネス要求と品質保証の不可分な関係」 ~ソフトウェアの品質を超上流で確保する~」が超満員で入れなかったので、もともと最初の予定だったこちらのセッションへ。
初めは、MathWorksの静的解析ツールの紹介。
今勤務している会社は、別の静的解析ツールを買って、結局使いきれなかったという黒歴史があります(笑
このツールは、使いやすそうな感じはあったので試してみたいと思いました。
ただ、プロセスにどう当てはめるかが肝だと思いますが。。。その後の楽天トラベルさんの発表を要約すると、
- 開発案件数、スピードが上がっている = QAが足りない
- テストケースが増える = テスト時間が足りない
- テストが漏れる = 品質低下
の問題を、
- 今までのテスト設計を2つに分け、設計段階から前倒し
- 一度作成したテストケースをオートメーション化
- “Quality Gate”(QA評価するための開発者が行うテスト)の導入
で、開発全体の改善が図れたとのこと。 自分が進めているのはテスト方法の改善ですが、やろうとしていることは同じだったのでためになりました。
テストプロセス改善「普及が始まったテストプロセス改善技術 導入・実践着手のために考えるべきこと」
テストプロセス改善でよくありがちな問題を、SEPG、コンサルタントのロールを持ったパネリストが答えるという形式でした。
テストプロセス改善技術導入以前の、部署が抱える問題に着目してて面白かったです。
でも、正直言えば、もう少し話を聞きたかったなぁ。。。テスト技術「VSTePのファーストステップ~JaSST'16東北出張おかわり会~」
テスト分析技法であるVSTePのワークショップに参加しました。
VSTePの詳細は、西先生の資料を参照してください。
http://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdfソフトウェアテストAdvent Calendar 2016書かれたブログ。
「観点の蒸留」 – QualabLhacaの仕様を一通り読んだ後、以降、仕様書は読まずに、チームでテスト観点出しします。 テスト観点をグルーピングしていくと、次のようなテスト観点図が作成されました。
その後、テスト観点図から、テストコンテナを作成していきます。
VSTePを使ってわかったこと、感じたことは、
VSTePはテストの意図を伝えるもので、この後テスト計画につながる。
仕様書にこだわらない視点で出す。
チームでアイデアを出し続けることが必要チームでの共通認識が持てるまで実施する
テスト観点をキーワードで出すのではなく、チームが理解できる言葉に落とすことが重要コンテナ作成と順序決めのプロセスが難しい
一定のプロセスがなくチームで話し合って決めていくので、テスト対象の全貌が徐々に明らかになるだろうと感じましたが、うまく使うためには、VSTePを理解した上で、一般的な思考プロセスやコーチングが必要になりそうだ、と。今の自分の業務に適用するには、それなりの準備が必要。
今回はファーストステップでしたが、VSTePを自分の中で昇華できるようになりたいなぁ、という気持ちがあります。
雑感
今回3回目の参加でしたが、WACATE参加以降で初めての参加でした。
今回はWACATEつながりの知り合いが多かったので、より繋がりが広がり楽しめたと思います。
JaSST参加当初は、「今の開発のテストの自動化を行いたい」というモチベーションでしたが、その考えが「開発プロセス・テストプロセスを改善したい」というモチベーションに変わっています。また、今までは一人で悩んでいたことも、知り合いのおかげで自分一人の背負う負担が減ってると思います(もっと早くやっていればよかった。。。
そういった事も含め、うちの社員にも積極的に社外で得てほしいため、自分の体験ごと社内に展開したいと思っていますが、
そのために、まずは「社員が開発で抱えている問題を聞いていくこと」が自分の行うことであり、今は、問題を引き出すスキルの必要性を感じています。