# タイトルコール ようこそ、世界が広がるソフトウェア編集生。 このチャンネルでは、エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストやソフトウェアの編集を中心に、日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、テストや編集の世界を広げていきます。 # 📣オフ会の企画進んでます 本編の前に一つだけオフ会の企画が進んでますよというお話をさせてください。 今ですね、プレミアムリスナーの方々と一緒にお話をしながら どんなオフ会がいいかなというところを企画しておりましてですね 今月中、10月中には何かしら日付と内容についてお話ししたいなという風に考えております。 内容が気になるなとか、ディスカッションに参加したいなという方は是非 プレミアムリスナーの登録お願いします。 # ソフトウェア開発・テストでのAI活用ログ こんにちは、サミィです。 お休みの方も多いでしょうか? 私は昨日の夜、工場夜景クルーズを見に行ってきました。 夫が新しいカメラを買ったんですよ。 それでいい写真を撮りに行きたい、いい景色を撮りに行きたいと思ったのかな? 私はあまり最初乗り気じゃなかったんですけど、 やっぱり行ってみたら行ってみたで、とても景色も綺麗だし、 ガイドさんの説明もすごく分かりやすくて楽しむことができました。 ということで、今回はソフトウェア開発とかソフトウェアテストでのAI活用のログといいますか、 最近こういうことをやってみて、こういうことを学んだな、感じたなというところを 3つぐらいかな、お話ししていこうと思います。 まず最初にその3つが何かというお話なんですけれど、 1つ目が影響範囲調査、2つ目が受け入れテストの作成、3つ目がテストケースレビューです。 順番にお話ししていきます。 1つ目が影響範囲調査なんですけれど、 ここでやっている影響範囲調査というニュアンスというのかな、 今回こういう開発をしますとか修正しますとかあると思うんですけれど、 実装する箇所というか画面とかはここら辺だよなというのがあって、 まず前提としてあって、その上で私の視点というか、 どこにも修正する箇所ってないんだっけみたいな観点でデビンを使いましたという話です。 デビンがいいのか他がいいのかというのはちょっとここの話ではしません。 今回の事例としてはデビンを使ったよという話ですね。 実際やってみたのがリポジトリ名ですね、pekepekeというリポジトリで、 これこれが表示されている箇所を洗い出してくださいというふうにデビンにお願いをしました。 するとソースコードベースで一覧を出してくれてですね、 プルリクの内容とか修正箇所とか等を照らし合わせながら、 ここって大丈夫なんだっけとかということを確認していました。 2つ目の話が事例が受入れテストの作成ですね。 ここで言っている受入れテストというのは、 Azure開発の文脈でストーリーを切っていて、各ストーリーごとの受入れテストですね。 何を確認できたらこのストーリーは完成と言えるのかという受入れテストを作っているわけなんですけど、 もう少し簡単にというか効率的に受入れテストを作れないかなと思ったのがきっかけです。 やってみたのはGeminiを使いました。 会社で法人プランなのかな、契約をしていて、 データが学習されないようになっているという前提ではあるんですけれど、 やったこととしてはPRDですね、今回こういうものを作りたいという要求が書いてあるものと、 あとFigmaをPDEVだったりスクショだったりを取って、それをGeminiにインプットをして、 あなたはテストエンジニアです、これこれというストーリーの受入れ条件を作成してくださいというふうにお願いをしました。 その出力の客観を読んでみて、叩き替えとしては良さそうだなという所感を受けたんですね。 もう少しそこからブラッシュアップとかをしていけばより良い受入れテストになったのかもしれないですけど、 今回はそこまでは確認していません。 ただ一方で思ったのは、インプット情報の質によってアウトプットも当然大きく影響されてくるので、 PRDがどのくらい詳細に書かれているかとか、Figmaがどのくらい情報量を持っているかというのによっても、 出てくる受入れテストの中身というのが変わってくるな、質も変わってくるなというふうに思ったので、 じゃあそこのCGIが出力しやすいようにインプットを一定整理するとか、情報整理するときちんと書くというのも大事かと思いつつ、 でもそれって本質なんだっけというふうに思っているというのが今の私の感想です。 続いて3つ目いきます。3つ目はテストケースレビューですね。 ここで言っているテストケースレビューというのは、手動のテスト、何かストーリーごとの機能テストだったり、 不具合修正の後に確認する、手動でも確認するテストのテストケースのレビューをさせています。 背景としては、これまで私がテストケースレビューをするときというのは、 修正の内容を開発者からヒアリングをして、その情報ベースになったりとか、あるいはプロダクトのナレッジとか、 この辺ちょっと不具合が起きやすいよねとか、あと他に関係ある画面がないんだっけ、関係ある箇所がなさそうだっけというところを、 自分の知識とかこれまでの経験とかを結構ベースにレビューしていることもあったんですけど、 そのテストケースレビューをするときに、ヒアリングの修正内容ではなくて、 もう少しコード上、コードの情報から、実際のどういう修正をしているところからというと、 この修正内容の解像度を上げたいなと思った。 こういう修正をしているからこういうテストが必要だよねという観点でもっとレビューできるといいなと思ったのが背景としてはあります。 使ったのはDevinです。 こちらもPromptとしては、「〇〇機能が利用できる画面を洗い出してください。」というので洗い出してもらって、 それとテストケースを見比べることもあるし、 あと他の事例としては、さっき手動テストのケースレビューというふうに言ったんですけれど、 自動で実行されるユニットテストのレビューというのもちょっとだけチャレンジしてみたことがありまして、 その時はプルリクのURLというんですか、そのテストコードが書いてあるURLをDevinに渡して、 このリンクのテストの内容をテストエンジニア向けに解説してくださいという形でお願いをして、 このテストコードで何を確認しようとしているのかというのを解説してもらったことがあります。 例えばその時のテストとしては境界値分析が、境界値でのちゃんとテストが行われているかどうかがすごく大事な部分だったので、 境界値分析の観点から不足のある内容はないですかというところを追加で聞いて、 ここら辺のテストはありますね、でもちょっとこの辺の異常系のテストとかあるともっと安心ですよみたいな具体的な提案をしてくれたので、 これもうまく使えるんじゃないかなというふうに実感というか感じはしました。 そしてここから最後をまとめと言いますか、まとめですね。 CCIの活用というのはソフトウェア開発とかソフトウェアテストという文脈で少しやってみて、 どういう効果が期待できるのだろうかというのを私なりの言葉で考えてみると3つあるのかなと思っていて、 1つが新しい価値を生むことができそうだ。そして2つ目が効率化ができそうだ。 そして最後3つ目が質を高めるということがこの3つが期待できるんじゃないかなというふうに思っているんですね。 もう少しお話をしていくと、例えば新しい価値というとこうなんですけど、 これまで私が何かレビューをするとか、テストのレビューもそうですし、 いつも開発担当者に今回どういう修正をしたんですかというのを聞いていたんですよね。 なんですけれども、今回Devinを使うことによって開発担当者に直接質問せずとも自分で理解できること、 見れる部分がものすごい増えたんですよね。 これって新しい価値というふうに言えるんじゃないかなと思うんですね。 今まで自分一人だとできなかったことが少しできるようになるという部分が1つですね。 2つ目は効率化。 こちらは結構イメージつきやすいかもしれないんですけど、 ここまでの例でお話をすると受入れテストを作るというのが、 ジミニーとかセシアを使うことによってより短い時間で叩き材をまず作れることができる。 それをベースにブラッシュアップしていくというところで、1つ効率化という効果がありそうだなというふうに思います。 そして最後3つ目が質を高めるです。 画面の洗い出しをしてもらって、自分の思っていたものと比較をして何か漏れていたものを見つけるだったりとか、 既にある成果物というか、例えばテストコードだったりテストケースというものをレビューしてもらって、 これこれという観点、例えば境界値分析の観点とか、あとセキュリティの観点とかで不足なるテスト観点ありませんかみたいな感じで、 よりテストケースだったりテストコードの質を上げていく、質を高めるというところもセシアの活用によって見込めるんじゃないかなというふうに考えております。 ということで今回はソフトウェア開発テストでのAI活用ログということで、やってきたこととか考えたことについてお話をしてきました。 ぜひぜひこういうふうなやり方もあるよ、やってみたよとか、こんな学びあったよとかありましたら共有していただけると、 私の学びになりますし、他のリスナーさんの学びにもなりますので、コメント欄積極的に書いていただけると嬉しいです。 # #299のコメント返し🥰 コメント開始のコーナーです。今回は299話目、AIが作ったテスト、あなたは信じますか?のコメントを開始します。 コメントはNASテストさんからいただいております。いつもありがとうございます。 さて、2つの対談、とても楽しみです。私も思考を深めるきっかけとして活用しています。 まず、ベースを作ってもらい、対話しながらブラッシュアップする形です。 テストデータ生成やチェックツールも生成AIで作成し、最終確認は人が行いますが、仕事のスピードは向上しています。 JSTQVシラバスのような基準を与えて思考の基盤を作るアプローチは良いですね。 AIに基準やプロダクト、特有のナレッジを丁寧にインプットすることがとても大事なので、 共有いただいたQAナレッジのような仕組みは素晴らしいですね。ということで、コメントありがとうございます。 対談、いよいよ明日です。 確かに、まずベースを作ってもらって対話しながらブラッシュアップする形っていいですよね。 私も例えば発表用のスライドを作る時とかも、ベースをまず作ってもらう。 自分がなんとなく伝えたいことを言葉にして、それをベースに生成AIでスライドの構成とか、 スライドの構成と、あと中身かな、スライドの各スライドで何を書くかというところを作ってもらうんですけど、 それを見ながら、ちょっと違うなとか、もっとこうしたいなというところをブラッシュアップしていくということをやっているので、 確かに、それがスライドの作戦とかじゃなくて、他の活用の時でもできるのかな。 あとは、JSTC Bのシラマスとか、これに沿ってますって言えるときっといいんだろうなと思いつつ、まだちょっと全然できてないですね。 ということで、コメント開始でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、Voicyのトークテーマ、 「ひそかに続けている良い習慣」についてお話をしていきます。 今回の放送を聞いて、 なるほどな、確かにな、学びになったなと思った方は、 ぜひ画面右下、ハートマークでいいねを押していただけると、 とっても励みになります。 ぜひぜひフォローもよろしくお願いします。 それではまた明日お会いしましょう。 ごきげんよう。