# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # 期待のルーキーに選出されました✨ Qエンジニアのサミーです。 とても嬉しいことがあったので、ちょっと本編の前にお話をさせてください。 Voicyの人気チャンネルランキング、 2024年12月期待のルーキーカテゴリーで選出いただきました。 パチパチパチパチパチ。 12位というところで、私12位という数字とても好きなので、 12月ですし、第12位ということでとても嬉しく思っております。 彼もいつも聞いてくださる皆さんのおかげでございます。 表彰があるのはもともと知っていたんですけれど、 まさか自分が選ばれると全然思っていなかったので、本当に嬉しいです。 # フィジビリティスタディからPoCへ ということで、本題に入っていきたいと思います。今回はですね、Mobileという、いつい自動テストのツール、テストを作って実行するツールがあるんですけど、それを使っていてですね、 フィジビリティスタディからPoCにした方がいいな、変えた方がいいなと思ったという話をします。 まず前提のところでフィジビリティスタディとPoCとは何かというお話をします。私自身もつい今週ですかね、 その違いをちゃんと知った感じはするんですけれど、まずフィジビリティスタディというのが、グロービス経営大学院のMBAを募集によると、 新規事業などのプロジェクトの事業化の可能性を調査すること、実行可能性、再産性などを調査するというふうに書かれています。 要はですね、新しく考えたプロジェクトといいますか、計画に対してそれが実現できるのかという実現可能性を調査するのがフィジビリティスタディになります。 一方でPoCはこのように書かれています。プルーフオブコンセプトの略で概念実証を意味する、ビジネスの構想段階にある新しい概念や方法などが、 それらが意図した通りの有効性を発揮できるか、そもそも実現可能性が高いのかということを簡易的な実験環境を用意して検証することだそうです。 フィジビリティスタディとPoCの一番の違いというと、フィジビリティスタディのほうは調査がメインであるのに対して、 PoCのほうはプロジェクトの計画の段階でちょっと作ってみるといいますか、実現可能性というところを簡易的に実際ちょっと触ってみる、やってみる、実行してみるで検証するということを指しています。 言葉の意味の違いを説明をしたところで、この後からは実際につい自動テストの導入といいますか、計画というところをしている中で考えたことをお話ししていきます。 まずKチームのロードマップの中に4つほど活動の柱があって、その1つがいついの自動テストなんですよね。 なので、他の業務もやりながらいつい自動テストのプランニングを開始しました。 いつい自動テストの目的を決めたり、コンセプトだったり、あとROI、費用対効果というのをちょっと簡単に計算を出してみたり、メトリクスどうしようかとか、あとスコープですね。 まず最初に自動化すべき機能はどの辺なのかというところを機能を洗い出して優先度をつけたり、みたいなことをしていました。 そのプランニングの一項のアクションとしてフィジビリティスタディというものを考えていました。 もちろんいつい自動テストの推進というのは必要ということは分かっていて、それをいろんな会社の今の状況というところを鑑みながら今やるべきなのかどうかというところを考えたいという思いがあって、 フィジビリティスタディ、実現可能性というところを確認したいなというふうに考えていました。 いろんな書籍を読んだり、インターネットで情報を探していたりしていたんですけれど、どのくらいテストスクリプトだったり、テストケースを作るのに時間がかかるのかというのがちょっとイメージがつかないし、 あと本だったり社外の勉強会でこういうことを気をつけた方がいいとか、導入だったら最初に2ヶ月ぐらいでわっと成果を出した方が協力者は安いですよとか、テストの独立性ですね、他のテストに影響しないように繰り返し実行しても同じ結果になるようにしましょうねとか、 知識としては知っているんだけれど、じゃあいざ自分のプロダクトでやるといったときに、具体的にどうしたらいいんだろうみたいなところの解像度が全然上がらないなというような課題感がありました。 なのでツールの選定というんですかね、どういうツールがモバイルアプリ、ネイティブアプリに対応しているのかというところをいくつか調査をしていく中でトライアルでツールを使うことができるので、 いくつか機能を実装、テストを作って実行してみるということをやってみようと考えたわけです。 実際にツールを使ってみて、いろんな問題が見えてきたわけですね。問題といいますか、例えば最初アプリへのログインのテストを作ったわけなんですけれど、 例えばメールアドレスでログインする場合、アドレスを入力してパスワードを入力してログインボタンを押す。そうするとホーム画面に遷移するという形ですよね。 で、キャプチャーアンドリプレイの機能がある。今回はMableを使ったんですけれど、キャプチャーアンドリプレイの機能なので、ポチポチ操作をして結構テストを作るのは一瞬でした。 いざ実行ですね、クラウドラウンをしてみたらですね、フェールで落ちるわけですよ。見ていくとどうやらテストの速度が速すぎてですね、画面が描画される前に メールアドレスの入力欄を探しに行って、そんなエレメントないよというふうに落ちてました。それを見て、これがよく社外の勉強会とかで聞くWait Untilを使うパターンか、みたいなのを実感したわけです。 あとはですね、ログインが成功したとして、そのテスト上、Mable上で何を持ってログインできたというふうに判断するのか、アサーションするのかというところも考えないといけないんだよな、みたいなところも改めて実感しました。 これらの経験、学び、気づきというところを実感したので、少しツールとか触ってみる、実行してみるというのは本当に大事なんだなというところをすごく強く実感しました。 なので当初はフィジビリティスタディをしようというふうに考えていたんですけど、フィジビリティスタディじゃなくて、POCをして実現可能性というところをしっかり見極めるといいますか、どうやったら実現できるのかというところを考えていきたいなと思っております。 # #33のコメント返し🥰と帝国ホテルのバイキング🍽️ コメント返しのコーナーです。今回は33話目のコメント返しをします。 1週間前の33話では、祝放送30回&誕生日ということで、収録開始1ヶ月を振り返りました。 コメントは一見いただいています。 みずけんさんです。いつもありがとうございます。誕生日おめでとうございます。 帝国ホテルのランジとはすごいですね。また放送30回後へおめでとうございます。 継続して配信し続けたり宣伝したりと大変だと思いますが、引き続き楽しみにしていますので頑張ってください。 というコメントをいただきました。ありがとうございます。 最初1ヶ月、33話目、4話目ぐらいまでは結構努力して継続するということをしていたんですけど、 35回過ぎてからはですね、こうやって収録をするのも楽しくなってきています。 引き続き楽しみながら配信を続けていきたいと思います。 あとですね、帝国ホテルのランチ行ってきました。どれもめちゃくちゃ美味しかったです。 帝国ホテルといえばローストビーフが有名で、久しぶりに食べてやっぱりすごい美味しくて2枚ほどペロリと食べたんですけど、 あと北京ダックとマンゴープリンが個人的には一番美味しかったです。 平日の1時半からという遅い時間だと2000円くらい安くなったと思うのでウェブ予約をお勧めします。 ということでコメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回は本ですね、その仕事を全部やめてみようという本を読んで考えたことをお話ししようと思っております。 今回の放送を聞いて、なるほどな、確かにな、学びになったな、と少しでも思った方は、 画面右下ハートマークでいいねを押してください。 ぜひフォローもよろしくお願いします。 1月29日の夜8時からは生放送も行えますので、ぜひお楽しみに。 それではまたお会いしましょう。ごきげんよう。