オープニングと自動テストを書く3つのきっかけ
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QAエンジニアである私、ブロッコリーが、テストや品質に対する私内の考えを、約10分間で語っていくポッドキ
ャスト番組です。
先日発表されましたけれども、毎年2月ごろに行われるDevelopers Summit、通称DevSummitですね。
そのイベントのコンテンツ委員となりました。今回で3回目になります。
これは別に、自分がなりたいと言ってなれるという話ではなくて、運営している商業者さんから、今年もどうですかというふうに声をかけていただいて、それでやりますという感じになっています。
このコンテンツ委員の主な仕事なんですけれども、プロポーザルの選定になります。
皆さんにいろいろ書いていただいた、こういうテーマで登壇したいと表明してくれたものを一つ一つ選定して、このプロポーザルだったらぜひ発表を聞いてみたいというのを選ぶというのが仕事になっています。
このイベントってプロポーザルいっぱい来るんですけれども、その中でより良いプロポーザルにするには、みたいなところについては、10月30日でしたかね、プロポーザルについての話すイベントも予定されている
ので、気になる方は概要欄にリンクを貼っておくので見てください。
ということで、今回もbtesting.fmスタートです。
今日本編は自動テストの続きになります。自動テストを書くきっかけ、どういうきっかけで自動テストって書くといいのかなっていうところを話していきたいと思います。
自分が思う自動テストを書くきっかけっていうのは、主に3つあるかなと思っています。もちろん新規で書くっていうのは全然ありだと思うんですけど、それ以外に3つ今回は紹介したいなと思っています。
実装内容に迷ったときのテストファースト
その3つっていうのは、何を実装すべきか自分でも迷っているとき、そして結果を修正するとき、そして同じことを繰り返し実行しているときっていうのが自動テストを書くきっかけかなと思っています。
一つずつ言います。まず一つ目がですね、何を実装しているか自分でも迷っているときです。
これ何言ってるかというと、そもそも何作るかちょっと固まってないまま実装を始めちゃうと、じゃあそもそもそれがどこまでできたら完成なのかっていうのも決まってない状態になるんですよね。
なのでそういうときこそ、先にこうなったら成功するよっていうテストを書いてみるっていうのがいいかなと思います。
そうすると何を実装すべきか自分でも迷っているということは、テストを書いてみたときに、あれ、そもそもこれってどういうテストを書けばいいんだっけっていうのを考えるきっかけになって、それが何を実装すべきか
っていうところの方針にもつながっていきます。
しかもその状態でテストを書くので最初は失敗している状態になるので、じゃあこのテストは成功するようにするためにはどういう実装にすればいいんだみたいな、まさにテストファーストな考え方ですね。
テストから先に考えるというやり方につなげることができるかなと思っています。
欠陥修正と再発防止テスト
続いてがですね、欠陥を修正するときです。
これは何を言っているかというと、特にリリースした後にお客さんに使ってもらって、その時に欠陥が見つかったとき、何かしら修正をしないといけないときっていうことになります。
これってリリースした後にそういう欠陥に気づいているっていうことはどうなるかっていうとですね、それってリリース前のテストをすり抜けてしまった証拠なんですよね。
なので本来はそこにあるべき失敗するテストっていうのがなかったから、リリースの前のテストの段階でも気づけずにリリースしてしまって、その後に欠陥として出てきたみたいになるわけですよね。
なので欠陥を見つかった、ただ直すっていう話だけではなくてですね、欠陥を見つかったときに、じゃあこれを再現するような失敗するテストっていうのをあえて書いてみて、欠陥を再現させるっていうのを試しっていう
のは必要かなと思っています。
そうすることによって、二度と同じ箇所での欠陥が起こらなくなるわけですよね。
以前にソフトウェアテストの7原則でも話した通り、欠陥の偏在という言葉があります。
欠陥が起きやすい場所っていうのは、まんべんなくあるわけではなくて、特定の場所にあったりするという話になります。
なので欠陥が見つかったっていう風になったら、それを再現させるテストをすることで、次も同じ欠陥を作り込む可能性は大いにあるとは思うんですけれども、その時にそもそもその自動テストが失敗する。
じゃあこれ危なかったねっていう風に直せるっていう良いサイクルになるので、欠陥を修正する時っていうのはまさに自動テストを書くきっかけになるかなと思っています。
繰り返し作業の部分自動化
最後3つ目ですね。同じことを繰り返し実行したい時っていう話です。
同じことっていうのが全て同じであるっていうのは結構珍しい稀なことだと思うんですけれども、実は普段の業務の中でも部分的に同じところっていうのはあったりすると思うんですよね。
最後の操作だけ違うみたいな、そういうものがあったらその最後の操作に至る直前のところまでっていうのは自動化するきっかけになるかなと思っています。
でこれを一つ、普段の業務っていう話だけではなくて、日常の中での自動化っていうところも考えています。
皆さん、毎朝どうやって起きますかね。起床するときってどうやって起きるかっていうと、大抵の方、例えば携帯のアラームをかけて起きるみたいなことをしてるんじゃないでしょうか。
この携帯のアラームをかけるっていうのはまさにこれ自動化してる証拠なんですよね。
毎朝起きるって言った時の自動化って考えてみると、ベッドが勝手に起き上がってて、手を広げるだけ自動的に着替えまでさせてくれるみたいなのは確かに自動化になるかもしれないんですけど、それは非現実的かなと思
っています。
で、その代わりベッドが勝手に起き上がる着替えるみたいなところは自動化してないにしても携帯のアラームみたいな決まった時間に音を出すっていうこと自体は自動化ができているわけですよね。
こういうふうに全ては同じことを自動化するのは難しいにしても、その決まった時間に音を出すみたいな部分的に毎回繰り返しているものっていうのは自動化できるきっかけになるかなと思っています。
で、じゃあ普段の業務のところで言うと、例えばデータを数百個作らないといけないみたいな、そういうデータを作るところまでは自動化で自動作成しますと。
で、作成した後の状況の確認は手動で行うみたいなそういうことができたりするかなと思います。
他にもとあるアプリゲームの話で聞いたことがあるのは、ゲームのアプリにおいて実際の端末、シミュレーションではなく実際の端末上でスーパーレアとかSSRとか、
そういうすごいレアな時をガチャで排出した時の挙動を確認したいみたいなそういうもの、しかも実機でっていうところを考えると、そのSSRの排出するまでをガチャを回し続けるみたいな、そういうところは自動
でやれるかなと思っています。
で、それを排出した時のSSRが出たって決まったらその瞬間に自動化を止める。で、そこからは手動で確認するみたいな、そういうふうな使い分けができるかなと思っています。
まとめとエンディング
ということで、この同じことを繰り返し実行するっていうのが最初に言った通りすべて同じっていうのは稀なんだけれども、ここまでは毎回一緒でしょと、毎朝決まった時間で音を出す、データを数百個作る、ガチャを
回し続けるみたいな、そういうところ、同じことを繰り返し実行したい時っていうのは自動化するっていうところがあるかなと思います。
ということで、今日は以上3つですね。自動テストを書くきっかけ、何を実装すべきか、自分で迷っている時、そして結果を修正する時、そして同じことを繰り返し実行したい時っていうのは自動テストを書くきっかけにな
るかなと思います。
ではエンディングです。 btesting.fmではリスナーさんからのお便りを募集しています。エピソードの感想や、私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。投稿フォームは番組
概要欄にあります。また、エピソードの感想は、ハッシュタグBテスティングでXのポストをお願いいたします。
今日の話でいうと、自分らの自動テストを考えるきっかけ、タイミングについて話してきましたけれども、他にもこういう時に自動テストって考えるんじゃないみたいな、そういう話があれば、ぜひ投稿をお願いします。
もしもこれからも聞きたいという方は、お手持ちのPodcastアプリで番組のフォローもお願いします。最新回が上がった時にすぐに気づけると思います。
このBtesting.fmは基本的に毎週月曜日の朝投稿、公開をしていますけれども、それ以外の時にも公開されるかもしれませんし、月曜日公開されているの忘れちゃったとかならないようにするためにもフォロー
していただけるとすぐに気づけるかなと思っています。
ということで今回はここまでです。それではまた次回。バイバイ。