Encraft #9 QA Enablement - Practical Test Design - 行ってきました。

Azukaritai

こんにちは。Azukaritai の村穂です。
今日は https://knowledgework.connpass.com/event/301142/ に行ってきました。初参加のイベントでした。

イベントは、テスト・QA領域で著名な秋山 浩一 氏、井芹 洋輝 氏、朱峰 錦司 氏の3名をパネリストとし、参加者から収集した課題や悩みをベースに議論を展開する形が取られていました。

議論の中で記憶に留めておきたいと思ったコメントを備忘録的に note に書いてみようと思います。

（パネルディスカッション前のぐんちゃさんのお話も非常に興味深かったのですが、途中参加でちゃんと聞けていないのでこの記事では割愛させていだきます。）

テスト分析・テスト設計が（作業的に）重すぎる問題について

  • VSTeP や HAYST法 といった技法は、汎用的な説明に書きかえられているから難しそうだが、やっていること自体はあまり難しくなく、マインドマップの整理とそこまで変わらない

  • 方法論は抽象化されているから理解が難しいが、現場に合わせてパターン化すると簡単かも

  • 各活動の本質を知って、本質的な目標を達成するのが重要

  • 設計段階からデシジョンテーブル作ったり、開発者を巻き込んだプロセスのパターン化はスピードアップに効く

  • 開発者に 3H（変化したところ・初めてのところ・久しぶりに書いたところ） を教えてもらうとテストする際に便利だった。初めてのところはバグが出やすい。

  • 開発者が作るテストは再利用しやすいものがある

  • サーバーの設計が上手くできていれば API テストでカバーできる

  • アーキテクチャがしっかりしていればテストしやすい

  • テスト設計コンテストがテスト分析・テスト設計に重そうな印象を与えているかも…？

リリースのスピードをテストで落とさないためには？

  • 開発だけアジリティを高めればよい場合はテスト工程は開発サイクルから外してもいいかもしれない

  • 開発だけではなく、デプロイのアジリティも高める必要があるのであれば自動テストが必要

テストどこまでちゃんと出来ているのか不安な問題について

  • 網羅的なテストを考えるより、重要なバグを見つけるにはどうすればいいか？そこを考えるところから始める。最低限のテストはどんなものだろうと考える

  • テストは自分たちの100点を決める行為でもある。合意形成が重要。どこまでしたらちゃんと出来たことになるのかは悩んでください。

  • テストの充分さは単一の指標では測れない。テスト観点ごとにカバレッジの考え方がある

  • 自分たちの能力を確認するプロセスを入れて、能力を上げる取り組みをしたほうがいい

  • 振り返りをしたほうがいい。改善を重ねるのがいい

ナレッジ化どうやるのか問題

  • QA のナレッジはテストタイプによって変わる。タイプごとに整理するのがいい。テストタイプごとに蓄積していくのがいい。

  • ナレッジの共有は難しい。文章化は無理だと思っている。みんな仲良しになって、段階的にドキュメントをつくってレビューして、そこで盛り上がって知識が共有されると思う。文章作って終わりの世界ではないと思う。

  • テスト技法しか教育できるものはないと思う。それ以上のことは伝えられない…。

  • JSTQB の FL を取りましょう

  • みんなでやりながら身につけるのしかないのかも

  • 教科書的に伝えるのではなく、お手本を見せてからやってもらうのがいい

ドキュメントどれくらい残すか？

組織的な標準化が上手くいかない問題について

  • 標準化を神格化しすぎかも？

  • 結果的によかったことをみんなに共有すればいい。やり方を知っている聞いたらやり方を教えてもらえる状況が作られていればいい

  • プロセスの設計をしてから手順を考えるのがいい

  • 明示的に作った成果物を繋げて考えてもいいかも

  • 標準化によって、成果物に対してレビュワーがレビューしやすくなるのは大事そう

  • 自動化するのがいい。フォーマットが乱れていないか自動で検出できるようにする

  • 難しいところから着手しているから協力しずらいのかも

  • 手順じゃなくてゴールを明確にするのがいいのでは？

  • コミュニケーションの問題かも。困っていることを腹を割って話すのがいいかも。

  • テストケースの粒度はばらついたほうがいいが、書き方のフォーマットは揃えたほうがい

スキルアップどうやるの問題について

  • テストよりテスト対象の仕組みを勉強するのがいい。どうやったらカバーできるかわかる

  • テスト技法は一人で学べるから学ぼう

  • 自分たちのやり方をリバースする（内省する）

  • テスト関係者副業している人増えてるからレビューお願いしてもいいかも

  • 日本語きちんとかけるのはテスト設計に必須のスキル

技法を勉強しても手が止まる問題について

  • 技法を勉強して解決できることは難易度低い（※記憶違いかも）品質やドメインの知識を得る必要がある。テストの勉強と並行して、プロダクトの理解をしましょう。

  • テストのモデリングの練習は効果ある。頭の中で複雑に考えるよりもいい。

スキルアップの方法

  • テスト対象を好きになって「なんでなんだろう」「なんで動くんだろう」という疑問を持って開発者をサポートするのがいい

  • テスト対象の品質を理解する

  • アーキテクチャとか設計を見てそこを突くテストができるとアジリティが出せる

  • 品質リスクを感じ取れる設計の知識や、ドメインの知識を持つのがいい

  • ドックフーディングやってみるのがいい

登壇者からの最後の一言（一部の方のコメントは聞き逃してしまいました…）

  • テスト分析とか考えない方がいいと思う。「これすごいな」「どうなっているんだろう」「どうやったらテストできるかな」から始まって、テストを好きになって技法を学ぶのがいい

  • 自分が普段やっていることを意識するのが初学者にはオススメ

イベントの感想

QA やテストに取り組んでいるとぶつかる疑問やテンションに対してベテランの方からそれぞれリアクションが聞けたのは非常に貴重でした。実践的な内容が多く、日々の業務で活かしていきたいと思います。

コミュニティ活動への参加が増えたこともあり、顔見知りの方が増え、久しぶりにお会いした方と情報交換をしたり、新しい方とのつながりができたのもよかったです。

周りの方の QA やテストに関する面白い話を聞くだけでなく、自分も話せるように日々の業務でトライ＆エラーを繰り返して経験を積まねばと思いました。



この記事が気に入ったらサポートをしてみませんか？