JaSST'20 Tokyo RejectCon

勢いでブログ枠に参加登録していたイベントに参加しました。

なぜ「わかった」と返信したのか、今でも覚えていません。 「そういうこともあるか…」と勤務先から前向きに会場へ向かおうとした矢先、お気に入りのジャケットが派手に破けました。心も破けそうになりました。

主催の tsuemura さんとは彼がソフトウェアエンジニアになる前からの間柄です。 昔から変わらないなと思うのは物おじしないことで、イベント慣れしているという印象でした。 特に、「節度を守っての行動をお願い致します」とアナウンスした直後に 「今日は節分なので拍手の代わりに豆をまいても結構です」と述べて、節度とは一体何かわからなくなったのが最高でした。

以下、発表ごとの感想です。 私はモバイルと Web はよくわかりませんし、聞き飛ばしてしまった部分もあるので、変な理解をしているかもしれません。

note でのテスト自動化に関する取り組み

iOS アプリのテスト自動化のお話でした。 Web は毎営業日デプロイしているけど iOS アプリはそうでもなくて、リグレッションチェックを効率化したいとのことでした。 「5種投稿、会員登録、ログインくらいができれば」と言っていた覚えがあります。スモークテストなのかなと理解しました。 ツールにはサポートが早いことから magicpod を選んだとのことです。

QA部門にいる発表者と一人の iOS エンジニアが組み、週15分の定例会議を設け、毎日一回リリース版で実行という形で歩み、変更箇所に集中できるようになったことが良かったことだそうです。 はまりを解消するためにエンジニアを巻き込むのが大事とのことでした。 どのようなはまりなのか聞き逃してしまったのですが、iOS アプリ固有のテクニカルな何かだったのでしょうか。 Pull Request をトリガーに実行すると時間がかかるそうで、Android の方が早いそうです。

発表者の増原さんは #ソフトウェアテスト タグがついた note 記事を書くとQA部屋に流れてくる仕組みを作っているそうです。 サービス愛と職業愛があるなあという印象でした。

リベラル・アーツの世界〜Flow理論に学ぶレベルアップの鍵〜

冒頭で「ソフトウェアテスト一切関係ありません」とのたまってヤベェなと思いました。 お話は面白くて、個人のレベルアップに適した状態を "フロー体験とグッドビジネス (チクセントミハイ著)" を参照して語るものでした。 横軸に能力、縦軸に挑戦を設けたメンタルステート図では、不安、退屈、覚醒、コントロール…そして最も右上のフロー状態という領域があり、 フロー状態へ至る際のルートについて語られました。簡単に言えば、能力を上げるのと、挑戦的なことに手をつけるのと、どちらを先にするかということです。 挑戦ルート、能力ルート、という言葉が使われていました。

発表者は、テストコードを書いているときはコントロール領域にいて、以前は心配の領域にいたのではないかという自覚があるそうです。 メンタルステート図が頭にあると、そういった振り返りができそうです。

フロー体験という言葉は初めて聞きました。 「ゾーンというとわかるのではないか?スポーツの世界はゾーンになりやすいように設計されている」
という説明があり、そういえばゾーンであればどこかで聞いた気もしました。 ただ、私のイメージでは、スポーツにおけるゾーンというのは1秒が10秒に感じるような集中している状態であって、 技術者のレベルアップに適した状態とは時間単位がずいぶん違うのではないかという印象を受けました。

さて、これは RejectCon でしたよね。これはどうすれば Accept されるのだろうか…と考えると、

…という案が出てきました。いやはや。

WebアプリケーションE2Eテスト自動化の3つの壁

WebアプリケーションE2Eテスト自動化3つの壁 - Speaker Deck

Web のことはちょっとしかわかりませんが (チョットじゃないぞ)、 何が理想と異なるのか、賢いツールがあるのか、わかりやすいお話でした。

実行速度の問題解決方法としてテストデータをAPIやコマンドで作るというところがよくわかりませんでした。 お話ではView A→B→C があるとき、B, C の前に Aを操作しなければならないとのことでした。 それはわかるのですが、View A に遷移することや、View A での操作をすることを "テストデータを作る" と言うのでしょうか。 また、それらの操作をするための API またはコマンドは備わっていることが普通なのかがわかりませんでした。 「そんなのないよ」という場合も結構あったり?と想像しました。

おそらくこれを含め、お話の最後で「E2EでなくてもいいテストをE2E環境でやっている」と述べられました。 例えば画面表示だけテストしたいときにサーバーサイドとの通信がいらないみたいな場合があって、 でもそうした部分的に動かす仕組みを作るのが難しいのかも、と想像しました。

また、Accept を狙うなら3つのうち1つの壁に絞って特定プロジェクトの改善事例とするか、 沢山の改善事例が3つの壁に当てはまるという話にするか、かなーと思いました。

プロダクト開発におけるアジャイルQA活動

JaSSTRejectConf - Speaker Deck

査読者からの Reject 理由が述べられていて、RejectCon らしい発表だと思いました。 健康を診るという例えは私が前々から意識しているので親近感がありました。 プロダクトまたは組織が今は動いているけど急病になるリスクを検知して手を打つということですね。 具体的なリスクの種別、見つける方法、対処方法を掘り下げると事例発表らしいのではないかと思いました。

なんかだんだん批評家っぽくなってきたぞ。

テスト?自動化?それよりもQA/QCの業務とは(仮)

JaSST'20 Tokyo RejectCon for Session - Speaker Deck

サービスが世に出て何年か経った組織によくある状態はこうなのかも、と想像させられたお話でした。 対ユーザーの活動よりも開発組織内の活動に焦点を当てていたので QA よりも QC のお話だと思いました。

Webサービス企業において Qが頭につく job が個々の開発チームに入るか俯瞰するかという話って どこかで聞いた覚えがあって、掘り当てると何か理解が進むかも。(LIFULL が俯瞰型でメルカリが入り込み型だったような??)

ウォーターフォール(V字)開発でモブ設計してみた

週一回二時間30分交代とのことなので、ソロが中心で、力を入れる時にモブとしているようです。 見間違いでなければ、人数は開発3人、テスト4人と書いてありました。テストの人が多くありませんか?

本編とは関係ありませんが、そろそろVモデルに全く出会わないキャリアを歩んでいる方も珍しくないだろうなと想像しました。 生まれたときからスマホがあって、ガラケーを見たことがない、という感じで。どうなんでしょうね。

さいごに

発表者の皆様、運営、会場提供をしてくださった皆様、ありがとうございました。

RejectCon っぽくないけど面白かった!というのと、査読者コメントや採択率などの RejectCon っぽい話も聞きたかったというのと、両方ありました。

また、職業柄なのか、事例発表が IMRaD (Introduction – Method – Results – and – Discussion) の構成になっているかを無意識に期待するので、 そうでない構成が多かったセッションを聞いて、「別にそうじゃなくていいのよ」と言い聞かせたりしてました。

あと、ソフトウェアシンポジウムのプログラム実行委員長から論文出せって言われて、うっかり「ネタあります」と答えてしまいました。 さすがにブログ枠ありますに対して「わかった」と応えるのとはわけが違うと思うのですが、はてさて…。