JaSST15九州(3)「招待講演：テストエンジニアを育てるためのポイント」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演：「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表：「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演：「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーＩＴソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、招待講演：「テストエンジニアを育てるためのポイント」です。
招待講演：「テストエンジニアを育てるためのポイント」 鈴木 三紀夫(リコーＩＴソリューションズ)
(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コンサルティング)
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表：「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演：「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーＩＴソリューションズ)
企画イベント(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コンサルティング)
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表：「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演：「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーＩＴソリューションズ)
企画イベント(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分間に込められた現場の工夫や想いを書籍を通じて伝えることで知恵を巡らせることも必要だなと痛感しました。
JaSST15北海道(2)「探索的テストチュートリアル：『やってみよう！探索的テスト。テストの常識を変えませんか？』」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演：
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル：
「やってみよう！探索的テスト。テストの常識を変えませんか？」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション：
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
前回書いた記事
今回は、セッション3-3 探索的テストチュートリアル：「やってみよう！探索的テスト。テストの常識を変えませんか？」でやったことをメモとしてまとめました。
セッション1 基調講演：「探索的テスト - アジャイル時代の効率的なテストを考える」 高橋 寿一
(1)資料
下記、JaSST'15 Hokkaidoレポートに掲載されていますので、参照下さい。
http://www.jasst.jp/symposium/jasst15hokkaido/report.html#tutorial1
また、基調講演の資料の26～43枚目もあわせて参照下さい。
(2)お題
スマートフォンのアプリを1つ選び、探索的テストを行う。
(3)選んだアプリ
電卓アプリ(Android OS)
(4)流れ
1.探索的テストのPass/Fail基準を書く。
2.下記5項目のタスクシートを書く。
1.タスクの記述
2.探索アプローチガイド
3.結果
4.終了条件
5.FAQ
※当日は、時間切れで2.探索アプローチガイドまで実施。
3.実際に探索的テストを行う。
※当日は、時間切れで未実施。
(5)私がやった記録
(5-1)探索的テストのPass/Fail基準
| 定義 | Pass基準 | Fail基準 |
|---|---|---|
| 機能性 | 四則演算ができること | 四則演算ができないこと |
| 信頼性 | 計算結果が正しいこと | 計算結果が誤っていること |
| 機能性 | ボタン入力が正しく入力されること | ボタンを入力しても何も出力(表示)されないこと |
| 機能性 | 最大桁数まで数値が入力できること | 最大桁数まで数値が入力できないこと |
| 信頼性 | 何らかの要因で電卓アプリが落ちないこと | 何らかの要因で電卓アプリが落ちること |
| 使用性 | メッセージ内容が理解できること | メッセージ内容が理解できないこと |
| 信頼性 | 様々な押し方をして、電卓アプリがクラッシュしないこと | 様々な押し方をして、電卓アプリがクラッシュすること |
| 信頼性 | 住宅ローンの金利計算が正確であること | 住宅ローンの金利計算がデタラメであること |
| 信頼性 | 飲み会の割り勘計算を何度行っても結果が同一であること | 飲み会の割り勘計算を何度行っても結果がバラバラであること |
| 信頼性 | 電卓アプリを動作することにより他アプリがクラッシュしないこと | 電卓アプリを動作することにより他アプリがクラッシュすること |
| 信頼性 | 年末調整の控除金額の計算が正しいこと | 年末調整の控除金額の計算が誤っていること |
(5-2)タスクシート
| 項目 | 内容 |
|---|---|
| タスクの記述 | 教科書の計算式を手計算と電卓アプリの2通りで行う |
| 探索アプローチガイド | 複雑な科学計算や役所の複雑な制度をネタにする。 |
| 結果 | (時間切れで記載できず) |
| 終了条件 | (時間切れで記載できず) |
| FAQ | (時間切れで記載できず) |
(6)頭をかち割るアイディア
(6-1)機会損失が無いことが品質
例えば、機会損失：デジタルカメラのバッテリ残量が知らないうちに無くなり、シャッターチャンスを逃すこと。
(6-2)ユーザ欲しいもの
どのような品質か？(例：満足度)
(6-3)いつ探索的テストを終わらせるか？
例：バッテリが切れるまで
(7)まとめ
探索的テストは、アプリケーションによってアプローチが違う。
所感
Android OSのスマートフォンに触るのは初めてであったが、電卓アプリの操作を試して挙動を確認した後、実際にPass/Fail基準やタスクシートを書いてみると、様々なアイディアが浮かんできました。本チュートリアルでは、3名1チームでワイワイ話し合いながら発表をまとめていましたが、2名の方のアイディアから新たなアイディアを思いつきましたので、探索的テストをペアで行うことも1つのアプローチと思いました。
頭の中にあるアイディアを書き出すと、記憶が揮発してもアイディア内容が復元できるだけでなく、プロジェクトマネージャにテストで考えたことや実施したことを説明できるので、探索的テストとad hocテストやランダムテストの違いを理解する一助になると思いました。
JaSST15北海道(1)「基調講演：探索的テスト-アジャイル時代の効率的なテストを考える」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演：
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル：
「やってみよう！探索的テスト。テストの常識を変えませんか？」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション：
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
今回は、セッション1-1「探索的テスト - アジャイル時代の効率的なテストを考える」の内容で印象に残ったことをメモとしてまとめました。
セッション1 基調講演：「探索的テスト - アジャイル時代の効率的なテストを考える」 高橋 寿一
(1)講演資料
下記、JaSST'15 Hokkaidoレポートに掲載されていますので、参照下さい。
http://jasst.jp/symposium/jasst15hokkaido/report.html#keynote
(2)網羅せずにどうやって品質を担保するか？
デイリーリリースに対応するには？
→今までのテストのやり方で解決できない。
そこで、探索的テスト。
(3)開発現場の状況
(3-1)アメリカ(90年代)
- システムテスト
- テクノロジーがあれば、システムテストで全部のバグ見つかると妄想していた時代。
- Cem Kaner
- 全数テストは無理なので、探索的テストを考案。
→全数テストしきれないので、やり方を転換した。
- 全数テストは無理なので、探索的テストを考案。
(3-2)スクラム、アジャイル
- スピードが要求される
開発スタイルによって、テストのやり方を変える。 - 自動化テスト
Salesforce社などの企業で進んでいるが、日本は逆にあまり進んでいない。
(3-3)ゆっくり手動テストとかしていませんか？
開発スピードが速い状況で、ゆっくり手動テストするやり方がよいのか？
→旧来のテスト。
(3-4)旧来のテスト
- 徹夜したテストが実りあるものか？
- 現在は、開発者がコード書く速度が速くなった
- 網羅できているか？
- しかし、網羅するにはコストがかかる
- 自動車系：膨大なコードで、(網羅したテストが望ましいが)全部テストするのが難しいジレンマが...
(3-5)スキルのあるテスター
テスターの給料は、開発者より安い。
→しかし、テストはスキルが必要。特に創造力が必要。
(4)探索的テストとは？
(4-1)ソフトウェアテストの1つのスタイル
スタイルと手法は違う。
(4-2)テスト手法を駆使して探索的テストする
境界値分析や状態遷移テストなど。
→細かいテストケースは書かない。書く暇があったら、テストしよう。
(4-3)同時実行
短時間で分析～実行を行う。
(4-3-1)省くのは文章化
時間がかかるのは、文章化である。
(4-3-2)省くのは文章化時間がかかるもの
- 仕様の不明点を聞く
- 無駄な会議
上記は、テストしていない時間が多い。つまり、製品品質を上げる時間が少ないと言える。
(4-4)バグ発見
(4-4-1)テストケース10万件の0.5%しかバグ発見できない。
テスト仕様を書く時間で予算が多く費やされる。
(4-4-2) テストケースからは見つからない
- スキルのあるテスターが触りながらテスト。
- バグが見つかる。
- テストケース書かなくてもよくないか？
(4-4-3) 修士論文＠フロリダ工科大学大学院の話
- 「自動化で繰り返しテスト」
- Cem Kaner:
「それでバグが見つかるか？意味があるか？」 - 教訓:
バグの原因を開発者と考えることが大切。
- Cem Kaner:
(4-5)テストケースベースドの限界
要求が不明確で、変化するかもしれない。
→モノが出てから考える。
(4-6)要求仕様
(4-6-1)「要求仕様の抜けからバグが出てくるのでは？」 by 高橋寿一氏
(4-6-2)形式手法で書けば...
前提は、ちゃんとできるならば。
(4-6-3)早い段階で要求仕様のバグを発見
例えば、仕様追加部分でささっとテストして1～2日程度で済ませる。
(5)探索的テストのやり方
(5-1)情報源
(5-1-1)"General Functionality and Stability Test Procedure"
・James Bachの資料
http://www.satisfice.com/tools/procedure.pdf
「本資料をベースに探索的テストをやってみては？」 by 高橋寿一氏
(5-1-2)Cem Kanerのサイトに膨大ない資料がある
(5-2)探索的テストの定義
人によってバラバラ。
※補足：
『ソフトウェアテスト標準用語集 日本語版 Ver.2.3.J02』では、下記で定義している。
非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。[After Bach]
「Cem Kanerベースで定義を築きあげるとよい。」 by 高橋寿一氏
(5-3)探索的テストの成果
- バグの数、市場バグの数
- ウォータフォールのテストと比較してみる。
探索的テストチーム vs スクリプトテストチーム
(5-4)探索的テストとランダムテストの違い
(5-4-1)ランダムテスト
- 戦略が無い
- モンキーテストと同義
- 単位時間当たりのバグ発見件数は少ない。
(5-4-2)探索的テスト
- 戦略がある。
- 単位時間当たりのバグ発見件数は少ない。
(5-5)多くのテストケース
- 殆どが無駄になる。
- 一方、開発者の「嫌だな～」というところをテストケースを作ると、バグが出てくる。
(5-6)バグがどこに出てくるか？
(5-6-1)最近の傾向(研究)
- ファイルが長い(サイズが大きい)
- ファイルが頻繁に変更
(5-6-2)7%(hotspot)のファイル
理論的には全てのバグが出る。
(5-6-3)80%のバグは全体の20%のモジュールから発見され、50%のモジュールにはバグは含まれていない。
50%のモジュールから市場不具合としてインパクトは小さい。
→レアケース
(5-6-4)テスト実行前に何のコンポーネントがバグがあるか分からない。
(5-7)タスクシート
- テストリーダが戦略を書くべき。
- ノウハウを共有するという意味でで書いておくとよい。
- テストケース(状態遷移とか)を考えるようなスキルセットが必要。
- 何かニオイを感じる人。
- 戯れているだけの人。
(5-8)探索的テストで大切なこと
ユーザにとって嫌な思いをさせないテスト。
(5-8-1)ユーザにとってそのソフトウェアをユーザの権利を奪わずにテストを担保できるか？
- 例：Excelの90%は使われていない機能。
- どこが必要な機能か？
- 頭を使う
- 要求仕様
- ユーザクレームから、製品のあるべき姿を考える。
- ユーザ視点を考える。
(5-8-2)バグの出るポイントでちゃんとテスト
(5-9)ドキュメント
- 最低限、戦略は書く
- Pass/Fail基準
- １つ１つのテストケースは書かない
(6)探索的テストの注意点
(6-1)非機能テスト(セキュリティなど)は探索的テストをあまりやらない
- 理由:
- 大変なため
(6-2)ユーザビリティテストは有効
(6-3)探索的テストのみに頼らない。
(6-4)終了判定
基準を決めておくとよい。
「"テストケース99.7%Passしたら出荷する"や"信頼成長曲線が寝たら..."は、違和感がある」 by 高橋寿一氏
(7)探索的テストの人材の問題
どういうスキルが必要か？
→プログラミングのスキルは必要。アメリカでは、コード書けるテスターが必要。
(8)Q&A
Q1：探索的テストで品質担保の説明をどうすれば...
A1：テストケースから品質担保の説明はできないと思う。
- コードの20～30%しかテストできていないのため。
- どうやって品質を担保できるかというone of themで探索的テストがある。
Q2：探索的テスト初期段階に陥りやすいことは？
A2：数チームでやりながら悩んで、メトリクスを取ってみる。
探索的テスト以外のチームと仲良くなり、探索的テストと探索的テスト以外で比較してみる。
Q3：「探索的テストの人材」の話でプログラミングスキルが必要と言及していたが、どういうところで必要か？
A3：境界値テストの場合、プログラミングのif/else文を理解する必要があるから。
例えば、sleep()のところにバグが多いな！など。
→プログラミングの構造を知ることが大切。
所感
探索的テストとad hocテスト/ランダムテスト/モンキーテストの違いがよく分からない話題が時折見かけるが、「戦略の有無」がポイントの1つであることに気付いた。また、タスクシートでPass/Fail基準を明確化すると、ad hocテスト/ランダムテスト/モンキーテストに陥らないので、工夫する内容の1つとして実践しようと思います。
私の中で暗黙的にPass/Fail基準はあるが、製品のあるべき姿を開発者と話したり、インシデントレポートに図解することで形式知として共有することを続けていこう。
今後の課題は、プログラミング構造を深く知ることである。テストケースを細かく書かなくても、バグを発見できるようにすることで、開発で手戻り工程が少しでも減らせるよう、多少のテストケースを書きながら工夫してみようと思う。
過去の私が書いたblog記事も探索的テストを実施する際のヒントになると思いましたので、時折読み返そうと思います。 masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
考える大人になるためのツール 国際認定プログラム2015(4)「アンビシャス・ターゲット・ツリー」
2015/8/13(木)～16(日)に京都大学で開催された「考える大人になるためのツール 国際認定プログラム 2015」に参加しました。参加した内容及び感じた事を書きます。
アジェンダ
<1日目>
自分の行いに責任が持てるようになる「ブランチ」
<2日目>
論理的に考え、検証できるようになる「CLR」
<3日目>
ジレンマを解消できるようになる「クラウド」
<4日目>
夢をかなえる「アンビシャス・ターゲット・ツリー」、全体のまとめ、認定資格授与式
以前書いた記事
<4日目>夢をかなえる「アンビシャス・ターゲット・ツリー」
(1)アンビシャス・ターゲットとは？
- 前向き、大変望ましい目標。
- 目標達成するには、戦略的計画が必要。
(2)アンビシャス・ターゲット・ツリーの作成手順
(2-1)手順1：ターゲットを特定
(2-1-1)前向きな目標を見つける。
(2-1-2)ポイント
- 明瞭に定義する。
- 専門用語を確実に理解。
- 学ぶべき主張や概念。
- 全員が確実に理解する。
(2-2)手順2：一連の障害(できないこと、言い訳など)を認識し、リスト化
(2-2-1)障害
- アンビシャスターゲットを妨げる。
- 疑問系ではなく、状況。
(2-2-2)障害を認識
障害を対策する方法を考える。
(2-2-3)障害を特定
既存知識を必要とする。
(2-2-4)ポイント
- 目標の「主語(目標のために行動する人)」が何か明確にしないと、空中戦になることもある。
- 全ての障害を出しきる必要はない。
- 途中で障害が追加されることもある。
- 事実関係の確認
- 暗示されている詳細情報を推察する。
- 「本当か？」
- 「なぜ、障害が目標達成を阻害していると感じるか？」→「なぜなら、･･･」
- 暗示されている詳細情報を推察する。
(2-2-5)例
(2-3)手順3：中間目標を提示
「何を、どういう形になればよいか？」
(2-3-1)例
(2-3-2)ポイント
- 中間目標を考えるとき、「行動」＋「目標」と混同することがある。
- 決め打ちで作るときは仕方がない。
- 「行動」が混入しないようにするのが望ましい。
例：
・Before
もやしを育てる。
・After
船内で食料が出てくる。
(2-3-3)中間目標を評価
「もし、◎◎ならば、結果として△△」で説明できるか？
(2-4)手順4：中間目標を整理、並べ替える
(2-4-1)順序
- 仮定や推測が隠れている
- 前提を想定する
- 根っこの中間目標を達成すると、以降の中間目標が達成しやすくなる。
- やりやすいことから行動するのではなく、やるべきことから最初に行動する。
(2-4-2)検証
「中間目標1」が「中間目標2」より前に発生しないといけない理由を説明できるか？
(2-4-3)例
(2-5)手順5：一連の行動をリスト化
(2-5-1)ターゲット
- 障害
目標達成を阻害する状況。 - 中間目標
障害を克服するための状況。 - 行動
中間目標を実現するための具体的な行動。
(2-5-2)例
(3)アンビシャス・ターゲット・ツリーを作成後の変化
好奇心や考える力により問題解決能力が向上する。
例：
・Before
闇雲に練習する。
・After
中間目標を確認し、できたか否かを確認する。
所感
今回の演習を通じ、「目標に対する阻害要因(障害)は何かを認識すること」「目標達成するまでに至る中間目標の繋がりを整理すること」「一連の行動をリスト化することにより、自分ができたこと/これからやることが明確になること」を念頭に置くと、悩みを解決することが楽しくなると思いました。業務でもプライベートでも問題vs我々(私)の構図でアンビシャス・ターゲット・ツリーを書いてみようと思います。
考える大人になるためのツール 国際認定プログラム2015(3)「クラウド」
2015/8/13(木)～16(日)に京都大学で開催された「考える大人になるためのツール 国際認定プログラム 2015」に参加しました。参加した内容及び感じた事を書きます。
アジェンダ
<1日目>
自分の行いに責任が持てるようになる「ブランチ」
<2日目>
論理的に考え、検証できるようになる「CLR」
<3日目>
ジレンマを解消できるようになる「クラウド」
<4日目>
夢をかなえる「アンビシャス・ターゲット・ツリー」、全体のまとめ、認定資格授与式
前々回、前回
<3日目>ジレンマを解消できるようになる「クラウド」
(1)対立事項の分析
- 解決方法を考えること
- 自分が非難されたとき、何が起こるか？
- 結果：反発して守りに入る。
- 悪影響：正しい論理で思考しない。反発して守りに入ることで、問題解決から遠くなる。
- 立場や解釈により、見え方が異なる。
問題解決に向けて
- Step by Stepで考える。
その他
- 絵で表現した事例もある(5歳児)
- 書籍「ザ・ゴール 2 ― 思考プロセス」に実践例がある。
(2)クラウドを書く
(2-1)問題を特定する。
- 対立やジレンマ
- 「対立」：同時に行動できないこと
(2-2)解釈、分類、自らの言葉で話す。
(2-2-1)意思決定する基準
- 行動に至る要望を特定
- 「要望」:強い動機付け
(2-2-2)問いかけ
- 「重要か？」
- 「必要か？」
- 「得られるものは？」
(2-2-3)注意事項
- 行動と要望を混同しないこと。
- 行動と要望の区別(境界)は？
- 行動→異動したい
- 要望→異動させたくない
(2-3)目標を設定する
- 解決策ではなく、2つの対立の共通目標。
- 「共通目標」：理想的な状況(※ただし、解決策ではない)
- 複数の要望
- 一番強い要望に対する目標
(2-4)一例
(3)解決策を評価
(3-1)避ける、あきらめる
Win-Winの関係にならない。
→Win-Lose関係または、Lose-Win関係。
(3-2)強制、綱引き、妥協
Lose-Loseの関係
(4)Win-Winの関係を見つけるには？
(4-1)直感的方法
クラウドを書いて、見直したときに直感的に思いつく。
(4-2)システマティックな方法
仮定を崩せるか検証。
(4-2-1)検証方法
- 「この仮定は本当ですか？」
- 「この仮定は、実在しますか？」
- 「常にそうなのか？」
(4-2-2)仮定を崩せる案＝解決案
仮定にチャレンジするから、解決策が考えられる。
(4-2-3)ポイント
- 「仮定」を常にチェックせよ
- 「要望」-「対立」の仮定に感情が入っている。
仮定の詳細を深入りし、感情を尊重する。
(5)Q&A
Q1：「クラウドを作るとき、どの程度、調査するか？」
A1：「当事者とクラウドを作るとよい」
Q2：「一人でクラウドを作るとき、一方の仮定が多くなり、他方の仮定が少なくなるのはよくないか？」
A2：「Win-Win関係への解決なので、仮定の数が同じである必要はない」
所感
今回の演習を通じ、頭の中にあるものを紙やディスプレイにクラウドの形で出すことで、自分という立ち位置を仮想的に第3者として見ることができると実感しました。書いてみてふりかえることは、習慣として諸々進めようと思います。
考える大人になるためのツール 国際認定プログラム2015 (2)「CLR」
2015/8/13(木)～16(日)に京都大学で開催された「考える大人になるためのツール 国際認定プログラム 2015」に参加しました。参加した内容及び感じた事を書きます。
アジェンダ
<1日目>
自分の行いに責任が持てるようになる「ブランチ」
<2日目>
論理的に考え、検証できるようになる「CLR」
<3日目>
ジレンマを解消できるようになる「クラウド」
<4日目>
夢をかなえる「アンビシャス・ターゲット・ツリー」、全体のまとめ、認定資格授与式
前回
<2日目>論理的に考え、検証できるようになる「CLR」
(1)CLRとは？
Category of Legitimate Reservation
→書籍「全体最適の問題解決入門―「木を見て森も見る」思考プロセスを身につけよう! 」岸良 裕司(著)/きしらまゆこ(イラスト)の83ページによると、『論理的検証方法』とのこと。
(2)CLRの目的
ブランチを書いて、考えを精査すること。
(3)質問すること
- 思考や論理の検証
- 推論、仮定、結論の有効性を評価。
- 発した言葉が相手にどう理解されるか？
(3-2)発した言葉が相手にどう理解されるか？
(4)□の文章をチェック
(4-1)明瞭性
(4-1-1)明瞭性の懸念
全ての単語は定義されているのか？
(4-1-2)ブランチに□の内容「○○は、･･･である」を加える
「取り入れた」と動詞のみ→「欧米諸国の学校教育の方法を参考に取り入れた。」
(4-2)存在性
(4-2-1)存在の懸念
- 意図しない一般性は、「誤解」「ミスリード」することになる。
- 条件を限定的にし、スコープを決めることで厳密かつ正確になる。
- いつも(定性的)→週1回(定量的)
- 人が私に(他人が主体)→私が人から(自分が主体)
(4-2-2)原因を改善する
結果が大きく変わる。
(4-2-3)抽象的にしすぎる場合
- 断定的なもの
- 抽象的な単語
- 例：依存する
- 対処方法
- 書いてある文章から、ブランチの中のコンテキストが何かを確認する
- 「有効か？」「当てはまるか？」「当てはまらないことはあるか？」
(4-2-4)内容が不正確になる場合
「原因：A かつ (原因：Cならば結果：B)ならば 結果D」
→原因：Cが無くても、原因：A かつ 原因：Bが成立するか？
例：
(4-3)因果性
「Aならば、Bである」→「Bならば、Cである」でしっくりくるか確認する。
例：
(4-4)十分性
「Aならば、Bである」で十分に説明できるか？ Bの結果になるには、Aの原因以外の原因はあるか？
例：
(5)ポイント
(5-1)ブランチの現密度を高めるなら、定量化するとよい。
(5-2)明瞭である基準
- 自分
- 自分が納得するまで
- メンバー
- メンバー間で共有し、合点いくまで。
- 言い換えや別の表現するとよい。
(5-3)因果関係の変化
[行動]→[結果]や[要望]→[結果]で、因果関係は変わる。
(5-4)原因の□の数
例：
所感
ブランチを書き出し「CLR」で論理関係を確認すると、因果関係に違和感があり、論理的に考えることの難しさを肌で感じました。何回もブランチを書いてみて、「CLR」で論理関係を確認して、少しずつ論理的に考えることが空気を吸うような感覚になるように業務の中でTRYしようと思います。
考える大人になるためのツール 国際認定プログラム2015 (1)「ブランチ」
2015/8/13(木)～16(日)に京都大学で開催された「考える大人になるためのツール 国際認定プログラム 2015」に参加しました。参加した内容及び感じた事を書きます。
アジェンダ
<1日目>
自分の行いに責任が持てるようになる「ブランチ」
<2日目>
論理的に考え、検証できるようになる「CLR」
<3日目>
ジレンマを解消できるようになる「クラウド」
<4日目>
夢をかなえる「アンビシャス・ターゲット・ツリー」、全体のまとめ、認定資格授与式
<1日目>自分の行いに責任が持てるようになる「ブランチ」
(1)概要
(1-1)TOC
数少ない制約に集中して取り組めば、効果的なアウトプットが出てくる。
(1-2)教育の制約
世の中の変化する中、ものごとの知識を暗記するだけでは変化に対応できない。
(1-3)考える力
- 教育者の板挟み状態
- 学ぶ人のレベルの違い
- 教育内容の広さ
- リード or 自主性
(1-4)学ぶことの障害
「答えを知る」のではなく、「問いかけで答えを見つける」。
(1-5)Learning Connection
因果関係：行いと結果の繋がり
(1-6)ものごとのつながりを見つける
忘れても思い出すことがきっかけとなり、暗記が楽になる。
(2)ブランチ
(2-1)流れ
- 最初の出来事を見つけて書く。
- 次に何が起こるかを書く。
- 「それは何故ですか？」と書いていない仮定を尋ねる。
- ブランチを書き終えたら、「もし･･･ならば、結果として○○。なぜならば、□□だから。」と読み、論理的意味が通じるか確認する。
(2-2)ブランチの例
(3)バナナ
(3-1)バナナの意味
2つ以上の原因が該当したときの印。
→AND条件
(3-2)バナナの検証
「もし･･･ならば、結果として○○。なぜならば、□□だから。」読み上げ、確認する。
確認するメリットは、下記の通り。
- 直接書いていない隠されたこと(理由)を考えるきっかけになる。
- 暗黙の仮定が見えてくる。
- 日常生活で当たり前なことでも理由を考えることは重要である。
- 理由から説明できるか、納得できるか考えるきっかけになる。
(3-3)一例
(4)ブランチを書くことの気付き
ブランチを作ることで未来を予想することも可能になる。
(5)ポイント
(5-1)因果関係の確認
ブランチを書いたら、「もし・・・ならば、結果として○○」と声を出して読み上げると、因果関係の誤りに気付く。
(5-2)行間を読む
- 他の前提があるか否か？
- 何故？
- 暗黙の仮定が隠れている
(5-3)ブランチの詳細さ
まずは書けるだけ書くとよい。
(5-4)要因が重複
消さない。
→もしかしたら、複数の解釈があるかもしれないため。
(6)注意
「答えを教えると、自ら答えを導くチャンスを一生奪う」
by ゴールドラット博士
(7)Q&A
Q1:ブランチ上の箱はどこまで書くか？」
A1：「ブランチを書く目的によって変わる」
Q2:「何を基点にするか？」
A2:「自分がしたの箱と思うことから基点にする。下の箱が分からないときは、とりあえず書き出す。」
Q3:「ブランチの上の箱が複数出てもよいか？」
A3:「それで構わない」
Q4:「ポジティブなこと(成功したこと)をブランチに書くか？」
A4:「成功した原因を次に活かすために書くことがある」
Q5:「あいまいな状態でブランチを作れるのか？」
A5:「直感のもとなのか、思い込みなのかに気付けるので使える。直感を検証するツールでもある。」
例：寒い日は仕事効率が悪い
Q6:「ブランチ書いて、コアな問題を見つけるコツは？」
A6-1:「気付いていないことがあるかもしれない。」
A6-2:「基点が下層に存在するかもしれない。」
Q7:「何故、因果関係が重要なのか？」
A7-1:「要因により、結果が発生する」から要因を解決すると、結果は発生しなくなる。
A7-2:「上手くいったときは、因果で分析するとよい」
Q8:「ブランチを作るときに必要なスキルは？」
A8:「必要なスキルは、東京ならオンデマンドでブランチを発表して、フィードバックを頂けるので、何回か練習するとよい」
Q9:「巨大なブランチの整理の仕方は？」
A9:「ブランチ作れる人同士でみんなでブランチを作ってみる。
所感
以前、書籍「全体最適の問題解決入門―「木を見て森も見る」思考プロセスを身につけよう! 」岸良 裕司(著)/きしらまゆこ(イラスト)や「考える力をつける3つの道具」岸良 裕司(著)/きしらまゆこ(著)を一読して実際にブランチを書いたが、書いた内容が検証できたかモヤモヤしていて、どこまで書けばよいか悩んでいました。1日目のブランチを書く演習で、5名1グループの方と共有したり、話を聞いたら、モヤモヤが解消される感触が得られたので、みんなでワイワイ取り組むと思考が洗練されていくように感じました。
JaSST15北海道 ライトニングトークスセッションで「探索的テストで工夫したこと」を発表しました
昨日(2015/9/18)開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」の発表を行いました。
発表内容をslideshareで公開しましたので、下記に掲載します。
上記スライドの詳細について、本blogで解説する予定です。
謝辞
本発表に関し、発表する場をご提供＆ご手配頂いたJaSST'15実行委員のみなさま、ありがとうございました。
追伸
JaSST'15北海道のセッション内容を本blogで紹介する予定です。
Asiyan Automation Alliance2015(4)「欧米風と関西風、2つのTest Automation Patterns」
2015/6/27(土)にAsiyan Automation Alliance 2015という関西のテスト自動化カンファレンス的なイベントに参加しました。
参加したセッション
・午前中セッション：オープニングセッション
そんな自動化で大丈夫か？ ～大丈夫だ、問題ない～
@みうみうこと三浦一仁氏(@kazuhito_m)
・午前中セッション
ギアと開発とわたし
@鈴木一裕氏(@kz_suzuki)
(STAR(テスト自動化研究会))
・テスト自動化セッション1
「神は細部に宿りたまう」
きめ細やかなテスト自動化 by Frienldy
@石川達也氏(@StoneGuitar777)
・テスト自動化セッション2
統合的でシームレスなテスト環境を提供する
@SRA 泉和行氏
・テスト自動化セッション3
しくったシステムテストを立て直す。しくらない画像認識自動化ツールsikuli
@徳隆宏氏(@tokutaka)
・午後まとめセッション
欧米風と関西風、2つのTest Automation Patterns
@前川博志氏(@posaune)、森田誠氏
最終回は、上記青文字のセッションについて紹介します。
・欧米風と関西風、2つのTest Automation Patterns ＠前川博志氏(@posaune)、＠森田誠氏
(1)当日のスライド
http://www.slideshare.net/NoriyukiMizuno/aaa2015-2test-automation-patterns
(2)Test Automation Patternsの参照先
(2-1)関西風
https://github.com/KenColle/AutomationPatternLanguage
(2-2)欧米風
http://testautomationpatterns.wikispaces.com/
※みずのりさんのblogに内容がまとめられています。
(3)2つのパターン、1つの世界
(3-1)関西パターンと欧米パターンの共通点
- 関西
善し悪しの状況を共有されている。 - 欧米
各々の内容がまとまっている。 - 共通点
- 例えば、
建て増し旅館 - Tool Mushrooming - 抽象的表現なので、言葉で表現しにくい
- 例えば、
(3-2)使い方
- 大まかな方向付け
関西 - 細かい困り事
欧米
所感
チーム内や会社間のエンジニアで空中戦にならないよう、共通認識するためのパターン言語を整備することは重要だと思う。特に組織(親会社/子会社/協力会社/部/課/開発グループ)が異なる現場では、共通認識が上手くいかず、プロジェクトが失敗に終わったことがありますので、共通認識できる要素を見つけ、ゴールに向かえるようにすり合わせネタとして活用しようと思います。
