ちょっとだいぶ遅くなってしまったんですが、こっそり。
で、テスト実況をしました。
実は2年前にも同じような内容で登壇したことがあって、
underscore42rina.hatenablog.com これも最後の方にYoutubeが公開されています。
今回も同じ感じで、でも今度は質問をしたりされたりしつつ進める形でやりました。
たのしかった。テスト・・・好き。
こちらも動画が公開されています。
この中で、質問に答えられてなかったなーっとか、ま、いっか。って言っちゃってるのがあったので、ブログに書いておこうと思います。
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が指定できる
があった場合に次の説明は以下のどちらかになるはずです。
- Add PlanではTest caseを指定しなくても登録できる
- Add PlanではTest case を指定しないと登録できない
(後から参加者のコメントで知ったのですが、おそらく今回は2が仕様ぽい)
この場合、1でも2でも今の時点では仕様としておかしくないと(自分は)思うのですが、
この機能を知っていくと、2でないと機能的に満たされないとか、2の方がよいとかの背景があるんだろうなって思います。
でも、今の私の仕様理解だと、一番親のTestPlanが作れていいやん。って思っています。
なので、逃げ道がないように検算しているのにとても似ている気がしています。
柔道マンガの「YaWaRa!」に出てくる、フランス選手のマルソーとの闘いで *1
あらゆるマルソーの攻撃(YaWaRaに瓜二つの攻撃を得意としている選手)をひとつずつ交わしていって、もう手玉がなくなっちゃうって試合をするんですよ。
どんな攻撃だろうとすべてわかってかわせます。それが猪熊柔です。ってシーンなんですが、私はそんなイメージでいます。
そんな操作をしても、そのあとどういう動きになるかわからないがないって状態にしたいんです。
なので、バグを探したいというより、わからないことが何もない、なぜできるのか、なぜできないのか、それが思惑通りか理解したい。という感覚です。
やり残したこと
基本的にCRUDのテストがしたかったのに、登録に行きつかなかった・・・・
自分が前に書いた
2回目のテスト(スクリプトテスト+探索的テスト、Issue確認) - テストする人。 まで本当はいきたかったのにいけませんでした。
ところで
今日(もう昨日かな)人類シリーズ第2弾が開催されていました。
その中で(Ask the speakerかな)、「テストの自動化があればマニュアルテストはいらなくなるか」って永遠のテーマが話されていました。
私はもともと 自分のテストはなくなることはないだろうなぁと思っていましたし(前にどう共存するんだっけ?て話も書いています↓)
underscore42rina.hatenablog.com
今回のテスト実況をみても、これ自動化わざわざしない・・・よね?というものも多いなぁとあらためて思います。
ただ、今働いている環境においては、今回みたいなテストをする必要もないのかもしれないなって思っています。
プロダクトの成熟度にもよるのかもしれないですし
開発の場に、デザイナーがいるなど専門家が増える場だと、そもそも指摘することがなかったりもしますし
行動ログとかクラッシュログとかログがとれる環境で、すぐに修正してリリースできるのであれば
がんばって手動でテストして守る必要もないことも増えると思っています。
というわけで、現在のわたしとしては、どれをやればいいみたいなのは全くなくて この2年くらいは、手でするテスト以外のこともやらせてもらっているので なんかもっといい感じになれるといいなって思います。
そんなわたしは、黙ってテストコードを書いていました。Passした。わーい。
— リナ? (@____rina____) 2021年1月21日
*1:多分誰にも伝わらないんですけど