Autify Podcast、エピソードを追加しました

ソフトウェアテスト、スタートアップなどにフォーカスしてさまざまなTipsや、事例などをお伝えするラジオ番組、Autify Podcastを公開しています。

今回は、辰巳 敬三 (@KeizoTatsumi) さんをゲストに迎え、、ソフトウェアテストの歴史から、品質保証の技術を追求する楽しさ、言葉の定義などをトークしています。

さっそく聞いてみる

Spotifyで聞く

iTunesで聞く

Google Podcastsで聞く

ご意見、感想はTwitterでメンションしてください。

https://twitter.com/AutifyJapan

ここからは書き起こし記事です。文末の参考文献・URLもあわせてご参照ください。

末村: Autify、Podcast始めていきます。よろしくお願いします。 今日は辰巳 敬三さんに来ていただいています。辰巳さん、最初に軽く自己紹介お願いしてもいいですか。

辰巳: はい、わかりました。辰巳と申します。古い人間なので、喋り出すとものすごく、40年前からの話をしなきゃいけないんですけども。 1976年に富士通っていう会社に。そのころはメインフレームの華やかなっていうか、これからどんどん行くぞっていうような時代でしたけれど、富士通に入社して、ソフトウェアの検査部っていうところに配属されました。

何をするかというと、ソフトウェア製品の出荷・検査。実際にはテストをして、そこで出てくるバグだとか何だとかから、品質・評価で、これは外に出していいんじゃないかとか、「いや、これはまだ駄目だ」とか、そういったことをやる部署なんですけれども、そこにいきなり。 大学の時もコンピューターは多少は触ってましたけど、まだソフトウェアのそういうところって、大学でもあんまり勉強するようなところはなかったんですけれども。実際にソフトウェアじゃなく、さらに “検査” なんていう話になってきて、結構いろいろやるときにいろんなことを新たに学んだっていう感じで。

そういう古い話がありますけど、そういうところからソフトウェアのテストに携わってですね、ずっとメインフレームのCOBOLのコンパイラーが最初の担当、その後オペレーティングシステムのOSですね、それのテストを出荷・検査っていうところをずっとやって。 ちょっと長くなりますけども、90年前後になるとメインフレームの世界から今度はUNIXの世界に。それからさらにはパソコンの世界になって。テスト、検査する対象もどんどん、それこそダウンサイジングの時代になっていて。 そういったところに、やっぱりテストとか対象にするものが自分たちでゼロから作るんじゃなくて、今度はどっかから持ってくるっていう世界に。UNIXだとかマイクロソフトのやつをベースにするとか。

その時代に応じたテストとか品質の考え方っていうところをやってきたっていう。そういう経歴です。 実際に、検査の現場そのものは、90年半ばぐらいに担当変わったりしてますので、実際に携わるってところはかなり、一戦を退いてからは長くなってますけれども、引き続きお話させていただけてるっていうのは、2005年、6年ぐらいにSQuBOKっていうソフトウェア品質知識体系っていう書籍を日科技連のコミュニティの中で作ろうっていうのでそこに参加して、ずっと会社の中でやってたのを、社外コミュニティでの活動っていうのが始めたのが本格的にはSQuBOKの作成からだったんですけども。 そういうSQuBOKのいろんな中のトピックを書いたりなんていう活動を通じて、やっぱり昔からの知識だとか、今度は作る上でまたいろいろ調べて、そういうソフトウェアのテストとか品質だとかっていうところの歴史も含めて、SQuBOKに書きながら、自分なりに新たに勉強し始めたっていうところ。

それを引き続き今も、現在はSQuBOKのVersion3っていうのを、今年出せると思うんですけれども。

そういうところを通じて、いろいろJaSSTっていいますか。その前はTEFですかね。テストのメーリングリストなんか、それからJaSSTのシンポジウムっていうところでも発表する機会をもらったり、あとはテスト PRESS (※「ソフトウェア・テスト PRESS (※参考」のこと) っていう雑誌が、テストっていうだけで雑誌が2008年から10年ぐらいまでは、テストの雑誌っていうのが出てましたから。 そこでテストの歴史の書きものを書いて出したりして。そういう昔からやっている人間として歴史をまとめて、いろんな人に伝えたいなっていうことで。

それも今も引き続きやっていて、ことあるごとにちょっと口出すことがあるんですけども、それは昔からの歴史を踏まえて少しコメントさせていただいているというところで。うるさい奴と思われることもあるかもしれませんけれども（笑）

「長い歴史の中で見ると、こうだよ」っていうところで、少し皆さんの参考になればいいなということで引き続き、今日のAutifyさんのPodcastなんかもそうですけれども、こういう機会があったらできるだけお話しさせていただきたいなと思っています。 大変長くなりましたけれども、そういう経歴を持ってますということで、お話しさせていただきました。

末村: ありがとうございます。すごいですね、何ていうか。自己紹介をするとコンピューターの歴史が大体全部出てくるような。自己紹介をするだけですごく話が深くなってしまう（笑）

辰巳: そうなんです（笑）

末村: ずっと長くやってられてる方と、僕あんまりお話しする機会がないので、今回みたいな形でお話しさせていただけるのが、すごくうれしく思います。 今回出演の経緯なんですが、Autifyの一番最初のPodcastをリリースした後に、辰巳さんが有り難いことに、Twitter上でいろいろフィードバックを頂けまして。その話の流れで「是非出てきていただきたい」という風にこちらからのオファーとらせていただいているという形になります。

なので今日も是非よろしくお願いいたします。

今の自己紹介の中で、メインフレームの話が出てきたと思うんですけど、辰巳さんメインフレームのテストにすごく長く関わっていらっしゃったんですよね。

辰巳: そうですね。富士通に1976年に入ったときに、メインフレームもそのころ一番、超大型とそれなりのやつと小型という感じで分けたときに、中クラスぐらいのメインフレーム。ようやく最初の版が出たぐらいなんですね。

だから、そういう富士通としての中型ぐらいのOSの検査に最初から関わって、実際には1990年ぐらいまではメインフレーム系のOSの検査に関わっていました。

末村: ありがとうございます。僕は社会人になるまで、メインフレームというものに全く触ったことがなくて。むしろ、この年で社会に出てからメインフレームに触ることがあるんだろうかというぐらいの気持ちでいたんですが、実際、新卒で初めて入った会社、実はメインフレームがあって。メインフレームで合ってるんだよな…。いわゆる汎用機とかオフコンとか呼ばれるものですよね。

辰巳: うん、そうですね。

末村: すいません。エンジニアとしてではなくて、僕はまだそのころは文系の大学を出て何のスキルもない状態で入れるしょぼくれた会社に入っていたので（笑） そのとき倉庫で働いてたんですけど、そこの会社で使っていた基幹システムが、IBMのAS/400というメインフレームだったんですけど。

辰巳: はいはい。

末村: エンジニアとして全く触ったことはないんですが、すごく思い入れがあって（笑） そのときにその会社のエンジニアたちと話していて、やっぱり開発もテストもすごく大変な印象があって。かなり影響範囲について厳しいものだったんじゃないかなと。これは完全に想像なんですが、多分当たってるんじゃないかなと思います。

是非、辰巳さんにお聞きしたいんですが、そのころテスターとして関わって、どんなふうに大変だったかっていうのを、是非聞きたいなと思うんですが。

辰巳: メインフレームの、テストの大変さっていうか。大変かどうかは別として楽しかったんですけども、やっぱりメインフレームなんで、机の上にはないんですよ、自分の。 だから、せいぜい端末から操作をする。私、もともとはOSの検査は最初の方なので、それは工場にメインフレームって何台かですよね。だから、一人一台じゃないですから。そういったところで時間を分けながら、1時間なり2時間なりの枠を皆が申請して、その時間をもらってそこでテストをして。夜中は、徹夜の前半後半に分けて勤務とか。

だから、そういったところで、でっかいやつを自分一人で占有しながら、いろいろガンガンぶん回すとか。そういうようなことをいろいろやってましたね。 だから、今はとてもじゃないけど徹夜もできないですし（笑）。やっぱりそういうなかなか今みたいに困ればちゃちゃっと修正できて、みたいな、そういう時代じゃないから。 途中からは、いろいろタイムシェアリングだとか何だとか、いろんな端末だとか、あとはクラサバみたいな感じで少しずつパソコンが出てきて、それと連携しながらっていうところで。

そうなってくると、今度はいっぱい出てくることで、それの繫がりだとか何とかを確認しなきゃいけないことが山ほど出てくるっていうところで。それはそれで、ものすごくテストとか品質を見ようっていうところが大変な状況になってきて。

そういう分散みたいなことになってきて、今度は集中みたいになってきてとかっていうことで、そういう時代は繰り返していると思うんですね。 今の最近の仮想化だとかDocker、Kubernetesとかいろんなことでなってますけど、いろんな書籍だとかを見るとわかるように、そういう仮想化みたいな話は昔からあって、私が入ったときも、もうすでにIBMはVirtual Machineみたいなもので、富士通もそれを追っかけて仮想計算機みたいなやつ。だから、ひとつの物理的な計算機を複数にその上に別のOSに乗っけてやるっていう時代は当時からもあって。多少時間を空けながらっていうところがひとつのマシーンの中に複数のVMを置いてそれぞれ使うっていうようなことはやってた。圧倒的に数は全然違いますから、大変さは違うんですけども今とは。

基本的な話みたいなやつは。数が多くなることでインターフェースが増えて、それの確認が増える。クライアントサーバーでサーバーがあってクライアント側でいろいろ非同期に動いているところの繫ぎをどうするとか、いろんな資材の移植性とか互換性みたいなやつがいろいろ考えなきゃいけないことが増える。

逆にそうなってくると、今度はお客さんに使ってもらったときに、はいって言って、いろんなバリエーションがありますねって言っても混乱するだけだから。あるパターンで商売をしていこうっていうことで、こういう組み合わせだったら品質、事前に確認できますからっていうことで、いろいろおすすめパターンみたいなやつを提供していくっていう。

そういったところも、ひとつメインフレームというか、コンピューターを売る側の、外への提案の仕方っていうことでパターン化っていう話がでてきたので。そういうパターンに応じて、検査もそういうパターンで大丈夫だっていうところを保証して、それ以外はごめんなさいって、あんまり変わった使い方しないでねっていう、そういうやり方に変わってきたっていう、そういう感じですよね。

末村: なるほど。確かに、売り方に応じてプロダクトもいろいろ変わってきて、それに応じてテストの仕方もどんどん変わってきたり、気をつけなきゃいけないところも変わってきたりということですよね。

ありがとうございます。

辰巳: 他社のやつを悪く言うとあれですけども、マイクロソフトのOSなんてのも、過去は評判悪かったんですね、いろいろ品質悪くてってことで。最初はパーソナルな個人のやつが、だんだんビジネスに使われるようになって、Windows NTだとかの時代になってきたり、そういうサーバーとして使われるようになっても、やっぱり品質がそこそこ、それなりにっていうことだったんですよね。

そういう意味でメインフレーマーというか富士通含めて、OSはMicrosoftのやつを使わざるを得ない。ただ、自分たちのサーバー、作ったハードの上で、MicrosoftのNTのやつを持ってきて、それで外にお客さんに提供するっていったときに、やっぱりNTのやつをそれなりにMicrosoftはテストして持ってきてるんでしょうけども、やっぱり自分たち品質で見るといろんな不都合が出てくるので。そういったところをできるだけ潰して、修正してもらって、ただここ以外は踏んじゃいけませんよっていうことで、ちゃんとそういう情報をお伝えするっていうような（笑）

だから昔でいくと、自分たちで作ったやつをできるだけ品質高くっていうことで、自分たちの努力でできてたのが、外から持ってくるもんだから、そこは限界があって。そうなると、踏み固めたとこをきちんと伝えて、それ以外のところはできるだけ踏まないようにねっていうやり方で、見た目っていうか実質上はある程度品質確保みたいな。

そういう作戦、アプローチが、考え方が少しオープンな時代になってくると変わってきたっていう、そんな感じですね。 今もそれこそ、オープンソースの時代になっているので、さらにそういういろんなことが必要になってくる。

今、決定的に違ってきていると思うのは、昔は富士通なら富士通の中での情報の話だったのが、それこそオープンイノベーションというか、世界中の人たちの情報を得ながらっていうことで、やっぱりそうなると世界中の力、知恵を結集してっていうことになるので。そこを上手くできれば、昔よりは上手いやり方ができるっていうことには最近なってきていて、そこをどう皆さんがうまくやるかっていうことが、今の現場の人たちの腕の見せ所なんだろうなという風に思います。

末村: ありがとうございます。ちょっと話を変えさせていただいてもいいですか。

辰巳: はい。

末村: 辰巳さんに聞きたかったのがメインフレームの話だったりっていうのもそうだし、もう1個、ずっと長くテストの世界、テストというものにずっと深く関わってこられている辰巳さんに、”開発者とテスターの関わり方” みたいなところが、昔と今で変わってるのかっていうので是非お聞きしたいと思ってるんですが。

辰巳: はい。私特殊なのかもしれないなと思ってるんですけども、富士通に入ってメインフレーム、それも富士通だけじゃなくていわゆるその当時メインフレームは日立さんだとかNECさんだとか。一緒かもしれないんですけども。組織的には開発の部門っていうのがあって、検査部門っていうのが別にあるんですね、あったんです。

基本的な考え方は、開発部門で出せるっていうとこまで、テスト含めて全部やるっていう前提なんですよ。 だから、今で言うと開発部門が当然設計してコーディングして単体テストだ、結合テストだ、システムテストだ、というのを、全部やってくるんですよ。

さらにその後に製品検査っていうことで、それが世の中に出せるのかどうかっていう出荷判定をする。出荷判定のためにひとつはテストっていう手段で実際にテストをして、そこからどう問題が出てくるのか出ないのかっていう。 そこである種の基準は設けないと判断できないので、どのぐらいのバグだったら何とか、これだったら差し戻しとかっていうような形でやるんですね。 だから、全く開発してる部隊と検査部隊っていうのは独立なんですね。 今、皆さん、いろいろテスターとディベロッパーの関係とかっていうときに、どこの話をしてるのかって。私がパッとこう、そういう経験を持っているので、全く独立と言うと、検査部門みたいなことを考えてるんです。

ところが、ある種考えると何とかチーム、開発チームの中にテスターが入り込んでっていうと、それはひょっとすると私の感覚でいくと、開発部門の中の役割分担の話であって、その先にまた検査部門っていうのがいるような世界とは、またちょっと違う話かなというふうに思うんですね。

だから、そういう意味で、私そのものは世間一般のディベロッパーだとかテストだっていうところの感覚の人たちと、ちょっと違ってる可能性が大いにあるなと思っています。 そういうことを前提に、聞いていただければなと思うんですけど。 検査と開発部門と全く独立に分けてそこで出荷判定っていうような世界でいくと、関わり方っていうと、本当に開発する側と検査する側で。私が1976年に入ってぺーぺーのときにいろいろ上のリーダーとか言われてると、やっぱりその当時は「負けちゃいけない、開発者に」っていう。

だから、一生懸命テストコードを作ってバグを見つけるわけですね。

やっぱり開発者から、開発部門の人たちから「お前ら、何か重箱の隅をつつくようなやつばっかり言いやがって」とか言われるんですけど（笑）

でも、ぺーぺーのころはそれでしょぼんとするんですけど、そう言われてしまうと。ただ、グループのリーダーなんかは「そういうところに見つかるってことは他にもいっぱいあるんだからダメだ」って開発部門に言い返したりとか（笑）

そういう、ある種、緊張関係を持ちながらやっていたっていう。

実際にはそれは良いことというか、そういう緊張関係がないといけない。あと、最近の議論で聞いてると、やっぱりそういうふうに分けるっていう判断っていうか、それはあくまで組織の考え方だとか、それの上の人。

昔の組織名で呼ぶとソフトウェア事業部っていうのが全体で私のところでもあって、開発部門はいくつかOSの担当とかミドルウェアの担当とかっていう開発部門。で、検査部門は1個。 そういう風に分けて、独立の部門できちんと出荷みたいなことをやろうっていう、ある種コストセンターですし、投資ですよね。

事業部長レベルがどうするかっていう判断をして、事業部長が判断をするために、やっぱり客観的に第三者的な検査部門が必要だからそこでやらせるんだっていう思いがあって、その意向を踏まえた上で、ある種の緊張関係で何かしら品質をいい方向に持っていく、組織的に持っていくっていうやり方だと思うんですよ。

それの考え方を開発チームに所属している人が、テスターとディベロッパーの関係っていうような議論でいくと、上位のマネジメントの関係の話と、少し違うかもしれないっていうふうに思うんですね。

今、最近のあれでいくと、アジャイルテスティングだ何だっていう話でいくと、Whole Teamっていう。だからチームとして取り組もうぜっていう。さっき言った事業部っていう単位で、大きなやつじゃなくて、最近は小さなチームでやっていくことを主に考えて、ひょっとしたらそういうのがでっかい事業部の開発の中で複数のチームを作ってっていうようなマネジメントの仕方になってるのかもしれないですけど。

だからそういうのでは、多少私の感覚でいくと、今まで経験したことない、なかなか話はしづらいんですけども。

でもやっぱり今の関係でいくとWhole Teamっていうことで、やっぱり最初の段階から開発の設計っていうか、構想の段階からテストとか品質の役割持った人たちが入り込む、入りこんで一緒にそこでやっていくっていうところはありだろうなっていうふうに思っています。 最初から入り込んでいくっていう発想そのものは、私が入社したときも、もう既にそういう発想はもともとあって、それ以前に昔のいろんな論文などをまた見てても、昔からそういう話がされているんですよね。

だから、具体的にどうやってできるか、その時代時代に応じて、最初から入って、最初から取り組むのはどうするのかっていうのが変わってきてるだけであって、最初からやるのがいいよねっていうのは、誰も昔はそんなこと考えてなかったっていうのは全くそういうことなくて、皆そういうふうに最初からやるのがいいんだと、最初からテスト設計を並行してやると、やっぱり問題見つかるよねっていうのは昔の人も言ってるので。

だから、それをいかにうまくやるか。それはあと気持ちの問題も含めて、「私開発の人、あんたテストする人」じゃないよ、っていう話にはなっていかなきゃいけないので、今のWhole Teamで、ワンチームで頑張りましょうっていう、それが最近の傾向だと思ってます。 ただ、緊張関係みたいなところとWhole Teamでのやつっていうのが、どういうふうに皆さんうまくやるのかなっていうのは多少気になるところではあります。

末村: そうですね。やっぱり緊張関係みたいなところを、最近よく聞くワードで「問題 VS 私たち」っていう言葉、アジャイル界隈でよく聞かれるやつがあったと思うんですが。

要は、開発チームとQA、品質保証のチームとで戦うような構図にするのではなくて、皆でいいものを作っていこう。品質が悪いみたいなそういう問題に対して、全員で戦っていこうっていうような話があったと思うんで。 多分、そういうものを思考した結果の、Whole Teamじゃないかと思うんですが。 一方で僕自身も、辰巳さんがおっしゃっていたような緊張関係みたいなものは、大事な局面もあると思っていて。

結構、製造業的な発想ですよね。検査をするチームがあって、作るチームと検査するチームがそれぞれの職責を全うしていいものを作り上げる。製造工程の中でそういうポイントがあるみたいなのは、(同じことをもう一回言っちゃうんですが)すごく製造業的な発想かなと思っていて。というふうにして品質を上げられるのであればそういう方法を使うべきだし、Whole Teamというような発想が、別に相反する概念に思われるじゃないですか。

辰巳: うん。

末村: そうではないのかなっていうのは、今、辰巳さんの話を聞いてちょっと僕は思いました。

辰巳: そうではないです（笑）

末村: ですよね（笑）

辰巳: というか、検査とか品質保証みたいなことの考え方も、ソフトの話以前から、検査至上主義って、とにかく作って最後の検査ではじこうっていう、そういう考え方は既に違うよねっていうことでは、ずっと言われていて。

私たちもソフトの世界で検査っていうのは、最後で厳しくは言うんですけど、やっぱりそこに来たら終わりだよねっていうことで、途中の工程完了のところできちんと見ながらやっていく。最後の出荷検査みたいなところも、途中の状況はこうだったから最後の段階でこうなってるけどここはあくまで単発的な事故だよね、バグだよね、っていうふうに判断できるんだったら、そこは修正してそれでよしとしようとか。

そうじゃなくて経過も悪くて結果も悪かったらもう1回作り直しみたいな。途中経過含めて考えていきましょう。さらには、その途中途中の工程で検査部門として支援できるようなところっていうか、早めに言った方がいいとか。それこそWモデル的にテスト設計的なところも含めて、検査部門として何ができるか、品質保証として何ができるかっていうのを、組織的にはそういう事業部レベルとしてはWhole Teamなんですよ。そうならなきゃいけないっていう考え方ではずっとやられていて。

それが今もっとスモールな、もう本当に個々のチームの中でそういうことを具体的に回す。そのためのやり方みたいなプラクティスはどんどんアジャイルの話が始まってるのでできてるので。そういう考え方とかやり方みたいな、大きな考え方は以前からもあって、それは今いろんなプラクティスがどんどんツールだとか環境含めてどんどんいいものが出てきているので、皆それでできるようになったっていうことかなっていうふうに、私自身は思ってるのでね。

だからそういう意味ではウォーターフォール、ウォーターフォールがいいのかっていう議論なのであれなんですけど、昔が間違っていて今がこうだっていうような議論になってくるとそれは違うよねって思ってコメントしたくなるっていう、そんな感じです。

末村: ありがとうございます。いや、本当にその通りだと思います、ありがとうございます。

ちょっとまた話を変えさせていただきたいと思うんですが、先日我々の初めてのPodcastに辰巳さんがコメントしてくださったときに、テスタビリティの話について言及していただきました。

僕があのときテスタビリティの話をしたのは、やっぱりテスタビリティだったり外部品質、内部品質といった概念っていうのは、プロダクトの持続可能性を高める上ですごく大事な概念だなというふうに思ってまいす。

要は、テスターとして、あるいは品質保証のテスターとしてであったり、QAとしてだったりでソフトウェアに関わっていると、テストのしやすさみたいなところを、きちんとプロダクトの開発の方に入り込んで高めていかないと、品質そのものを上げるのは難しいというような感覚を持っているんですね。

なので、テスタビリティを高めていく、あるいは品質の指標っていうのが外的にあるもの、ユーザーに直接影響するものだけではなくて、ソフトウェア自体の内部的な品質っていうものがあって、「それも品質なんだよ」っていう考えを持つっていうのが、すごく大事なことだなっていうふうに思ってます。

辰巳: はい。

末村: それを考えるにあたって、Autifyは今、E2Eテストを自動化するためのプラットフォームを提供しているんですが、E2Eテストとそれ以外のテストにおいて、テスタビリティのいろんな要素の中で、利用できる要素とできない要素っていうのがすごく明確にあると思っていて。

例えばE2Eテストにおいて、制御容易性だったり観測容易性だったり単純性だったりって、あげにくいんじゃないかな。あるいはそこに考えることが難しいんじゃないかなというふうに思っていて。もし辰巳さんの方でここについてご意見があれば、是非伺いたいなと思ってるんですが。

辰巳: 直接ご意見は全然ないんですけど（笑）

末村: すみません（笑）

辰巳: 先ほども言いましたけども、実際に現場で何かツール使ってっていうような作業とか今ですと私は全く触ったことがないので。

まず、お話で末村さんが言われているのは全く正しいっていうか、その通りだと思っているんです、テスタビリティとか外部品質とか。

末村: はい。

辰巳: 私はコメントしたのはあくまで言葉の定義というか、そういったところが気になっただけなんですよ、まず。

末村: はい。

辰巳: ちょっと古い話、また歴史の話になってしまいますけど、テスタビリティっていう言葉っていうか概念、ソフトウェアの品質に関してものすごく古い、昔からあるんですよ。

私が見てテスタビリティってあるなってさかのぼって見ると。品質特性っていう今のSQuaREですね。それが前はISO9126、その前がいろいろ品質特性っていうことがいろいろ議論されていて、一番最初だと思っているのがBarry Boehmが1973年に品質特性のレポート (※1 文末「参考文献・URL」を参照のこと) を出してるんですけども、テスタビリティって出てくるんですよ。そういう意味では、昔の人たちは全部そういうソフトウェア製品の品質って考えたときに、単に外の話だけじゃなくて、そういうテストの容易性みたいなところもきちんと品質の中だっていうことで昔からずっと考えていて。

そういうことで、あくまで製品として持つべき特性、特徴、がテスタビリティ。末村さんにコメントしたときにはテスト側の話、テスト資材みたいなところだとか、そういったところのニュアンスに聞こえたところがあって、それがちょっとテスタビリティの定義でいくと違うよっていうことを言っただけであって。テストの容易性みたいなことをきちんと考える。 それはテスト資材とかテスト側の話でのテスタビリティ的なものっていうのも当然考えなきゃいけないんだけども。

それと品質特性の言葉としてのテスタビリティを混ぜると、何かどこかで誤解が生じるかなっていうところで気になってコメントさせていただきました。

あとはもう1点、言葉関係でいくと、外部品質、内部品質っていう話で、これは末村さんの話じゃないんですけど、名前出してあれですけど、@twada さん (※注: 和田卓人さんのこと) の最近講演されている資料だとか何とかって、やっぱり外部品質、内部品質っていう言葉で説明されている。 資料として非常に歴史的な話も含めて勉強になる話で良いんですけど。以前コメントっていうかTwitterで、外部品質、内部品質、@twada さんの資料の中で言ってる外部品質、内部品質っていうのは、いわゆるISO9126だとかで言ってる外部品質、内部品質、言葉の意味が違ってるんですよね。なので、そういう意味で聞いている人たちが混乱しないようにいっていう意味で言ったつもりで。

和田さんの資料はテスタビリティは内部品質だって言われてるんですね。内部品質の中にテスタティリティがあるよっていう。ISO9126の特性の話でいうと、外部品質にも内部品質にもテスタビリティっていうのはあるんですよ。

というか違う次元の話をしていて、ISOの方でいくと、内部品質はあくまで動く前のソースコードだとかドキュメントとか、そうったところの品質に関して内部品質って言ってて、動く普通の製品になって動いているものの品質を外部品質と言ってるんですよね。だから交差するっていう。

ソースコードとか、いろいろドキュメント上でテスタビリティっていうのは確保されてるのっていうような見方をする。動いてるものでテスタビリティっていうのは、うまく考慮された機能だとか仕掛けなんかはあるんですかっていう議論なので、両方に存在するんですね、テスタビリティっていうのは。内部品質にも外部品質にも。

そういうような、細かいですけども。そこのニュアンスが違うので注意した方がいいよと。品質特性の話でいって、テスタビリティって内部品質ですよって言っちゃうと、ある定義でいくとそれは間違えてますよっていうことになるので。そういうところも含めて「ちょっと違いますね」って言ったんです。

テスタビリティの、ちょっとよく分かりませんけど、今こうすりゃいいんじゃないのっていうよりもAutifyならAutifyでどんどんお客さんに使っていただくっていったところで、うまいテストのやり方っていうところで、製品側でこういう仕掛けがあるとかフックがあるとか、何かこういうようなものがあるというのとAutifyの機能と連動すると、よりE2Eの世界でもきめ細かく確認できるとか。そういうやつがどんどんアイディアが出てくると思うんですね。

だからそういうアイディアをうまくAutify側で吸収できる、Autifyとして実装できるっていう話と、そうじゃなくてAutifyでこう実装してるけれども、それをうまく使うためには製品がっていうか、そういったところで何かこういう仕掛けを入れとくといいよとかっていうことをAutify側からお客さんの方に提案するみたいな。そういうエコシステムっていうのか分からないですけど、Autifyで頑張る部分、製品側で頑張る部分みたいなことがうまく連動して、Autifyコミュニティ、Autifyにこだわらなくて、自動化とか、そういうコミュニティの中で製品側で持つべき仕掛けだとかっていう話と、自動ツール側で持つ仕掛け。あまり密接にやるとオープンな世界からクローズな世界になっちゃうんで、それは避けながら、そういう世界がどんどんコミュニティの中でできてくると素晴らしいなって。だから、コミュニティ作り的なところも含めて、やるといいんじゃないかなっていうふうに思います。

末村: そうですよね。自動テスト、特にE2Eの自動テストをうまく運用していくためのベストプラクティスみたいのは、是非我々もまとめたいと思ってるし、多分他の似たようなことをやっている会社も、きっとそういうのをやっていきたいと思っているので。 できるかわかんないし、僕の立場でこういうこと言っていいか分からないんですが、今、辰巳さんがおっしゃっていたように、ちゃんとそこをオープンな世界の中でやっていきたいなという気持ちは、いち開発者としてはすごくありますね。

ありがとうございます。

少し戻って、先ほど和田 卓人さんの質とスピードの発表のときの話だったと思うんですが

多分、和田さんがおっしゃってらっしゃったのは、テスタビリティの中でもコード側のテスタビリティの話だと思うんですね。

全然そこについて全然何も意識してなかったので、辰巳さんが和田さんにTwitterでさっきの件をお話しされてたときに、確かにそうだなって思っていろいろ調べたんですが、James BachがJames Bachだったよな。James Bachだったと思うんですが（笑）　が、テスタビリティの具体的な特性としていろいろ挙げた中で、例えばなんですが理解容易性みたいな話がありまして。Understandability。テスト対象の理解のしやすさ。ここら辺ってすごくコードレベルでっていうこともあるかもしれないし、そうではなくてUIだったりAPIだったりも分かりやさみたいなところが、テスタビリティの特性のひとつだよっていうような話が確かあったはずなんですが。コードレベルではなくてソフトウェア全体の、いろんなインターフェイスの中でテスタビリティっていうのは表出してくるんだなっていうのが、すごく思いました。

はい。ちなみに辰巳さん、テスタビリティについてまだ何か話したいことってありますか。

辰巳: いやいやいや。

末村: 大丈夫ですか。

辰巳: 大丈夫です。はい。

末村: テスタビリティだったり、外部品質、内部品質みたいな話だったり。

辰巳: 本当に申し訳ないですけど、定義上の話で混乱しないようにっていうことでコメントさせていただいただけですので。

言葉の定義抜きに、和田さんの資料なんかはものすごくいいなと思っています。

末村: ありがとうございます。

辰巳: 末村さんに言われていることも別に、全くその通りだと思ってますので。あとは本当に言葉の定義だなって。

ただ気になって言ってるのは、定義を踏まえていろんなことを話したり、外国の文献を見たりとかしたときに、ちょっと混乱したりするので、そこは基本的なところは押さえておいた方がいいなというふうには思ってます。

末村: 本当にそうだと思います。定義すごく大事で、僕まだまだ不勉強なので。 実はつい最近、JSTQBのFoundation Levelに合格したばっかりなんですが、テストについて人と何か話したときに、気が付かないうちに僕が勝手に思ってる定義で、人に話しているので、全く話が通じないみたいなことがやっぱりあって。そういうときにやっぱり、辰巳さんがおっしゃっているような定義がすごく大事なと。人ときちんと同じ土俵で話すために、そこを学ばなければいけないんだっていうのをすごく痛感しています。なので、今回の突っ込みは本当にありがたかったっていうのをお伝えしておきます。

辰巳: ありがとうございます（笑）。

**末村: ** いえいえ（笑）、こちらこそありがとうございます。 全然余談なんですが、テスタビリティの話を僕がぼんやりと、テストのしやすさって大事だなというふうに思ったときに、TestingCommunityJP (※参考) というslackチャンネルで、チャンネルじゃないや、SlackのWorkspaceでポロっとその話をしたところ、やっぱりそのときも辰巳さんが確か、定義と論文を共有していただいたんでしたね。

辰巳: そうだっけ（笑）

末村: はは（笑）辰巳さんがポロポロっと助け舟を出してくださるのが凄く有り難いし、業界のためになってる感じがあるので、是非今後もよろしくお願いしたいです。

辰巳: はい、ありがとうございます。

末村: ありがとうございます。最後、最後ではないのか。もう1個ちょっと話をさせていただきたくて。リグレッションテストについての話なんですが、これも前回のPodcastの中で僕か話した件について辰巳さんにコメントいただいたやつです。辰巳さんがおっしゃっていた、リグレッションテスト、リグレッションバグっていうおっしゃり方をしてましたね。リグレッションバグは基本的にはゼロにしていかなければいけないというお話をされていて、ちょっと分からないところがあったのでお聞きしたいんですが。

リグレッションバグを0にするための、目指すための、開発者側で取るべきことって、具体的にどういうことになるんでしょうか。

辰巳: それぞれの開発されているものに応じていろいろ違うと思うので、何ともひと言では言えないんですけども。

何でその ”ゼロ” っていうのを言ってるかっていうことで。Twitterにも書いたかもしれませんけども、私メインフレームをやっていて、基本的にはメインフレームのでっかいところっていうか、やっぱりお客さん、ミッションクリティカルな銀行さんだとか、工場の生産管理だとか病院だとか、そういったところが使ってるので、バグがあるととんでもないことになる。いわゆる一般のバグもそうですけど。

リグレッションバグっていうか、昔まだ言葉がよく、レベルダウンって言ってたんですね、辰巳のソフトウェアチームの中では（笑）

従来のものよりも落ちちゃうっていうことで、レベルダウンバグとかって。それは本当にあっちゃいけないっていう。お客さん、お金を扱うところがバグで、バグの種類も、ポコンとシステムダウンするのはまだマシだと。数字が変わって、金額が100円のところが1万円になるとか、1万円が10円とかっていう、もうとんでもない社会問題にまでなってしまうので。

とにかく今まで動いてたやつからレベルダウンとか、そういうリグレッションバグが出ちゃって、それは本当に出してはいけないものだって。それは絶対ゼロにしようぜっていう。もうひとつ、開発者側からするとゼロから作るものに関してはゼロにしろって言うんだけれども、基本的にはそういうところにいかないと確率的に工程を追って見ながら出荷検査しながらですけれども。

ただ、従来言ってたリグレッションバグっていうのは、例えば何かしら問題があって修正を出して、その修正を出したがために別のところが動かなくなったって、そういったところはもう絶対ゼロにしようねっていうことで。

それは、何かしら開発技術で何とかできるはずだ、何とかしなきゃいけないっていうことでずっと取り組んできたし、今も取り組んでるかも。私は卒業してだいぶ経つので分かりませんけれど。

そういう意識で、全く違う意識で修正だ何だって。今はお客さんのところで動いてるものに対して何かを出そうとしたときに、そこまでの意識でちゃんとやろうねっていうような。

そのために、ある意味外でそういう問題が出たときには、全件開発部門が事業部長に報告なんですよ。それはなぜ発生したのか、どうすれば防げたのかっていうのを全件チェックするっていう、それも事業部長自ら見てやるっていう。だからそこまで含めて、単純に報告だけじゃなくてやっぱり再発防止のことをどういうふうに自分たちの仕組みの中でやるかとかも含めて。それを皆、検査部門も含めて議論して、検査部門も最終的には見逃した責任もあるよねっていう部分はありますから。そういった気持ちでずっとリグレッションバグ、リグレッションテストは。リグレッションバグ、テストじゃないな。リグレッションバグみたいな、そういうお客さんに動いてたものが動かなくなるようなバグっていうのをゼロにするための取り組みっていうのは、別枠でもうやっていたっていう背景があるんですよね。

だからそういう意味でちょっと気になったのは、言葉は悪いですけど、末村さんのテストで見つけるんだっていうやつが、非常に軽く見えたっていうところがあります。

末村: なるほど。

辰巳: 一般にこのリグレッションテスト、今も最近リグレッションテストみたいなのもCI/CDの世界になって、よりシフトレフトで、前段階でどんどんコーディングして作ったらCI/CDのパイプライン流して、どんどんリグレッションテストそのものがいっぱい、物量的にはどんどんテストとしてはためて、それが有効かどうかは別として、たまってるやつをどんどん早く前段階で実行して、まわしていこうぜっていうような、今はアプローチだと思いますけども。

一方ではさっき言ったような、お客さんに出しちゃいけないっていうようなところを1個でも出したらどうすんのっていうようなところで、もっとビシッとおさめるようなところのアプローチも必要なんだろうなって思ってます。

末村: それは何でしょう。例えば、最初に出荷をするときにテスト項目が100ありました。100はすごく少ないと思うんですが、一旦100にしといてください。

100あったとします。派生開発によって、10個機能が追加されました。そのときに、今まであった100とプラス10のテストケースを全部実行したら、想定している上でのリグレッションは0ではないかなと思うんですが、そうではないというふうに。

辰巳: うん。と言うのは、それもテストの原則そのものですよ。テストで全て見つかるわけではないんだから。だからもともと元あった100が全て見つけてるわけじゃなくて、リグレッションあったらそれで見つかるっていうことではなくて、100のテストケースが通っただけであって、それ以外の通り道っていうか、ケースが山ほどあるわけだから。それで保証できたと思うのは大間違いですねっていう、そういうことなんです。

末村: なるほどなるほど。

辰巳: 逆に言うとテスタビリティの話と繋げて言うと、修正の仕方みたいなものも、波及しないような修正の仕方みたいな技術があれば、ある種そこを狙い打って、テスト容易性ですね。そういったところには繋がってくると思うので、そういう、モノの作り方とかそういったものとテスト範囲とかっていうところを、どうやってうまくロジカルに、厳密にロジカルにいうとあれですけども。

どういう作戦で。

闇雲に今あるやつを流せばいいよねじゃなくて、どういうふうな修正の仕方をしたからここは確実にテストしようとか、リグレッションテストのときに、既存テストセットがないのでそれに追加をして従来のバージョンで動かしてみて、リグレッションテストに追加をして今回は修正したやつどうかなってって見るのも、それもリグレッションテストだと思うので。 だからそういう連動で考えるとかね、っていうような話。

あくまでテストを流して、(バグが) 無かったから、リグレッションバグゼロねっていう世界は、全くないと思うんです。

末村: なるほど、そうですね。

辰巳: 例えばね、そんな大きくないプログラムだったら、ある程度現実的にテストでいろいろ潰すっていうのが可能なのかもしれないです、現実的には。 ただ、どのぐらいの大きさの話をしてるかで、少し様子が変わってくるかもしれないっていうふうには思います。

末村: そこはすごく思います。辰巳さんがやって来られたのって、すごくミッションクリティカルな世界で、先ほどおっしゃっていたような銀行の勘定システムみたいのがかなり多く含まれていて。

それこそ、僕が今まで関わってきたプロダクトって、最悪数字がちょっと変わってても人は別に死なない。ただ、そうじゃない所ってやっぱりあって、そういう価値観の違いがすごく大きいかもしれないなっていうのは、ちょっと思いました。

辰巳: だからそういう風に、分けて考えていかなきゃいけないと思うんですけど、基本的にはやっぱりテストで見つかるからテスト頑張りましょうっていうアプローチは、やっぱり違うんだろうなというふうに思います。

やっぱり、開発者が修正する限りは波及範囲だとか何とかっていうこともちゃんと踏まえて、場合によっては波及範囲はこう思ってるからこうよ、っていうのをテストする人に伝えて、テストする人はそういうやつを踏まえながら、テストすることの濃淡、それこそリグレッションテストセットの中から、力ずくで全部やるっていうアプローチもあるかもしれませんけども、ある期間でやろうとしたら、そこから選択していかなきゃいけないので。

何をリグレッションテストケースとして選択をして実行するかっていうところの考え方っていうやつが、開発者の修正の波及範囲の分析、修正そのもの等を踏まえた上でのリグレッションテストのセレクションみたいなことが、うまく説明付けられるようなアプローチで作業を進めていく。

場合によっちゃ不幸にもバグがあったときには、そういう考え方に対してフィードバックをかけていくっていうような、そんな流れをつくっていかないと、テストすればいいはずだ、テスト頑張るからっていう話でいくと、そこでもう話が終わってしまうので。

だから、そういう繋がりをきちんと意識しながらやった方がいいかなというふうに思います。 リグレッションテストというかリグレッションバグというのかな。これも古い話にはなるんですけど、リグレッションテストっていう言葉、いつ頃からあるか分かりますか、想像できますか。

末村: いや、想像、全く想像できないです。ものすごく昔からあるんだろうなと（笑）

辰巳: 昔からのです。以前書いたやつでは1972年、73年にソフトウェアのテストとしては初めての書籍というか、72年に初めてのソフトウェアテストに関するシンポジウムっていうのがあって、そこの論文だとかを集めた書籍 (※2 文末「参考文献・URL」を参照のこと) が73年に出て、それが最初のプログラムテストの書籍だっていうふうに言われてるんですけども。そこにリグレッションテストっていう言葉が出てくるんですよね。

もうちょっと見ていくと、1969年に論文があって、別にリグレッションテストの論文じゃないですけども、IBMのElmendorfっていう原因結果グラフを考案した人の論文があるんですけども、そこでもリグレッションテスティングっていうのが出てくるんですね。

IBMのSystem/360のソフトウェアっていうのは、Brooksの「人月の神話」、Brooksはそのときのプロジェクトの責任者ですけど、1965年前後に出てきているソフト、それの開発のときには既にリグレッションテストをやられてたっていうか、そういう言葉でいろいろやられてた。

やっぱり、ものすごく古い、昔から皆悩んでる話なんですよ。ちょっとそういう古い話はさておき。

リグレッションテストっていうのは、リグレッションっていうバグも、もう少し場合分けをしていて、単なる修正のやつだとか、機能追加をしたときのサイドエフェクトみたいな話だとか、そういう場合分けをしていろいろリグレッションテストのテクニックみたいなことを、サーベイしている論文は、2007、8年か何かに出てたと思いますけれども。 (※3 文末「参考文献・URL」を参照のこと) 単なるリグレッションテストよりも少し場合分けをして、それの技術的なアプローチ、セレクションだとか、優先順位付け、プライオリタイゼーションみたいな話だとか、そういったやつも書いてる論文もあるので。

少しリグレッションテストを考えるとすると、そういう枠組みの中でいろいろ考えていくのがいいのかなって思っていたりします。

末村: ありがとうございます。ありがとうございます、大変参考になりました。

じゃあ、結構いい時間になってきましたので締めに入りたいと思うんですが、もしよろしければ辰巳さんの方から最近のテスターだったりQAだったりに対して、熱いメッセージがあれば是非頂きたいなと思うんですが。

辰巳: 熱いメッセージって（笑） 私そのものは皆さん、末村さん含めて、最近の実際やっているテストだとか品質やっている人たちと、こういう交流を持たせていただくのが非常に有り難いなと。 私は会社は卒業して、無職ですから。ソフトウェアのテストとか品質に関するような技術だとか勉強みたいなことは引き続き続けていきたいと思っていて。

こういうお話しして、最近の話を聞かせていただく機会をいただくのが非常に有り難くてですね。私の方から出せるのは、先ほど言いましたように昔からの話だとか、今こうなってるこういう技術だとか、こういうツールだとかがあるよねっていうのは、それは昔からの流れの中で、こうだからこうなってきたのよ、こういう背景があってこうなってるのよっていうようなことが分かると、今の皆さんの中で、より理解が深まるかなっていうふうに。 逆に深めていただきたいなっていう思いでいろんな話をしたり。

実は今、冒頭に申し上げましたけど、2008年、2009年ぐらいにソフトウェア・テスト PRESSっていう雑誌に、ソフトウェアヒストリーっていうことで、テストのいろんな技術の歴史、日本におけるテストとか品質の歴史みたいなことを書いたんですけど (※4 文末「参考文献,URL」を参照のこと)。それ以降もテスト自動化の歴史的なもの (※5 文末「参考文献,URL」を参照のこと) だとか、品質モデルの話 (※6 文末「参考文献,URL」を参照のこと) みたいなところも講演の中でいろいろ喋らせてもらったこともあるので。もう1回テストなり品質なりの技術の系譜みたいなものを、整理して皆さんにお伝えしたいなと思って。

私はそもそも在宅なので（笑）

在宅で、さらにあまり遊びに行っちゃいけないっていうことなので、こういう時間で今どちらかというと昔の資料を整理しながらですね、「もう1回テストの全体を整理してやろう」っていうことでやり始めたので。

ポロッポロッっと何らかの形で外に出すかもしれませんが、そういう昔からの技術の流れみたいなことを自分なりにもう1回まとめて、最近の技術も勉強して。

実は去年、初めに、某会社さんの広報誌の中でAIツールの最新情報 (※7 文末「参考文献, URL」を参照のこと) みたいなやつをまとめて出したんですけども、その当時にはAutifyさん知らなかったので一覧には載ってないんですけども、その後私が持ってる一覧表 (※8 文末「参考文献,URL」を参照のこと) の中にはAutifyを入れてやってますけど（笑）

そういう最近の話を勉強しながら、長い流れの中でどういう位置付けになってるかっていうことは私なりに整理して、皆さんにお伝えしたいなと。

皆さんにはそういった流れを知った上で、今何、何でって、その背景は何だっていうような考え方で取り組んでいただくと、より自分のテストとか品質に関する技術が高まったり、深みがあったり、何かしら未知のことが出てきたときに、それどういうアプローチでやるのかっていうところの参考になるかなって思うので、是非そういったことに興味を持っていただきたいなというふうに思います。

ぜひ、引き続き仲良くしてください。

末村: ありがとうございます。今回、Twitter経由で辰巳さんとコミュニケーションとって、最終的にPodcastで実際にお話しさせていただいたという形になりましたが、何て言うか、本当にいい時代になったなと思っていて（笑）

多分、今までだったらと言うか、それこそインターネットがない時代だったら絶対実現しなかったようなことですし、技術の進歩だったり、あるいは生涯寿命と言っていいのか分かんないんですけど年齢にかかわらず活動する機会だったり場所だったりみたいのが増えたり、あるいは本当に直接やり取りができて、こういうお話を聞ける機会が作れるっていうのが、有り難いことだなというふうに思いました。

辰巳: もう1点、ちょっと話長くなりますけど、もう1点。 今のネットの話でいくと、私もZoomでこうやってやるっていうのは、去年ぐらいかな、初めてやったんですけど。

ネットでいい時代になったなっていうのはものすごくそう思っていて、国内だけじゃなくて国際的にできるようになってきて。

PractiTestっていうテスト管理ツール、イスラエルのテスト管理ツールで、去年JaSSTとかSQiPシンポジウムにJoel Montveliskyさんが来て、PractiTestも日本でもビジネスしたいっていう話で、私ちょっと協力したりしてるんですけども。State of Testing、テストの現場調査レポートっていうのを2013年、14年に初めに出て、毎年出てるので、有志で翻訳をして、その現状調査レポートっていうのを、翻訳版を出してるんですけども。

きっかけは、そのレポートが出たときに、イスラエルのJoelともう1人、インドのLalit。Lalitの方に「日本語で翻訳したいんだけど」っていうふうにメールで出したんだけどね、そしたら連絡取って毎年やるようになって、そういうメールで繫がって、実際には会ったこともない人たちとやりとりをして、だからものすごい世界が広がって。

そうこうしてるうちに、「日本でもビジネスちょっとやりたいんだけど」っていう、PractiTestの話が出てきて、じゃあやろうかなっていう話で、協力しますよってお手伝いして、日本に来てやったりとか。

最近の打ち合わせっていうのは、全部イスラエルとはZoomでやったりしてますので。

最初の1本のメールがどんどんどんどん広がってそういう交流が。だから、若い人たちもできるだけ世界に、最近はコロナのあれで行くこともままならなくなりましたけど、ネットだとかいろんなことで、海外のテストとか品質の人たちと繋がれるので、機会があればそういったところでいろいろ繋がって、自分の世界を広げていくっていうのが非常にやりやすいし、そういうのをできるだけ使ってやると楽しいよねっていう。ちょっと英語は大変ですけど（笑）

だからそういうのを、Autifyさんなんかはアメリカの方にも事務所が、というか元々アメリカでいろいろやられていたので、そういう機会があるかと思うので。ぜひ向こうの人たちとも繋がりを増やして、日本のいろんなテスターと僕とかを繋いでいくっていう役割もやってくれるといいなという風に思ってます。

すいません、余計な話になりました。

末村: いえいえ、ありがとうございます（笑）頑張ります。

辰巳さんに来ていただいたのに、完全に今の今まで、OnlineTestConfとState of Testingの話をするのを忘れていた（笑）　ありがとうございます。

辰巳: いえいえ。

末村: ちなみにどちらのイベントにも、イベントというか、State of Testingの翻訳には、弊社の創業者山下さんも。

辰巳: そうそう、山下さんに来てもらって、その流れで昨年12月のOnlineTestConf Japanで喋っていただくのも、AI関係のツールで山下さんにお願いしたいなということで、お声かけさせてもらってやっていただいて、Autifyさんにはいろいろお世話になってます。

末村: こちらこそ、仲良くしていただいてありがとうございます（笑） じゃあ、結構いい時間になりましたので、すごく名残惜しくはありますがこの辺で切らせていただきます。

辰巳: また何か機会がありましたら。

末村: はい、是非またいらしてください、お待ちしております。 この騒動が落ち着いたら是非、弊社の方にも遊びに来てください、お待ちしておりますので。

辰巳: ありがとうございます（笑）

末村: お願いします！じゃあ今回のPodcastは終わりです、ありがとうございました。

ありがとうございました。
 
Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開していますので、ぜひこちらからご覧ください。

参考文献・URL一覧

※1

TRW社の1973年のレポート
B. Boehm et al., “Characteristics of Software Quality,” TRW Software Series, TRW-SS-73-09, December 1973

辰巳 敬三さんブログ

辰巳 敬三さん著

※2

書籍「Program Test Method 」
参考: https://www.worldcat.org/title/program-test-methods/oclc/446069

参考: 「ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬 クロージングセッション) 20101219」
https://www.slideshare.net/Bugler/wacate2010-20101219

※3

S. Yoo, M. Harman, Regression Testing Minimisation, Selection and Prioritisation : A Survey, In Software Testing Verification and Reliability, 2007
http://www0.cs.ucl.ac.uk/staff/mharman/stvr-shin-survey.pdf

※4

ソフトウェア・テスト PRESS Vol.8
https://gihyo.jp/book/2009/978-4-7741-3749-0

ソフトウェア・テスト PRESS Vol.9
https://gihyo.jp/book/2009/978-4-7741-4013-1

※5

「テスト自動化クロニクル – デジタルビジネス時代の今、テスト自動化の背景と歴史を振り返る – 」
JaSST’16 Tokai 基調講演, 2016年12月2日
https://www.slideshare.net/Bugler/ja-sst2016

※6

「ソフトウェア品質技術の歴史を振り返る – ソフトウェア品質測定を中心に -」
https://www.slideshare.net/Bugler/ss-77998794

※7

辰巳 敬三さん寄稿
「AI利用テストツールの最新動向 ～AIはテスターを超えるのか～, VERISERVE NAVIGATION 2019年1月号, 2019年1月」
https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol16.pdf#page=18

※8

「ソフトウェアテストの歴史と近年の動向」
slide-45. AIを利用したテストツール
https://www.slideshare.net/Bugler/ss-139696080/45