テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

MeetyでQAのカジュアル面談をやっているよ

Meetyって何?

meety.net

カジュアル面談のプラットフォームです。
ほんとにカジュアルに応募してもらえてるなって思っています。

なんでやってんの?

いまの会社の採用活動のひとつとしてやっています。
Slackで、Meetyっていうのがあるらしいよ。みたいな会話があがって
気づいたら周りの人たちが登録してました。
私たちQAの募集もしていたので、じゃ、登録しとこーって感じでしました。

会社からは、Meetyでカジュアル面談やっている時間も用意している時間も、業務として扱えるので
自主的な活動を認めてくれているのも、やろっかな?ってハードルの低さになってます。

その代わり、お話ししてくれる方のお名前を人事にお伝えしています。

どんな人とやってんの?

知り合いだったり、SNSでは知ってますって人だったり、ほんとにはじめまして!って人だったり。
私の場合、採用目的の人はほとんどいないかもしれないです。
Meety使ってみたいからって友人もいたり、職種もQAだけではなく、PdMやエンジニアなど色々いました。
といっても、面談してもらった方みなさん一緒に働きたい人ばかりとできてます!

やってみてどうだった?

もともとの「採用目的」は、私の場合あまりつながっていません。
ただ、いますぐ転職意志がなくても、将来転職を考えたときに
わたしたちの会社が候補としてあがってもらえたらいいな と思っています。

なので、当初の目的からは外れてしまうのですが、
それでもこの2年全然新しい人と出会うこともなかったですし、
固定の人(1 on 1ですることも、4人くらいですることもあった)と、一定時間話したり
お互いの情報を共有できるのはいい時間だなーって思っています。

もうちょっと段取り良く話せたらいいかもしれないけど。

ってことで

meety.net

2021ふりかえり

ことしもふりかえるよー

1月 

ブログ 1本

テスト実況生中継をしてきたよ - テストする人。

前年末のイベントについての記事。

1月1日に、「来年から本気出す」って、今年は副業とかやっちゃおっかなーと思った矢先に
社内異動の話が出てそれどころじゃなくなったのが1月です。
そっこう当時のマネージャーやら数人に相談した。

2月 

記憶がありません。たぶん引継ぎの用意をしたのか、そんなにそもそも引き継ぐものがなかったなって感じだったかも。

3月

ブログ1本

engineering.mercari.com

昨年末に書いたブログの英語版。Google翻訳使いつつ書いて、めちゃくちゃメンバーに添削してもらって
さらに社内でも翻訳レビューもしてもらってどうにか出せた。

英語が体育の次くらいに苦手でいまだに中1レベル抜けないんですけど、
それでもブログというものを出せたのは進歩かなって思います。
あと、全然言葉出てこないけど、それでも英語の先生とかのコミュニケーションは緊張しなくなったので進歩してます。
(しゃべるの怖いレベルだったので・・・)

この3カ月は、WebのE2Eのテストコードを書いたりしていた。全然上達しなくて、レビューしてくださった方々にとても申し訳なかった。

4月

ブログ1本

underscore42rina.hatenablog.com

異動にともない、メルカリでしてきたまとめ。
といっても、たいていまとめてたので、まとめのまとめのまとめって感じ。

5月

GWもうっすら仕事していた。

6月

ブログ1本

underscore42rina.hatenablog.com

Twitterのリプライしたけど、そういえばそのエントリー書いてないんだなって書いたやつ。
それ以外は仕事をしていた。

7月

仕事をしていた。
プレローンチをしたので、ようやく大きな声で何の仕事をしているのかを言えるようになった。
SlackのHuddleが使えるようになったのもこのころ。ローンチ直後にバタバタしてて、Huddleでわいわいしてた。
青春だった。

8月

ブログ1本

engineering.mercari.com

ローンチ直後に連載をしてたので、私も書いた。
おさわり会はまだやってるけど、内容が変わってきていて、さらに変わりそうなので楽しみ。
もうちょっと変えたい。

mercan.mercari.com

おさわり会の話はここにも出てきていて、PMもエンジニアもQAもみんな考えてるってことがわかるのがすごい好きです。

9月

イベント 1本

mercari.connpass.com

会社のイベント。こういうイベント数年ぶりなので楽しかった。

会社掲載的なの

anchor.fm

上のイベント直後の収録。色々会社が仕掛けつくるっておもしろいですよね。

10月

会社掲載的なの

福岡に住むソウゾウのエンジニアに突撃。コロナ禍によって働き方はどう変わった?#SouzohEngineeringCafe | mercan (メルカン)

そんなこんなでグループ会社の入社3年が経ってしまいましたね。
福岡で働くこと、自宅で働くことが当たり前になっているのがすごいなって思います。

11月

会社掲載的なの

ソウゾウエンジニア談義。みんな、どうしてソウゾウに異動したの?#SouzohEngineeringCafe | mercan (メルカン)

今年はたくさん会社掲載してもらったので楽しかったです。
このお二人はとくにイベントのモデレーターしているのをみて、社内だけどすっごいファンです。
よくそこで拾えるなとか広げられるなとかまとめられるなとか、めちゃくちゃ頭いいんだろうなって思います。
しかもちょっと天然というかマイペースぽい感じが最高に推せます。
って人たちと働けてるのが最高です。

あと、この月にオフサイトで動いているみなさんに会えました。社内であったことあるひと3~4人しかいなかったので。
めちゃくちゃキョドってました。私。人見知りがひどくなりました。
やっぱり一度はちゃんと会うの大事。

12月 

ブログ 2本+25本

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

アドベントカレンダーが空いていたので、埋めるべく下書きから拾って書き足したエントリー。
テストする人。的に使ってた話だけど、テストなのかっていうのもあるけど。
テストだけする人ではないからいっかな。(どうかな)

adventar.org

今年もやってしまった。今年もうっかり11月30日に、明日からと思わず作ってしまった。
でも、アドベントカレンダーってこのくらいのちっこい話が アドベントカレンダーぽいんじゃってお気持ちあります。
私が完全に毎日何かいたか楽しみに開いていました。
まじで、アドベントカレンダー

って、去年も同じこと書いてたw

もう完結マンガはほとんど読んでいないので、来年するなら完結していないマンガもいれたらやってるかもしれません。

unsco.hatenablog.jp

今年は物欲少な目だったのかリピートが多かったのか・・・
載せてないけど、ネットでお洋服が買えるようになりました(そしてお気に入りだったお洋服ブランドがなくなったことにより、ほんとに物理的にお洋服を買 いにいくことがなくなっています)

来年はモニター買い替えとスマホあたりは買い替えそう。スマホ回りのものも。

ふりかえった

7本+25本のブログと、1つの登壇をしていたみたいです。

とにかく異動してからは仕事仕事だったようです。
自分からの発信だけじゃなくて、会社がここまで取り上げてくれたことはなかったと思うのでうれしいです。
来年は東京のオフィスにも出社してみるのもいいなぁと思ったりしています。

あ、あとカジュアル面談もしました。色んな人とお話しするのたのしいです。

社外活動のことを全く書いていませんが、いくつかのJaSSTに参加したのと
あとは運営の裏方をひっそり続けています。
あと、今年から テストの街葛飾 をこっそり聴いています。たのしい。

ost-zatu.connpass.com

そして気づいた。登録せずにこっそり参加してた。すみません。 来年もこっそり参加します。

来年はもうちょっと何かやるのかなどうかなって思います。めちゃくちゃライトな副業があると楽しそう。

ドキュメントのレビューを効率化しよう!~コメントと変更履歴の使い方~

qiita.com

5日目です。

昔に下書きに置いたままだったエントリーを加筆しました。

ユーザーマニュアルなど、何度もレビューと修正を繰り返すと、前回との差がわからずめんどくさいですよね。  

そこで、今回はドキュメントレビューで重宝するコメントの使い方と、変更履歴の使い方をします。 使っている方には当たり前かもしれませんが、私は数年前まで知りませんでした。

説明はGoogle Docsを使用していますが、Wordでも同様の機能があります。少しこのエントリーでも紹介していますが 気になったら調べてみてください:)

ドキュメントレビューで指摘事項を追加したい

「コメント機能」を使う

ドキュメントレビューを行うときに指摘する側(レビューア)が以下の手順を行います。 f:id:underscore42rina:20211206213305p:plain

  1. 指摘事項の範囲を選択する
  2. 「コメントを追加」をクリック
  3. コメントを入力する

コメント機能の利点

コメントに名前が自動記載されるので、複数レビューアがいるときや、再修正のときのやり取りが発生するときも、どちらのコメントかがわかります。 f:id:underscore42rina:20211206213455p:plain

※Office製品を使っていて、名前が表示されない方は コチラをご確認ください。

何度も修正があると、どこが修正箇所かわからない

やり直しを再レビューするときに、以前とどこが違うか最初から読みなおすのは大変です。

ここで、「変更履歴」を使い、効率的に再レビューをします。 これはWordの説明になります。Google docsは特に設定せずとも変更履歴を見ることができますが、 代わりに、「提案」機能を使うことで、レビューアが変更したものを残すことができます。

1.記録の用意

Officeの場合:変更変更履歴の記録

f:id:underscore42rina:20211206214046p:plain

校閲」-「変更履歴の記録(G)」をクリック

この状態で修正を行います。

Google Docsの場合

  1. 右にあるウィンドウをクリック 2 [提案]をクリック f:id:underscore42rina:20211206214950p:plain

2.修正をする

変更履歴の記録のまま修正すると、次のように修正内容がすべて表示されます。 f:id:underscore42rina:20211206214249p:plain

Wordの場合、
このままでは、修正に集中できませんので、 最終版 だけ表示するようにします。 f:id:underscore42rina:20211206214428p:plain

この状態でも変更履歴は記録されていますので、この状態で修正します。

Google Docsの場合はこのまま提案モードで変更することが多かったです。

3.再レビュー、または提案された内容を再確認する

再度「確認してください」と言われたレビューア、または、提案した内容を確認するレビューイは「承認」を行います。

(Wordの場合、始めるときは変更履歴の記録を「最終版:変更箇所/コメントの表示」を選択してください)

f:id:underscore42rina:20211206215328p:plain

修正内容でOKの場合、✓(Wordの場合承諾)をクリックすると
修正箇所の履歴が消えます。

おわりに

QAエンジニアやテストエンジニアをしていると、レビューをする機会もあるかなと思います。
私の場合、前職ではユーザー操作マニュアルを作成したり、現在は会社のブログを書く機会や、社外活動で記事を書いたりすることもありました。
ドキュメントのレビュー文化をするのに、今回のようなちょっとしたやり方を知っていると
少しだけレビューする方もされる方も楽になるといいなと思います。

ポジティブふりかえりマッピングをやってみたよ

qiita.com

の6日目です🎄

やったのは1年半くらい前なんですが、せっかくなのでブログに書いてみます(というか下書きにずっとあったので放流します)

ということで、ファシリテーションをやってみました。

参考にしたサイト

ふりかえりを拡張する「ふりかえりチートシート」 - Qiita

https://kawaguti.hateblo.jp/entry/2018/09/06/12542

qiita.com

選んだ理由とか

どうやって ポジティブふりかえりマッピングを選んだのか

ふりかえりチートシートを使用しました。
このチートシートは同僚に教えてもらったのですが、どんな目的でふりかえりをしたいかを考えるときに
より適切な手法を選びやすいっていうことがいいなぁって思っています。

今までは、同じもの(KPT)をなんとなく使い続けている(ベスト・セレクションかどうか悩みつつ)
のが悩みだったんですけど、このシートとともにふりかえりをしてもらって
なるほど、ちゃんとやりたいことにあわせて適切なものを選ぶといいのね!と思ったのでした。

なぜ ポジティブふりかえりマッピングを選んだのか

今回実施したチームは、定期的にふりかえりをやっています。(2020年当時)
そこではシンプルに議題・改善案をあげて、次のアクションを決めるような会になっています。

今回のふりかえりは、広い期間のふりかえりがしたいということと
いつものスコープは運用など限定されたものにフォーカスされていたので、もっと広いスコープで考えたい
いつも課題が多くなりがちで、みんなで褒め合うような会がしたいという理由で
ポジティブふりかえりマッピングを選んでみました。

成果

こちらです f:id:underscore42rina:20211206210051p:plain

だいぶ記憶が古いのですが、とにかくお互いをたくさん褒められて、次へのアクションが前向きに色々でてきた記憶があります。

おわりに

今回はQAエンジニア内でおこなっているふりかえりのひとつとして紹介しました。
ふりかえりをする機会が多い(と勝手におもっている)QAやテストエンジニアのみなさんの
ちょっとした機会になるといいなと思います。

参考

↑の画像は、以下のスライド資料から使用しました。 speakerdeck.com

キャプチャーツールのおすすめとつかいかた

ブログにまとめてなかったなーって思ったので、まとめ。

Windows: Screenpresso

www.screenpresso.com

最近WindowsのPCを使うことが本業ではないのでもっといいのがあるかもだけど、めちゃくちゃおススメです。

f:id:underscore42rina:20210630214722p:plain
Screenpresso

使っている様子はこのエントリーからいける動画をみるとわかるかもしれません。 ライブテスティングするときはいつも使っています。 underscore42rina.hatenablog.com

推しポイント

  • 無料でもかなり使える

    今は無料版で使っていますが、エビデンス作成であれば十分使えます。
    40ショットくらいごとに広告が表示されることと、一度確定すると前に戻すことができないことくらいです。
     とにかく操作が簡単にできるし、やりたいことへのストレスがないのが素晴らしいです。
     PrintScreenボタンでショットし、編集して、確定ボタンでキャプチャできるのはほんとに感動します。
     PrintScreen押す必要がある人はとりあえずいれてほしい。

  • 有償版(プロフェッショナル版)も買い切り4000円弱

 もしユーザーマニュアルを作るなど、画像変更があとで発生するような場合はこちらがおススメです。
 買い切りで4000円なので、個人利用でも買うのをおススメできます。

Mac : 標準

Screenpressoの反動なのか、他にいいツールも見つからなくて、標準のものを使っています。
スクリーンショットも動画も撮れるのでまぁいいか・・・くらいの感じです。
マニュアルを作ることも今はないので、そのくらいの熱量なのかもしれません。

[shift]+[command]+[control]+[4]で矩形選択のクリップボードコピーをするくらいです。標準のプレビューに貼って編集するくらいです。
ほとんどがエビデンスのために使っています。

iOS: 標準

これも標準のものを使っています。エビデンスをとるために使っています。

最近は動画もよく撮るので、ストレスなく使えていると思います。 support.apple.com

スクショ撮る→編集でマーカーでマークとコメント入れる→AirDropでPCに画像・動画を送るがなめらかにできるのはいいですよね。

今のところそれで満足しているので、他のアプリは使っていません。

Android : スクリーンショットは標準、動画はAZ Screen Recorder

play.google.com

前職からずっと使っています。 スクリーンショットについては標準でいいかな。と思ってそのままです。

AZ Screen Recorderも無料で使っています(有償もあるのかな・・?)

AZ Screen Recorderで動画撮る→シェアする→GoogleDriveに置く が多いです。
AirDropのように送れるといいけど、今のところはこれでなんとかしています。
Androidの端末によっては、GoogleDriveにアクセスするのがめんどくさくて、iPhoneで撮影することもあったりします・・・


この前参加したイベントで

jasst-nano.connpass.com

画面キャプチャーツールを使わずにあえて別のスマホで動画撮影をすることで、操作の指の動きを映すことができて、 相手に操作を伝えやすくできる

って発表を聞いて、なるほどたしかにそういう効果あるね!って思いました。

私の場合はエビデンス(PMやエンジニアに説明をしたいときに撮る)がとても多いので、
今回紹介したツールたちを使って効率的にエビデンスを取ることも大事ですが、
より伝えるためにはどう使うといいのかなって考えることも大切だよね。と思いました。

2年半のふりかえりとこれから

mobile.twitter.com

ということで2年半をふりかえるよ!

underscore42rina.hatenablog.com

これが入社、控えめに言ってひいた。(ほめてる)
濁流に呑み込まれたのかとおもったなぁ。
今ではすっかりslackの流量とスルースキルはみについた
海外からのエンジニアにもオンライン上は慣れたけど、直接みんなと会うと緊張するとおもう

OKRとか1on1てこうやってきめるんだーほーってなってたたぶん

underscore42rina.hatenablog.com

後半にプロジェクトのことやオンボーディングのこと書いてた。
あのプロジェクトが遂行できたのは、あのチームだったしAll for Oneだったよねってなった
めっちゃあれだけど、入社前なのにJaSSTのスポンサーのお願いも聞いてもらえて、メンターと長崎行ったのもよきおもいで。スポンサー対応のお願い諸々、お引っ越し前の博多オフィスだったなぁとか

underscore42rina.hatenablog.com

すっかり社外イベントもなくなったけど、自分の所属チームの人がはるばるやってきてくれたのよかったなぁ。
メンターが福岡社内で人気すぎて楽しかった
自社イベントに関わったのこれだけかもしれない

underscore42rina.hatenablog.com

当時最高のプロジェクトチームにいられたんだなぁと思うし、ここが最高だったなぁと。
自分の価値提供が一番できたのはこのときだったのではないかと、ふりかえるとおもうけど、それはテスターとしての力を使うことが多かったからだろうなって思います。

underscore42rina.hatenablog.com

ふりかえりここに書いてあった

半年ほど会社のことは書いてなかったけど、この間に、ボスとの出会いやら別れやらがありました。わたしとしては、スクラムマスターなQAとか、プロセスって何なのさとか今までしたことないことをやり始めてます、まだまだ少し落ち着いたけど、やる気に満ち溢れてますね。
スクラムは楽しくてつらかった

少しずつQAチームの何かもやってますね、クライアントリリースファシリは2年くらいやってたのかー

underscore42rina.hatenablog.com

ここにも少し書いてあるけど、大体そんな感じ。
会社のブログ書き始めたのが入社後半年くらいとかなんだって。

なんかこう目標全然達成してないなぁ。

underscore42rina.hatenablog.com

このブログの直後から、東京はおろか福岡のオフィスにすら行かない生活がはじまりました。
あんまりQAチームでの活動が出てきてないんですが、それでもたぶん、チームメンバーの何割の人とオンサイトで1on1してもらったりしてました。

なんかすごいわがままばっかり言ってたなぁ。
やる気のあるわがままだったけど、価値の提供ができたのかなぁとか思うことばっかり。

あと、社外活動のおもしろさを一番伝えられるはずなのに、ぜんぜんたりなかったなぁというか、伝えるの下手くそかって今でも思います。

underscore42rina.hatenablog.com

この頃からプロジェクト(開発チーム)から離れはじめて、QAチームのみんなとお仕事することが増えてきたみたいです。
というか、今まではプロジェクトの傍らでやっていたことが多くて、そりゃ大変だよねってなりました。
そう思うと、もしリモートワークじゃなかったら、私はいまよりもっと仕事が遅かったかもしれないです。恐ろしい。

そして、今のボスに割とちゃんと相談できるようになったのがこの頃なのは、こういう背景も影響してるのかもしれないなぁ。(それまでは連絡と近況報告でおわってた)

リモートワークを感じさせない働き方はある程度評価してもらえてたけど、新しい仕事を身につけるのに、自分だけリモートワークとかはかなりつらいだろうなぁ。

underscore42rina.hatenablog.com

そして2年のふりかえり。

ここからQAチームの改善活動を能動的にやるためのファシリテーションをはじめたり(これがまた難しい)そして、マイバディになった。誰かとペアで仕事を継続できるのっていいですね。

少しずつスクラムチームとかクライアントリリースファシリチームのビジネスパートナーとの働き方とかを書いたり話したり、テストの勉強会を社内の数十名の人たちにしてみたり、なるほどなんかアウトプット出してるかもしれない。
そして、わたしのモチベーションはアウトプットからのフィードバックで得られているのかもしれない。

そして、東京のスクラムチームのQAエンジニアとしても入り出した。とはいえ、あまりプロダクトに貢献できた気はしてない(もともとずっと長くいるQAエンジニアもいたし、ドメイン知識足りなさすぎて)
きたるべきときもあるかと、ただただたのしく仲良くしてもらっていた。あと、アジャイルコーチの話とかも色々聞いたり参加したりできて楽しかった。
今年くらいにどこかスクラムのことでプロポーザルだしたらいいのになぁ。

QAチームでの活動も色々やってたはずだけど、自分でやったやつは、イマイチな感じだった。わたしって。。、
他の人がリードしているチームに自分も入っていたけど、コミュニケーションの取り方とか、気の配り方とか、すごいなって思った。
この会社入って、自分より一回り若い人とか沢山いて、なんかすごく優秀な人だと、自分のポジションに応じたコミュニケーションの撮り方とか色々知っていて、なんか、すごいって思いました。
立ち振る舞い方ってどこで覚えるのだろう。立ち振る舞い方ではないのかもしれない。

underscore42rina.hatenablog.com

大体同じこと書いてるけど、このとき私は、今の会社でガシガシ成果を出したいことを半ば諦めていて、無理なく働いて、その分得意なテストを副業をはじめてみようそうしようってお気持ちでした。

そのときのお気持ち表明

そして数日後

それから、たまたまだけど、この3ヶ月はふりかえりの一環で、QAチームの人たちととにかくたくさん話した。いや、在宅勤務になってから私は確実に距離は縮まってったけど、色々人となりが知れて、そして、私がいかに色々見えてないかとか知ったなぁ。

そして本格的にplaywrightでE2Eを書き始めました。プログラマーが向いてなかったことを再び思い出しましたけど、ちゃんとレビューしてもらうってことがどういうことなのか体感できました、そして、ようやく少し普通にGithubが使えるようになったかもしれません。
ちなみにPRレビュー中のソースコードのURLの取得の仕方がまだわかっていません。

それから英語、約一年勉強して、苦手アレルギーは少しずつ治まっています。英語の発音が上手くても下手でもあまり気にならなくなってきました。 理解できなくても聴くことのストレスはかなり軽減されていて、ブログも翻訳版として英語で出せました。もちろんレビューがあるからこそなんで すが、出せたのはよかったです。
入社時の私からしたらめちゃくちゃすごいです。
あとGoogle翻訳の進化もめちゃくちゃすごいです!

ビジネスレベルには到底遠いですけど、千里の道も一歩からなので、ぼちぼちスタートに戻らないようにしたいです。

ってことで、このチームたちとの活動はしばらく抜けます!

mobile.twitter.com

今日からあたらしいチームの活動がはじまりまっす!わいわい

https://www.souzoh.com/_next/image?url=https%3A%2F%2Fapi.super.so%2Fasset%2Fsouzoh.com%2F8263ea58-2431-4ec4-9778-fb5fb728ebe6.png&w=1920&q=100

テスト実況生中継をしてきたよ

ちょっとだいぶ遅くなってしまったんですが、こっそり。

mabl-japan.connpass.com

で、テスト実況をしました。

実は2年前にも同じような内容で登壇したことがあって、

underscore42rina.hatenablog.com これも最後の方にYoutubeが公開されています。

今回も同じ感じで、でも今度は質問をしたりされたりしつつ進める形でやりました。
たのしかった。テスト・・・好き。
こちらも動画が公開されています。

us02web.zoom.us

この中で、質問に答えられてなかったなーっとか、ま、いっか。って言っちゃってるのがあったので、ブログに書いておこうと思います。

00:13:00 頃 Plansにある〇について

ここで違和感があったので、軽く聞いたんですが、違和感の説明は以下になります。

  • おそらくRadioButtonかCheckBoxだろうと予測はつくけどRadioButtonにしては各項目離れすぎていて、一般的なUIに見えなかった

通常だと、この画面のテストをすれば、ほんとに違和感なのか、なんか法則があるのかわかるので、そこではっきりさせます。
今回はここに気を取られると、NewPlanの画面にいけなさそう(他にも気になるところがたくさんでてきそうだった)だったので、止めました。
普段は止めないです。

00:20:00 頃 スクリーンショットを1枚にしている話

今回の発見だったんですが、今まで基本的に1枚の画像になるようにしていました。たぶん。
おそらく、Issueの報告って(バグ票)1チケットに1事象しかかかないので、
必然的にスクリーンショットもその事象にあうような1枚画像になるんじゃないかなと思いました。
たとえば、画面遷移とか今回みたいなスクロールしないと複数画像になるような場合でも、言いたいことを表現するのに1枚にしたほうがよく、編集していました。

スマホのテストとかになると、動画と画像の組み合わせも多いかも。

00:22:00 頃 アプリの機能のテストのとき、どのタイミングでどっから始めるか決めている?

フロントとバックと分かれて、実装タスクも細かく分かれているので、都度テストしている・・・かも?

ちょっと質問の範囲が広いかもしれないけど、自分が今やっているものとしては、
フロントエンドとバックエンドが明確にわかれているので、バックエンドで実装したもののテストとフロントエンドで実装したもののテストを
それぞれでやります。そのとき、実装した内容で確認したい点はことなるので、それぞれの気になる点のテストをします。
バッグエンドだとホワイトボックスぽいテストになるかなと思うので、探索的テストっぽい何かってイメージが自分はあまりないかもしれません。

今回のものも、バックエンドとフロントエンドがわかれていたら、そもそも 例の呪文使ってない可能性もありそうです🤔

underscore42rina.hatenablog.com

探索テストっぽい感じでやるときは、おさわり会とかの時間制限があるようなとき(そして自分が担当していないチームの機能)に
機能仕様の説明聞きながら、組み合わせたりして触っているときは探索してそうです。
感覚的には、デバッグしているときに似ているんじゃないかと思います。
でも大抵自分が十分にさわったーって思う前に時間がきてしまって消化不良になります。

01:13:21頃のコメント

CLOSEとCANCELの使い分けって、どんな気持ちなんだろう?()

実はこれ私どっちもCANCELだと思っていました!NICE QA!

正常系からするか異常系からするか 00:50:00

あとで異常系(ここではバリデーションメッセージが表示されるようなデータ)をいれるくらいなら 先にいれます。

なんでだろう・・・

あとで異常系するのが苦痛だからかもしれない・・・ でも、自分が作っていたときは異常系というものはあとでしていた気がします。

懇親会ででていたこと

「できないこと」を探すのは「できるようにする」ためですか? 「できないこと」を明確にするためですか?

解答したような気もするけど、これは「できないこと」を明確にすることがメインだと思います。でもちょっとこれも違うかもしれないです。
例えば、

  • Add Planでは、Test caseが指定できる

があった場合に次の説明は以下のどちらかになるはずです。

  1. Add PlanではTest caseを指定しなくても登録できる
  2. Add PlanではTest case を指定しないと登録できない

(後から参加者のコメントで知ったのですが、おそらく今回は2が仕様ぽい)

この場合、1でも2でも今の時点では仕様としておかしくないと(自分は)思うのですが、
この機能を知っていくと、2でないと機能的に満たされないとか、2の方がよいとかの背景があるんだろうなって思います。
でも、今の私の仕様理解だと、一番親のTestPlanが作れていいやん。って思っています。

なので、逃げ道がないように検算しているのにとても似ている気がしています。

柔道マンガの「YaWaRa!」に出てくる、フランス選手のマルソーとの闘いで *1
あらゆるマルソーの攻撃(YaWaRaに瓜二つの攻撃を得意としている選手)をひとつずつ交わしていって、もう手玉がなくなっちゃうって試合をするんですよ。
どんな攻撃だろうとすべてわかってかわせます。それが猪熊柔です。ってシーンなんですが、私はそんなイメージでいます。
そんな操作をしても、そのあとどういう動きになるかわからないがないって状態にしたいんです。

YAWARA! 完全版 (19)

なので、バグを探したいというより、わからないことが何もない、なぜできるのか、なぜできないのか、それが思惑通りか理解したい。という感覚です。

やり残したこと

基本的にCRUDのテストがしたかったのに、登録に行きつかなかった・・・・
自分が前に書いた
2回目のテスト(スクリプトテスト+探索的テスト、Issue確認) - テストする人。 まで本当はいきたかったのにいけませんでした。

ところで

今日(もう昨日かな)人類シリーズ第2弾が開催されていました。

mabl-japan.connpass.com

その中で(Ask the speakerかな)、「テストの自動化があればマニュアルテストはいらなくなるか」って永遠のテーマが話されていました。
私はもともと 自分のテストはなくなることはないだろうなぁと思っていましたし(前にどう共存するんだっけ?て話も書いています↓)

underscore42rina.hatenablog.com

今回のテスト実況をみても、これ自動化わざわざしない・・・よね?というものも多いなぁとあらためて思います。

ただ、今働いている環境においては、今回みたいなテストをする必要もないのかもしれないなって思っています。  
プロダクトの成熟度にもよるのかもしれないですし  
開発の場に、デザイナーがいるなど専門家が増える場だと、そもそも指摘することがなかったりもしますし
行動ログとかクラッシュログとかログがとれる環境で、すぐに修正してリリースできるのであれば
がんばって手動でテストして守る必要もないことも増えると思っています。

というわけで、現在のわたしとしては、どれをやればいいみたいなのは全くなくて この2年くらいは、手でするテスト以外のこともやらせてもらっているので なんかもっといい感じになれるといいなって思います。

*1:多分誰にも伝わらないんですけど