個人的にソフトウェアテストに関して有益（後から見返したい）と思った論文・資料を列挙しておく。
随時、追加・更新していく。

[1]秋山浩一,「テスト技法の位置づけとテストの十分性」，JaSST'09 Tokai，2009

http://jasst.jp/archives/jasst09n/pdf/S2.pdf
この講演で初めて「品質コスト分析」を知った。テスト技法の全体象を教えていただいた。

[2]鈴木誠,「品質判定マップによる人員配置とテストマネジメント」，JaSST'09 Tokai，2009

http://jasst.jp/archives/jasst09n/pdf/S3-2.pdf
「品質判定マップ」という仕組みは、すごく面白い。活用できそうと感じた。その後、活用する場面に出くわしてはいない。

[3]松尾谷徹,「テストから観た実体のモデリングと実装構造の評価～ 検証指向設計の実現に向けて ～」，JaSST'15 Tokai，2015

http://jasst.jp/symposium/jasst15tokai/pdf/S1.pdf
私の人生を変えてくれた発表。私の論文・発表で何回か参考文献にさせていただいている。「検証指向設計」「テストデバッグ」等大切な考え方が多数述べられている。

[4]西康晴，「Re-collection of embedded software QA in the last decade」，JaSST'20 Tokai，2020

https://www.slideshare.net/YasuharuNishi/recollection-of-embedded-system-qa-in-the-last-decade
P32-36に示されている「バグのミクロ分析」「構造分析」「ソフトウェアトラップ分析」が興味深い。私も現在、同等の取り組みを行っている。

[5]西康晴，「車載ソフトウェアの品質保証のこれから」，2020

https://www.slideshare.net/YasuharuNishi/ambidexterity-of-automotive-software-qa
P7の絵とP22の「QualiTrax」という言葉が好き。にしさんの発表からはいつも刺激がいただける。

[6]西康晴，「モデルと作戦盤」，2018

http://qualab.jp/tacticsboard/
「モデルは作戦盤。手順書は作戦盤。方法論も作戦盤。ついでに言えばプロセスも作戦盤。」という言葉は響いた。

[7]ＴＦＣ　ＫＡ・ＲＩ・ＹＡ，「TFC KA・RI・YA流テストのすすめ」，テスト設計コンテスト'14，2014

http://aster.or.jp/business/contest/contest2014/pdf/presentation_tfc_kariya.pdf
プレゼン資料が衝撃的。面白い。

[8]MKE98，「自動販売機のテスト設計における目指したことと工夫点」，テスト設計コンテスト'14，2014

http://aster.or.jp/business/contest/contest2014/pdf/presentation_mke98.pdf
我々のチームの資料。よい思い出。

[9]TETTAN，「話題沸騰ポットを対象としたテスト開発の実践とその工夫」，テスト設計コンテスト'13，2013

http://aster.or.jp/business/contest/contest2013/pdf/presentation_tettan.pdf
河野さんから刺激を受けた。私達のテスト設計コンテストの成果にも大きな影響を与えている。

[10] 野中誠，「今さら聞けないソフトウェア品質データ分析の基本」，ソフトウェアエンジニアリングシンポジウム2014(SES2014)，2014

http://www.se.mng.toyo.ac.jp/wordpress/wp-content/uploads/2014/09/SES2014-tutorial-nonaka.pdf
SQiP研究会で野中さんからご指導いただき、"不具合"、"欠陥"、"誤り"等の用語を使いわけるようになった。機能性欠陥と発展性欠陥という分け方は好き。

[11]Project Fabre，「過失に着目した欠陥のモデリング～バグ分析はなぜうまく行かないのか？～」，JaSST'13 Tokyo，2013

http://www.jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf
欠陥のモデリングをするのは本当に面白い。

[12]松尾谷徹，「ソフトウェア論理の設計/検証における決定表の応用」，日本信頼性学会誌 信頼性/34 巻 (2012) 6 号 p.397-404，2012

https://www.jstage.jst.go.jp/article/reajshinrai/34/6/34_KJ00008159905/_pdf/-char/ja
決定表（デシジョンテーブル）の詳しい説明がされている。

[13]堀田文明，「論理の設計とテストを考える ～CFD++、その目指すところ～」，JaSST'13 Tokai，2013

http://www.jasst.jp/symposium/jasst13tokai/pdf/S4-1.pdf
決定表を分割する技が説明されている。

[14]松尾谷徹，「テスト／デバッグ技法 効果と効率」，会誌「情報処理」 Vol.49 No.2 p.168-173，2008

https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=60855&item_no=1&page_id=13&block_id=8
テストを検算の一種とする考え方が示されている。

[15]松尾谷徹，「ソフトウェアテストの展望」，JaSST'07 Tokyo，2007

http://www.jasst.jp/archives/jasst07e/pdf/A7.pdf
有則・無則・禁則の説明がされている。

[16]水野昇幸，「テストケースの表現と粒度」，2017

http://blog.amateur-factory.jp/?eid=1444287
http://blog.amateur-factory.jp/?eid=1444288
テストケースについてのよい記事。テストケースとは何か、テスト項目とは何か、を定義しておくこと重要と再認識した。

[17]湯本剛，「変更における状態を含むテスト網羅尺度とテストケース抽出法の提案」，ソフトウェア・シンポジウム2017，2017

https://www.sea.jp/ss2017/download/1-1_SS2017.pdf
この論文の技法を取り入れたい。CRUDマトリクスから、機能の組み合わせテストを考えるのは、理にかなっていると思う。データを介して機能間の関連が生まれる。
アプリからのAPIの呼び出し順なんて、色んな組み合わせが考えられるから、どんな組み合わせでテストしてるか、データアクセスを軸に説明しやすいようにしたくて、CRUDの活用を考えてます。
Cを不揮発からの読み込みと考えると面白い。
単純にU→Rではなく、U→C→Rの組み合わせも出てくる。D→RだけでなくD→C→Rとか、U→UだけでなくU→C→Uとか。
状態遷移テストのスイッチカバレッジみたいにテスト設計の基準を決めておきたい。過去の不具合経験から。

[18]牛尾剛，「6 Minutes DevOps: テスト駆動開発」

https://channel9.msdn.com/Blogs/livedevopsinjapan/6min-DevOps-10
https://sec.ch9.ms/ch9/3a21/18b6d2c2-6f2a-4ba7-a4d2-93c59b353a21/6minDevOps10_mid.mp4
テスト駆動開発のイメージがすごく理解できた動画。

[19]@mima_ita，「20年物のC言語で作られたシステムのテスト工程を改善しようとした話」

https://qiita.com/mima_ita/items/cb94a767e9d9e5a84a2f
「単体テスト環境の分離」という話は共感した。ドライバスタブは共通化したほうが流用できてよいが、副作用もある。

[20]野田 夏子，岸 知二，「プロダクトライン開発における検証」，コンピュータソフトウェア 30巻 3号，p.3_3-3_17，2013

https://www.jstage.jst.go.jp/article/jssst/30/3/30_3_3/_article/-char/ja/
ソフトウェアプロダクトライン開発における4つのテストの戦略が示されている。
私のプロジェクトでは、この論文に示されている4つのテスト戦略のうち「テスト資産の再利用」という戦略をとった。そして、テスト資産の流用率という指標を定義した。

探している資料

• N-Switchカバレッジに関するよい資料。昔、1-Switchでだいたい十分とどなたかからお聞きしたが、忘れてしまった。