JaSST'26 Tohokuの思い出 #jassttohoku
ごきげんよう。saeです。
今年もJaSST'26 Tohokuに参加してまいりました。楽しかったです。実行委員のみなさま、お話ししてくださったみなさま、ありがとうございました。
以下感想です。
感想
本会
JaSST'26 Tohoku、今年のテーマは「生成AIと歩むテスト設計 〜AIはもう1人の仲間〜」でした。
自分は、生成AIについては「触ってはいるけど使いこなせてる感じはまったくない」という感じで、かといってなにか困っているという訳でもなく。なんか面白い話聞けたら良いな〜といったようなのほほんとした心持ちで参加しておりました。
この会に参加して心に残ったワードとして、「説明性」「説明責任」というものがあります。
生成AIにコードやテストを作らせたとして、その責任は「人」にあるということ。そして、テストには説明性がある、というお話でした。
生成AIで作られたものだとしても作ったお前が責任を持て、AIで生成したコードやテストでも説明できる状態でいる必要がある、生成AIで作ったからわかりませんは仕事じゃ通らんぞ、ということと理解しています。（違ってたらすみません）
個人的に生成AIで作られたものに対してなんとなくずっと懐疑的だったと言うか、便利っぽいのはわかるけどそのデータってどこまで信用していいんです……？ みたいな気持ちがずっとあり、これに対していまいち自分の中で答えを見つけられずにいました。なんか信用ならんやつだなぁと思って生きてきたわけです。
とはいえ、これだけ生成AIが一般にも浸透している世の中で生成AIを使わないのは逆張りが過ぎるという認識はあり、少しずつ触れてはいました。ただ、人から「こういう風に使えるよ」「AIでこんなことできるよ」みたいなことを教えてもらう分にはなるほどすげーじゃん、となりつつも、いざ手元で使ってみるとうまいこと使いみち思いつかないなー、どこまで信用していいかわからんし……みたいな感じだったのです。
「説明性」「説明責任」のお話を聞いて、自分が生成AI使う時になんとなくずっと引っかかってた、「信用できない」っていうのはここなんだなと思いました。
責任はあくまで作った人が持つもので、生成AIそのものや生成AIを作った人は責任持ってくれないよね、と。
例えば仮に自分の思想が元になったAIがあったとして、その生成AIがテストケースを作ったとして。そのテストケースに対する責任は思想元の自分じゃなく「そのAIを使ってものを作った人」「レビューした人」にある、と思っています。
なので、自分がこの話で大事に思うこととしては「使った人間が生成AIが作ったものに対して責任を持つ」「作られたものを理解し、レビューして、説明できる状態である必要がある」かなと思いました。
要は信用ならんなら無理に信用しなくていいか、みたいな結論です。手放しに信用しすぎずに、レビューする前提で使おうねって話。
それに加えて今回の会に参加して得た学びとして、「ナレッジの整理とか管理には良さそう(すでにあるデータを学習させて再利用するのには良さそう)」「0→1でなんか作るのはなんか気をつけたほうが良さそう」という感想になりました。
使っている方々からすると当たり前のことかもしれませんが、改めてしっかり生成AIを使っている人たちの話を聞いて、今のところはこういう付き合い方が自分には良さそうだな、と思っております。
ワークショップ
ところでワークなんですけど、めっちゃ難しかったです（個人の感想です）。
多分なんですけど、「自分たちが普段やっていること」とワークのレビューのフローとか生成物の内容とか順番とか全部が違いすぎて、個人ワーク → ペアワークの時間になるまでに仕様書が読み終わらないという残念具合でした。これは自分の普段の仕事が、自分たちがやりやすいように効率化されまくっているのだとポジティブに捉えておきます。
ただ、生成AIのワークを紙に落としてるのはめっちゃ面白かったです。すごい設計。自分だったらとりあえずPCは必要だよね、って安直に考えちゃいそうですが、時間の兼ね合いとか色々考えた結果こうなったそうで、ワークの設計にはただただ感心していました。
すごい！
懇親会 〜
生成AIに業務中の怒りをなんとかしてもらってる人たちの話が面白すぎました。
自分もなにかあったらAIに頼るか〜という気持ちになりました。楽しかったです。
おしまい
今年もお疲れ様でした。そしてありがとうございました！
相変わらずご飯も美味しく、めっちゃ食べました。ごちそうさまでした！！！
JaSST'25 Tohokuいってきたよ
ごきげんよう。sae (@sito_110) です。
先日、JaSST'25 Tohokuに参加してきました。
色々お話聞いたり話したりしたので思い出を書きます。
ワークについて
VSTePの詳細については各々ググっていただきまして、今回参加したワークでは、すごくざっくりとまとめると以下のような手順で進めていきました。
- テストしたいことを出し合う
- ツリー構造にする
- グループに分ける
- 実際にやる順番に並べる
自分たちが普段やっているやり方だと、テストしたいことをテストに入るメンバーで色々話し合う → 実行する順番に並べる、という感じでテストを考えています。
ツリーにしたりグループに分けるくだりが難しかったんですが、普段やっている中で『なんとかテスト』、みたいにグループにまとめて名前をつける みたいなことをしないからピンとこないのかなぁ、とか思っていました。
普段はむしろ、1個のテストを小さくしようとしてる傾向にある気がします。1テストケースは1個の目的でできていてほしい宗派。
感想
楽しかったです！
ワークの途中で「最初に何テストする？」を考えるターンがありまして、それぞれ考えて出したのですが、普段同じチームで開発してらっしゃるmiwaさんと咳さんが同じ「起動と終了」、普段同じチームでテストしてるyoshitakeさんとわたしは「起動して時間を指定してアラームが鳴るまで」という回答でした。普段一緒に仕事しているメンバーで同じ答えを書いていて、「これが『文化』か〜」と感慨深くなるなどしました。
『文化』というワードは以前から何なんだろうなという感じだったんですけど、こうやって見えてみると、作ろうとして作るものではなくて、やってきたことの結果というか、気がついたらできてるもんなのかもな、と思いました。
テスト設計のレビューの話
懇親会に参加した折、テスト設計のレビューで困っているという話を聞きました。
その場でも色々喋ったんですが、その後に自分たちはどうしてるかな、をもう少し考えてみたのでここに書いておきます。
自分たちがテストをはじめる時、まず、今回のテストで確認したいことを喋ります。ここで喋ったことはこの時点では決定稿ですが、テストが進んできたら「ここもうちょっとテストいるよね」とか、逆に「ここって別のテストでもうできてるから改めてやらなくて良いんじゃない」とか、ブラッシュアップされていきます。ので、ここで考えたことがすべてではないです。
確認したいことを出し終わると、実際にテストする順番を決めます。
「これは修正大変そうだから早めに見よう」とか、「運用上1番大事なとこだから先に見よう」とか、「この細かいテストは1回大枠のテスト終わってからが良いからこっちのテストの後にしよう」とか、「これはテストは必要だけど最悪リリース後でも修正間に合うから後で見よう」とか。色んな要素を考えて決めます。これも、1回決めた後にバグの出方とか状況次第で順番変わったりします。テストって生きてる？
順番が決まると、具体的なテストケースを考えます。
自分がレビュイーの場合の話ですが、ここまでに議論したチームで必要だと思ったテストの中で最初にやるものについて、実際に手を動かすためのテストケースを作っていきます。
この時、項目を考えてテストケースの中身を5行くらい作ります。で、1回レビュアーに見せます。
たくさん作ってしまう前に1回すり合わせてほうがお互いに不安にならなくていい、という思想です。（この大きさで見せるに至るまでには紆余曲折ありました）
全部作り終わってからだと気に入らなかったときの手戻りでっかいし、作り直すのも指摘するのもたくさんになります。
早めに1回見せておけば、カラムの作り方とかなんとなくの流れは先に共有しておいた状態で作り始めるので「気に入らない」が減るし、このまま進めて大丈夫なんだ、という安心も得られる。
自分が抽象的な話を理解するのが苦手なのもあり、少しだとしても具体的に物を作ってからのほうが会話しやすいというのもあります。
まあ調子が悪いとこれでも失敗することがありますが、人間なのでそういうときもあるよね。
ちなみに、手をつけてから最初の5行を作るまでの間ずっと喋ってるときもあります。
このときはもうレビューと言うよりは一緒に考えて作っている状況で、こっちのほうが話は早いですね。最初だけ一緒に作って、じゃあ後よろしく！みたいな感じになります。
終わりに
JaSST東北、本会でも懇親会でもいっぱいお話聞けて楽しかったです。お話してくださった皆様、ありがとうございました！
そして仙台、美味しいものいっぱい食べられて幸せでした。はらこ飯、牛タン、ずんだシェイク、笹かま。仙台最強！
私はテストをしている時何を考えているんですか？
この記事は
ソフトウェアテストの小ネタ Advent Calendar 2024 2日目の記事です。
はじめに
ごきげんよう。saeです。
少し前に、社内で発表する機会をいただき、「テストしているときに何を考えているかしゃべるぞ」みたいな話をしたんですが、オチが弱かったな～～と反省しましたので、これについてもう少し考えてみました。
※ ネタバレ：オチは弱いです
本題
とりあえず前置きといたしまして、当日お話ししたことはこんな感じです。
- テストしているときに何を考えているか？
- 仕様書に書いてあること
- 仕様書に書いていないけど気になること
- 起きてほしくないこと
- でっかいデータ/大量にデータを入れてみる
- ここなんか起きそうな気がするな〜
で、この箇条書きの中身を1つ1つ考えてお話ししました。
ここから、最後に書いてある「ここなんか起きそうな気がするな～」をこのブログでは考えてみようと思います。
ここなんか起きそうな気がするな〜
テストをしていて、何かが起きそうな気配を感じることってありますよね。
これって、システムの理解とか、ITやドメイン知識などのいろいろな知識とか、テストの経験とかをよりどころにした勘みたいなものだと自分は思っています。
で、なんか起きそうなところ、と漠然と書いていますが具体的には以下のような思考が思いつきます。
- ん？なんだ今の
- さっきなんか起きたな！…再現しなくなったなぁ…？
- 再現した！こうやると起きる！ヨシ！…ヨシじゃないな…
- 初回だけなんか起きてた気がするなぁ～
こういうのを頑張ってつかまえたいなというお話です。逃がすな！
もう少し分解する
「ここなんか起きそうな気がするな～」を感じるために大事にしていることを考えてみます。
端的に言うとこうです。
- 丁寧にやる
丁寧にやるということ
このためにいくつか気を付けていることがあります。
初見は気合いを入れて見る
初めましての印象というか、素直に見る、みたいなのはなんとなく大事にしています。 慣れる / 飽きると見落とすことがあるし、目新しいものを見るのは単純に楽しいからです。
多少時間がかかっても見る
今見つからなくて後で見つかったほうがトータルで時間食うな～みたいなお気持ちになるので、今見るべき！と思ったら今見ます。
これやるの面倒くさいな…と思ったら見る
面倒くさいということは他の人が触っていない可能性が高いです。だって面倒くさいからね！
今やらないと多分後でやらないなと思ったら見る
皆様が「単純なCRUD」と呼ぶものなど、シンプルな部分って意識しないとあまり見返さないから意外となんかあったりします。
考え続ける
そのシステムをどんな人が使うのか、なんのために使うのか、どんなときに使うのか、どうやって使うのか、使う環境どういう感じかな、画面サイズなんだろう、端末何使うんだろう、PCのみ？スマホ？タブレット？、こういう操作をする可能性があるかな、使いやすいか、勘違いしないか、わかりやすいか、壊れてないか、見にくい見た目になっていないか、色・フォント・コントラスト・余白・テキストの大きさは適切か、誤字脱字衍字がないか、コード露出してないか、導線は自然か、最初のページに戻れるか、今どこにいるかぱっとわかりやすいか、ログイン中のアカウントはわかるか、ログアウトできるか、ボタンの位置、連打したらどうなるか、ネット遅いときどうなるか、屋外でも使うか、IP制限いれるか、ページのロード重くないか、アップロードできるか、ダウンロードできるか、画像読み込めてるか、画像でかすぎないか、そういえばFaviconとページタイトルあってたっけ、URLのドメインちゃんとしてたっけ、管理画面複数あるけど見分けつかないな、カメラ使うんかいな、端末の認証使うかな、なんかエラーでた！？何！？
とか。なんか色々考えながら触っています。思いつく限りのリスクを考える、という感じです。
疲れたらやめる
脳が疲れてへとへとでテストしたときにそれは「テストした」と言えるのか？否(個人の感想です)
まあ時と場合にもよるけど基本は元気なときのほうが調子いいよね、というだけのお話です。
テストというものには、めちゃくちゃ頭を使うテスト と そうじゃないテスト があると思っています。
自由に触るのと、この部分がこうなっていることを確認する、が細かく記載されたチェックリストを実行するのは頭を使う範囲がぜんぜん違うよなぁ、みたいなことです。
自分は、疲れてくるとチェックリストやテストケースに起こすことが多いです。これは、「テストを考えるフェーズ」と「テスト実行するフェーズ」を分けることが目的です。あとは、テキストに書き出したり構造を図にしてみたり、誰かにしゃべってみたり。これらも目的は全部一緒で、やりたいことを分解・分散してちょっとずつ考えることで、全部組み合わせたときによりたくさんのテストを考えられるようにするためです。
テストに限らずですが、1人で孤独にのめり込んでると、そもそも疲れを自覚するのも難しかったりします。このようなとき、誰かと喋りながらやってると、変なことをしだしたときに止めてもらえるのでお得です。ついでに喋ると脳みそがよく回るような気もします。※これには個人差があるかと思います。
おわりに
ひとつひとつのテストや自分の思ったことを丁寧に取り扱っていこうというお話でした。
おしまい。
話しかけると褒めてくれるSlack Botが賢くなった
この記事は、テスト小ネタアドベントカレンダー2020 18日目の記事です。
伝えたいこと
去年書いた「話しかけると褒めてくれるSlack Bot作った」のBotを拡張して、ペンギンちゃんが頭良くなったぞ！どや！という話をします。 ito128.hatenablog.com
ペンギンちゃんって何？
GASとGoogleスプレッドシートを使ったSlack Botです。 Bot名とアイコンは某ペンギンのキャラクターからお借りしています。 仮名「ペンギンちゃん」とします。
なにができるの？
「@ペンギンちゃん テストデータ」と話しかけると、架空の氏名、住所、電話番号などのテストデータをくれる
「@ペンギンちゃん テスト記事」と話しかけると、テスト端末のアカウント情報やテストツールの使い方が書かれた記事など、テストに関係ありそうな社内ブログの記事の一覧を出してくれる
つくってよかったこと
- Slackだけでテストデータやテスト関連の記事情報を出せるので楽
- かわいくてほめてくれるだけじゃなくて役に立つBotに進化した。すてき。
用例
1. 「@ペンギンちゃん テストデータ」と話しかけると、架空の氏名、住所、電話番号などのテストデータをくれる
こんな感じで、氏名、生年月日、年齢、血液型、郵便番号、住所、電話番号、携帯番号を出してくれます。 データは疑似個人情報データ生成サービスで作成したデータを500個ぐらい持っておいて、そこからランダムに1つ返すようにしています。
何かしらでアカウント作成する必要があるとき、なんとなくそれっぽいデータを考えるというどうでもいいことに思考を持っていかれないのでよいです。 こういう「どうでもいい思考」をできるだけ削ってその分テストに思考を割きたいんですよね。
架空の情報なのですが、もしかしたらこの人が実在するかもしれない可能性に賭けて一応モザイクをかけました。えらい！
2. 「@ペンギンちゃん テスト記事」と話しかけると、テスト端末のアカウント情報やテストツールの使い方が書かれた記事など、テストに関係ある社内ブログの記事の一覧を出してくれる
ツールの設定方法とかテストアカウントとかの情報を社内用のブログシステム的なものに置いているので、その一覧をデータで作っておいて出してくれます。
これは、単純に記事を探す手間が省けるので楽です。大体探す記事って決まってるので、あぁこれは後で見に来そうだなってやつを随時登録しておくようにしています。
記事を1個ずつじゃなくてまとめて一覧にして出すようにしているのは、記事一つ一つに反応ワードを設定してみたところ、なんて送ったら記事を出してくれるのか全く思い出せなくなり全然使いやすくなかったからです。かいぜんってこうやって行われるんですね。(ごめんなさいてきとうなことを言いました)
おわりに
『必要だけど割とどうでもいいこと』に思考を割く前にペンギンちゃんに相談だ！
余談ですが、去年作った「褒める機能」も随時アップデートされておりまして、誰かが「できた」「終わった」と言うととりあえず褒めてくれたり、出勤したら「出勤してえらい！」と褒めてくれたり、「お疲れ」といったら「おつかれさま〜」って言ってくれたり、ランチに出るときはいってらっしゃいを言い戻ってきたらおかえりを言うなどなどなど、素敵な機能がたくさん増えております。Channelが賑やかになり、微笑ましくて癒やされますね。どんどんどんぱふぱふぱふ〜！
みんなもれっつペンギンちゃん！
おしまい。
話しかけると褒めてくれるSlack Bot作った
この記事は、Fusic その2 Advent Calendar 2019 21日目の記事です。
ごきげんよう。さえです。Fusicでテストエンジニアをしています。
今日はSlack Botを作った話をします。
伝えたいこと
褒めてくれるBotがかわいくて癒やされるのでおすすめ という話をします。
なにつくったの？
GASとGoogleスプレッドシートを使ったSlack Botです。
Bot名とアイコンは某ペンギンのキャラクターからお借りしています。
仮名「ペンギンちゃん」とします。
顧客の要望
「@ペンギンちゃん 〇〇した」と話しかけるとスプレッドシートに「〇〇した」と書き込むBot
できあがったもの
「@ペンギンちゃん 〇〇した」と話しかけるとスプレッドシートに「〇〇した」と書き込み、Slackで「〇〇してえらい！」と褒めてくれるBot
なにができるの？
- 「@ペンギンちゃん 〇〇した」と話しかけるとGoogleスプレッドシートに「〇〇した」と書き込み、Slackで「〇〇してえらい！」と褒めてくれる
- 「@ペンギンちゃん」と話しかけるとスプレッドシートのURLをくれる
- 「@ペンギンちゃん 褒めて」というと褒めてくれる
- だれかが「すごい」というと盛り上げてくれる
褒めて、すごい以外にもいくつか反応ワードを実装しています。
あとは、日々だれかがBotに話しかけるのを眺めて、そういうことを話しかけたいんだな、というワードをこっそり反応ワードに追加しています。
つくってよかったこと
- やったことリストの更新が簡単になった
- チームのChannelに入れたら、Channelが明るくなった
- 和む
- かわいい
せっかくなので
社内向けに「話しかけると褒めてくれるBot」として公開してみました。
スプレッドシートに書き込む機能は、自分のチーム用の機能なのでチームChannelでしか使えないように制限しました。
DMには対応していないので、このBotで遊ぶためのChannelも作成して一緒に公開しました。
公開から2週間経ちましたが、今もちょこちょこ話しかけてくれる人がいて遊んでもらえています。わーい。
用例
こんな感じで遊んでもらっています。
メイン機能はこんなかんじです。
「すごい」に反応する。最初は反応ワードが1パターンしかなくて荒らしでしたｗ
たまに空気を読んでない発言をして笑う（むしろ空気を読んでいる？ｗ）
最後に
単純にChannelが盛り上がるだけでちょっとニコニコできて楽しいです。
誰でもいいから褒めてほしい人、Channelを盛り上げて欲しい人はぜひ作ってみてください。思いの外癒やされますよ。
自分の好きなキャラクターや有名人で実装してみたらめっちゃ楽しいと思います。口調や返すワードをキャラクターに似せると本当に会話できているみたいでハッピーです。
れっつペンギンちゃん！
おしまい。
なにかを教えてもらうときにグラレコをかくといいぞ
ごきげんよう。saeです。
この記事は、ソフトウェアテストの小ネタ Advent Calendar 2019 - Qiita 14日目の記事です。
伝えたいこと
「なにかを教えてもらうときにグラレコをかくといいぞ」
一言でいうとこれです。
今回は「テストの小ネタ」がテーマなので私が普段テストで活用している場面の話になります。
そもそもグラレコって何？
こういうやつです(雑)
会議や勉強会で話されている内容をリアルタイムにグラフィカルにまとめていくものです。
自分は紙とペンがメインです。たまにホワイトボード。
持ち歩いているものたち ↓
いつどこで使うの？
主に仕様を説明してもらうときに使います。
話の規模や相手にかかわらず、なにかの説明をしてもらう。
このときにグラレコをかきます。
描くこと
テストするときに見返せたら嬉しそうなことをかきます。
- その時の仕様
- わかること
- わからないこと
- その場で解決したら答えもかく
- 絵や図
- 画面の配置や階層、構造
- 誰かが言ってたことを、似顔絵とふきだしでかく
- ちょっと気になること、テストしたいこと など。
機能や階層でカタマリを分けてかいていきます。
ひとカタマリはこんな感じです。↓
説明してもらった後は、できあがったグラレコの写真を撮り、全部Slackに貼ります。
こうするとこの時点の仕様書ができ、かつみんなに見てもらえます。わーい。
なんでグラレコがいいの？
- 構造をかきたい！とか図をかきたい！がライトにできる
- 線で囲ったり分けたり見出しをつけたりできて、カタマリや境目がわかりやすい
- 「あーこれ仕様共有のときに聞いた気がするなーなんだったっけなー」ということは大体かいてある。天才。
- わからないことが見つかるから聞ける
- かいてないことは話されてないからわからない
- かいてあるけどわからないまま放置されている
- 読み返してもなんのことかわからない
まとめ
このグラレコでわかるのは「その時の仕様」なので、仕様書をちゃんと更新したい人向けではないです。
あくまでも、その時の説明を簡単にかき残しただけのものです。
「あれ？これ説明聞いたけどなんだったっけ？」ってなりやすい人にはおすすめです。れっつグラレコ。
おわりに
おすすめの紙とペンがあったら教えてください。手首が痛くならないやつを探しています。
もしくは誰かiPad Proください。
おしまい。
参考書籍
#テストラジオ #107 のグラレコ
テストラジオを聴いたので、練習がてらグラレコを描きました(((((((((((っ･ω･)っ ﾌﾞｰﾝ
間があいちゃったので、一旦最新回のグラレコを書きました。
キーワード
グラレコ
