「一意な値」パターンのテスト設計を考える

ユーザーネームとかで重複を許容しない場合に、
1. すでにAがある時に別の人がAを登録しようとする
2. BさんがAに変更しようとする
3. Aを削除してから別の人がAを登録しようとする
の3パターンは検証しないといけないと思う。
ただ、そういう話はテスト手法？としては体系化されてない気がする。

— Hideo Oide🍜 (@hide_ramen_san) 2024年3月28日

おいでさんのツイを見て、「あっ、これ！」と思いました。
テスト設計技法って、たとえばデシジョンテーブルテストとか状態遷移テストなどいろいろありますが、「テスト対象として割とよく遭遇する割には、”テスト設計技法”みたいな形ではまとめられていない」ケースがけっこうある気がするんですよね。

おいでさんの例は、シンプルでわかりやすいので、自分がどう考えているのかを整理してみました。

サマリ

• ありがちな仕様なのに、テスト設計の定石がそこまで広まってないものがある気がする。
• 「一意な値」パターンは、CRUDとライフサイクルの2つを考えるとよさそう。
• テスト設計は、仕様の曖昧さを減らすことのできる活動である。早く始めよう。
• 思いついたケースを無造作に追加していくのではなく、そのケースからテスト観点を逆導出すると、網羅性が考えやすくなる。

対象とする仕様

仕様は以下とします。ここでは「一意な値」パターンと呼んでおきましょう。

1. ユーザは、固有のユーザIDを持っている。ユーザIDを変更することはできない。
2. ユーザは、ユーザ登録時にユーザ名を決めることができる。
3. ユーザは、ユーザ名を変更することができる。
4. ユーザ名は一意であり、重複することができない。すでに使用されているユーザ名を使おうとするとエラーとなる。

これ以外の要素、たとえば以下のようなものは無視します。

• 文字列長、文字種といった、入力値の属性についての仕様
• 変更したユーザ名がシステム全体に反映されるまでの時間差みたいなもの

テスト設計1: まずCRUDを考える

おいでさんが例として挙げられている3つのテストケースは有効だと思います。

1. すでにAがある時に別の人がAを登録しようとする
2. BさんがAに変更しようとする
3. Aを削除してから別の人がAを登録しようとする

ただわたしの性格的に、リスト型のテストセットは網羅性が見えづらく、テーブル型にしたくなります。
おいでさんも言及されている通り、「登録」「変更」というキーワードから、まずはいわゆるCRUD、Create（作成）、Refer（参照）、Update（更新）、Delete（削除）での整理をしたくなりますね。

仕様2・3を確認するためのテストケースは、こういうテーブルになります。単純な機能テストです。

作成	〇: ユーザ作成時に、ユーザ名をつけられる
参照	〇: 作成・変更したユーザ名を参照できる
変更	〇: ユーザ作成後に、ユーザ名を変更できる
削除	〇: 作成・変更したユーザを削除できる

次に、仕様4を考慮しましょう。横軸に、「使用されているかどうか」の要素を加えます。

	使用されていないユーザ名	使用されているユーザ名
作成	〇: ユーザ作成時に、使用されていないユーザ名をつけられる	×: 使用されていないユーザ名を指定したユーザを作成できない
参照	〇: 作成・変更したユーザ名を参照できる	n/a: 作成・変更できないので対象外
変更	〇: 使用されていないユーザ名に変更できる	×: 使用されていないユーザ名に変更できない
削除	〇: 作成・変更したユーザを削除できる	n/a: 作成・変更できないので対象外

ここでもしかすると、「使用されている」の特殊パターンとして、「自分自身が使用している」というケースを思いつくかもしれません。言い換えると「ユーザ名の変更において、現在と同じユーザ名を指定する」ものです。この結果は、

1. 問題なく「変更」処理を完了させる
2. 「変更前と後で同じユーザ名である」旨のエラーメッセージを出す
3. 「ユーザ名が重複している」旨のエラーメッセージを出す

といくつか考えられるので、仕様を確認するいい機会かもしれません。テスト設計はできるだけ早く始めましょう。なお、わたしは2.が好きです。

テスト設計2: ユーザ名の状態の分解能を上げる

おいでさんのツイの3つ目

1. Aを削除してから別の人がAを登録しようとする

も大事ですよね。ですが、上の表の中にはうまく表現できていません。
このような場合、思いついたケースを単品で追加するのではなく、そのケースがどのような観点に属するものなのか考えることが大切です。

表をよく見ると、「使用されていない」には2つの状態が混在しているることに気づきます。

1. 過去から現在まで一度も使用されていない
2. 過去に使用されていたが、現在は使用されていない

「使用されていない」状態の分解能を上げると、テーブルはこのようになります。

	一度も使用されていないユーザ名	現在使用されているユーザ名	過去に使用されていたが今は使用されていないユーザ名
作成	〇: ユーザ作成時に、一度も使用されていないユーザ名をつけられる	×: 現在使われているユーザ名を指定したユーザを作成できない	?
参照	〇: 作成・変更したユーザ名を参照できる	n/a: 作成・変更できないので対象外	?
変更	〇: 一度も使用されていないユーザ名に変更できる	×: 現在使われているユーザ名に変更できない	?
削除	〇: 作成・変更したユーザを削除できる	n/a: 作成・変更できないので対象外	?

最初に示した仕様記述の曖昧な点が明らかになりました。ユーザ名の一意性を「ある時点では一意」と考えるのか、「過去・未来に渡って一意」と考えるのかは重要な決め事なので、仕様をクリアにするいいチャンスです。

ユーザ名の使い回しがトラブルになりうるようなケースでは「過去・未来に渡って一意」とするのが良いのでしょうが、ここでは「ある時点では一意」、つまり「使い回し可能」ケースで表を埋めてみます。

	一度も使用されていないユーザ名	現在使用されているユーザ名	過去に使用されていたが今は使用されていないユーザ名
作成	〇: ユーザ作成時に、使用されていないユーザ名をつけられる	×: 現在使われているユーザ名を指定したユーザを作成できない	〇: ユーザ作成時に、過去に使用されていたが今は使用されていないユーザ名をつけられる
参照	〇: 作成・変更したユーザ名を参照できる	n/a: 作成・変更できないので対象外	〇: 作成・変更したユーザ名を参照できる
変更	〇: 使用されていないユーザ名に変更できる	×: 現在使われているユーザ名に変更できない	〇: 過去に使用されていたが今は使用されていないユーザ名に変更できる
削除	〇: 作成・変更したユーザを削除できる	n/a: 作成・変更できないので対象外	〇: 作成・変更したユーザを削除できる

ここでも、「過去に使っていた自分のユーザ名を、再度使う」というケースを考慮してもいいかもしれません。

テスト設計3: ユーザ名のライフサイクルを考える

さて、ユーザ名の「状態」を考えた以上、状態遷移も考えたくなります。ユーザ名が生成されてから消滅するまで、これはユーザ名の「ライフサイクル」ということができるでしょう。

状態は、以下の3つでした。

1. 過去から現在まで一度も使用されていない
2. 利用されている
3. 過去に使用されていたが、現在は使用されていない

ユーザ名のライフサイクルには、以下の5つがあります。

1. 初期状態→1→終了状態: 一度も使われることのなかったユーザ名
2. 初期状態→1→2→終了状態: 一度だけ使われたユーザ名
3. 初期状態→1→2→3→終了状態: 一度使われた後、使われなくなったユーザ名
4. 初期状態→1→2(→3→2)ⁿ→終了状態: 使い回されたユーザ名
   　※nは繰り返しの数。n>0とする。n=0はサイクル2と同じ。
5. 初期状態→1(→2→3)ⁿ→終了状態: 使い回された後、使われなくなったユーザ名
   　※nは繰り返しの数。n>1とする。n=0はサイクル1と、n=1はサイクル3と同じ。

上のCRUDとは別に、このライフサイクルのテストもしたくなります。といっても、内容は重複しています。
サイクルaはテストするまでもないでしょう。サイクルbとサイクルc、サイクルdのn=1もカバーされていると言えるでしょう。

サイクルdとeを区別したテストは必要なさそうですが、サイクルdのn>1、サイクルeのn>2の、「複数回の使い回し」が起こるパターンはどう考えればよいでしょう。
これはもう仕様と実装によるので唯一解はなさそうですが、一般的にはこういうテストを行いたくなります。

• n=3、つまり「使い回しが2回起こる」パターン。
• n=大きな数、つまり「使い回されまくる」パターン。優先度低。

言いたかったこと

「一意の値」パターンのテストについて、「これが鉄板でござい！」と言いたいわけでないです。
ある仕様に対してテストケースを思いついてたら、それをポイっと追加する前に、

• そのケースは、どういう観点の中に位置付けられてられるのか
• その観点には、他にどのようなケースがあるだろうか
• その観点を網羅するにはどうしたらいいだろうか

を考えるのがいいなあというのが、実は今回の主張だったりします。

単純な例ですが、「仕様で制限された文字数より長いテキストを入れたらどうなるんだろう」と思いついたら、

• これは「文字列長」というテスト観点に属するテストケースだな
• このテスト観点には、「短いテキスト」というテストケースもあるな
• じゃあ、何文字のテストをやれば、この「文字列長」という観点を網羅できるだろう。同値分割を使ってみるか。

みたいな感じです。

サマリ (再掲)

• ありがちな仕様なのに、テスト設計の定石がそこまで広まってないものがある気がする。
• 「一意な値」パターンは、CRUDとライフサイクルの2つを考えるとよさそう。
• テスト設計は、仕様の曖昧さを減らすことのできる活動である。早く始めよう。
• 思いついたケースを無造作に追加していくのではなく、そのケースからテスト観点を逆導出すると、網羅性が考えやすくなる。

今回「一意な値」パターンと名付けてみましたが、このように「ありがちな仕様」をパターンとして抽象化し、それに対するテスト設計の定石をまとめるって、もしかするとすごく面白そうじゃないですか？
もうそういうのありますかね？

Generated By Dalle

「品質」と「価値」と「顧客満足」の関係が難しい

JaSST'24 Tokyoに参加して感じたことの一つに、「顧客に素早く価値を届けるために・・」という表現の発生頻度の高さがあります。特定の発表を批判したり、揶揄したりする意図はありません。この表現が決まり文句的に使われているために、その言葉の意味を考えずにいることを自覚したのでした。

「品質」と「価値」は何が違うのか。
みなさんからいただいたコメントも踏まえて、少し考えてみました。

先にイイワケしておくと、

1. 過去の偉人の議論とか、論文とか、規格における定義とかはほぼ参照していません
2. 特に明確な結論もありません、頭の体操にすぎません

ので、ご承知おきください。もちろん、「価値という言葉を使うな」という主張でもありません。

1. 価値・品質 同一説

過去幾度となく引用されたであろうG. M. Weinbergの定義、

品質は誰かにとっての価値である。

を単純に受け取ると、「品質＝価値」とも読めます。

身も蓋もない言い方をすると、2つの言葉に明確な意味の差はない。ないけれど、何となく目新しい響きもあり、好んで使われるようになったという説です。

面白いなと思ったのが山崎先生のこのご意見。

それに対して「価値向上」あるいは「魅力品質向上」というような言葉を使うと，攻めのイメージで，それによって購買者に訴求し，売り上げが増えるイメージを伴っていると思います．

— Susumu Yamazaki (ZACKY) (@zacky1972) 2024年3月16日

確かに、テスト・品質保証という言葉に、「守り」とか「最後の門番」の印象を持つ人も多いでしょう*1。極端にいうと、「マイナスをゼロに持ってくる」イメージ。
一方で「価値」というと、より積極的に「ゼロをプラスに変えていく」というイメージを、わたし自身は感じます。その結果、よりポジティブな印象を与える「価値」が、好んで使われるようになったというのはあるかもしれません。

2. 価値・品質 包含説

品質は価値の一部分ではあるけれど、そのすべてではない、という捉え方です。

品質には価値があるけれども品質だけで語れない価値があると思っています。

「品質＝価値」ではなく
「品質⊂価値」かなと思います。

— あきやま🚵‍♀️ (@akiyama924) 2024年3月16日

秋山さんは例として

牛丼屋の、早い・安い・うまいの「早い」は価値だと思うけど、品質（商品やサービスの特性）ではないと思います。

とおっしゃっています。わたしは「早い」はサービス品質の一つだと解釈するので、ここは意見の分かれるところです。

ではわたしは、品質以外で何を、牛丼屋の価値と考えるのか。たとえばですが、

• いつ行っても、期待した通りの品質のモノが供されるだろうという信頼感
• どんな時刻でも、行けばご飯が食べられるだろうという安心感

があるでしょうか。うーん、これもサービス品質ですかね？

またJaSST後の懇親会で、とあるサービスのベンダとそのユーザ、お二人の会話を聞いていて感じたのが、
「このベンダは、自分たちユーザの要望をバックログリストに載せている」 という「実感」
もまた、価値の一つであるということです。これはサービス自体の品質でも、サポート自体の品質でもないのですが、ユーザを惹きつける要因だと思います。

別の例としては、一部のクレジットカードの、「持っていること自体がステータスになる」という特性は、クレジットカード自体の品質とは無関係の「価値」であると感じます。持ちたいとは思いませんが。

3. 価値・品質 因果説

品質が価値につながる、という解釈です。

備わっているものが品質で、届くものが価値とも言えそう。←ブレインストーミング

— あきやま🚵‍♀️ (@akiyama924) 2024年3月16日

身近な例だと、果物の「糖度の高さ」は品質で、「甘くてうまい！」が価値、ですかね。
「品質が価値につながり、その価値が顧客満足につながる」というのは、わかりやすい流れに思えます。

ただし、以下の3点に注意する必要があります。

同じ品質でも、ユーザが感じる価値は異なる

果物に「甘い」を求めていない消費者にとっては、糖度が高くても「うまい！」とはならないですよね。
品質が同じでも、価値が同じとは限らない。「開発側がユーザ目線でテスト」するにも限界があり、最終的にはユーザに聞くしかない、となります。

すべての品質が価値につながるわけではない

牛丼屋の例でいうと、食器をメチャクチャ高級なものにしたところで、顧客価値は上がらないでしょう。

ソフトウェアでいうと、たとえばソースコードの複雑度を下げれば、いわゆる内部品質が上がったことになりますが、顧客の価値が直接上がるわけではないでしょう。
もちろん、コードの複雑度が下がる→保守性が上がる→コードの変更の難易度が下がる→新規機能やバグフィックスがより容易に行える→ユーザに新機能やバグフィックス版を迅速に提供できる→ユーザは嬉しい という間接的な因果関係はあるかもしれません。

価値につながるのは品質だけではない

これは包含説と同じ話ですね。
ただ、「品質以外で価値につながるもの」が、わたしには今のところ「プロダクトやその提供者への信頼感」「ブランド」みたいなものしか思いついておらず、もう少し考えたいところです。

みなさんはこれらの3つのうちどれが、品質と価値の関係に近いと思いますか？

アジャイル・スクラムの原点では？

『アジャイルソフトウェア開発宣言』にも「価値」という言葉が出てきますが、これは顧客にとっての価値というより、ソフトウェア開発における価値、と読みとれます。
『スクラムガイド』（2020年11月版、PDF）には「価値」という言葉が何度も出てきますが、その一部は顧客にとっての価値を表し、他のものはスクラムチームにとって価値を表しているようにわたしには読めます。

違うかな？
この辺はあまり書くとボロが出るので（もう出てるか）、この辺にしておきます。

Weinbergに戻る

Weinbergに戻りましょう。
上述のWeinbergの言葉は、以下のように続くそうです。

これは書籍
Quality Software Management: Systems Thinking (1991)（ソフトウェア文化を創る1 ワインバーグのシステム思考法(1994)
で書かれたもので、原文は
By "value," I mean, "What are people willing to pay (do) to have their requirements met."
となっています。

— Keizo Tatsumi (@KeizoTatsumi) 2024年3月17日

品質は誰かにとっての価値である。
「価値」という言葉は、「人びとはその要求がみたされるなら、喜んで対価を支払う（または何かをする）か？」ということを意味している。

こうしてみると、「価値」とはシンプルに、「要求が満たされること」なんですよね。

でもその「要求」は、「人びと」が明確に言語化できるとは限りませんし、仮にできたとしてもそれは不変ではありません。なのでアジャイル開発では、高い頻度で「動くソフトウェア」をリリースして、「要求が満たされること」を確認するんですよね。

なので、「顧客に素早く価値を届ける」というのは、本当は、「顧客に素早く価値（があると自分たちが仮説として考えたもの）を届ける」なのかなーと思ったりもします。揚げ足取りかもしれませんが。

おわりに

もともと「品質っていったい何なんだ・・？」とQAエンジニアみんなが悩んでいたところに、「価値」という言葉も加わり、ますますワカンネー感が広がりました！

Generated By Dalle

追記

その後まとめたワンページサマリーです。

品質と価値の関係　ワンページサマリー

*1:その割には「QAエンジニア」というロールの認知度と印象が急に上がった現象もあり、不思議ではあります・・・。

【参加メモ】「QA業界のパイオニアが語る！アジャイル・AI時代の品質保証の今」

2024年3月7日(木)の午後、「QA業界のパイオニアが語る！アジャイル・AI時代の品質保証の今」というイベントに参加してきました。
スピーカーは早稲田大学の鷲崎弘宣先生、永和システムマネジメントの平鍋健児さん、AGESTの髙橋寿一さんです。

この記事は当イベントのメモですが、AGESTのオウンドメディアであるSqripts会員限定＆抽選式のイベントであり、SNSでの発信についてのご案内もなかったことから、あまり詳細には触れずに概要を紹介したいと思います。

sqripts.com

アジャイルメトリクスの全体像と利用者・顧客満足に向けて

鷲崎先生のご講演です。

初めに、従来型開発とアジャイル開発における品質メトリクスの違いを説明したうえで、アジャイル開発においてよく利用されている品質メトリクスは圧倒的に製品品質に関するものが多く、一方で肝心の顧客満足を測定する取り組みが目立たないことを課題として提起されました。ユーザ価値を目指しているはずが、それを調べられていない状態ということです。

この課題を解決するために、バグ票やソースコードのコミット履歴が公開され、かつアプリストアでユーザレビューも見られるソフトウェアを対象にした研究を実施。間接的ながら、コミット履歴からは開発プロセスの特性を定量化でき、ユーザレビューからは顧客満足に相当する情報を定量化できる、というわけです。

結論として、レビュー依頼からマージまでの時間は、レビュースコアと明らかな負の相関があるということがわかったそうです。
擬似的な代替メトリクスであり、両者に因果関係があるとまでは断定できないとのことでしたが、顧客満足に影響する要素を特定するための活動としてとても面白いと感じました。

デジタルビジネスの潮流とアジャイル開発 〜ビジネスとエンジニアの協働チームづくり〜

平鍋さんのご講演です。

まずウォーターフォールの課題として、「要求からリリースまでのターンアラウンドタイムが長い」「終盤になってモメて、発注側と受注側のゼロサムゲームで消耗する」ことを挙げられました。これとは対照的なモノ作りとして、現場でユーザの実施のふるまいを観察しその場でプロトタイプを作り上げていくNordstromのアジャイル開発を紹介。

www.youtube.com

その中で品質保証の人間は意思決定できるチームの中にいるべきで、プロダクト横断的な観点、たとえばセキュリティの作り込みやテストのような開発項目を、「品質シナリオ」*1としてプロダクトバックログの中に組み込む役割を果たせるだろうとお話しいただきました。

また、「アジャイル開発の全社標準」といったものには注意すべきで、やるとしても、実践してうまくいったチームの経験を使うこと、またそれぞれの開発チーム自身が工夫できる余地を残すことを強調されていました。
個人的にも、「うまく行ったことのあるやり方」や、「工夫して作り込んだテンプレ」みたいなものを共有・紹介するのはとてもいいと思う一方で、それらの謎ANDを取って「全員このプラクティスに従うべき！」というのはチームを縛るだけで、アジャイル開発の良さを殺すんだろうなと感じます。

AI時代のソフトウェアテスト入門（シフトレフトするの？シフトライトするの？）

高橋 寿一さんの講演です。

高橋さんは、「生成AIによって開発生産性は上がるが、テストの生産性は上がっていない」と問題提起したうえで、AIのテストの難しさについて解説されました。
出力の非決定性、学習データのバイアス問題、テストオラクル問題*2とそれに伴うテスト自動化の困難さ、未成熟なテスト技法、といった具合です。また技術面とは別に、法規制などの側面でも新たな問題が生まれそうだとしています。
良くも悪くも、テストエンジニアの仕事はむしろ範囲が増える形になっており、それをどうやって減らしていくかが課題になりそうだとお話されていました。

なお、AIのテストについての翻訳本が春に出るというアナウンスがありました。
現著者は、Adam Smith氏とRex Black氏。Black氏はソフトウェアQA/テスト業界ではあまりに著名なコンサルタントですし、Smith氏はISO/IEC JTC 1/SC 42（人工知能）のメンバーでもあります。つまり、テストのプロとAIのプロが組んで書いた本。これは楽しみですね。

Artificial Intelligence and Software Testing: Building systems you can trust (English Edition)

↑ これは原著ですのでご注意！

おわりに

どれも印象に残る講演で、自分の仕事にも取り込んでいきたいと感じました。
わたしはAGESTさんの回し者ではありませんが、SqriptsはQAについての記事を幅広く、またかなりの頻度で出しているメディアであり、購読をお勧めします。まあ読み切れないのですが。。

余談ですが、懇親会で供されたビュッフェ、めちゃくちゃ美味しかったです・・・帝国ホテルのローストビーフ・・・。

Generated By Dalle

*1:『アジャイル品質パターン』で定義された、アジャイル開発における品質プラクティスの一つ。

アジャイル品質パターン「QA to AQ」 伝統的な品質保証からアジャイル品質への変革（CodeZine Digital First）

*2:テストにおいて、あるべき期待値を決める根拠が得られないという問題。たとえばChatGPTに「美しい詩を書いて」と指示した場合、どんな詩が出力されれば「正解」で言えるかを決めることは難しい。「テストオラクル」については、こちらの記事も参照。 www.kzsuzuki.com

【参加メモ】AI時代のソフトウェアテストの現在と未来 #genai_autify_launchable

本日2024年3月5日(火)の昼間に開催された、『AI時代のソフトウェアテストの現在と未来』というイベントがとてもよかったので、特に印象深かったポイントについて共有したいと思います。

イベントの詳細はこちらで。 autifyjapan.connpass.com

登壇者はタワーズ・クエストの和田卓人 @t_wada さん、Launchableの川口耕介 @kohsukekawa さん、Autifyの近澤良 @chikathreesix さんのお三方。ファシリテーターは、近澤さんと同じくAutifyの、末村拓也 @tsueeemura さんです。

宣伝タイム

• Launchableは、「テストの失敗をよりインテリジェントに扱う」ことを目指している。
  たとえば、テストのFlakinessの判定や対処にできるだけ人を介在させないとか、過去の実行結果を見て再実行要否の判断をするといったもの。
• Autifyは、E2Eテストの2つのペインポイントである実装と保守を、ノーコードで行う。画面変更にも自動的に追随できる。

質問1. AIを活用した開発プロセスのあるべき姿

「ソフトウェア開発における生成AIの活用といえばまずコード生成が挙がるが、生成AIは要件定義でも強みがありそう」という川口さんのご指摘に対して、近澤さんも「要件定義など上段をしっかり作ると、良いアウトプットができる」とおっしゃっていました。
基本設計→詳細設計→プログラミング と、設計ドキュメントを十全に作り上げてから実装の始まる従来の開発から、「包括的なドキュメントよりも動くソフトウェアを」を旨とするアジャイル開発へのシフトが起こりましたが、今後は「動くソフトウェアを素早く作るためのドキュメントを」というパラダイムも来るのかなーと感じます。

生成AIによって生成されたモノの質の担保について、「何をもって正しいかは人間が判断する」とした和田さんのご意見が印象的でした*1。AIはあくまでも「自分が書くとこうなる」とわかっているものを作ることは楽にしてくれるけれど、「どう書けばいいかわからない」ものは、質を評価できないと。これはプロダクトコードもテストコードも同じ。
「プロダクトコードとテストコード両方を書く場合、プログラマーは頭のモードを切り替えて自分との会話をするが、LLMにこの対話をさせるパイプラインをデザインできないか」という川口さんのアイデアに対し、「両方をAIに生成させると、両方が等しく誤るリスクがある」とおっしゃっていました。ただ、「要件・仕様ドキュメント」「プロダクトコード」「テストコード」のトリオのうち2つを人間が作り、残りの1つを生成させると、高い精度が得られる傾向があるというお話をされていました。
何となくRAID5の分散パリティを思わせるようでもあり、またある意味「たがいに冗長」である2つをしっかり作ることで、残りの1つが間違える確率を減らしているようにも思え、ワクワクする知見でした。

質問2. テストにおけるLLMの活用

近澤さん、川口さんともに、今後はテキストベースのログだけでなく、マルチモーダルAIでスクリーンショットをチェックし、従来はベテランの直感頼りだった異常検知もできるようになるだろうとおっしゃっていました。
「才能のあるテストエンジニアの力を民主化し、スケールさせる」という表現も面白かった。

質問3. 人間に残されるタスク

たとえば運転は、自動運転に代替され始めている。そうなると、「運転する」こと自体は重要ではなく、「どこに行くか」を考えられることが重要というのが、San FranciscoでWeimoの自動車を目の当たりにしている近澤さんのご意見でした。「何を作るか」は人間が考えるということですね。
一方川口さんは、いわゆる「上流」の仕事も、ユーザやマーケットの観察などある意味で機械的・言語処理的なものであり、生き残るかどうかには懐疑的とのご意見。

ファシリテーターの末村さんは、ベテランのエンジニアが行っていることの例として、「どのタイミングでどういうテストを行うべきか」といったテスト戦略の立案や、新しいテスト技術の開発*2といったものがあり、こういった作業は代替されないのでは？と問いかけを行っていました。

前者について和田さんは、従来のテスト戦略の暗黙の前提になっている点を見直す必要が出てくるというお話をされていました。
これまでのテスト戦略は、テストを行う主体が人間であることを前提とし、そのうえで最適な方法を模索しています。単純な例だと、「パラメータの全組み合わせを手動で実行している時間はないから、リスクに応じてカバレッジ基準を落とそう」といったものです。
テスト自動化によりそれも変わってきてはいますが、生成AIがそれに拍車をかける。よって、今まで前提としてきたもののうち、依然として有効なものがどれで、すでに無効になっているものがどれかを見極める必要がある、ということです。

4. レガシーコードの技術的負債に対するAIの活用

巨大なコードベースで、テスト容易性・理解容易性・変更容易性がすべて低いような状況において、「リファクタリング前後のサンプル」を少数与えることで、残りのレガシーコードも「以下同文」としてすべてリファクタリングすることができるのではないか」という和田さんのお話が面白かったです。
また、数万行オーダーのコードを生成AIが一気に理解できるようになれば、コードから仕様ドキュメントの生成も容易になり、「誰も全体を把握していない」「超ベテランしか把握していない」という状態から抜け出せるというお話もありました。夢が広がる話です。

感想

今後のテスト・QAに対する自分の取り組みに新たな発想を与えてくれる、非常に有意義なトークセッションでした。生成AIを含めたAI全般についての知識を深めつつ、業界内の動向や事例をよく吸収して、良いモノづくりにつなげていきたいと感じさせられました。

登壇者のみなさん、運営のみなさん、ありがとうございました。

Generated By Dalle

*1:なお、人間が指示→AIが作業→人間が確認する形を「サンドイッチワークフロー」と言うそうです。

*2:たとえば、最近書籍が出版された話題になっているプロパティベーステスト（Property-based Testing）を挙げられていました。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう

JaSST'24 Tokyoでパネルディスカッションに参加します！

JaSST'24 Tokyoは3/14(木)、3/15(金)に開催。再来週に迫ってきました。

jasst.jp

わたしも同僚とともに2日間、現地で参加予定。とても楽しみにしています。

IT系イベント・カンファレンスといえば最近はオンライン開催も多く、自宅から気軽に参加できる大きなメリットを享受しています。運営に関わるみなさまには感謝ばかりです。
一方で現地イベント。移動の手間はかかるし、聴講する環境も必ずしも良くはなかったりする。それでも。
それでも、現地ならではの熱気と、何より自分自身の集中力がまったく違うんです。現地イベントにおけるわたしの集中力を53万とすると、映像コンテンツの苦手なわたしのオンラインイベントにおける集中力は5くらいなんですよね。

また、わたしはコミュニケーション能力が高い方ではないのですが、それでも現地に行けば、多少なりともネットワーキングができる！
有力な転職情報は特に求めていないのですが、「ソフトウェアの品質やテストについて、ダラダラしゃべったりできる同志」がとても大切なんです。 現地にいらっしゃるみなさん、当日はどうぞよろしくお願いします。

なお2日目は、『テスト管理ツールの向かう先』というセッションで「しゃべる側」になります。

jasst.jp

テスト管理ツールベンダ三社とユーザ（これがわたし）の立場から、「テスト管理ツールってどうなの？」に加えて、「テスト管理ツールって、これからどうなっていくの？」という話ができればと思っています。
Quality Forwardを担ぐベリサーブの朱峰さん、CATを担ぐSHIFTの石井さん、TestRailを担ぐテクマトリックスの会田さん。みなさんそれぞれベンダーの立場としてのご登壇ですが、「ぶっちゃけで行きましょう」という方ばかり。

「テスト管理ツールにはこんなメリットがあるのでみんな使おう！」に終始する提灯セッションではなく、「テスト管理ツールでテストを・品質を・開発をどう変えていきたいか」という未来の話を、プロのみなさんから引き出せるよう、わたしも頑張ります！ よろしければぜひ、ご聴講ください。