システムテスト自動化カンファレンス2015(1)「テスト自動化のスキルを考えよう! ~テスト自動化エンジニアに求められるスキル、期待される役割~」(前編)
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)「ワークショップ:意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」
11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。
セッション1 基調講演:「テストから観た実体のモデリングと実装構造の評価 ~検証指向設計の実現に向けて~」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演:「はじめてのコンコリックテスト ~基本原理から知るホワイトボックステストの新技術とその応用~」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表:「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」 鈴木 三紀夫(リコーITソリューションズ)
情報交換会
以前書いた記事
masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
今回は、セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」です。
4-3 ワークショップ 「意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」 鈴木 三紀夫(リコーITソリューションズ)
(1)ワークショップを通じ...
下記3点が現場でも実践できるきっかけとする。
- 観点出しができる。
- 仕様書の裏返しからの改善ができる。
- テスト目的が明確になる。
(2)ワークショップの流れ
- 仕様書を読み、「テストしたいこと」「確認したいこと」をマインドマップで書き込む。
- 「テスト分析の三角形(※1)」を見て、仕様書から気付くことをマインドマップに追記する。
- 「タートル図(※2)」を見て、仕様書から気付くことをマインドマップに追記する。
- グループでディスカッション
- 「意地悪漢字(※3)」を見て、仕様書から気付くことをマインドマップに追記する。
- 「対立漢字(※4)」を見て、仕様書から気付くことをマインドマップに追記する。
- グループでディスカッション
※1:ソフトウェアテストシンポジウム 2015 九州 招待講演 セッション5「テストエンジニアを育てるためのポイント」 講演資料 47枚目スライドを参照のこと。
※2:同上:講演資料 52枚目スライドを参照のこと。
※3:同上:講演資料 54~55枚目スライドを参照のこと。
※4:同上:講演資料 60~62枚目スライドを参照のこと。
(3)私が書き出した内容
(4)実例
- その1
要件定義でイレギュラーケースを考えるために「意地悪漢字」「タートル図」を活用した。 - その2
- 「意地悪漢字」「タートル図」をレビューで活用している。
- 理由は、レビュー観点をリスト化すると、イメージが沸かないため。
所感
「テスト分析の三角形」「タートル図」「意地悪漢字」「対立漢字」を各ステップ毎に見ると、何らかの気づきが次々出てきました。様々な切り口でテスト対象を見ると、鋭く感じるものがあり、製品を取り巻く世界を更に知る必要があると思いました。
JaSST15東海(3)「事例発表:安全系組込ソフトウェア開発におけるユニットテストの効率化」
11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。
セッション1 基調講演:「テストから観た実体のモデリングと実装構造の評価 ~検証指向設計の実現に向けて~」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演:「はじめてのコンコリックテスト ~基本原理から知るホワイトボックステストの新技術とその応用~」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表:「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」 鈴木 三紀夫(リコーITソリューションズ)
情報交換会
以前書いた記事
masaoapril.hatenablog.com masaoapril.hatenablog.com
今回は、セッション 4-2 事例発表:「安全系組込ソフトウェア開発におけるユニットテストの効率化」です。
セッション 4-2 事例発表:「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
1.背景
安全系組み込みソフトウェアでは、自動車機能安全規格ISO26262の準拠が求められている。
2.ユニットテスト
- 現行のツールでC0/C1 MC/DCカバレッジを100%にするのは困難。
- カバレッジを網羅できていないところは、人手でテストを行っている。
- ユニットテストの自動化について、色々なアプローチを研究した。
3.CREST
3.1 サイト
http://jburnim.github.io/crest/
3.2 CRESTとは?
3.2 工夫したこと
- パスが網羅できるか確認するため、複雑度(以下CCN)=2,4,8のサンプルソースコードを作成して、CRESTで確認した。
- CCN=28にしても、テストカバレッジ率100%未達成なので、入力値に制約をかけた。
- マイコン変更時
所感
ユニットテストの手間を減らすため、ツールの選定から、実務に耐えうるかを検証するために試行し、適用可能であることを確認した内容でした。自組織のユニットテストは、手作業のところも多々あるので、手間を減らしながらもユニットテストで検出できるバグが効率的にできるように進める必要があると思いました。
"State of Testing Survey 2016"に回答してみた
先週の記事「"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の質問がありましたので、回答される方は参考頂ければ幸いです。
(意訳ですので、解釈が誤っている可能性があることをご了承下さい。)
- 職位は?(テストエンジニア、テストマネージャ、テストリーダ、テスト自動化のテスターなど)
- 経験年数は?
- どの地域で働いていますか?(アフリカ、アジア、中国、西ヨーロッパ、インド、アメリカ/カナダなど)
- 年収は?
- "testing"をどのように学んだか?(研修、ISTQBなどの資格認定、自習、OJTなど)
- テスト技術の維持向上はどのようにやっているか?(書籍、テストのカンファレンスやセミナー、Twitterやblog、トレーニング研修など)
- 過去3年間、勉強会に参加していましたか?また、何の研修やカンファレンス、セミナーに参加していましたか?
- 会社の従業員数は?
- 組織内のテスターの人数は?
- 会社の拠点数は?
- 開発スタイルは?(ウォータフォール、アジャイル、TDD、DevOpsなど)
- テスターの役割は?(テスト、ユニットテスト、顧客サポート、要求収集、ツール開発など)
- テストドキュメントのタイプは?(高レベルテスト計画、低レベルテスト計画、詳細なテストスクリプト、テストチャータ、マインドマップなど)
- マニュアルテストのテクニックは?(スクリプトテスト(テスト仕様書に従ったテスト)、探索的テスト、バグハンティング、ペアテストなど)
- テスト管理ツールは?(ExcelなどのOffice系アプリ、BTS、プロジェクトマネージメントツール、探索的テストのメモ書きツール)
- テスト自動化は、どのテストで実施しているか?(テスト自動化自体やらない、Unit Testing、CI、回帰テスト、負荷テストなど)
- テスト自動化率は?(分からない、10%未満、10-50%、50-90%、90%以上)
- " 静的テストや他の品質保証活動で下記のうち、普段のプロジェクトで使っていますか? (要求分析、リスク分析、高レベル/低レベルのテスト計画、テストレビュー会議、ふりかえりミーティングなど)"
- テストチームで挑戦したいことはどの程度か?(テストチームの予算、テストチームの規模、良いテスターを確保する、トレーニング、業務や会社の意思決定のさらなる改善、組織の政治的や文化的挑戦など)
- 昨年、テストについて変化したものは何か?
- 成功するために必要なテストスキルの重要度は?(Web技術、組み込みシステム、セキュリティテスト、コミュニケーションスキル、アジャイル方法論、営業スキル、プログラミングスキルなど)
- 5年後は何の役割になりたいか?(テスター、テストコンサル、プログラマー、引退するなど)
- 仕事の安定性は、どの程度不安か?
- テスターを確保する立場であるとき、テストの仕事で望んでいるスキルは何か?
- テスターとして、(人々、組織、業界で)テストの仕事を良くするには何が変わってほしいか?
[4]回答してみて
- 設問は昨年とほぼ同じでした。
- Survey Monkeyの仕様と思いますが、一度回答すると再度回答することができないので、Prevのボタンで自分の回答を確認してから提出するとよいです。
- 英語で回答するのに苦労しますが、自分の置かれた状況や立場、悩みや課題を整理できるので、自分にとってのふりかえりとして活用できると思いました。
- 昨年は、自由記述欄に書いたものが少なかったのですが、今回は自分が取り組んでいることをできるだけ書いてみました。英文に書くことに慣れていないと書こうと思っても書けないので、洋書"Basic Grammar in Use"で基礎を固めるとよいと思いました。
"State of Testing Survey 2016"が1/7より実施
あけましておめでとうございます。本年もよろしくお願いいたします。
1年ほど前、State of Testing Survey 2015(ソフトウェアテストの現状調査)に回答し、2015年12月下旬にState of Testing Survey 2015(ソフトウェアテストの現状調査)の結果が日本のテストコミュニティ有志により日本語訳として公開されました。
Practitestのblogによると、State of Testing Survey(ソフトウェアテストの現状調査)が2016年1月7日(※イスラエル時間)から実施されます。英語による設問ですが、英語に怖じけずに日本からも回答してみましょう。
昨年(2015年)に私が回答したとき、どのような設問があったか概要を下記に書きましたので、参考頂ければ幸いです。
2015年をふりかえる
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)「特別講演:はじめてのコンコリックテスト ~基本原理から知るホワイトボックステストの新技術とその応用~」
11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。
セッション1 基調講演:「テストから観た実体のモデリングと実装構造の評価 ~検証指向設計の実現に向けて~」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演:「はじめてのコンコリックテスト ~基本原理から知るホワイトボックステストの新技術とその応用~」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表:「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」 鈴木 三紀夫(リコーITソリューションズ)
情報交換会
前回書いた記事
今回は、セッション 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)を組み合わせたもの。
流れは以下。
- 入力する変数を指定する。
- 入力する変数に任意の初期値を指定
- 実行の過程で出てきた数値を次のテストに入れて、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)デモ
- Symbolic Path Finder
- 植月さんのblog(http://blog.utkeiji.com/?cat=2)に詳細情報が掲載されている。
所感
Concolic Testは、1~2年前から時折耳にしていますが、概要は分からない状態でした。近い将来、concolic testを適用する場面が出てくると思いますので、開発者と連携して取り組もうと思います。まずは、情報収集と活用できるところの検討から始めたいと思います。
JaSST15東海(1)「基調講演:テストから観た実体のモデリングと実装構造の評価 ~検証指向設計の実現に向けて~」
11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。
セッション1 基調講演:「テストから観た実体のモデリングと実装構造の評価 ~検証指向設計の実現に向けて~」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演:「はじめてのコンコリックテスト ~基本原理から知るホワイトボックステストの新技術とその応用~」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表:「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう! ~テスト設計ワークショップ~」 鈴木 三紀夫(リコーITソリューションズ)
情報交換会
今回は、セッション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つと思いました。
JaSST15九州(3)「招待講演:テストエンジニアを育てるためのポイント」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表:「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表:「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演:「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーITソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、招待講演:「テストエンジニアを育てるためのポイント」です。
招待講演:「テストエンジニアを育てるためのポイント」 鈴木 三紀夫(リコーITソリューションズ)
(1)講演資料
JaSST'15九州のサイトに掲載されていますので、ご参照下さい。
http://www.jasst.jp/symposium/jasst15kyushu/report.html#invitation
(2)テストエンジニア育成 3つの段階
テストエンジニアの成長段階にあわせ、指導方法を変える。
(2-1)テストエンジニアになりたて
- 長所を伸ばす
- のびのび取り組んだ人:2~3年後劇的に変わる
- 型にはめ込まれた人:伸び悩む
(2-2)自信がついたころ
自己流ではなく、世の中でやってること(Test.SSF、HAYST法など)を知る。
- 自己流でやり続けないという意味で学ぶとよい。
- 自己流でやり続けると、行き詰まる。
- 自己の欠点を補うため。
「テストケース」という言葉は、仕事した人と話しても通じない。
- 理由:テスト設計のイメージがそれぞれ異なる。
- イメージ例:仕様書をコピー&ペーストしてモディファイしたテスト。
(2-3)リーダになったころ
- InputからOutputへ移行。
- Outputすると、伸びる!!
- テストプロセスの改善。
- 人を動かすほうが評価される。
(3)まとめ
(4)付録の話
(4-1)3色ボールペン法
メリットは、テストケースを考えるとき、仕様書を読みながらぼやいていたことを逃さずに書くと気付きがあり、テストケースを書くときに効果抜群であった。
(4-2)Test.SSF
- テストプロセスをアクティビティに分割すること
- 逸話
JaSST'04東京の情報交換会でテスト設計の話をじっくり聞いた人がいた。翌年のJaSST'05東京の情報交換会でテスト設計の話をじっくり聞いた人から「テスト設計がよかった」と話をされ、理由を聞くと「テスト設計の概念を社内で話したら、バグ検出が向上した。」とのこと。 - テスト要求分析
テストの質が上がる。 - テストアーキテクト設計
無駄なテストが見えてきた。
(4-3)テスト観点リスト
- 資産である。
- 「何をテストしたいか?」のノウハウが蓄積されている。
(4-4)不具合蓄積リスト
- プログラムを書く前に半日バグについて情報を集める。
- 過去のバグを引き出す
- 「どういうバグがあるか?」
- 気付いたバグは、バグを埋め込まれない。
- コストがかからず、効果が出る。
所感
本講演は、現場で工夫されたことを第3者に伝える形でまとめられているので、自組織でも実践できると思いました。「世の中でやっていること」を知ることは、失敗しないための工夫を知ることになるので、さらなる工夫ができるように開発メンバーに伝えつつ、共に進めようと思います。また、本講演資料から何らかのヒントが得られると思うので、開発現場で工夫するネタを考えてみようと思います。
JaSST15九州(2)「事例発表・経験発表:『開発エンジニアがどうしてソフトウェアテストに関心を持ったか』『テストする人。の思うところ』」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表:「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表:「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演:「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーITソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、事例発表・経験発表:「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」と「テストする人。の思うところ」の2講演です。
事例発表・経験発表:「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
(1)テストに関心をもったきっかけ
仕様書に書いた内容を満たしてもバグは発生する。原因は、「テストのやり方がよくなかった」「テストの手法を知らなかった」であった。
(2)テストを勉強する上での問題
情報収集の限界があったとき、Facebookページの「九州ソフトウェアテスト勉強会」に出会った。
(3)九州ソフトウェアテスト勉強会に参加
- 月1回の勉強会。
- コミュニティに参加すると、情報が集まってくる。
- JSTQB FLの情報を知り、勉強して合格した。資格取得がテストを勉強するために有効であることを実感。
- テスト設計コンテスト
- 今の知識でどれだけできるか試したくて参加した。
- 学んだことは、「テストも設計すること」「テスト仕様書がよくても、ソフトウェアの構造がダメだと、テストの効率がよくない。」ことである。
(4)まとめ
- テストを楽しめる仕組みをつくる。
- 開発エンジニアもテストに興味を持てる。
- テストを学ぶコミュニティの存在は大切である。
事例発表・経験発表:「テストする人。の思うところ」
(1)blogからのネタ
ユーザ登録時に設定するユーザIDの桁数に関する疑問の記事。
(2)ユーザIDの桁数
ユーザID登録時の文字数が6~14桁であるが、「なぜ、桁数制限があるか?」疑問に思ったとのこと。
(3)徳丸さんに聞いた
セキュリティの理由は思いつかないので、画面デザインではないか?
(4)エンジニアに聞いた
- お客様に安心感を与えたいから
- なんとなく守られている感
- 意味のある言葉をつけてほしい
聞いたエンジニア本人の感覚であり、上限の14桁は深い意味はない...
(5)テスターのあり方
- ユーザのため
- 一般的なものから逸脱してないか?
- 使用性
- エンジニアのため
- バグが混入しにくいようにする。
- 意図を理解し、システムを改善する。
所感
開発現場の問題や疑問を解決するため、地域コミュニティを知って情報交換や議論することで、(JaSST'15九州のテーマである)「知識の広がりは可能性の広がり」を実現したんだなと肌で感じたセッションでした。また、本セッションを聴講後、地域からネタを発信することで開発現場の問題を解決するためのヒントが地元や他地域の方からフィードバック頂けるので、「知識の広がりは可能性の広がり」から新たな道が見つかると思いました。
JaSST15九州(1)「基調講演:ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表:「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表:「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演:「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーITソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」のメモをまとめました。
基調講演:「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」 徳丸 浩 (HASHコンサルティング)
(1)脆弱性とは?
(1-1)悪用可能なバグ。
サーバーの設定不備により、できないはずのことができてしまう。また、できてはいけないことができてしまうこと。
(1-2)脆弱性の例
- バッファオーバーフロー
C言語のメモリ確保関数 - SQLインジェクション
文法ルールを守っていないこと - XSS(クロスサイトスクリプティング) 悪意のあるスクリプトが実行される
(2)進入経路
- 認証突破
簡単なパスワードで入られる - ソフトウェアの脆弱性を悪用
基盤ソフトウェア
自開発のアプリケーション
(3)あらゆるバグは脆弱性に通じる
排他制御の漏れなど。例えば、仙台の某アイドルグループのライブ開催におけるホテル予約殺到で、ダブルブッキングやトリプルブッキングした事件。
(4)脆弱性=バグと捉えるのが一般的
(4-1)脆弱性の責任
発注者に責任がある(徳丸さんの意見)。
(4-2)家具インテリアECサイト
- 東京地裁でSQLインジェクション攻撃と断定。
- SQLインジェクション対策を怠ったのは、重過失。
- 考察
専門家としての責務を重視。
「安全なWebサイトの作り方(https://www.ipa.go.jp/security/vuln/websecurity.html)」に記載している対策は、最低限対策したほうがよい。
(5)デモ
(5-1)SQLインジェクション攻撃@EC立方体
EC立方体の初期状態(インストール直後)で、都道府県の欄に
'OR" "a-a" init 10 #
と入力すると福岡県のはずが北海道が出力される。
UNION SELECT 1, cardname ...
UNION SELECT文でカード情報を取得し、information_schemaでテーブルを取得し、その情報から攻撃。
(5-2)PHP入門書
- 掲示板の削除ボタンのリンクにあるIDに"?id=729-1"を付与すると、728番目の書き込みが消える。
- extractvalue関数で故意にエラーのあるクエリを入れ、わざとエラーメッセージを出して、個人情報を取得。
- sleep関数を利用して時間差で情報を盗む。
(5-3)横浜市のCSRF悪用
- XSS
見えないiframe。
投稿欄にjavascriptを仕込む。
利用者側で注意はできないので、サイト側で対策の必要がある。
(6)脆弱性対策と開発プロセス
- 実装や開発者のテストでも脆弱診断するとよい
- 発注者側:仕様書にSQLインジェクション、XSS対策を書く
- 安全なWebサイトは、抽象的なので具体的に仕様を書くとよい
- RFPに「SQLインジェクションなどの対策」などの範囲があいまいなので、セキュリティ要件は開発標準に盛り込んで明確化する。
- セキュリティテストを内部でこれからのトレンドになりそう。
(7)脆弱性診断
- リモート(ブラックボックス)診断
害の無い攻撃(疑似攻撃) ツールを使った診断もある - ソースコード(ホワイトボックス)診断 ツール(Fortify)
- グレーボックス リモート(ブラックボックス)診断とソースコード(ホワイトボックス)診断を組み合わせる。
(8)Webアプリ脆弱性診断
- 脆弱性診断は、テストの一種。
- テスト環境を準備
DBが壊れてもOKな環境 - 課題
費用高額
安全性(DB破壊など) - ネットの情報を鵜呑みにしない
- 脆弱性検査するときは、1箇所だけSQLインジェクションして、その他は正常データを入れて検査。
- whileのところは、orよりand使う。andはプロが使う。
- 新しい攻撃手法は、それほど出ていない。もし出たら、大騒ぎするレベルである。
(9)質疑応答
Q1
サーバ側の脆弱性診断したいが、jsで弾かれたので脆弱性診断がやりにくいが、どうすればよいか?
A1
Burp Suiteなどのツールを利用するとよい。本ツールは、サーバにパケットを投げる前に色々仕込める。
Q2
セキュリティ検査を社内で実施するのがトレンドだが、第3者的な監査は残るか?
A2
第3者的な監査は残ると思う。
Q3
非属人化が問題だが、どうすればよいか?
A3
- 人はなかなか集まらない。
- ツールの進化に期待する(ただし、緩やかだが...)。
- Webアプリ開発経験者を教育するのが現実的だと思う。
所感
初め、脆弱性のイメージがピンと来なかったですが、脆弱性が「悪用可能なバグ」という話でガッテンしました。また、Industrie4.0が当たり前の時代になり、脆弱性や機能安全の対応を疎かにすると市場不具合が発生したときに、多大な損害を被ることになりますので、開発もテストも予防できることは何か、どのようなアプローチがあるか、情報のアンテナを張り、日頃から議論したり考えていこうと思う。
JaSST15北海道(4)「JaSST Hokkaidoセッション:『ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか』」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演:
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル:
「やってみよう!探索的テスト。テストの常識を変えませんか?」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション2:
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
以前書いた記事
今回は、セッション4-1-3 JaSST Hokkaidoセッション2:「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」の聴講メモをまとめました。
セッション4-1-3 JaSST Hokkaidoセッション2:「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」 相沢 直人(インサイト)
(1)資料
下記を参照下さい。
http://jasst.jp/symposium/jasst15hokkaido/report.html#session2
(2)ユーザビリティとは?
ISO9241-11やニールセンのユーザビリティの定義があるが、一言で言うと...
「ユーザビリティ≠使いやすさ」
(3)ユーザビリティテスト
下記2種類ある。
- ユーザテスト
ユーザが評価 - エキスパートテスト
第3者が評価
やりやすさはユーザテストよりも優位
(4)ユーザビリティテストのガイドライン
(5)10年のユーザビリティテストの変化
- ソフトウェアからサービスへ
- 「使いやすい」から「楽しい」へ変化
(6)UXの時代へ
(6-1)UXの考え方、モデル
- ジェシー・ジェームス・ギャレットのUX
見た目のデザインしか考慮していない問題がある。 - ピーター・モービル
UXハニカム - UXPA
UXプロフェッショナル - UPA(現:UXPA)
ユーザエクスペリエンスフロー
(6-2)UXの期間
- 利用前
予期的UX - 利用中
一時的UX - 利用後
エピソード的UX - 利用時間全体
累積的UX
(6-3)UX事例
- UXを意識して設計
airbnb, LINE, ディズニー< スタバ - 次も体験しようとする設計
- 使う前、使う後、また使いたくなるのがUX
→ゲーミフィケーションも似ている。
(7)ユーザビリティからUXへシフトしたのか?
(8)ユーザビリティの担保は必要
(8-1)ユーザビリティの検証
楽しさ・心地良さは、ユーザビリティのようにテストできるか?
(8-2)UXテスト
- 楽しさ
生理指標。 - 心地よさ
サクサク感。
触覚。 - 価値がある
ある程度の期間を使って判断。
(8-3)リーンUX
- ユーザテスト
お金、時間、スキルが必要。
(9)UXを考慮したサービスの企画開発
- ISO9241-10
人間中心設計 - デザインリサーチ
定量調査(アンケート、データマイニングなど)
定性調査(インタビューなど) - カスタマージャーニーマップ
どのようにやっているか、思考過程を書く。
(10)まとめ
この先、魅力的な製品をつくるためにUXを考慮することは欠かせない。
(11)今後の参考情報
- SQuaRE
ISO25010 - CIF(ISO25062)
Common Industory Format for usability test
(12)デザイン北海道ブログ
http://designhokkaido.blogspot.jp/
所感
業務用組み込み系機器開発でも5~10年の間に「使い勝手」という言葉を経営層から管理者→開発リーダ→担当者の方向へ耳にするようになりました。しかし、現場の開発エンジニアからは「「使い勝手」をどのように考えて設計すればよいか分からない」との悲痛の声があがっていますし、テスト担当者からも「「使い勝手」をどのように考えてテストすればよいか分からない」との悲痛の声があがっています。悲痛の声を減らすには、ユーザビリティのガイドラインから仕様を具象化してみることも進めようと思います。また、UXについてはぼんやりとしたイメージしかないので、参考文献から理解を進めようと思います。
JaSST15北海道(3)「ビブリオバトル」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演:
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル:
「やってみよう!探索的テスト。テストの常識を変えませんか?」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション:
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
以前書いた記事
今回は、セッション4-1-2「ビブリオバトル」を聴講メモをまとめました。
セッション4-1-2 ビブリオバトル
(1)セッションの内容
下記を参照下さい。
http://www.jasst.jp/symposium/jasst15hokkaido/report.html#bibliobattle
(2)ビブリオバトルのメモ
(2-1)書籍:「UNIXという考え方」 Mike Gancarz(著)、戦人:鶴谷 俊之
- 言いたいことは、表紙に書いてある。
- 表紙の内容にビビッと来る。
- 薄い本。
- lsコマンド。
- プログラムを作るときの哲学に通じる。
(2-2)書籍:「ソフトウェアプロセス改善手法SaPID入門」 安達 賢二(著)、戦人:長友 優治
- プロセス改善は仕組みが分からないことが多い。
- 安達さんとの出会い
- 本の中の人は、優しい(分かりやすい)。
- 問題構造図から因果関係が分かり、現場の人が取り組むので、適用範囲が広い。
- みんなを巻き込む。
(2-3)書籍:「「超」入門 失敗の本質 日本軍と現代日本に共通する23の組織的ジレンマ」 鈴木 博毅(著)、戦人:奥 大輔
- ビジネス書。
- 戦略、組織、指標。
- 初期のソースコード中にconst修飾子が3箇所あったが、開発が進む毎にconst修飾子の箇所が増加して保守で困ったが、本書で学んだことを応用し、const修飾子を使うことを止めた。
- 零戦に勝つことで、指揮を変えた。
(2-4)書籍:「これだけ!KPT」 天野 勝(著)、戦人:坂 静香
(2-5)書籍:「はじめよう! 要件定義 ~ ビギナーからベテランまで」 羽生 章洋(著)、戦人:浦山 さつき
- 2015年4月に出版された本。
- 要件定義を目玉焼きをつくるコックさんに例えている。
- 目玉焼きを食す人は、テスターと同じ。
- 企画→要件→要件定義だが、企画については書籍に書かれていない。
(2-6)書籍:「ゲーミフィケーション―<ゲーム>がビジネスを変える」 井上 明人(著)、戦人:根本 紀之
- 上手くのめり込むためのメタ。
- バグ報告時に実施したテストにプロレス技名を付けて点数化。
- 節電アプリで、ゲーム化。
- ドラクエ風スキルマップで、役割を明確にした。
所感
書籍との出会いは、何かを動かす一歩と思う。5分間に込められた現場の工夫や想いを書籍を通じて伝えることで知恵を巡らせることも必要だなと痛感しました。