JaSST'26 Tokyo 参加ブログ #jassttokyo
2026/3/20(金)に開催されたJaSST'26 Tokyoに現地参加してきたのでその感想ブログ。 特に印象に残っていることを書きました(うろ覚えな部分もあるけど、間違っているところもあるかも)。
基調講演 When AI Joins the Test Team: Promise, Pitfalls, and the Future of Software Quality
AIがテストチームに加わるとき- 期待、落とし穴、そしてソフトウェア品質の未来 –
Gayathri Mohan さんによる基調講演。 最近常に話題になっている生成AIについて、ソフトウェア開発(ソフトウェアテスト)にどのような影響を与えるのかについてのセッション。
構成がとても好きでした。 いきなり生成AIの話から入るのではなく、ソフトウェアテストの話をしっかりした上で進めてくださったので話に入っていきやすかった。
- 構成
- そもそもソフトウェアテストとは？
- 生成AIを使ったテストの分類
- 現状の利用できる生成AIのツール
- 生成AIツールを実際に使ったデモ
- 生成AIを使う上での落とし穴
- 参考情報
講演で紹介された内容では、生成AIを使ったテストは3つ「AI Assisted(AIがツールとして手伝ってくれる)」「AI Powered(AIでテストを実現する)」「AI Driven(計画して判断して、実装して仕事を完了できる)」にわけられる。 現在、テストに利用できる生成AIのツールは4つで「AI Chatbots(テストの相談)」「AI Coding Assistants(テストの先導/実行)」「AI Powered Platform(AIを組み込んだテストシステムの提供)」「AI Extensions(今あるシステムにAIを組み込んだ拡張)」がある。 といったあたりの分類は、わかりやすかったので、自分がこのあと生成AIを活用するうえで参考にしようと思った。
あと、生成AIの部分ではなく「そもそもソフトウェアテストとは？」で話されていたソフトウェアテストの5つの分類がなんだか良いなぁって思った。
- SoftwareTesting: Techniques
- Functionally(機能)
- Usability(ユーザービリティ)
- Reliability(信頼性)
- Performance(パフォーマンス)
- Supportability(サポート性)
いろんな定義や考え方でこれ以外もあるのは知っているけど、これは5つと割とコンパクトで覚えやすいので他の職種の人にも説明しやすいなぁと。 今後使っていきそうな気がする。
生成AIを使ったテストについては「生成AIの成果物については、人が最終的に責任を持ちましょう」といった感じのまとめで、自分の最近の考えと近かったこともあり、最後の納得感も高かった。 自社でも「生成AIをテストにどう使うか？」とか「実際に生成AIを使って作っているシステムのテストをやったりしてる最中」だったりもしたので、講演を聴いたタイミングがよかったと思う。 ありがたい講演だった。
新規事業×QAの挑戦：不確実性を乗りこなす！フェーズごとに求められるQAの役割変革
hacomonoの塩濱 優(hama)さん、廣田 大騎(Piro-chan)さん、西 映音(akine)さんによる、今月リリースされたFitFits開発中の出来事と対応をパネル形式で紹介したセッション。
福岡でやっている「ソフトウェアテスト技法練習帳をやる会」に参加してくれたり、2月にやった「QAとテストに関する発表会@福岡天神 #テストラジオ」で発表してくれた akineさんがJaSST初登壇ということと、新規事業立ち上げ時の話に興味があったので聴きに行った。 スライドにある通り、プロジェクトの立ち上がりからサービスがリリースされるまでの年表に沿って、それぞれのタイミングで起きたエピソードを紹介されていて、かなり具体的な話もしてくださっていた感じ。
全員が基本フルリモートで働いているというのがhacomonoさんの特徴らしく、コミュニケーションの壁についてのエピソードが印象的だった。 エンジニアは(実装タスクをやるので)個々で動くことが多く全体への情報共有に課題があったそうで。プロジェクト内を横断的に動くのはPdMやQAなのでこの課題にいち早く気づけてアプローチできたという話は良いなぁと思った。
プロジェクトへ途中から参画したakineさんも、プロジェクトを成功させるためにどうしたらよいか？を考えて動いていた感じで、これも良いなぁと思った。 社員向けにβ版をリリースしたタイミングや、一部のユーザー向けにβ+版をリリースしたタイミングでは問い合わせがたくさんあったそうで、その中でやりたいこともあったけどそれよりもやらないことを決めて進んでいっていたとのことで、その辺りの判断の話は素晴らしいなぁと思った。
たぶんまだいろんなことがあったんだろうなぁと思うのでもっと話を聴きたかった。 参加された方は(たぶん)後日アーカイブが見れる(と思う)のでおすすめ。最後のPiro-chanさんの魂の乗った発言、良かった（笑）
今日から始められるテスト自動化 〜基礎知識から生成AI活用まで〜
MagicPodの伊藤 由貴さんによるテスト自動化の始め方や始める時に考えたほうが良いことなどを紹介したセッション。
昨年夏ごろから自社でもMagicPodを導入して自動テストに取り組みだしたこともあり聴きに行った。
感想としては最高。
「テスト自動化」というワードの一般的な使われ方や、本題であるシステムテストレベルの自動テストを導入する時に考えた方が良いことなどをとても丁寧に紹介されていた(なので講演内容については、後日公開されるであろう資料を見たほうが明らかによいし、自分ももう一回みたい)。
伊藤さんは物事の整理と説明がとても上手だなぁと思っていて、これまでもいろんな資料にお世話になっているのだけど、今回の資料は中でもだいぶ好きな感じだった。
自分が自動テスト(MagicPod)を導入するときや、今運用する中でなんとなく気をつけていたことも書かれていたりして「あー、こういうことなんだよなぁ」と頭の中がすっきりした。
講演の中で「まずは1つのテストを作ってそれを毎日実行して運用してみる」といった旨の話があったけど、これは本当にそうだなぁと思う。 自分もMagicPodを契約したとき、「自動テストはFlakyな面があるので、毎日実行することで作ったテストケースのテストができる」という話をカスタマーサクセスの方から教えていただき、「なるほど！」となったので 試しにやってみたんだけど、これはやってみて良かったなぁと思った。 教えてもらった通りテスト結果がFailになることがあったので、その調査や修正や確認をするというタスクが突然発生するので、「自動テストの運用がある日常」を小さく経験できる。 この経験があれば「自動テストを作る時に運用も想定してテストを考える」ということが自然にできるようになるので、無理のない範囲で自動テストを組み込んでいけるようになるなぁと。
こういった実際に自分が体験したことを講演を聴くことで改めて整理できたので、とても良かった。
みんなでつくったJaSSTnanoなの
JaSSTnanoのお世話係、いこ(ICO)さん、安達 賢二(きたのしろくま)さん、朱峰 錦司(a.k.a. きんぢ)さん、川﨑 久美(かわくみ)さん、そうすけさん、簪さん、やまずんさんによるJaSSTnano 1st Seasonの運営時の出来事について話すパネルセッション。
どういった経緯でJaSSTnanoが企画されたのか、運営中にどういった事が起きていたかや、どういうことを思っていたかを話されていた。
中でも1番印象的だったのが、お世話係のミーティングは40回ぐらいまでなかったということ(回数うろ覚え。かなり後半の方までなかったという話だった)。
Discordに質問を募集する形式だったので「(お世話係のオンラインミーティングは定期的に行われているだろうという前提で)、リアルで会ってミーティングすることはあったんですか？」と質問したら、パネリストの方々の反応と噛み合わず（笑）
「そもそもミーティングしてなかったんだよね」と回答をもらい、基本的にチャットベースで物事を決めていったとのことでびっくりだった。今年1番驚いた話かも。
会を運営する上では判断がつきまとうので、何を大事に決めてきたかというのを聴くことができてよかった。 JaSSTnano、2nd Seasonもあるようなので楽しみだなぁ。 1st Seasonは登壇することはなかったので、2nd Seasonで話したいことができたタイミングで発表させていただけたらなぁと思っている。
招待講演 人と関わるロボットの研究開発 –ロボットにおける人間らしさの重要性 –
石黒浩先生によるセッション。
講演内容なのか、写真やスクリーンショットだけなのか、どちらかがSNSブログNGという案内があった(うろ覚え)。 なのでブログには書かないことにする。ただ講演の感想としては人間らしさとはなんなんだろう？と思った。 そしてこの本を読んでみようとなった。
それから、展示ブースに石黒先生が代表取締役社長を務めるAVITA株式会社のAVACOMの展示があったので、お話を聴いたり体験させていただいたのだけど、とてもすごかった。
いわゆるV-Tuberってこんな感じで操作してるんだろうなぁ〜っていう体験ができたのも面白かったんだけど、このシステムのテストについて考えたときに、操作画面を見ながらアバターの画面を見ることはできないから最低でも2人いるし、同じ場所でテストするのが難しかったり、その都合で発話された音声が正しいかの確認も大変だし、多言語対応なんかもあったりなんだりで色々あるし、自動テスト難しいよねなどなどをブースの方と話したり想像したりもできて、とてもよかった。
あと、ブース入口のところに設置されていたAVACOMを使ってリモート操作している方とお話もしたけど、想像以上に自然に対話できたのが驚きだった。 もっとラグがあったり違和感を感じたりするものだと思っていたので。 ただただすごいとなった(写真は掲載OKをもらったので掲載。
おわり
ブログ、久々にいっぱい書いたｗ
JaSST'26 Tokyo、ビッグサイトで会議室を利用できるというなにげに貴重な体験をさせてもらったなぁ。
メインホール(国際会議場)を始め、どの会議室でも椅子がとてもよくて、座っていて疲れなかったのがとてもありがたかった。
並列セッションが増えたり会場がとても大きかったり実行委員の方々に感謝だなぁ。ありがとうございました。
情報交換会や通路とかで久々に会えたり話せたりもしてとてもよかったなぁ。 やっぱり現地で会って、ちょっとの時間でも話せるっていうのは良いなぁ。話してくださった方々、遠目にちょっと見て「おぉ！」となってくださった方々、ありがとうございました。 ただ、今年本当に会場が広かったんだろうね。一目合うことも叶わなかった方が結構いて、それもびっくりだった。 またどこかでお会いできたら良いなぁ。
JaSST'26 Tokyo、参加できてとてもよかった。
それと色々といただいた！
お菓子については今週ゆっくりと食べる予定。ありがとうございます！
参加した感想について、 #テストラジオ でもなそさんと話したのでこちらもお時間あればぜひ！ (なそさんのターンは、本会当日に行われた「選択が運命を分ける！リスク体験ゲームブック」チュートリアルの話をしてくれたんだけど、この話聴いていてとても面白かった。
位置情報権限の設定をiOSとAndroidで確認する方法 #テストアドカレ
この記事は、ソフトウェアテストアドベントカレンダー2025の1日目の記事です。
はじめに
スマートフォンのブラウザから位置情報を使ってあれこれするシステムのテストをやる機会が今年はちょこちょこありました。 そのテストに際して、iOS端末とAndroid端末で位置情報の設定を設定したり確認したりする必要があったのですが、OSが違えば当然設定方法も違うので、それぞれの設定方法と確認方法をまとめました*1。
iOS Safariの場合
iOS Safariの位置情報設定については、以下の3ヶ所から設定を変更することができます。
- 設定アプリ > プライバシーとセキュリティ > 位置情報サービス > SafariのWebサイト
- 設定アプリ > アプリ > Safari > 位置情報
- Safari > ページメニューボタン(アドレスバーの左にあるアイコン) > その他ボタン(右側にある「⋯」) > 位置情報
2と3は、手段が違うだけで、実態としては同じ項目を設定しているようです(なのでここからは、2だけに触れます)。
気をつけるべきところは、1と2は別々の項目として存在しているという点です。
そのため、2の項目で位置情報を許可していても、1の項目で許可されていなければ、Safari上では位置情報を使うことができない、となっています。
1と2は独立しているため片方を許可にするともう片方も許可になる、ということはありません。
例えば、1の項目が拒否かつ2の項目が拒否の場合に、2の項目を許可しても1の項目は拒否のままとなり、Safari上で位置情報を使うことができない、という感じです。 もちろん、1の項目が許可の場合でも2の項目が拒否なら、Safari上で位置情報を使うことができません。 1と2、両方が許可されているときのみ、Safari上で位置情報を使うことできます。
| 項目1 | 項目2 | 位置情報の利用 |
|---|---|---|
| 拒否 | 拒否 | 利用できない |
| 拒否 | 許可 | 利用できない |
| 許可 | 拒否 | 利用できない |
| 許可 | 許可 | 利用できる |
※ 片方の設定を変更しても、もう片方は変わらない
Android Chromeの場合
Android Chromeの位置情報については、以下の2ヶ所から設定を変更することができます
上記の2つは、手段が違うだけで、実態としては同じ項目を設定しているようです。 Androidは、iOSと異なり設定できる項目は1つだけのようです。 また、AndroidのChromeは、bの手段だと「権限をリセット」というボタンがあるため、気軽に権限をリセットすることができテストしやすくなっています。
位置情報を許可したサイトの確認
位置情報を許可したサイトや拒否したサイトについては、以下から確認することができます。 サイトに対して個別に設定を変更することもできます。
端末の位置情報を機能の大元をON/OFFする場合
ブラウザや特定のアプリに関係なく、そもそもこのスマートフォンの位置情報設定をON/OFFしたい、というのは以下から設定できます。 ON→OFF→ONとした場合、各アプリの個別の設定はOFFにする前の状態のままになっています*2。
おわりに
位置情報を使ったシステムのテストは過去にもやったことがあったんですが、たまにしかやらないこともあり、設定方法や設定場所を忘れちゃってたんですよね。
なので特にiOSの方で「位置情報許可しているのになんで使えないんだろう？」となることがありました(片方が拒否のままになっていることに気づかず、あれ？と沼にハマっていました。
備忘録的に書いたので次やるときはこの記事を参考に位置情報の設定を確認しようと思います。
余談
位置情報を使ったシステムはテストしづらいことが多いなぁと思います。
今回テストしたシステムは、管理画面から地図上に特定の座標とその有効範囲を登録する > スマホの利用者がその有効範囲内に入ったときにアクションがある、という様な感じのものでした。
毎回移動しながらテストするわけにもいかないので、スマホの位置情報はそのままに管理画面で設定する位置情報を変更する(= 有効範囲に入ったか/外れたかのテストにはなる)という感じのテストを主にしていました。
ただ、やっぱりちゃんと正しい使い方を想定したテストは必要ですね。
正しい運用通り、拠点を固定して、スマホを持って出歩いてテストをしてみたところ、これまでやっていたテストでは気づくことができなかった不具合が見つかりました*3
テストしづらいからテストしようですね。
Issueに添付する画像や動画を作るときに気にしていること
この記事は、ソフトウェアテストの小ネタ Advent Calendarの9日目の記事です。
はじめに
今年、Issueを書くときに気にしていることなどについて話す機会が定期的にありました。 その中で、画像や動画を作るとき何も考えていないつもりだったんだけど意外と色々と考えていたみたいだぞ！と思ったので、Issueに添付する画像や動画を作るときに、気にしていることを書くことにしました。
Issue
バグ票/不具合票/バグチケット/課題などなどという、テスト中に見つけた不具合が書かれたものを、業務ではIssueと呼んでおり、1事象1件で管理しています *1。 自分がIssueを登録するときは、見つけた現象のスクリーンショットを加工した画像や状況を録画した動画を基本的に載せています。 その画像や動画を作るときに気にしていることを書きます。
画像の場合
現象がわかるように情報を書き込む
スクリーンショットをただ載せるだけでなく、画像に書き込みをしています。 例えば「ボタンをクリックしたら500エラーになる」や「エラーメッセージが〇〇のほうがいい」などを書きます。 書き込む内容は、Issueの本文に同じことが(なんならより詳しく)書かれていますが、画像にも書きます。 理由は、Issueを読むときの順番が、「タイトル→本文→画像」ではなく「タイトル→画像→本文」となっているからだと思います。 この順番で読むとタイトルでなんとなく現象を想像し、画像でその想像をより具体的なものにして、本文で起きる手順やどう修正してほしいかを補うことができます。 そのため、スクリーンショットをそのまま使うということはほぼ無いです。
書き込む文字のサイズを画像内で1番大きくし、システム内の文字と重ならようにする
書き込む文字は、1番大きな文字サイズにシステム内の文字とは重ならないように置いています。 そうすることで書き込みした文字を目につきやすくするためです。 「これを読んでくれ！」とわかりやすくするために書いているので文字は目立つように。 そしてその他の情報を確認したくなったときのために、システムに表示されている文字にはなるべく重ならないように配置しています。 なんなら、配置についてはあえてバランスが悪いように置いています。 1枚の画像としてきれいにしすぎてしまうと、書き込みが目立ち加減が小さくなって最初に読むのに迷うかもしれない、というのとシステムと同化しすぎないことで「この書き込みはシステムにはないよ」というのをわかりやすくしたいからというのが理由です。
画面全体のスクリーンショットを元にする
ブラウザの全景だけでなく、タスクバーも含めて撮っています。 不具合だけを伝えるならこんなにいらないと思うのですが、Issueを読んでいてふと色々気になることが出てくることがあると思います。 そのときに情報を知れるようにするためです。 これを試していた時間はいつか？アドレスバーの表示は？不具合が起きている以外の要素はどうなっているんだろう？など。
全景を載せる結果、Issueを最初に読むときに不要な情報が増えるので、↑の「とにかくでかく」などのことを気にしています。
動画の場合
普段よりもゆっくり操作する
画像にしづらい、画像のほうがわかりにくいときに、操作手順も含めて録画して動画にしています。 動画を見る人は手順がわかっていない状態なので、普段操作するスピードだと早すぎて、動画を見ながら「待って待って！」となることがあります。 なので、体感通常の3倍はゆっくり操作して録画するようにしています。 また、動画の場合は、動画上にテロップを出すなどの編集はなく、スクリーンのキャプチャかスマホのカメラで動画を撮ったものを未編集の状態で添付しています。 理由は動画を編集する労力がまぁまぁかかるからです。 動画を編集するツールを持ってはいますが、画像を編集するよりも比較的時間と手間がかかるので、そういう編集をせずに
画像にするか動画にするか？
自分の中では、基本的には画像で、画像だと難しい場合は動画にするようにしています *2 。 理由は、読み手が現象を理解するために必要な時間を考えたときに、画像のほうがお得だなぁと思っているからです。 動画の場合「動画の再生時間」が読み手に一律に求められますが、画像の場合は読み手によって変わります。 また、見たいシーンを選ぶという手間も発生するため、そういった操作が不要な画像をつけるのを基本にしています。
おわりに
Issueを書いたり画像や動画を作るときに気にすることの話をしていて、他のメンバーも気にしていることが同じだったり、別の所を気にしているところもあったりだったのですが、それはまた別の機会で紹介できたら良いなぁと思っています。 テストラジオとかで話すかもです。 あと、普段何気なくやっていることを話してみると意外と考えて何かをやっていてすごい！となりました。 他の人と話したり、自分は普段どうやっているんだろう？と考えてみたりするのも良いですね。
Issueを読んで真似する #テストアドカレ
この記事は、ソフトウェアテストアドベントカレンダー2024の1日目の記事です。
はじめに
「良いテストとは？」や「テストが上手くなるとは？」について考えることがあります。 ふとしたときに考えるだけなので、その都度変わったりするのですが、「不具合を見つける」ことは「良いテスト」で、特に「この状況 *1でその不具合よく見つけたなぁ」というときに「テストが上手いなぁ」と、自分は思っているみたいです。
その流れで、じゃあ「どうやったらテストが上手くなるのだろう？」というのを考えてみたときに、「丁寧にやろう」と「Issueを読んで真似する」という2つが出てきました。 丁寧にやろうは去年書いたので、今回は「Issueを読んで真似する」について書きます。
Issue
バグ票/不具合票/バグチケット/課題などなどという、テスト中に見つけた不具合が書かれたものを、業務ではIssueと呼んでおり、1事象1件で管理しています *2。 Issueには「再現手順」「動作結果(=バグの内容)」「期待結果」が書かれているので、読むだけでその不具合について知ることができます。 Issue読んで、その内容を真似したり、「どうやったらその不具合を見つけられるか」や「この不具合から他に起きそうなことは何か」などを考えたりすることで、同じ不具合を逃さずに、さらに新たな不具合を見つけられるようになる = テストがうまくなると考えています。 基本的には、毎日全部のIssueを読めば良いと思っているのと、業務の都合もあってテストチームが登録するすべてのIssueを読んでいるのですが、それが難しいという場合もあると思うので、個人的におすすめするIssueを読む順番を書きます。
おすすめの順番
現在進行中のプロジェクトで、他の人が見つけたまだ直っていないIssue
まず、何よりこれが1番おすすめです。
まだ対応されていないので、Issueに書かれている手順をやれば、自分もその不具合を体験できます。 さらに、このIssueは鮮度が高いので、Issueの内容の不具合を見つけた人に「どういう流れでこの不具合を見つけたの？(=なぜこの操作をしたの？)」を知れる可能性も大きいです。 また、プロジェクトは現在進行中なので、これらをやることで「もしかしたらこういう不具合が起きるかも？」とテストしたいところがさらに出てきて、新しく不具合を見つけられるかもしれません。 もしそうならなくても、次のプロジェクトでテストをするときに真似してみたり、設計や実装中に不安なこととしてIssueを紹介できたりもします。
現在進行中のプロジェクトで、他の人が見つけた既に直っているIssue
次は、これです。
直ってしまっているので、手順を実際に行っても不具合を体験することはできないです。 とはいえ、現在進行中であればテストできる環境はあるはずなので、手順を実際に行うことをおすすめします。 鮮度は、直っていないIssueに比べると劣りますがまだまだ良い状態ではあると思うので、不具合を見つけた人に「どういう流れで見つけたか」を聞いたら、覚えている(思い出せる)可能性があります。
また、直っているIssueであれば「不具合の原因」や「修正時にどういう確認をしたか」が知れます。 不具合の原因を知れば、他に影響がありそうなところが思いあたるかもしれないです(思いついたらやってみましょう)。 また、「修正時にどういう確認をしたか？」を知るのも良いです。「自分ならこういう確認する」と思って読むのもありですし、書かれていることを読んで「他に確認したほうがよいところはないか？」と思って読むのもありです。
もちろん、直っていない状態のIssueを読んで真似したあとにそのIssueが直った場合は、これらのことを原因や修正時の確認方法を読むことをおすすめします *3。
過去のプロジェクトで、他の人が見つけたIssue
最後はこれです。
現在進行していないので、もしかしたらテスト環境がなく、手順を動かすということはできないかもしれません(もし環境があるならぜひ手を動かしてみるのをおすすめします)。 さらにもしかしたら不具合を見つけた人や対応してくれた人がいなくなっていたりして、当時のことを知れないかもしれません。 それらの情報は獲得できないけど、最低限の手順や動作結果、原因などを知ることができます。 もちろん、これまでやっていたジャンルとは違うジャンルのプロジェクトのテストを新しく始めるといった場合では、類似のプロジェクトのIssueを読むことはとても良いと思います。
(その他)過去に自分が見つけたIssue
このブログを書くに際して、昔自分が登録したIssueを読んでみたところ「意外と忘れている興味深いIssue」があったり「このあと〇〇したらどうなるんだろう？」と新しくテストが思いついたりしたので、自分自身が見つけた不具合のIssueを読むのも良いと思いました。 また、Issueを読んでいて「物足りない」と感じるときがあったのですが、これについては別の機会に書いてみようと思います。
おわりに
Issueは読むだけではなく、真似することが大事なのかなぁと思っています。
真似というと、まず書かれていることをその通りやるというのももちろんなんですが、そこからさらに「なんで？」や「他には」を考えることで、自分の身になり、テストがうまくなるのかなぁと思いました。
Issueを読んでぜひ真似しましょう。
「ソフトウェアテストをカイゼンするいくつかのアイデア」を聴いて思ったこと #jassttokyo #50QuickideasTests
2024/3/14(木)と2024/3/15(金)にあったJaSST'24 Tokyoに現地で参加して、その中のセッションの1つ、 「ソフトウェアテストをカイゼンするいくつかのアイデア」を聴講して、講演中に思い浮かんだことやその後考えたことがあったので、せっかくなのでそれぞれ書くことにしました。
※ 講演の様子を細かく書いたレポート的なものではないです
※ 自分について
・Web系システムの受託開発会社のテストチームのリーダー
・システムを動かしてテストする
・たまーにE2Eの自動テストを作ったりもする
・システムのジャンルや規模は様々
・HP/ECサイト/転職サイト/大学の研究室用のなどなど
・継続して追加開発しているシステムもある
講演資料
「時間経過を待つのではなく、イベントを待とう」
講演では「Loadingアイコンが出るまで待ってます、ならwaitやsleepじゃなくてそう書いたほうが良いよ」という話があり、自分もその通りだなぁと思った。 だけどそう思う一方で、自分はこのコードを書くことがまだある。 自動テストに関連するイベント(システムテスト自動化カンファレンス/ソフトウェアテスト自動化カンファレンス)や 自動テストに携わる多くの方のブログでもこれは言われているし、おそらく自動テストの「キホンのキ」的なものなんだろうなぁと思う。
でも自分がいざ自動テストを書く場面になると、自分の「とりあえずすぐ書けるレベルのコード」がwaitだったりsleepだったりなので、 一旦そう書いて「他のコードが自分の想像通り動いているかな？」って試して問題がなかったら、その後にwaitやsleepの部分をそう書かなくて良いように作り直している。
「とりあえずすぐ書ける」っていうのは「コードが動かなかったときに、疑う優先度が低い部分」という感じかなぁ。 自分の場合は、講演中に鉄平さんが言われていた「ある要素が表示されるまで待つなら、そういう風に書けば良い」というケースがほとんどなので、本当とてもごもっとも。 この辺りまだまだ力が足りない部分だなぁ。
「テストを作業項目に沿ってグループ化したり構成したりすることを避けよう」
講演中も質問もあったけど、説明が難しそうなアイデアだったなぁと感じた。
自分は、このアイデアの説明や質問を聴きながら「操作が同じだからといって、目的の違う複数のテストを、1つの操作でまとめてやるのは避けよう」ってことかなぁと思った。 「1つの操作であれもこれもそれも確認してはだめだよ」みたいな感じ。 テストという仕事をやり始めた初期の頃(6 ~ 7年前ぐらい)は、「効率よくテスト実行を終わらせるにはどうしたら？」っていうのをよく考えていた。 極端に言うと「このケース、手間が多い(同じ操作を何回もやらないといけない)から非効率だ」みたいなｗ
いつからかは忘れたけど、今はこういった考えはしなくなった *1。
この「1つの操作であれもこれも」みたいなやり方は「テストして不具合を見つけたり問題ないって確認することが目的」ではなく「テストを終わらせることが目的」になっているんだと思う。
テストやテストケースを終わらせることは、普段のお仕事では求めてないので、このやり方はやってない。
あと、このやり方はテストがうまい人ほどやってて負担が大きくなるんだろうなぁって思う。 例えば、「1つの操作で4つの別々の事柄を確認しないといけない」のと「『1つの操作で1つの事柄を確認する』が4つある」だと、「一度に気にしないといけない最低限のこと」は後者のほうが少ないので、後者のほうが良い。 自分の身近にいるテストがうまい人は「気にしないといけないこと」はもちろんテストするけど、テストを始めると、テストケースには存在しないことをどんどんテストしていってくれる。 テストを始める前に気になってたこともテストしてるだろうけど、テスト中にシステムを動かしてみてから「さらに気になること」ができる。 そして「さらに気になること」をやると、「さらにさらに気になること」ができる、という感じなんだろうと思う。 こうしてテスト中に気になることが増えていくので、「一度に気にしないといけない最低限のこと」が多いと、気にすることの数が爆発してしまうので、しんどくなるんだろうなぁと思う。
ということもあって、自分はなるべく「テストの目的」ごとにテストケースを考えるようにしてるんだけど、 「あ、これとこれ一緒に確認したほうが良いかも」って思って、複数の目的がくっついたテストケースを作ることがたまにある *2 *3。
だいぶ元のアイデアから逸れてしまった。
本に書いてある内容とはたぶん違う気がするので、ブログを書き終わったら改めてアイデアを読んでみる*4。
「テストコードは書くためではなく読むために最適化しよう」
講演中、「例えば、自動テストで検索のテストを書いてるんだったら『〇〇をクリックする』じゃなくて『検索する』って書こうよ」的な話があったんだけど、自動テストだけじゃなくて手動テストでもそういう場面あるなぁと思った。 あと、手動テストの話だけど、自分は『〇〇をクリックする』って書くときも『検索する』って書くときも両方あるなぁと。
「〇〇をクリックする」って書くときは、検索のテストの中で詳細なステップを書きたいときとかで、例えば以下の感じかなぁ。
・検索のテスト 1. 〇〇ページを開く 2. □□にXXと入力する 3. ◯◯をクリックする
講演で出てた検索を例にしたけど、検索のときはここまで細かくは書かないかもしれない。 検索を実行する方法が複数あったら(たとえば、検索ボタンだけでなくEnterでも検索できるとかなら)書くとは思うけど、いずれにせよ状況次第な気がする。
具体的に書きたいときは、どちらかというとテスト手順が難しいときかなぁ。 「外部連携しているシステムを使わないといけないから、操作手順をいつもより細かく具体的に書いておこう」というときとかはかなり具体的に書いてることが多い。 テストと言うよりはマニュアルに近いかもしれない。 未来の自分たちに向けて、例えばこの先追加開発などがあってもう一度この操作をするときとかに思い出せるように、と思って具体的に書くことがある。
あと、講演では自動テストの話が主だったけど、自動テストの場合はより読みやすさが大事なのかなぁとも思った。 このテストは、「検索機能」をテストしたいのか、それとも「〇〇をクリックする」というテストをしたいのか。 この場合「〇〇をクリックする」は検索を実現する1つの手段のように見えるから、「検索する」って書いてあるほうがテストしたいことがわかって良いなぁと思った。
「自動テストは頻繁に実行し、割れ窓はすぐ塞ごう」
これも自動テストだけでなく手動テストもそうだなぁと思う。 自動テストと手動テストだと起きる事柄が変わってくる気はするけど。 でもどちらにせよ、窓を塞ぎやすいような状態にしておくのがコツかも、と思った。 修正する習慣をつけることで、と資料に書いてあるけど、面倒くさがりな自分からすると、こういうのは習慣にするまでが結構大変。 だから「修正しやすいようにするにはどうしたら？」とか「修正したくなるようになるにはどうすれば？」っていうのをよく考えている *5。
手動テストの話になるけど、テスト中にテストケースを書き換えれるようにしたりとか、テストケースをマスターからコピーして使うというタイプのテストケースには、マスターへのリンクを張っておくとか。 地味だけどそういうちょっとしたことをやっておくと、すぐに修正しやすくなる。 あとこういうときは、チームメンバーがすぐ修正してくれるというのがとてもありがたい。 「自分じゃなくてチームメンバーがやってくれる」というわけではなくて「チームメンバーがやってるし自分もやらないとな」という動機が生まれるのでやりたくなる *6。
おわり
講演で紹介されたアイデアは11個あったんだけど、さすがに11個書くと大変なのでその中から特にいろいろ思ったものを書いた。 講演とても良かったなぁ。 本の解説もありつつ、鉄平さん自身の話もいっぱいあって「訳者オススメの本書籍の使い方」っぽく感じた。 Xにも書いたけど、読書会をしているように感じる講演だったなぁ(他の方の質問に、「えっ、それって〜」と声を出しそうになった)。
あと「ソフトウェアテストをカイゼンする50のアイデア」は、正解じゃなくてアイデアが書いてあるのが良いんだろうなぁと思う。 アイデアだから「自分のところだとこっちのほうが良いかも？」といった感じで、紹介されているアイデアに更にカイゼンを加えることができるし。 もしも「ソフトウェアテストをカイゼンする50の正解」とかだったら微妙だったかもしれない(その場合は、正解じゃないよね〜とかどうやったら良いかなぁとかいう議論が起きそうだからそれはそれで良いのかも)。
現地で参加できたのも良かったなぁ。 同じセッションに参加した人とちょっと会話できたりもするし。こういうのは現地のほうがやりやすいので良い。 楽しい時間だった。 書籍、読めてないアイデアがまだまだあるので、読んでいこうと思う。
気になったことを丁寧に扱おう #テストアドカレ
この記事は、ソフトウェアテストアドベントカレンダー2023の1日目です。
「良いテストをするなぁ」と思う人達に共通してるところは、仕事が丁寧というか、テストが丁寧なところだなぁと最近よく思う。 丁寧なポイントは分解するといくつかあるんだけど、その中でも「気になったこと」をとても丁寧に扱ってるなぁと思う。
例えば、一昨日。
同じチームのsaeさんがテストをしているとき「あれ？」と声を上げた。
よしたけが「どうしたの？」と聞くと「ここの機能がうまいこといかないんですよね」と画面を見せて説明してくれた。
たしかに、普通に触っているのにうまく動いてなかったので、なんでだろうね、と原因を探った*1。
その結果、その機能はちょうど改修されている最中であるっぽいというチャットをよしたけがみつけた。
「じゃあ今動いてないのはしょうがないのかぁ。とりあえずそのままにしとくか」
よしたけがそう言うと、saeさんは「んー」と怪訝な声を出してから「ちょっと聞いてみます」と言ってからすぐに、その機能を開発しているエンジニアにチャットを送った。
そうしたら、その機能は改修中ではなく、不具合(デプロイが正しく当たってない)ということがわかった*2。
いろんな場面を思い浮かべてみると、自分が一緒に働くテスターは気になったことを「まぁいいか」とはしていない。
気になったことがあったら内に留めてない。
動かしてみたり、人と話したりして確かめている。
「そんなの当たり前でしょ」って思うかもしれないけど、この当たり前をやっていて、やり続けているのはとてもすごいことだと思う。 「これ気になったけど、なんか忙しそうにしてるし言わなくていいや」「他にもやらないといけないことがあるし」とか言って、サボりたくなるときもあるんじゃないかな。 自分は昔、そういう風なことを思って、気になることを雑に扱ってたときがあった(今はこういうことはやらないようにしている)。
良いテストができるようになる方法はいろいろあると思う。 ただ、その中でも1番身近な今からでもすぐにできる方法は、気になったことを1つ1つ丁寧に扱うことだと思う。 これを続けると、積み重なっていって、それが当たり前になって、不具合を逃さない、良いテストができるようになるんだろうなぁと思った。
気になったことを丁寧に扱おう。
とちぎRubyの勉強会 拡大版 参加ブログ #toruby
2023/8/5(土)にあった、とちぎRubyの勉強会 拡大版の感想ブログ。
自分用の覚え書きなので、参加してない人は読みづらいかも(参加してると読みやすいというわけでもない)。
toruby.connpass.com
前座
track8さんによる前座。
ウエスト・サイド・ストーリーのてんどん、面白かったなぁ。
3年前にあったとちぎRuby会議09(たぶん初オンラインのやつ？)でお手紙を書かれていたのはこの方だったのか〜と勝手にちょっとしみじみ。
ゆるっとしてて良かった
ウエスト・サイド・ストーリー見たことないから、お盆休みに見てみようと思う。
magazine.rubyist.net
せきさんの割り込みの話と契約の話
せきさんの話を生で聴くのはたぶん4回目。
(とてか05 → JaSST Review'19 → JaSST'19 Kyushu→今回)。
テストやチームじゃない話を生で聴くのは初めてでなんだか新鮮だった。
割り込みっては実はポーリングだった的な話。面白かった。 途中で話にもあったけど、割り込みは特別な何かだと思ってた人に自分は該当する。 実はちょこちょこと確認しててなんだかかわいいなぁと思った。
assertの話は、最近「『ソフトウェアテストをカイゼンする50のアイデア』読書会を聴く会」でも少し話にあげてくれたなぁって思い出しながら聴いた(ちょうどそのあたりの回をaki.mさんがブログに書いてくれている。ありがたい *1 *2
「せきのコードのバグが以上に少ないのはなぜか問題」は、どれだけ少なかったのかとっても気になった。
あと、少ないってことは0ではなかったってことだと思うので、そんな中どんなバグがあったんだろう？っていうのも。
せきさんは自慢がうまいので聴いてて楽しかったなぁ。 asserについての理解が全然ということがわかったので、ひとまずassertについて調べてみることにする。
ruby.wasmハッキングガイド
なかじまさんのブラウザでRubyをキメると気持ちいいという話。
自分がRubyを書かないからなのか、キメる気持ちよさが最初はピンときてなかった。
でもギークな話を聴いていき、最後に実際に動かしてもらった画面で.rbのファイルがネットワークタブに表示されてブラウザ上で動いているのがわかったときは自分も「おぉぉ！」と感動したから、少しだけわかったかもしれない。
あと、ブラウザ上で動くってことはRubyを試す機会が増えるから自分も勉強しやすい(試しやすい)のかなぁ？とか思った。
それと、もしお仕事でruby.wasmを使うとなったときに、Rubyを書いてる会社の数名は「ブラウザ上でRuby動いてるんですよ。すごくないですか！？」と嬉々として言ってそうだなぁと想像できたから、たしかにキメると気持ちよさそうだって思った。
なかじまさんが見せてくれたシステムがとてもきれいですごかった(最初、表示されている文字は画像かなぁと思っていたら、文字はプログラム中にあったのでびっくりした)。
研鑽Rubyプログラミング勉強会
「研鑽Rubyプログラミング」の読書会。
普段のtorubyでやっていることらしく、今回は、第5章「エラーに対処する」の最初から。訳者の角谷さんの音読で進行した。
訳者による音読、とても貴重な体験だったなぁ。
Rubyを書かないからついていけるか心配だったけど、自分でもわかりやすいテーマと内容だったのでだいぶついていけた気がする。
特に言語によって同じような場面でも失敗したときにエラーを返すのか、例外を発生させるのかといった思想の違いがあるというのを知れたのがよかった。
自分は普段全然意識しないから、そんな違いがあるのか〜！となった。
あと「コードで書くと2 ~ 3行で伝わることを、日本語で説明するのが難しい」(うろ覚え)といった話が出てて、たしかになぁと思った。配列の要素がないところを参照して〜とか言わなくてもコードを書いたら何したか伝わるのすごい。
ただ、後半になると、Rubyの具体例が出だして自分はよくわからなくなってしまった(具体例が出るとわからなくなる、っていう珍しい体験だった)。だけど、みんながうんうんうなずいてたり、同じようなところでん？となってそうなのが感じれて面白かった。あと、終わってから「これってそう感じるものなの？」と一緒に行った後輩に聞いたら「そうですね」って教えてくれたので、そういうものだったらしいこともわかってよかった。
あと、オープニングだったっけ？ 「研鑽Rubyプログラミング勉強会のターンで本はなくてもいいんですか？」という質問に米澤さんが「大丈夫ですよ」って答えた後、角谷さんが「Lambda NOTEでお求めいただけます」って返してたやり取りがまるで打ち合わせしたみたいにきれいでとても面白かった。
続きを読んでみたいなぁと思ったので、福岡に帰ってからちゃんと原著も買った(中級から上級のRubyプログラマーではないけど、自分自身のプログラミングを改善するために原則とトレードオフを学ぶことに関心のある方には当てはまるのでよし！)。
研鑽Rubyプログラミング ― 実践的なコードのための原則とトレードオフwww.lambdanote.com
GAIとRuby
酒匂さんによるGAI(Generative AI)を使った事例や応用の発表。6月のSS2023で話された内容を元にさらに追加もあるという感じだった。
個人的に、SS2023での酒匂さんのお話がめちゃくちゃ良くて、酒匂さんの資料を参考に、実際にChatGPTを使ってコードを生成してテストツールをいくつか作ったりしてた。 そんな中もう1度、酒匂さんのお話を聴くことができたのはとても幸運だった。特によかったのが伝えることと翻訳することの部分のお話をもう1度聞けたこと。 モデルの表現方法をAIに任せるというのは自分もいくつか試してみようと思った。 そして紹介される事例もお話もすごいことだらけだったんだけど、何よりも、そんな風に使おうと思う(使い方を思いつく)ところがすごいなぁと自分は思った。
テストの健全性とコンテキストにおける重要度の変化について思ってることを話したい！
今回の「とちぎRubyの勉強会 拡大版」をやるきっかけになったというヨシオリさんのターン。
誰かが言ったことに参加してる人がそれぞれ考えて、気になることがあったら口に出して、もし言いづらくてもついポロッと口に出しちゃったりしてそうな、よい時間だった。
50分しっかり脳みそを使ったおかげで自分はヘトヘトになってしまった(もちろんよい意味で)。
直前に芋ようかんを食べてなければダメだったかもしれない。芋ようかんとても美味しかったです。
プログラムを書くのを生業にしてる人が多い中で、テストについての考えを聞けたのよかったなぁ。 あと、たしかせきさんか米澤さんが言ってた「時間は限られてるからお得なテストはなんだろうって考える」っていうのは真似して使おうと思った。 うちのチームもテストを減らしたいんじゃなくて、もっとテストしたいんだよね。っていう話を、福岡に戻ってからsaeと話した。
それから、めちゃくちゃ一方的な思い出なんだけど、ヨシオリさんを知ったのは、とてか05のとき。 120秒LTが時間切れになり途中で終わるやいなや、すごい勢いでホワイトボードに2回目の名前を書いて、「で、続きなんですけど」ってLTの2回目をしてて「めっちゃアツい方だなぁ」って思った。 その短い時間だけだったんだけど、そのときのことがなんだかとても印象的で、今回のテーマを見たとき、せきさんたちととちぎでどんな話するんだろう？って気になって今回参加したいなぁって思った。 そして参加してよかったって思う(もしこの思い出が間違いだったりもし違う人だったら…それでも今回参加できてよかったのでそれはそれでよし！)。
LTのターン
覚えてることをつらつらと。
- タイマーがとってもよかったなぁ。かっこいいし。ちゃんと拍手や歓声も出るのよかった。モードの切替がサクッとできてるの良いよなぁ。使い勝手良さそう
- ルービックキューブうまくてすごかった。練習用のあるのすごい。作ったのかな？
- 本めちゃくちゃ読まれててすごかった。感想がところどころ秀逸でおもしろかった
- Rubyにまつわるクイズおもろかった。みんな結構正解しててすごい。最後の問題が単語なのか言語なのか気になった
- TDDでFailになったのをさらにAIが直して〜っていう話。すごい世界だった
- 自己紹介に自分のレントゲン写真を使ってる人を見たの、かれこれ4人目でびっくりした。栃木では流行っているのかもしれない
- ボルダリングすごかった。ちょっとずつ繰り返してできるように〜ってところがとても好き
- 舞踏！(チグリス・ユーフラテス？に住む人々の文化の本、面白そうだったけど舞踏の印象が強すぎて忘れた…)
- 読書会のBGMの原曲があったの知らなかった(忘れただけかも)。原曲とてもよかった
- 推しにあったときの気持ちめちゃくちゃわかる。自分も一度遭遇したことがあるけど、頭の中が真っ白になったなぁ
- 自分は最近あった珍しい事象(DBリセット事件)の話をした。120秒には間に合わなかった
おわり
本当は翌日にでも書きたかったんだけど、移動もあったし当日頭をいっぱい使ったのもあって疲れたので今日にｗ(でも今日書いているのでよし！)
ブログを書きながら当日のことを思い出して、あーよい時間だったなぁ、って何度も思った。
それに今回は会社の後輩と一緒に2泊3日で行ったんだけど、行きの飛行機、新幹線、前日の夕ご飯、当日終わってからコンビニへ買い物に行く道中、帰りの新幹線、東京での食事中などなどの時間でずーっと開発に関わる話やとちぎでの話もできて、それも楽しくてよかった(帰りの飛行機では自分は疲れ果ててずっと寝てた。後輩氏はずっと読書してたらしくすごかった)。
あ、あととっても重要。
「ソフトウェアテストを改善する50のアイデア」に鉄平さんからのサインをやっともらうことができた！
コメントまでいただけてとても嬉しかった。25番はよしたけです。
それから今回、セコンさんに大変お世話になったし、差し入れにあったシフォンケーキがふわふわでとても美味しかった…。感謝しかない。
あれからまだ一週間しか経ってないのかぁ。もっと前だったようにも感じる。めちゃくちゃ濃い時間だったなぁ。また行きたい。
いいtorubyだった。
おまけ①
前日の夜に入った、黒磯駅の近くにある「Pico Pizzeria」ががとても美味しかった。 野菜もお魚もお肉も美味しくて。またとちぎに来たときは絶対行くと思う。 pico-pizza.jp
おまけ②
今回キャリーケースを新調したんだけど、それがとてもよかった(OltimoのOT-0861-46)。 まぁまぁ力がないので、元が軽い & キャスターのロックがめっちゃ便利だった。
