あ、今やっちゃいますね〜

adventar.org

23日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

今日のタイトルは、あさかいのファシリをしているときによく私が言っている言葉です。 あさかいではいつもJIRAの Active Sprintというタスクボードを眺めながらあさかいをしています。 そのときに、実際にタスクが完了しているのに、DONEにしていないというようなことがよくあります。 （他にも着手しているのにTODOのままだったり）

これを言うと「あとやっておきます」と言われることが多かったりします。 今みんなの時間を止めてまでとか、自分のことなので自分でやるのは当たり前だからってお気持ちからだとは思うのですけど、 私はその場でやってしまいます。

変更量が膨大でそれだけで10分かかるとかであれば各自にやってもらうとかするかもだけど 少なくとも1分以内、大体数秒〜数十秒で終わるのでそれであれば今この場でやってしまったほうがいい あとでやるっていっても忘れることも多くて そうすると、また明日のあさかいで同じことを聞くはめになるし、プロジェクトもチケット上動いてないことになってしまいます。

ということで、私は少しでも前に進めたいので、今やっちゃいまーす　って言ってやっています。 チームでうまく動けるなら、今やっちゃっていいと思うこといっぱいある。

アルバイトの学生エンジニアにテストを教えると、そのあともテストを気にするエンジニアになった

adventar.org

22日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

タイトルの通りであまり深い話はないんだけど。

昔働いていた会社では、大学生のアルバイトや、今のインターン学生みたいに内定前だったか内定者だったかのエンジニアが いたんですよね。

そのときに、私の仕事のヘルプをしてくれていて、 その後そのままその会社のエンジニアになった人もいて（先に内定決まっていたかもしれないけど忘れた）

その会社はフルスタックエンジニアになってもらうんだったけど 彼らはすごくテスタビリティだったり、UI E2E（当時はCabibaraだったかな、とか）を導入したりして すごくテストに対する取り組みをしようとしていたなぁと時々思い出します。

当時の私のテストは、たぶんExcelのテンプレートファイル渡して あまりちゃんとテストって教えてない（教える技術がなかった）けど 一定彼らのエンジニアのキャリアの１要素として役にたっていたならうれしいなぁと思いました。

割とカジュアルにチケットを切っちゃう

adventar.org

21日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

今の会社で初めてQAエンジニアというかテストをする人たちと一緒に働いているんですけど 私は他の人に比べてかなりカジュアルにチケット切っちゃうみたいです。

いや、だって忘れるんだもん。

他の人を見ていると、Slackで状況確認して、これは不具合でチケットあげたほうがいいですね！ってなってから書くことも多いみたい。 もちろん不具合って一発でわかるものならチケットすぐに書くのだろうけど。

私は、いわゆる仕様バグもだし、カイゼンでも気軽にチケットを切ってしまう。

忘れない？（２回目）あと、Slack過去の探すより、チケットでトレースできたほうが早くない？

しないなら却下にすればいいからいいと思うんだけど、嫌なお気持ちにさせてしまうこともあるので そっかーと思って　バグチケットにするかどうかはちょっと考えるようになりました。

でも、チケットをもっとカジュアルに作れるといいなって思います。

なんでチケットって切るっていうんだろうね

テストプランって大事なんだなーって話

adventar.org

20日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

昨日に引き続いて、テストプランの話。

いや、大事なことなんて5年以上前からわかってはいたんですよ。 とはいえ、なくてもそんなに困んない世界にいたんだなーって思っています。今。

今までは、手の届く範囲の開発組織や、QA組織にいたので、話したり任されたりで特に困らなかった。 一時期書いてみたりもしたけど、結局運用するほど大事なものには昇華できてないとおもいます。

それがいま、書かないと何度も同じ話をしないといけない状況になっている。 なので、書いています。 やっぱり、気にする（が実行者じゃないとかその組織ではない）人が多いと ここを見れば書いてあるって状態にするのがめちゃくちゃ大事だなって思っています。大事や。

どういう組織やプロジェクトで働いているかに依存もするなぁという感覚なんだけど 私は当面 10minites test planは書けそうにない〜〜〜　毎日が 10 minites test plan〜〜〜

はじめて書くテストプランもちゃんとしたフォーマットがあれば大丈夫！そうISO/IEC/IEEE 29119とChat GPTがあればね！

adventar.org

19日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

タイトルのとおりです。

わたし、今までちゃんとテストプラン書いたことないんですよね。書いても自分だけとか、自分と自分のPdMだけが見るくらいものしか書いたことがない。 でも、今回ちょっとちゃんとしたテストプランを作成することになって。

そこで登場するのがChatGPTさんです。 会社には社内で使える、つまり社外秘情報をいれても大丈夫なChatGPTがあります。（ChatGPT-4)

今回ちゃんとテストプランを書くために、オリジナルのテンプレートとかじゃちょっと自信も持てなかったので、 ISO/IEC/IEEEE 29119-3 に則って、それをベースにChatGPTに草案を書いてもらっています。

めちゃくちゃ心強い。

もちろん、そのままでは実際と異なっている部分や不要な部分、足りない部分もあるんですけど 文章も書いてもらえるので大変ありがたいなってお気持ちです。

たぶんオリジナルのでもそれらしいのを出してくれるんだと思うのですが、29119って標準のものを出すことによって 先回りして項目を出してもらえるのがめちゃくちゃよかった。

未来すごい。

再現確認をするときってキッチンに行く時のお気持ち

adventar.org

18日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

再現確認をするときも大きく二つあるような気がします。 狙った動きをして不具合を見つけたとき もう一つは、割と無意識に動かしていて、ん？あれ？おかしい気がする　とか、何もしてないのに壊れた（そんなことはないのに稀によくある）　みたいなときです。

前者の場合は、手順も記憶しているので、再現手順は同じ手順をするだけなので特に困ることはないんですが、 後者の場合は、無意識に引き起こしているので大変です。

例えば、キッチンにきたのに、何でキッチンにきたんだっけ？を思い出す過程と同じです。 もう一度自分の部屋に戻って、再びキッチンに歩いてみて、キッチンへの用事を思い出すような感じです。 その場合、思い出せればいいんですけど、それでも思い出せないときもあります。

テストするときも私は一緒で、無意識すぎてわからないときもあります。 自分だったらこう考えて、こう操作するなーって思い出すことも多いですけど。

それでも思い出せなかったら一旦放置しています。それで見逃した不具合もあるかもしれません。ごめんなさい。

リナ流テスト設計方法 4 バックエンドが入るようなところの設計のやり方

adventar.org

17日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

リナ流設計方法

www.jasst.jp

で話した話をもうちょっと切り取って書こうかなというお気持ちになったのでちょっと考える

長くなりそうだったら途中でやめるかも。

この書き方は自分がむかしっから書いている基本スタイルです。 前提として、私は画面を操作するようなシステムやサービスのテストをすることが多いです。

カテゴリーとしては大きく３つあります。

• デフォルトの表示系
• 動作系でもバックエンドの操作がないまたはほとんどなさそうなもの
• 動作系

バックエンド・つまりロジックや更新・画面遷移などもりもり

もりもりすぎてわけるかも

• 仕様書が書いてあるなら、一旦？上からまずはうつす（いわゆるCPM法と言われていた方法。大体良くないと言われる方法です）

• 日本語を噛み締める だいたい噛み締める必要があるものは、絵を描きたくなってくる ここで仕様の検討不足（仕様バグと呼ばれたりもする）がでてくるので、PMに確認する

• うつそうとすると、日本語なんか整理されてそうでされてないところにでくわす

• ひとまず仕様は一番シンプルな大きさに分解する

• その次に組み合わせ（複数同時に実行されうる）を一番シンプルな大きさで書く
  ** だいたいそのときにデシジョンテーブルをつくる

• テストデータの作り方などの疑問がでてくる　エンジニアに相談する

• いけるかなと思ったら一旦おわり 　だいたいいけてないことがテストするとでてくる