MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST’16東京のコミュニティブースに出展します＠探索的テスト研究会

JaSST exploratory testing Conference Community

　2016年3月8日(火)～9日(水)に開催される「ソフトウェアテストシンポジウム2016東京(JaSST'16 Tokyo)」のコミュニティブースで私が所属する『探索的テスト研究会』からポスター発表いたします。

発表内容は、「探索的テストのモデル」「探索的テストに関するFAQ」の二本立てです。

「探索的テストのモデル」について

　探索的テストを説明するとき、「事前にテストケースを設計せず、テスト実行と、テスト対象に関する学習を、同時並行で実施するスタイルです。」と国内外の文献で言及されています。しかし、探索的テストの性質としてテスターのスキルに依存する部分が大きく、かつプロセスも一意に定められるものではないので、他組織や他社の方と探索的テストに関する議論がかみ合わないことがあります。
　前述の課題を解決するため、探索的テスト研究会では議論の土台として、探索的テストのモデルを検討しました。
　本モデルは、探索的テストを行うときに「何の情報を参照し、どのように考えたり行動して、何を残すのか。」を流れとして表現しています。なお、本モデルはβ版ですので、JaSST'16に参加されるみなさまとの議論やご意見をフィードバックして、ブラッシュアップします。

「探索的テストに関するFAQ」

　探索的テスト行うときの疑問点をFAQ形式でまとめ、1つの回答として提示しています(※ポスターの掲示サイズが限られていたり、議論中の内容がありますので、一部内容を掲示しています)。なお、本FAQはβ版ですので「探索的テストのモデル」と同様にJaSST'16に参加されるみなさまとの議論やご意見をフィードバックして、FAQをブラッシュアップします。

「探索的テストのモデル」および「探索的テストに関するFAQ」について議論したいみなさまへ

　JaSST'16東京の参加申込が必要です。
参加申込の受付は終了していますが、会場で当日券が販売されますので、参加申込がまだの方は当日券を購入頂いてからコミュニティブースへお越しください。

みなさまからの議論やご意見をおまちしております。

〆

追記：コミュニティブースに説明員が常駐する時間帯について

　下記を予定しています。会場の混雑状況や研究会メンバーの都合により一時的に不在になるかもしれませんが、ご了承いただきますようお願いいたします。

<1日目>

  • 11:40～13:10
  • 14:40～15:10
  • 16:10～16:50
  • 18:20～18:40

<2日目>

  • 11:30～11:50
  • 12:25～14:00

システムテスト自動化カンファレンス2015(5)「楽天の品質改善を加速する継続的システムテストパターン」

TestAutomation STAC2015 Conference

　2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
　本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

　講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～　早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"　→<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと -　/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)　→<資料>
4.楽天の品質改善を加速する継続的システムテストパターン　/荻野 恒太朗(楽天), 菊川 真理子(楽天)　→<資料>
5.キーワード駆動によるシステムテストの自動化について　/小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)　→<資料>
6.Testing Tools for Mobile App　/松尾　和昭(クックパッド)　→<資料>
7.パネルディスカッションLIVE！　テスト自動化”エンジニア” の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

　今回は、「4.楽天の品質改善を加速する継続的システムテストパターン」について紹介します。

4.楽天の品質改善を加速する継続的システムテストパターン//荻野 恒太朗(楽天), 菊川 真理子(楽天)

(1)開発の永続性と継続的テスト

(1-1)Facebook社の論文
  • 開発
    • どんどんリリース
  • テスト
    • テストを成長させる
(1-2)永続的開発
  • 課題
    • ○○機能の仕様を変更→バグがあった。
    • ○○機能の仕様を変更をやめた→どこをどう直したか追跡できない。
  • 困ったこと
    • 用空が適切に優先順位づけ：ない
    • 要求と開発用件のトレーサビリティ：ない
  • 解決
    バージョン管理など
(1-3)CI
  • 課題
    • 継続的な品質のフィードバックが困難。
  • 困ったこと
    • 継続的にソースコードがコミットされない
    • テスト実行時間：長い
    • 品質可視化コスト：高い
  • 解決
    • 毎日自動テスト：Jenkinsで毎日実行することで、いつ失敗したか把握できる。
    • CIの導入：ツールを用いたレポートの自動化
      • メトリクスを自動収集し、現場で品質改善したことが目で見える→モチベーションが上がる。
      • デプロイの頻度で価値を見える化。→機能追加の頻度(2weekで1つから1日で1つ)
    • SQiP2014の経験発表も参考のこと
(1-4)Infrastructure as Code
  • 課題
    • 頻繁なデプロイ・リリースができない。
  • 困ったこと
    • サーバー構築が大変
      • 手動でインフラ構築
      • 秘伝の手順書
      • インフラ構築手順：テスト未実施
  • 解決
    • vagrantでサーバー環境の構築を自動化
    • インフラの設定：SCMで管理
    • インフラ構築手順：テスト実施
(1-5)CI in Test
  • 課題
    頻繁なテスト実行ができない。
  • 困ったこと
    • 問題切り分け：時間がかかる
    • テストの継続的な変更と信頼性が問題
    • テスト設計の変更に時間がかかる
  • 解決
    • 自動テスト：自動テストコードは、gitでバージョン管理。
    • 手動テスト：テストケース管理ツール
      • テスト開発環境を提供
      • テストしてからコミットする
      • テスト設計のリファクタリング容易性(?)の改善

(2)生産性と自動テスト

(2-1)自動テストによる生産性改善

　中身が分からない貯金箱より、目に見える貯金箱。

(2-2)自動テストの実装
  • 課題 テスト自動化のカバレッジが低い。
  • 困ったこと
    • テスト確認項目がシステムから取得不可
    • 外部サービスとの結合テストが困難
    • テストデータの作成が困難
  • 解決 テスト要件をプロダクトに入れる。

(3)信頼性とアジャイルテスター

(3-1)アジャイル4象限
  • 課題
    バグの見落とし
  • 困ったこと
    • 無駄なテストや重複するテストの実行
    • 非機能テストの見落とし
  • 解決
    「誰の？」「どんな？」テストの価値を整理
    • ユーザストーリーテスト
    • オペラビリティテスト
(3-2)スキルセット
  • 課題
    テストができるひと、やりたい人が少ない。
  • 困ったこと
    • テスト自動化エンジニア：新しい
    • トレーニング不足
  • 解決

所感

　現場で困っていることを挙げてあるべき姿を明確にしてから、「解決したい課題(品質)」→「解決方法(コンセプト)」→「実装」と目的から手段にブレークダウンする流れから、QC活動の良好事例に似ていると思いました。私の現場でも、課長や一部の同僚や私が「あるべき姿って何だろう？」と問いかけ、「何がボトルネックなの？」と課題を洗い出し、「じゃあ、どうする？」と課題に対する取り組みを進めています。私の現場では他社事例に触れることが少ないので、本発表の事例での問題解決の良いところを何らかの機会で紹介してみようと思います。

システムテスト自動化カンファレンス2015(4)「広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-」

TestAutomation STAC2015 Conference Management development environment

　2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
　本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

　講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～　早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"　→<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと -　/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)　→<資料>
4.楽天の品質改善を加速する継続的システムテストパターン　/荻野 恒太朗(楽天), 菊川 真理子(楽天)　→<資料>
5.キーワード駆動によるシステムテストの自動化について　/小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)　→<資料>
6.Testing Tools for Mobile App　/松尾　和昭(クックパッド)　→<資料>
7.パネルディスカッションLIVE！　テスト自動化”エンジニア” の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

　今回は、「3.広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-」について紹介します。

3.広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)

(1)B to B でエンプラシステム

　データ登録の比重が大きい。

(2)困ったこと「妙につらい」

  • 小改修だが...
    • 大規模かつ複雑化
  • 結合が...
    • 道具とやり方が合わない
  • なんとなく動いていて...
    • 積み重なる技術負債

(3)組織変更のタイミング

　(組織変更後の)部門長「いちから全部変えろ！」というきっかけがあった。

(4)目指したもの

  1. 3倍早い開発スピード
  2. 変わるべきは「自分たち」
  3. システム刷新は「結果」

(5)やったこと

(5-1)体制づくり
  1. リード役の配置
    部付きで刷新活動に集中できる環境へ
  2. 仲間づくり
    同じ問題意識の人に声かけ。
  3. 部門長による宣言
    刷新することをステークホルダや部内メンバに宣言した。
(5-2)プログラミング言語を変える
  • 変える前 型が使えなくて、痛い目(金銭的損失)にあった。
  • 要件 コンパイルできること、型宣言。(C++もあったけど)Javaを選択した。
  • その他
    しょうもないレベルのものを潰す。
(5-3)テストできるアーキテクチャに
(5-4)テスト向けのDSL採用(Spock)
  • JUnit
    Java言語でテストを書くことになるが、Java言語はテストを表現する手段がない。
  • 記述言語は、JVM言語のgroovy
    テストを記述するためのDSLが構築されている。
  • IDE
    eclipseからInteliJに変えた。
(5-5)CI/CD、静的解析
  • Cloverによるカバレッジ計測
  • Coverityによる静的解析
    • Quality Advisor
      NullPointerExceptionを検出。
    • Test Advisor
(5-6)インターフェイス定義言語(IDL)
  • テストと別の観点で、開発効率向上と品質向上のため、インターフェイス定義言語(IDL)を選択。
  • OSSを利用できないか検証したが、以下の理由で一から作った。
    • バリデーションが表現できない
    • ドキュメントが生成できない

(6)ふりかえっての所感

  1. 問題検出をできるだけ前工程にもってくる
  2. テストできないと言い訳される要因を潰す
  3. 未熟でも早めに適用/フィードバック受けて磨く
  4. 部門長サポートと仲間が大事

所感

　開発における課題を乗り越えるため、技術的に工夫することも大切ですが、組織の中でも部門長の後押しが無いと、自動テストシステムの開発や保守が頓挫するので、仲間作りも軽視できないと思いました。また、組織の体制や役割も適切に機能しないと、技術的に工夫することが難しくなるので、どのように組織のマインドを変えるか、クリアすべき課題に取り組むことも大切と思いました。

システムテスト自動化カンファレンス2015(3)「自動家は見た ～自動化の現場の真実～」

TestAutomation STAC2015 Conference Management

　2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
　本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

　講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～　早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"　→<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと -　/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)　→<資料>
4.楽天の品質改善を加速する継続的システムテストパターン　/荻野 恒太朗(楽天), 菊川 真理子(楽天)　→<資料>
5.キーワード駆動によるシステムテストの自動化について　/小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)　→<資料>
6.Testing Tools for Mobile App　/松尾　和昭(クックパッド)　→<資料>
7.パネルディスカッションLIVE！　テスト自動化”エンジニア” の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

　今回は、「2.自動家は見た～自動化の現場の真実～」について紹介します。

2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"

(1)1年間の活動＠みうみう(M氏)

(1-1)背景
  • 開発対象
    • B to BのWebアプリ
    • ソースコードはカオス的状態
    • メンテナンスされていない
  • 開発チーム
    • 5～7名規模
    • 所属会社：様々
    • スキル：バラバラ(ピンからキリまで)
  • M氏の立ち位置
(1-2)開発チームに参入
  • 与えられた課題を実現。
  • 8割：開発、2割：自動家の割合で進めるよう、オーナーから要望があった。
(1-3)状況が変化

　方針が変わった。

  • 開発規約の導入 WBS導入によるプロジェクト管理 詳細設計書の作成 *従来のアプリから、新機能を搭載するため別アプリとしてフォークされる。
  • M氏
    • フォークされた新アプリのソフトウェア構造の整理＆再設計をしていた。
    • 非公認のレビュアーやリファクタリングも担当した。
    • 自動家としての業務が縮小し、ついに離脱。
(1-4)自動化離脱後のふりかえり

　「雇い主」と「お客さん」が望んだ場合に自動化の効果が最大になるのでは？

(2)マネージャ側＠みずのり

(2-1)パターン

　「うるさい人がいなくなる」

(2-2)マネージャ
  • コンフォートゾーン
    • 自分の経験や知識があり、因果関係を予想できる範囲。それ以外は、理解するのは容易ではない。
    • 自動化は、範囲外となることが多い。
(2-3)抵抗の6階層
  1. 問題
    1. 問題の存在に合意しない
  2. ソリューション
    1. ソリューションの方向性に合意しない
    2. ソリューションが問題解決できると思わない
    3. ソリューションの実行でマイナス影響が発生
  3. 解決策実現
    1. ソリューションの実行を妨げる障害がある
    2. その結果起こる未知のことへの恐怖
(2-4)本当に価値があれば

　数値で説明できるメトリクスを持つことが大切。

(3)「自動家」を「仕事」にするには

(3-1)顧客サイド

　自動化システムの成果物を得るには？

(3-2)マネージャサイド
  • 組織でお金が儲かる
  • ロジック検証
    • 投資に対するペイバックどの位か？
(3-3)M氏(現場)サイド
  • 本当に「売るべきモノ」は？
  • 開発現場での制約
    • 「社内スタンプラリーお遍路」
    • 「内線番号の手配」
    • 「役職クラス以上が見れる進捗閲覧システム」
    • 「テスト自動化の道具を印刷して自前で再現」
    • ネット禁止、OSS利用不可
  • 開発現場での制約を打ち破るには？
    • 自動家を増やす！

所感

　自動テストを進める上の課題や問題点で自組織に該当するものもあり、現場とステークホルダの間の溝を埋められるよう、自動テストで実績をあげることが必要と思いました。また、「利益を増やす」「損失を減らす」の2点が両輪となるよう、問題提起と解決案を見つけることが課題として進める必要があると思いました。

システムテスト自動化カンファレンス2015(2)「テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～」(後編)

TestAutomation STAC2015 Conference Skill Development

　2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
　本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

　講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～　早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"　→<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと -　/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)　→<資料>
4.楽天の品質改善を加速する継続的システムテストパターン　/荻野 恒太朗(楽天), 菊川 真理子(楽天)　→<資料>
5.キーワード駆動によるシステムテストの自動化について　/小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)　→<資料>
6.Testing Tools for Mobile App　/松尾　和昭(クックパッド)　→<資料>
7.パネルディスカッションLIVE！　テスト自動化”エンジニア” の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

　今回は、「1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～」について後半部分を紹介します。

1.テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会)

(1)ポリシー

(1-1)Test.SSFとの関係は？

　 特定非営利活動法人 ソフトウェアテスト技術振興協会(ASTER)及び一般社団法人 ＩＴ検証産業協会(IVIA)が策定したTest.SSF(@ASTER)/(@IVIA)とは別。

(1-2)目的

　現場の人が「学習するための指標」を作れるようにすることを目指す。何が弱くて、何を勉強すればよいかが分かるようにする。

(1-3)想定しているもの。

　レーダーチャートで表現。

(2)状況

(3)自動化のスキル

　AutomaitonTest.SSF樹形図

(3-1)テスト自動化関連の管理
(3-1-1)上手くテスト自動化を進め、維持する。
  • 計画の策定
    • 各領域の見積もりと計画
    • テスト対象のSDLC(System Development Life Cycle)との協調
(3-1-2)テスト自動化システム関連のトレーニング(教育)
  • スキル把握
  • カリキュラム
  • 教育の実施の管理
(3-1-3)テスト自動化関連の保守

　「テスト自動化研究会で多く議論出たもの」
→ボトルネックになるところ。

  • テスト自動化システムの構成管理
  • 自動テストケースの構成管理
  • 変更管理
  • 不具合管理
(3-1-4)効果の予測・計測

　自動化KPIの設定と測定。

(3-1-5)フィードバック
  • フィードバックサイクルの構築
  • テスト自動化作業、プロセスへ
  • テスト対象プロダクトへ
  • ふりかえり
(3-2)テスト自動化戦略の策定
(3-2-1)策定準備
  • 技術蓄積
  • テスト要求の分析
  • テスト自動化の方向性分析
  • テスト自動化の効果の補床
(3-2-2)戦略の策定
  • テスト自動化要件の定義
  • 目的の策定
  • SUTの状況把握、調整
  • アプローチ決めなど

　どうやって、いつツールを使うか？

(3-3)テスト自動化システムの開発

　「テスト自動化システムを作る。」

(3-3-1)自動化システムの設計
  • システムアーキテクチャ設計
  • 実行プロセスの設計
  • 自作部品の設計
  • 運用ルール
(3-3-2)実装
  • テスト容易性向上
  • ツールチェインの実装
  • 実行環境の構築
(3-3-3)検証と妥当性確認
  • テスト自動化システムの検証
  • 妥当性確認
(3-4)自動テストケースの開発・実行
  • 「自動テストケースを作り、実行する。」
    • 特定目的のために自動化されたテストケース。実行されるテストコードやテストスクリプト。
  • 自動テストケースの開発
    • テストケース設計
    • 環境構築など
  • 自動テストケースの実行

(4)テスト自動化システム

  • Monitoring
  • Drive
  • Judge
  • Report
  • Initialize
  • Teardown

(5)役割

(5-1)キャリアやロール

　検討中。

(5-2)検討対象
  • 自動テストコード作成
  • テスト自動化システムの開発
  • アーキテクト
(5-3)今後必要になってくる(かもしれない)役割
  • SBST
    • Search Based
    • ICST(International Conference on Software Testing)での研究
    • テストケース・戦略を探索理論で探索
  • 結果分析
    • 自動不具合分析
    • テストケースへ自動的にフィードバックして、テストデータやテストケースを変更など。

(6)展望

(7)言葉が定義できないと議論できない

　「パブリックコメントよろしくね！」by @snsk

所感

　自動テストに関する知見が体系化されると、自動テストを進めるときに「何を考慮すると、プロジェクトが上手く進められるか？」「現状から次の目標を達成するために何から取り組むか？」「陥りやすい罠はどのようなシチュエーションか？」が考えやすくなると思いました。今後の動向を気にしながら、開発チーム内での取り組みを考えていこうと思います。また、最後の「言葉が定義できないと議論できない」は、様々な技術コミュニティの課題ですので、開発メンバーやコミュニティメンバーが共有できるように土台作りを進めようと思います。

システムテスト自動化カンファレンス2015(1)「テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～」(前編)

TestAutomation STAC2015 Conference

　2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
　本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

　講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～　早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。　コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た～自動化の現場の真実～　/".reviewrc"→"おいしが"　→<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと -　/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)　→<資料>
4.楽天の品質改善を加速する継続的システムテストパターン　/荻野 恒太朗(楽天), 菊川 真理子(楽天)　→<資料>
5.キーワード駆動によるシステムテストの自動化について　/小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)　→<資料>
6.Testing Tools for Mobile App　/松尾　和昭(クックパッド)　→<資料>
7.パネルディスカッションLIVE！　テスト自動化”エンジニア” の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

　今回は、「1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～」について前半部分を紹介します。

1.テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～ 早川 隆治(テスト自動化研究会)

(1)ISTQB エキスパートレベルシラバス

  • スキルや役割を解説。
  • STARの有志で翻訳(ただし、非公式)。
  • シラバス＝教科書、エキスパート＝専門家
(2)シラバスの概要ページ
  • 更新され、中身が無くなっている。
  • シラバス自体もダウンロード不可...
(3)シラバスのpart
  • テスト自動化の管理
  • テスト自動化の技術
(4)略語
  • TAE:Test Automation Engineer(テスト自動化エンジニア)
  • TAS:Test Automation Solution(テスト自動化ソリューション)
  • TAA:Test Automation Architecture(テスト自動化アーキテクチャ)
  • gTAA:Generic TAA(包括的テスト自動化アーキテクチャ)
  • SUT:System Under Test(テスト対象システム)
(5)目次(内容)
  • 3章 gTAAが多くのページを割いている
  • 6章→手動テストの自動テスト環境への変換
(6)シラバスに書いてあること→スキルが必要なもの
(6-1)TAS

　テスト自動化の仕組み構築。

  • 分析、設計、開発、テスト、配置、展開、...→分析へ(※S/W開発と同じ)
  • SUTとの互換性
    • チーム(同じようなスキル保有者で構成)
    • 技術
    • ツール
  • SUTとTASの同期
    • S/W開発ライフサイクルは2倍、手動テストとの同期も考慮するとS/W開発ライフサイクルは3倍になる。
(6-2)TAA
  • 単純化
  • 再利用
  • 全体に影響を与えず交換可能
  • メンテナンスや拡張が容易
(6-3)gTAA
  • Test Generation Layer
    • テストケース設計の支援
  • Test Definition Layer 　
    • テストケースやテストスイートを定義
  • Test Execution Layer
    • テスト実行とロギング
  • Test Adpation Layer
(6-4)CI(Continious Inprovement)継続的改善
  • TAS改善の選択肢
    • 高い効率性
    • 使いやすさの向上
    • 付加的な機能
    • テスト活動のサポートの改善
  • 改善するときに考慮する範囲
  • TPIの改善ソリューションではなく、TAS改善
(7)シラバス：2014年公開

　ほぼ、実行の自動化が対象。

所感

　ISTQBで自動テストに関するシラバスが存在していたことを初めて知りました。現在は存在が無くなっているので情報が分かりませんが、ISTQBなどの海外からの情報もアンテナをもう少し張ろうと思います。

JaSST15東海(4)「ワークショップ：意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」

JaSST Tokai Conference TestDesign

　11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会

以前書いた記事

masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com

　今回は、セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」です。

4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)

(1)ワークショップを通じ...

　下記3点が現場でも実践できるきっかけとする。

  1. 観点出しができる。
  2. 仕様書の裏返しからの改善ができる。
  3. テスト目的が明確になる。

(2)ワークショップの流れ

  1. 仕様書を読み、「テストしたいこと」「確認したいこと」をマインドマップで書き込む。
  2. 「テスト分析の三角形(※1)」を見て、仕様書から気付くことをマインドマップに追記する。
  3. 「タートル図(※2)」を見て、仕様書から気付くことをマインドマップに追記する。
  4. グループでディスカッション
  5. 「意地悪漢字(※3)」を見て、仕様書から気付くことをマインドマップに追記する。
  6. 「対立漢字(※4)」を見て、仕様書から気付くことをマインドマップに追記する。
  7. グループでディスカッション

※1：ソフトウェアテストシンポジウム 2015 九州 招待講演 セッション5「テストエンジニアを育てるためのポイント」 講演資料 47枚目スライドを参照のこと。
※2：同上：講演資料 52枚目スライドを参照のこと。
※3：同上：講演資料 54～55枚目スライドを参照のこと。
※4：同上：講演資料 60～62枚目スライドを参照のこと。

(3)私が書き出した内容

http://f.st-hatena.com/images/fotolife/M/MasaoApril/20160124/20160124233952_original.jpg?1453647330

(4)実例

  • その1
    要件定義でイレギュラーケースを考えるために「意地悪漢字」「タートル図」を活用した。
  • その2
    • 「意地悪漢字」「タートル図」をレビューで活用している。
    • 理由は、レビュー観点をリスト化すると、イメージが沸かないため。

所感

　「テスト分析の三角形」「タートル図」「意地悪漢字」「対立漢字」を各ステップ毎に見ると、何らかの気づきが次々出てきました。様々な切り口でテスト対象を見ると、鋭く感じるものがあり、製品を取り巻く世界を更に知る必要があると思いました。

JaSST15東海(3)「事例発表：安全系組込ソフトウェア開発におけるユニットテストの効率化」

JaSST Tokai Conference Concolic test

　11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会

以前書いた記事

masaoapril.hatenablog.com masaoapril.hatenablog.com

　今回は、セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」です。

セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)

1.背景

　安全系組み込みソフトウェアでは、自動車機能安全規格ISO26262の準拠が求められている。

2.ユニットテスト

3.CREST

3.1 サイト

http://jburnim.github.io/crest/

3.2 CRESTとは？

3.2 工夫したこと

  • パスが網羅できるか確認するため、複雑度(以下CCN)=2,4,8のサンプルソースコードを作成して、CRESTで確認した。
    • 確認の流れは、「ソースコード→静的解析ツール→関数入出力情報→CREST」である。
    • CRESTでオプションスイッチを色々試し、テストケースを全て作成。
  • CCN=28にしても、テストカバレッジ率100%未達成なので、入力値に制約をかけた。
  • マイコン変更時
    • マイコンAとマイコンBでCRESTでかけた結果を比較する。
    • 課題は、各bitデータでは生成時間がかかること。

所感

　ユニットテストの手間を減らすため、ツールの選定から、実務に耐えうるかを検証するために試行し、適用可能であることを確認した内容でした。自組織のユニットテストは、手作業のところも多々あるので、手間を減らしながらもユニットテストで検出できるバグが効率的にできるように進める必要があると思いました。

"State of Testing Survey 2016"に回答してみた

State of Testing

　先週の記事「"State of Testing Survey 2016"が1/7より実施」で書きましたが、PractiTestというサイトで"State of Testing Survey 2016"が開始されましたので、(英語で)回答してみました。 なお、回答の〆切日は書いていないですが、昨年の〆切は2月初めでしたので、今回も同じ時期と思われます。

[1]過去の調査結果

　下記を参考下さい。

<2013年>

英語版
日本語版
※日本語版がありましたので追記しました。
たつみさん、ご指摘ありがとうございました。

<2015年>

英語版
日本語版

[2]回答先

http://qablog.practitest.com/state-of-testing/の"TAKE THE SURVEY"から回答できます。

[3]質問内容(概要)

　下記、25の質問がありましたので、回答される方は参考頂ければ幸いです。
(意訳ですので、解釈が誤っている可能性があることをご了承下さい。)

  1. 職位は？(テストエンジニア、テストマネージャ、テストリーダ、テスト自動化のテスターなど)
  2. 経験年数は？
  3. どの地域で働いていますか？(アフリカ、アジア、中国、西ヨーロッパ、インド、アメリカ/カナダなど)
  4. 年収は？
  5. "testing"をどのように学んだか？(研修、ISTQBなどの資格認定、自習、OJTなど)
  6. テスト技術の維持向上はどのようにやっているか？(書籍、テストのカンファレンスやセミナー、Twitterやblog、トレーニング研修など)
  7. 過去3年間、勉強会に参加していましたか？また、何の研修やカンファレンス、セミナーに参加していましたか？
  8. 会社の従業員数は？
  9. 組織内のテスターの人数は？
  10. 会社の拠点数は？
  11. 開発スタイルは？(ウォータフォール、アジャイル、TDD、DevOpsなど)
  12. テスターの役割は？(テスト、ユニットテスト、顧客サポート、要求収集、ツール開発など)
  13. テストドキュメントのタイプは？(高レベルテスト計画、低レベルテスト計画、詳細なテストスクリプト、テストチャータ、マインドマップなど)
  14. マニュアルテストのテクニックは？(スクリプトテスト(テスト仕様書に従ったテスト)、探索的テスト、バグハンティング、ペアテストなど)
  15. テスト管理ツールは？(ExcelなどのOffice系アプリ、BTS、プロジェクトマネージメントツール、探索的テストのメモ書きツール)
  16. テスト自動化は、どのテストで実施しているか？(テスト自動化自体やらない、Unit Testing、CI、回帰テスト、負荷テストなど)
  17. テスト自動化率は？(分からない、10%未満、10-50%、50-90%、90%以上)
  18. " 静的テストや他の品質保証活動で下記のうち、普段のプロジェクトで使っていますか？ (要求分析、リスク分析、高レベル/低レベルのテスト計画、テストレビュー会議、ふりかえりミーティングなど)"
  19. テストチームで挑戦したいことはどの程度か？(テストチームの予算、テストチームの規模、良いテスターを確保する、トレーニング、業務や会社の意思決定のさらなる改善、組織の政治的や文化的挑戦など)
  20. 昨年、テストについて変化したものは何か？
  21. 成功するために必要なテストスキルの重要度は？(Web技術、組み込みシステム、セキュリティテスト、コミュニケーションスキル、アジャイル方法論、営業スキル、プログラミングスキルなど)
  22. 5年後は何の役割になりたいか？(テスター、テストコンサル、プログラマー、引退するなど)
  23. 仕事の安定性は、どの程度不安か？
  24. テスターを確保する立場であるとき、テストの仕事で望んでいるスキルは何か？
  25. テスターとして、(人々、組織、業界で)テストの仕事を良くするには何が変わってほしいか？

[4]回答してみて

  1. 設問は昨年とほぼ同じでした。
  2. Survey Monkeyの仕様と思いますが、一度回答すると再度回答することができないので、Prevのボタンで自分の回答を確認してから提出するとよいです。
  3. 英語で回答するのに苦労しますが、自分の置かれた状況や立場、悩みや課題を整理できるので、自分にとってのふりかえりとして活用できると思いました。
  4. 昨年は、自由記述欄に書いたものが少なかったのですが、今回は自分が取り組んでいることをできるだけ書いてみました。英文に書くことに慣れていないと書こうと思っても書けないので、洋書"Basic Grammar in Use"で基礎を固めるとよいと思いました。

"State of Testing Survey 2016"が1/7より実施

State of Testing

　あけましておめでとうございます。本年もよろしくお願いいたします。

　1年ほど前、State of Testing Survey 2015(ソフトウェアテストの現状調査)に回答し、2015年12月下旬にState of Testing Survey 2015(ソフトウェアテストの現状調査)の結果が日本のテストコミュニティ有志により日本語訳として公開されました。
　Practitestのblogによると、State of Testing Survey(ソフトウェアテストの現状調査)が2016年1月7日(※イスラエル時間)から実施されます。英語による設問ですが、英語に怖じけずに日本からも回答してみましょう。

　昨年(2015年)に私が回答したとき、どのような設問があったか概要を下記に書きましたので、参考頂ければ幸いです。

2015年をふりかえる

look back

　2015年も残り1週間を切りましたので、今年やったことを振り返ってみます。

1月

・初の海外＠フィリピン(WARAI in Philippines)

　関西のソフトウェアテスト勉強会(WARAI)の企画で、WARAIメンバーでフィリピンでテストマネージャとして活躍されているGakuさんの会社で勉強会行われ、私は参加者側で参加しました。

　後に、GakuさんがJaSST'15関西の招待講演でフィリピンでのテストチーム立ち上げの話がありました。

・State of Testing Survey 2015に回答。

　ソフトウェアテストの現状調査が世界規模で行われていたので、日本からの回答者の1人として回答しました。

なお、7月に調査結果が公開され、12月下旬に日本のテストコミュニティ有志により日本語訳が公開されました。

2月

・Rapid Software Testingのスライドを読んだ。

　3月にJaSST'15東京で基調講演されたMichael Boltonの講演内容を予習するため、Rapid Software Testingのスライド内容を読み、概要をまとめました。

3月

・JaSST'15東京に参加しました。

　Rapid Software Testingについて聴講でき、開発とテストのあるべき姿について一考するきっかけとなりました。

・James Bachのblog記事"Exploratory Testing 3.0"を目にする。

　下記記事を少しずつ読み、探索的テストが変化していることを掴み始めました。 http://www.satisfice.com/blog/archives/1509

4月

・第3者検証課から開発課に異動しました。

　3年間所属していた第3者検証課から、入社時に所属していた開発課に異動、つまり出戻りしました。

5月

・開発課でピンチヒッターな案件に参入していました。

　異動前からのプロジェクトで炎上している案件があり、諸々支援することになりました。

6月

・探索的テストの活動モデルをblogで発表しました。

　探索的テストについて議論するとき、課題を明確にしようと思い、悩みながら表現しました。

・JaSST'15関西に参加しました。

・AAA(Asiyan Automation Alliance)2015に参加しました。

7月

・開発課で新規開発プロジェクトのテスターとして参入しました。

　5月のピンチヒッターな案件が終わった後、休む間もなくテスト実施の日々でしたが、製品のあるべき姿が描けていないため、大量のインシデントレポートを登録することに...

8月

・考える大人になるためのツール 国際認定プログラム 2015に参加しました。

「考える大人になるためのツール 国際認定プログラム 2015」に参加し、「ロジックツリー」「クラウド」「アンビシャス・ターゲット・ツリー」を4～5名のチームで取り組みました。また、懇親会では「ロジックツリー」「クラウド」を書いたものを見て頂いたり、他の方の「クラウド」を作る課程を見たりして、充実した4日間でした。

9月

JaSST'15北海道に参加＆ライトニングトークスで発表しました。

　 「探索的テスト」祭りでしたが、国内で探索的テストの情報がまとまりつつあり、時代が進んだと思いました。

10月

・JaSST'15九州に参加しました。

　セキュリティテストに関心があり、参加しました。また、九州のコミュニティの方々のセッションもアツイなぁと思いました。

11月

・JaSST'15東海に参加しました。

　Concolic Testについて関心があり、参加しました。開発でのテストについて、工夫する余地があると思いました。

・blogを毎週書いてから2年経過

　継続は力なり。時間の使い方を意識しないと、継続して取り組めないと思いました。

12月

・システムテスト自動化カンファレンス2015に参加。

　自動テストのキャズムを超えた先の世界でした。また、マネージャや経営層に自動テストのメリット&デメリットを説明しないと、形骸化して失敗に至ると危機感がありました。

さいごに

　駆け足でふりかえってみましたが、他地域のイベントに参加することが多い1年でした。また、探索的テストに関するアウトプットが(質の良し悪しがありますが)少しずつ出てきたと実感しています。探索的テストに関しては、さらに探究していきます。
　来年ですが、探索的テストを探究することの他に、マネジメントや経営などの分野も開拓してみます。

JaSST15東海(2)「特別講演：はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」

JaSST Tokai Conference Concolic test

　11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会

前回書いた記事

masaoapril.hatenablog.com

　今回は、セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」です。

セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)

(1)シンボリック実行(Symbolic execution)

  • プログラム解析後、実行パスの抽出と実行パスを実行するための入力データを特定する技術。
  • 入力データ：シンボリック(Symbolic)として扱う。
  • 静的テストに分類される。

(2)SAT(充足可能性問題)

  • 論理式の変数True/Falseの組み合わせで、結果がTrueかFalseかを判定する問題。
  • 論理式をコンピュータで解くアルゴリズムを利用。
  • SATソルバで解く。

(3)動的実行

　実行結果の値を入力してSATソルバで解かせる。

(4)Concolic = Concrete + Symbolic

　"Concolic test"は、具体的な値(Conclete Value)を使った動的実行とシンボリック実行(Symbolic execution)を組み合わせたもの。

流れは以下。

  1. 入力する変数を指定する。
  2. 入力する変数に任意の初期値を指定
  3. 実行の過程で出てきた数値を次のテストに入れて、SATソルバに解かせる
(5)Concolic testを現場適用するときの障壁
  • パス数が爆発
    10回のループが2つ並んだら→100回。
  • ソルバの制約
    • 種類によって得意不得意。
    • 浮動小数やポインタは苦手。
  • オラクル問題
    入力は求められるが、期待結果は求められない。
(6)ツール
  • PathCrawler
    • C
    • Web上で試行できる。
  • CUTE
    • C/Java
    • 更新が滞っている。
  • CREST C
  • KLEE LLVM
  • Microsoft Pex
  • SPF(Symbolic Path Finder)
  • DART(非公開)
(7)実例

　Fuzzテストで応用されている。MictosoftのSAGEというツールの事例が有名とのこと。

(8)課題
  • パス数の爆発
    • 処理能力Upで改善。
    • 部分適用で工夫する。
  • ソルバの制約
    • ソルバの進化で改善。
    • SMTソルバ。
  • オラクル問題
(9)デモ

所感

　Concolic Testは、1～2年前から時折耳にしていますが、概要は分からない状態でした。近い将来、concolic testを適用する場面が出てくると思いますので、開発者と連携して取り組もうと思います。まずは、情報収集と活用できるところの検討から始めたいと思います。

JaSST15東海(1)「基調講演：テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」

JaSST Tokai Conference TestDesign

　11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会

　今回は、セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」松尾谷 徹(デバッグ工学研究所)

(1)背景 検証指向設計とは

(1-1)背景
(1-1-1)オブジェクト指向
(1-1-2)流用技術
  • 簡単にコード書ける。 →逆に言うと、バグを書くと簡単にシステムが停止する。
  • プログラム規模が増大し、テストの規模増大という事情がある。
(1-2)開発オーディション

　テスト能力の範囲でソフトウェアを設計する。

(2)派生開発

(2-1)確認すべき2つの仕様
  • 追加、変更、削除された機能やふるまい。
    →派生部分のテスト。
  • 何も変わっていない機能。
    →回帰テスト(Regression Testing)
(2-2)回帰テスト設計
  • 入力となる仕様(成果物)は「？(変更なし)」である。
  • linuxの世界では、回帰テストの部分も含めてリリースしている。
    • 1行変更や追加すると、テストを書くことが当たり前の世界である。
  • 日本は、回帰テストはビッグバーンテストとなっているのが実情である。
(2-3)後工程
(2-3-1)製造業の美徳

　「後工程はお客様」

(2-3-2)製造業のの内なるソフトウェア業では

　Cowboy Programmingで我流でソフトウェア開発するが、共倒れになる。

(2-3-3)解決策
  • 美徳で守るプロセスへ改善
    →精神論では...
  • 現実を受け入れる。
    →新たな解決方法へ
(2-4)派生開発の回帰テスト
  • 問題点
    • 仕様ベースのテストでは不可能。
    • 実装ベースのテストで乗り越える。
  • Concolic Testing
    前のバージョンと現バージョンの動作結果を比較する。

(3)スキルの成長

(3-1)元NECの東さん

　バグとテストケースの対応は...

  • 半分くらい。
  • テストケースの重複。
  • テスト準備でバグを見つけることも。
(3-2)プログラミング演習

　演習法は、「机上でプログラミング→プログラミング組んで実習」よりは「早く習得→早く書いて、早くデバッグ」を行うことにしている。

(3-3)諸々のスキル習得
  • 失敗して、学んでフィードバックする。
  • ブリコラージュ：「デバッグで成長する」。
  • エンジニアリングは、「綿密な論理の積み上げ」。
(3-4)プログラミング

　確かめながら作る。つまり、動かしてみないと分からない。

(3-5)ソフトウェア工学

　1968年NATOの時代に「早期警戒システムの失敗」がきっかけで始まった。

(3-6)テストスキルの実態
  • テスト設計の問題を解く。
    8割の網羅達成者は、全体の5%以下であった。
  • テストスキルが身につかない。
    原因は、テストケース書くがテストケースのデバッグが無い。
  • テスト(デバッグ)
    テスト対象プログラムとgcov
(3-7)テスト対象の出来栄え

　本質は、「検算」である。

(3-8)テストのモデル
  • 検算の変形である。
  • 現状は、テスト側のデバッグが欠如している。
  • テストのデバッグ環境があると、テストスキルが伸びる。

(4)テストのモデル：探索モデル

(4-1)OR(Operations Research)

　Uボードを探索する方法を考案することがきっかけ。

(4-2)探索要素
  • 探索空間
  • 探索目標
  • 有効探知幅
  • 探知速度
(4-3)ランダム探索

　発見確率から見ると非効率である。

(5)プログラムの探索行動

(5-1)問題
  • そもそも探索していないので、探索漏れがある。
  • 時間や工数がかかるのが探知効率の問題である。
(5-2)テスト技法の問題
  • テストケースを詳細化するが、全体を網羅していない。
  • 系統的な技法が敬遠される。
(5-3)テストのデバッグ課題
  • テストケースの重複
  • 実施済みテストのフィードバック
(5-4)マイヤーズの三角形問題

　CFD(原因流れ図)で解く。

(5-5)探知効率

　平行探索に持って行く必要が...

(5-6)まとめ
  • 検算できるようにする必要がある
  • ブリコラージュ＋科学的手法

所感

　ソフトウェアが望まれた動作するか検算できるようにモデルを考えるためには、小さなサイクルで失敗して学んでフィードバックしながらスキルを高めることが必要と痛感しました。また、世の中でやっているソフトウェア設計やテスト設計を幅広く知り、開発プロジェクトで試行することも私にとっての課題の1つと思いました。