こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- アシカさんからのプレゼンテーション
- フリーディスカッション
- テスト設計コンテスト以降に実務で使えた要素はあるか?
- テスト設計コンテストの文脈で良いので、作成されたテスト成果物に対してどんなテストの課題や制約に対応したのかを知りたい
- RDRAは普段の業務におけるテスト設計では使わないという話だったが、これは一人でテストすることが多いからか?
- テストアーキテクチャーを見ると実施に時間のかかるロングランやセキュリティを前に持ってきているが、実は実装上バグが出た時に改修影響が大きい(工数がかかる)ものを前に持ってきているのか?
- 機能テストとは?アーキテクチャとは関係がない?
- テスト設計コンテストはおすすめか?
- テスト設計コンテストに出たモチベーション
- 継続参加したほうが良さそうに感じたがどう思うか?
- 要求分析の手法としてRDRAをどう評価しているか?
- 良いテスト成果物とはどんなものだと思うか?
- テストアーキテクチャとテスト計画の違いは?
- アシカさんにとってテストの面白さは?
- アシカさんはスキルアップはどのようにしているか?
- 何もわからないまま最近テスト担当者になったが、テスト設計についての情報を集めている中で、多角的な視点が必要だと素人視点で感じた。その背景で、こういう視点の勉強方法がおすすめなどあれば知りたい
- システム理解でRDRAモデルを活用しているということで、ユースケースや情報に落とし込むときにどのくらいの粒度で書けば良いか迷ったりしなかったか?
- 生成AI×テスト
- テスト設計コンテストに出てアシカさんが変わったこと
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
バキバキQAチャンネル初の公式コラボ企画! 特別ゲストとして、2023年テスト設計コンテスト優勝者のアシカさん(@tyngw)をお招きして、勝利の裏話や成功の秘訣を深掘りしていきます!
テスト設計コンテストについての詳細はこちら
アシカさんの優勝成果物はこちら
本イベントはASTERやテスト設計コンテストとは関係がありません。それらの団体とは無関係で非公式のものです。
アシカさんがどのようにしてソロでテスト設計コンテスト優勝に至ったのか、その戦略とテクニックを大公開! コンテストで使用した技術やアプローチの背景、実務との違いについても掘り下げて学べます。 質疑応答セッションやディスカッションで、あなたの疑問や意見を直接アシカさんにぶつけるチャンス!
会の様子
アシカさんからのプレゼンテーション
今回はテスト設計コンテストに参加している人たちが少なかったということもあって、最初にアシカさんにプレゼンテーションをしてもらいました。
詳細は前述した資料にも記載されているので、資料から読み取ることが難しそうだった部分を箇条書きかつ常体で記載していきます。
- アシカさんは特にテスト要求分析に注力した。テスト要求分析技法として要件定義のフレームワークであるRDRAを活用しているのが工夫をしている一つのポイント。システム化の目的はテストとの親和性が高いと感じたことと、各システムがどういう振る舞いをするのかの深い理解をすることが主な採用理由である
- モデルとして見ることで気付けなかった観点が見えてくることもあったので、UMLを活用したのはよかった
- 生成AIは網羅的に全てを洗い出すという意味ではまだ改善の余地があるが、思考の発散という点で効果があった
フリーディスカッション
講演の後はフリーディスカッションがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
テスト設計コンテスト以降に実務で使えた要素はあるか?
テストコンテナは実務でも使っているということでした。
テスト設計コンテストの文脈で良いので、作成されたテスト成果物に対してどんなテストの課題や制約に対応したのかを知りたい
園内チケットシステムとWebチケットシステムが別々で開発されているという話があり、単体はできているけれど結合での動作確認はないという話があったので、システム連携疎通テストを一番最初にやるようにテストアーキテクチャを設計した。
また、テストを外注するという前提でセキュリティテストを最初にやった。
RDRAは普段の業務におけるテスト設計では使わないという話だったが、これは一人でテストすることが多いからか?
その通り。
テストアーキテクチャーを見ると実施に時間のかかるロングランやセキュリティを前に持ってきているが、実は実装上バグが出た時に改修影響が大きい(工数がかかる)ものを前に持ってきているのか?
今回のシステムは入場規制がMustで他の要件は落としてもいいのではないか?と思っていたのが入場規制のテストを前に持ってきている理由。
機能テストとは?アーキテクチャとは関係がない?
確かに見方によってはアーキテクチャとは関係がないかもしれない。
0時ぴったりに使用する際の境界値テストとかは考えていたのでそういうのはアーキテクチャと関係があるかもしれない。
ただ、それを機能テストというのかみたいなのはまだ議論の余地がある。
テスト設計コンテストはおすすめか?
n=1だが出たほうがいいと思っている。
10年以上なんとなくでテスト設計をしていて自分の実力に疑問があったのだが、フィードバックコメントをもらえることでテスト設計の上達に繋がったし、優勝したことで自信に繋がった。
特にフィードバックコメントはピンポイントでもらえるのが非常に良かった。
テスト設計コンテストに出たモチベーション
以下のブログに書かれていることに加え、西さんが話していたイノベーションが生まれ続ける場がテスト設計コンテストという想いに答えたいというのもあった。
継続参加したほうが良さそうに感じたがどう思うか?
気力があればそうだと思う。
休日や深夜をはじめプライベートの時間をかなり使ったというのと、優勝したことでモチベーションの維持が難しくなったというのはある。
要求分析の手法としてRDRAをどう評価しているか?
テスト要求の分析という意味だと、正直よくわかっていない状況で出場した。
そのため、色々調べていく中で見つけたものである。また、神崎さんの講演を会社で受けたという背景もある。
ちなみに、以下の資料などで勉強したので、興味がある人は参考にしてほしい。
良いテスト成果物とはどんなものだと思うか?
そもそものテストの目的とかに関してはJSTQBなどを見てもらえば良いと思いつつ、リスクを低減するという目的やソフトウェア品質が充分か?という部分に関しては、レビューの中で確認しながらステークホルダーに充分な説明が必要だと思っている。
そのため、テストの目的が満たされているか?を関係者が見てわかりやすいのか?というのはあると思う。
テストの目的を導出する際には、まずステークホルダーを理解するようにしている。
テストアーキテクチャとテスト計画の違いは?
テスト計画でも、どういうテストをするのか?やテストの目的などは考えるので、敢えてテストアーキテクチャを考えるのはどういう理由からか?という話に関して議論がありました。
テスト設計コンテストという意味だと、プライベートな時間を削っているということもあって曖昧になりがちだが、実務だと一定は区別があると思う。
テスト計画だと、ハードウェアや実機準備をはじめとした制約などに関して見えている情報を元に推測も含めて構成するのに対して、テストアーキテクチャだと実際に実現可能なテストになるように落とし込む必要があると考えている。
アシカさんにとってテストの面白さは?
自分の作ったテスト設計成果物でバグがでたり、テスト設計の過程で仕様の漏れや考慮されていない要件を見つけることができたときは面白いと思う
アシカさんはスキルアップはどのようにしているか?
机上で勉強できるものはまず読みやすいところからやっていけばと思っている。
自分自身に翻ると、自分よりもテストを勉強している人はいると思っていて、日々そういった人たちから学んでいる。
前述したようなネット記事や動画は見ている。
何もわからないまま最近テスト担当者になったが、テスト設計についての情報を集めている中で、多角的な視点が必要だと素人視点で感じた。その背景で、こういう視点の勉強方法がおすすめなどあれば知りたい
勉強方法かはわからないが、所属している会社でのテストが重要な部分、例えばバグが出やすい部分から情報を得るのは重要だと思う。
バグをもとに、なんでこんなバグ出たんだろう?と考えていくことは大切だと考えている。
なお、やましたさん的にはテスト設計技法を技法が必要な目的とセットで学べると良いと思っている。
システム理解でRDRAモデルを活用しているということで、ユースケースや情報に落とし込むときにどのくらいの粒度で書けば良いか迷ったりしなかったか?
RDRAに関してこれで完璧かというとそんなことはないが、RDRAはHOWに関して表現をしないのでそんなに細かいデータまでは表現しなくてもいいのかな?と考えはした。
(以下、その後神崎さんからあったコメント)
- 粒度はアシカさんの成果物でイメージ合っているが、ログイン/ログアウトとかはちょっと細かいかな?と思った。このシステムでやりたいことが分かるのが重要なので、「ログインをしたい」というのがすごく重要なセキュリティ関連のシステムとかでなければやらなくていいような気はした。
- 時間枠残数とかであれば、ビジネス的にはどういう風に管理したいのか?というところにフォーカスしたほうが良さそうだとは思った。
- RDRAは要件→仕様というレベルで捉えているので、テスト対象という意味では要件ではなく仕様がテスト対象になりそう。
- テストとの親和性という意味だと、状態モデルはテストとの親和性が高い。
生成AI×テスト
NotebookLMは良いと思っている。
ちなみにやましたさんは異常値系で活用したり、バグチケットのタイトル決めで活用している。
テスト設計コンテストに出てアシカさんが変わったこと
優勝という結果をもらえたことで、完璧にできるとは思っていないけれどテスト設計が一定できたんだろうなという自信には繋がった。
会全体を通した感想
テスト設計コンテスト優勝者から直接色々な話が聞けたのがすごくよかったです。
また、アシカさんはテスト設計コンテストで優勝したことが自信になったという話はされていましたが非常に謙虚でしたし、まだまだ色々なことを学びたいという姿勢が随所であった点も個人的には感銘を受けました。