見出し画像

ソフトウェアテスト初心者の開発者CがWACATE 2023冬に参加してみた

Cちゃん

はじめに

こんにちは！
QAエンジニアになりたい、WebフロントエンジニアのCちゃんです。
この記事はWACATE 2023冬の参加者側から見た振り返りです。
ソフトウェアテストやWACATEに興味がある人や、WACATEに参加したことがあって他の人がどんな感想を持っているのか知りたい人に読んでもらえると嬉しいです。
一部セッションの内容が非公開のものもあるので、書ける範囲で書いています。

WACATEとは

WACATEとは、若手のソフトウェアテスト従事者向けのイベントです。
1年で夏と冬に2回開催しています。夏は1分野に特化した内容で、冬は複数の幅の広い内容を扱う構成だそうです。
私は今回が初参加だったので、夏のWACATEにも参加したいと思っています。
WACATE 2023冬は、2日間にわたる合宿型のイベントでした。詳しくは、以下の公式ページを見てみてください！

イベントへの期待と実際の内容

私がWACATEについて知ったのは、LT登壇したJaSST nanoという別のイベントでした。そこで、運営の方がWACATEについてLTをしており、興味を持ちました。公式サイトなど見ていく中で、絶対に参加したい！と思ったので今回参加させていただきました。

参加する前の心持ちとしては、ソフトウェアテストについてとにかく学んで自分視点でテストが楽しいかどうか判断できる2日間になればいいと思って、深く考えずに参加しました。
また、ワークショップ形式かつ2日間の合宿形式ということもあり、少し高額な参加費用だからこそみんなが受け身の参加になりづらそうなところもいいなと思って参加しました。

実際に参加してみて、思ったよりも若手が多かったです。若手と言いつつも私よりも経験の多い方が9割くらいいるんじゃないかと思って参加したのですが、JSTQB FLの資格をもっていない人も半分くらいはいそうな感じでした。参加者の中で私はソフトウェアテストの経験的には、経験が少ない方から3、4割に入るくらいかなという体感を得ました。

セッションの内容

イベントの各セッションについて書きます。内容が非公開のものについてはあまり触れていません。
プログラムは、以下の公式ページの内容でした。

ポジションペーパーとは

参加申し込み時に自分の自己紹介がわりになるA4のポジションペーパーを提出する必要がありました。参加してみて分かったのですが、これは参加者を知るのにとても便利でした。
毎年全員のポジションペーパーからベストポジションペーパー賞が選ばれます。今年はLEADING QUALITY翻訳者のMarkさんでした！おめでとうございます！！

a chance of acceleration〜BPP行脚がくれたもの〜

資料はこちら！

前回WACATE夏のBPP(ベストポジションペーパー)賞に選ばれたぐんちゃさんのセッションでした。
歴代のBPP受賞者に話を聞いていく中で、工夫されたことや学んだことがたくさん散りばめられている発表でした。WACATEの歴代のBPP受賞者がXやPodCastなどで見かける方が多く、ソフトウェア界隈で有名な方は1度はWACATEを通るのか！という個人的な発見もありました。
発表外の時間に自身のペースでBPP行脚を進められたという話を聞いて、自分のペースを守り抜くことって人生においてとても大事なことだなと改めて思いました。
自分の中での優先度やその物事を実行する上での目的を忘れないで進めていくことの大切さなどを教わりました。

単体テストソムリエになろう

「これ、単体テストで出ていいバグじゃん！？」
私は最初、なぜ開発者側がやるべき単体テストをソフトウェアテストのイベントで話し合う必要があるのかわかりませんでした。
実際にワークを行ったり参加者のお話を聞く中で、テスト担当者側が単体テストについて足りていないと感じていたり困っているという他社事例が多くあるから、このセッションがあることを理解しました。
開発者側が品質に対しての責任を持たないと、単体テストの実施を開発者自ら行おうという意識になりづらいのかなと感じました。この辺りは、全体的なプロセス改善を行うQAが先導して行っていく必要があるという理解もしました。

テスト活動にまつわるお悩みを解消するカギはどこに？〜テストのモニタリングとコントロールに貢献できるテストエンジニアになろう

モニタリングがプロセスで、コントロールが各プロセスでの行動。
テスト活動に対して、主体的に動くにはどうしたらいいか考えさせられる話でした。これは開発視点でも言えることだなと思いました。また、QAの大きな領域においては開発もテストも、プロセス改善という点において、基本は同じなんだと思いました。

WACATE実行委員座談会　〜Specialist シラバス編〜

JSTQBのFLレベルのSpecialistの日本語シラバスが追加されたので、その紹介がありました。
実際に、実行委員の方々でのディスカッションを通して、私自身もたくさん発見がありました。以下のシラバスは読みます。

  • AIテスティング

  • モバイルアプリケーションテスト担当者

  • 性能テスト担当者

分科会 皆で語ってみませんか？

Markさんの分科会に参加しました。ソフトウェアテストの枠に囚われす品質について話し合ういい機会になりました。
同じ分科会に参加された方の感想はこちら！

バグから学び、次につなげよう

資料はこちら！

バグの分析手法が複数紹介されていました。
ODCのプロセス改善を目的とする分析手法は、大きめのプロジェクトが複数動く現場で使ってみたいと思いました。
欠陥モデリングについて、バグから得られた知見を抽象化して横展開することでバグの再発防止に務めるのは、どの現場でも効果的だと思いました。

バグ分析のやり方として、2つの視点が紹介されていました。

  1. ポストモーテムや障害報告書として、1つのバグに対して根本原因を調べて対策を練ること

  2. バグの統計情報を使って、プロセス改善や組織の改善を行うこと

特に2つ目をやる時は迷子になりやすそうなので、必ず目的を定義することが大事。困っていることを解消するために何をしたいのか課題と目的を言語化し、目的に沿った分析手法を使うのがよさそうだと思いました。

JSTQB FL 幻のテスト技法「ユースケーステスト」を学ぶ

資料はこちら！

UMLのユースケース図からテストケースを作成しようというセッションでした。ユースケース図は仕事で使う機会がなく、書いたのは大学の講義ぶりでした。シーケンス図やモデル図など他のUMLはどういう時に書いて、ユースケース図はどういう時に書くんだっけ？とUMLについて思い出すきっかけになりました。開発の設計の際にも自分から書くことは現状基本はないので、必要な時に選択肢として取れるよう、UMLについても振り返っておきたいと思いました。
個人的に最近はフロントエンドとバックエンドの両方を担当する機会もあったので、視覚化するためにも何かしら図は用意した方がいいなと感じています。現状、図を書くことは少ないのは反省です。

実際にユースケーステストのケースに落とすまでに、ユースケース記述を書くプロセスを踏みます。このユースケース記述の中に出てくる、代替フローや例外フローをどれだけ出せるかが重要という話がありました。
たしかに、実際の開発を思い返してみると、考慮漏れとして実装中に出てきてしまうものは、こういった、代替フローや例外フローで事前に考えておけるものが多いと感じました。
実際に開発のタスク一覧を作成する際にこれらのフローについて考える時間を取ると、考慮漏れが減ると強く思いました。社内チームの資料に代替フローや例外フローについて考えるチェック項目を追加してみます。

テストの目的って何？私がテスト設計でやってしまった3つの失敗

テストの目的について、私自身うまく説明できていない部分だったので考えるとてもいいきっかけになりました。班の中で一番活発に議論できたセッションでもありました。

QMファンネルを使って自分の立ち位置/やりたいことを可視化しよう

このセッションは今の自分の状態や今後どうしていくか考えるいいきっかけになりました。QAとしての領域について知識を得ました。また、QMファンネルについて知らなかったので勉強になりました。自分のこれからに役立てていきます！

WACATEから？？？へ　～WACATEで育ったあるテスターの軌跡と創りたい技術の未来～

このセッションに一番感銘を受けました。詳細は書きませんが、自分もWACATEに参加できたこと、そのきっかけを自分で作れたこと誇りに思います。


参加者との交流

参加者や運営の方全員、直接会うのが初めまして方でした。一部、JaSST nanoのオンラインイベントでLTをしたときにお世話になった方や、Xなどでよく見かける方やなどと交流することができました。
同じ班の合計6人のメンバーとは、ワークショップで2日間一緒に議論や意見交換をし合いました。

また、今回以下のような様々な立場の方が参加されていました。ソフトウェアテストと言っても、本当にいろんな立場から考えてイベントに参加する方がいるんだなと思いました。またその方々の意見や実際の現場の話を聞くことができたのがよかったです。

  • 第三者検証会社

  • 開発者の1人

  • テストエンジニア

  • QAエンジニア

今後の行動計画

今回WACATEに参加してみて、大きめのプロジェクトのテスト計画や設計をやってみたいと思いました。
QMファンネルでいう、テストエンジニアの仕事について、私は開発者の立場から少し担当させていただくことはあります。ただ当たり前なのですが、守備範囲が広がり、大きめのチームや開発組織対象にテストを行う人になったり、QAエンジニアになったりすると、自分が与える影響範囲も広くなり改善できることも増えるというのがよくわかりました。
私の現場では小さめのプロジェクトの開発が多いのですが、プロジェクトの規模が大きくなると考えることも増えるので、まずはそういった大きめのプロジェクトに参加してたくさん経験を積んでいきたいと思いました。

おわりに

今回は参加者が41名だったそうです。同じ班の方やごはんや分科会のときに一緒になった方とお話ししたり、お話しできなかった方も同じセッションを共有できてよかったです。充実した学びを得ることができました。

JSTQB FL取りました！くらいのソフトウェアテストの知識レベルの人にとっては、ちょうどいい内容だったと思います。わからない言葉がたびたび出てきたり、理解が足りていない部分も説明されている印象でした。
本当に初学者で実務経験半年程度の方にも冬のWACATEをおすすめします。様々な情報が2日間に凝縮されており、知識を得るいいきっかけになると思いました。全てを理解するのは難しいところもあるかと思いますが、同じ班の方や運営の方がサポートしてくれるので、主体性を持てるなら安心して参加できると思います。

実行委員の方も参加者の方もありがとうございました！夏のWACATEも実行委員会にも参加したいので次の企画を楽しみにしています！


この記事が参加している募集

#買ってよかったもの

59,268件

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