「探索的テストで工夫したこと」(3)探索的テスト実施中：観測
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
以前書いたこと
masaoapril.hatenablog.com
masaoapril.hatenablog.com
[2]探索的テスト実施中：観測
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
探索する目的や手段や探索するスコープ
前回の探索的テスト実施前：情報収集で収集した情報や過去のテストで分かったことを踏まえ、テストで何を知りたいか、知るためにどのような手段を講じるか、現時点での(プロジェクトで確保している)工数でどの範囲でテストを行うかを勘案し、探索する目的や手段や探索するスコープを決めます。
データ出力
テスト実施中に着目するデータをいくつか決めておきます。開発している製品やサービスによって異なりますが、Wiresharkで取得したパケットデータ(TCP/IPなど)の特定部分の変化を観測したりします。アプリケーションソフトでは、バイナリデータとして画像も観測します。
物理的出力
組み込みシステムでは電気的出力として、視覚的なもの：Ethernet PortのLEDの点灯/消灯の時間間隔、聴覚的なもの：電気的スイッチのリレー音(例：車のウィンカーのカチカチ音)の時間間隔や音の大きさ、触覚的なもの：マイコンチップや電源回路から発せられる熱といった人間の五感(センサ)として観測しています。
普段の生活の中で観測した出力をどう研ぎ澄ませるか？
電車通勤では、自動改札機でICカードを読取り部にかざしますが、ICカードと読取り部の距離を5mm余分に離したり近づけたりすることを試し、自動改札機のふるまいを見ることもよいでしょう。また、会社のセキュリティエリアでICカードの社員証をかざし、解錠音が聞こえてからドアノブのレバーを下げるまでの時間を200ms間隔で変えてみて、ドアノブのレバーが完全に下がるか感じてみるのもよいです。
次回
[3]ET実施後について、詳細を説明する予定です。
「探索的テストで工夫したこと」(2)探索的テスト実施前：情報収集
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」について、当時私が考えていたことを数回に分け書き記しています。
前回書いたこと
[1]探索的テスト実施前：情報収集
下記について書き記します。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
何故、ET実施前に情報収集を行うのか？
私だけかもしれませんが、テスト対象で不具合が隠れていると思われる機能を絞り込み、どのような手段でテストを行うか頭の中で検討するためです。また、漠然とテストしたところ、不具合を見つけることができなかったことがありましたので、「テスト対象の怪しいところは何か？」を明確にしたいと考え、「怪しいところ」に繋がる情報を収集したら、不具合が見つかるだろうと考えました。
初めに取り組んだこと
当時、インシデントレポートを多く読んでいなかったのですが、 ソフトウェアテスト293の鉄則の『鉄則055：報告の内容でテストをした“人”がわかる』を読んだ後、「発見したバグは何故修正しないといけないか？」という理由が明確なインシデントレポートを探して読んだら、「テスト対象やシステムのあるべき姿は何かを考えることができるのでは？」と考え、これまで関わったプロジェクトや同僚が関わった過去プロジェクトのインシデントレポートを印刷して読み込みました。
インシデントを何件か読んでいくうちに...
スクリプトテストを実施しながら、「バグが存在することでユーザが困ることは何か？」「どのような手段で、ユーザが困ることを見つけることができるのだろうか？」と思い始め、テスト対象に関する仕様書(要求仕様、製品仕様、テスト仕様)や過去プロジェクトのインシデントレポートを参考情報として、読み漁りました。
読み漁った後...
スクリプトテストで疲れたので、少しリフレッシュしようとペットボトルのお茶を飲んでいたとき、(「そういえば...」と)デジャブを感じるバグが何件かあることに気付きました。バグの傾向をつかみ、インシデントレポートから新たなテストケースを頭の中や裏紙に書きながらテストケースを思いついたので、試しにテストを実施してみたら、偶然バグを発見することができました。
開発者に状況を話したところ、開発者から「それはバグですね。インシデントレポートを書いて、私に送ってもらえますか？」ということで、少しずつですがバグのにおいを感じるようになりました。
次回
[2]ET実施中について、詳細を説明する予定です。
「探索的テストで工夫したこと」(1)全体像
昨年9月に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)のライトニングトークスで「探索的テストで工夫したこと」の発表を行いました。これからの議論が発展することを願い、当時私が考えていたことを書き記します。
ライトニングトークス「探索的テストで工夫したこと」の以前に考えていたこと
私が考えていたことのベースになりますので、下記に掲載します。
masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
ライトニングトークス資料
全体像は、下記になります。
図中の凡例は、下記5点です。
- 白地の四角
抽象度：低の成果物 - 白地の円
抽象度：低のプロセス(行動、やること) - 黒地の四角
抽象度：高の成果物 - 黒地の円
抽象度：高のプロセス(行動、やること) - 赤囲み白地の四角
白地の四角(抽象度：低の成果物)を集約した情報
なお、ET："Exploratory Testing(探索的テスト)"と略称しています。
図を書いた目的
探索的テストにおける私のイメージを第3者が共有しやすい形で表現し、探索的テストがad hocではなく、状況を考慮した(高度な)考えと行動であることを示したいため。また、テストを極めることは易しくないことを経営層やプロジェクトマネージャに伝え、製品品質に対するテストチームやQA組織が寄与するために考えていることを説明するため。
全体像からの概要
イメージは、探索的テストで多種多様の情報と人の五感をテスター自身が吸収しながら、テストをグルグル実施しているものです。時間軸は、1分から1時間単位でプロジェクトの状況によってまちまちです。
次回
[1]ET実施前について、詳細を説明する予定です。
【速報】State of Testing 2016の調査レポートが公開されました
"State of Testing Survey 2016"の調査レポート(英語)が先ほど公開されました。2016年1月にアンケートの回答を募集していましたが、世界中の1000名を超える方から回答されたそうです。
調査レポートは、こちらからご覧ください。
〆
システムテスト自動化カンファレンス2015(8)「パネルディスカッションLIVE！テスト自動化“エンジニア”の今とこれから」
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)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
今回は、「7.パネルディスカッションLIVE！ テスト自動化“エンジニア”の今とこれから」について紹介します。
7.パネルディスカッションLIVE！ テスト自動化“エンジニア”の今とこれから/登壇者：森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
(1)TLからの質問
- Q1
IoTの話は無視できないが、工夫していることはあるか？ - Q2
サービス内容自体のテストへの関わりが増えているか？ - Q3
手動テスト用のテスト設計と自動テスト用のテスト設計の違いは？ - Q4
自動テストが進むと、マニュアルテストやレビューの重みが強くなるが、役割分担はどうなるか？
(2)TLからの質問に対する話
- 機械をいじれる方法をやっている。
- 替えが効くものが入手できる時代。
- 0と1の判断できるか？(例：アニメーションがちらつく)
- 事前条件が書けるか？アンニュイな判断。
- 感覚でバグを検知するひとがいる(少し遅いという感覚)。
- 自動テストと手動テストを使い分ける。
- 人間系の問題、仕組みの問題。
- どれくらい繰り返すかによるが、自動化はコストかかる。
- Cheking
- テストデータは自動も手動も変わらない
- アジャイル
- 幸せになること
- 行動心理学
- 作りが妥当か？仕様にバグがないか？
- もっとできたことがあると気付く。
所感
パネルディスカッションを通じ、テスト自動化のキャズムを超えた先にある世界は、手動テストと自動テストの共存が課題だと思いました。また、"Checking"と"Testing"の役割を開発チーム内で議論して、開発現場や組織にとって幸せな開発になるよう、自動テストの技術を進化することも大切だなと思います。現在、私は昨年度末から参入している開発チームで仕事をしていますが、製品特有のテスト(特にパフォーマンス面)やスモークテストをもう少し網羅したいという話(課題)がありますので、製品のあるべき姿を確認するためのテストをプロジェクトマネージャと納得できるように議論しようと思います。
システムテスト自動化カンファレンス2015(7)「Testing Tools for Mobile App」
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)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
今回は、「6.Testing Tools for Mobile App」について紹介します。
6.Testing Tools for Mobile App /松尾 和昭(クックパッド)
(1)モバイルアプリ
組み込みの次に難しい開発。
(1-1)実情
- OS
- 利用場面の多様化
- サービス開発中心
- 開発サイクルの短期化
- サービス成長、コード肥大化
- アプリのデプロイリスク
- iOS:いきなり100%
- Google Play:段階リリース5-100%
- リジェクトリスク
Apple：1week待ちやポリシー変更 - ダウンロード(できない)リスク
- アプリ評価のビジネスへの影響
(1-2)必要されているもの
- 安定したリリースを回す
- 内的要因への対応
リリース前後の不具合や障害増加防止 - 外的要因
外部サービス障害対応など
(1-3)OSの変化
- 環境変化が激しい
- 必然的に標準で提供されるツールが中心
- 破壊的な仕様変更
(2)事例
(2-1)チーム事情
(2-2)発生した障害
- Androidアプリ
1.機能的に問題ない
2.CPU/メモリ資源が過剰消費
3.発覚したきっかけ：レビュー、お客さんからのお問い合わせ
4.対策：資源の監視
(2-3)学び
- 学び
- 計測から:見えないものを見えるように(CPU使用率やメモリ消費量)
- 開発の流れに組み込むことで習慣化
- 失敗
- 開発の流れに組み込まれていない
- 検出できない
- 学びと失敗を踏まえ
必要なものは実装しよう
(2-4)課題
- シナリオ管理
- 結果のフィードバック
開発者やテストエンジニアだけでなく、デザイナへ拡大。 - サーバーとの協調
API変更の追従。
(3)One More Thing:手動テストから現在に至るまでやったこと
- 自動化を進めた理由
- 開発量やリリース頻度が増加したら破綻する。
- ビジネスのコアとして継続的な改善の土壌。
- 実績を残す ソフトウェアテストへの専門性：ディレクターに施策の効果を説明するなど。
- デファクトを変える
これまでの概念を変える。 - マインドマップ
- 仕様の落とし込むと理解
- 複雑さの理解：テンプレートを作り情報整理
- 開発者に近いところに入る
- 外から内へ
- 開発者が機能実装時にGUIテストが書けたりできたりする。
所感
リスクに繋がる予兆を検知するため何の情報(メトリクス)が必要かを見極めた上で、ツールの活用や自前で作成することも開発方針に盛り込み、開発スピードや開発者の体力気力が落ちないように工夫してみようと思います。
システムテスト自動化カンファレンス2015(6)「キーワード駆動によるシステムテストの自動化について」
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)メンバ, モデレータ：浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)
今回は、「5.キーワード駆動によるシステムテストの自動化について」について紹介します。
5.キーワード駆動によるシステムテストの自動化について /小井土 亨(SQiP 運営委員会メンバー、株式会社OSK)
(1)システムテスト
- End to Endテスト ユーザに触れる直前なので、GUIテスト。
(2)自動化されたシステムテストの課題
自動テストのスクリプトの工数を減らしたい、楽したい。また、スクリプトを直さずに自動テストしたい。
(3)データ駆動
- テストスクリプトとデータが分離。
- 値をファイルに格納している。
(4)キーワード駆動
- 対象、値、操作
- 対象(単価データとか)と操作(セット、クリックなど)がキーワード。
- 問題点：制御処理(IF文)の記述が難しい
- 同じコードが大量作成。
- コードが共通の部分とバリエーションがある部分が混在。
- キーワード駆動の要素
- 値の設定
- 値の読み込み
- 処理実行
- ログ出力
(5)アーキテクチャ
- 何をどのように検査するか？
- キーワード駆動はゴールではない。
- ルールと指針を決める。
- 誰がやっても間違えない。
(6)使い分け
- 同じ操作
スクリプト - バリエーションがあるところ
データ駆動
(7)デモ
C#とPowerShellを組み合わせた内容。
所感
キーワード駆動テストは、現場周辺で適用している事例は聞いたことがないが、バージョンアップを繰り返す開発が進行していくにつれ、自動テストも開発毎に進化していく必要があるので、本発表から現場で適用するネタを考えようと思います。
また、ISO/IEC/IEEE29119 Part5や書籍『システムテスト自動化標準ガイド』第13章も参考文献として、アイディアを温めようと思います。5年後、10年後の開発を見据えて。
JaSST’16東京のコミュニティブースにお越しいただきありがとうございました＠探索的テスト研究会
2016年3月8日(火)～9日(水)に開催された「ソフトウェアテストシンポジウム2016東京(JaSST'16 Tokyo)」のコミュニティブース＠探索的テスト研究会で議論いただいたみなさま、ありがとうございました。
所感
「探索的テストのモデル」は議論の余地がありますが、探索的テストのイメージをある程度共有した上で議論すると、課題が徐々に明確なったと実感しています。「探索的テストに関するFAQ」は、いくつかのFAQでみなさんからの悩みや課題、分からないことなどのお話をいただきましたので、研究会でさらに議論して解決の糸口を探索していきます。
「探索的テストのモデル」及び「探索的テストに関するFAQ」の正式版公開について
今回発表した「探索的テストのモデル」及び「探索的テストに関するFAQ」はβ版です。みなさんと議論した内容を踏まえ、正式版として公開する予定です。
「探索的テストのモデル」及び「探索的テストに関するFAQ」の正式版が公開されましたら、本blogでお知らせします。
JaSST’16東京のコミュニティブースに出展します＠探索的テスト研究会
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)「楽天の品質改善を加速する継続的システムテストパターン」
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
- 課題
- 継続的な品質のフィードバックが困難。
- 困ったこと
- 継続的にソースコードがコミットされない
- テスト実行時間：長い
- 品質可視化コスト：高い
- 解決
(1-4)Infrastructure as Code
- 課題
- 頻繁なデプロイ・リリースができない。
- 困ったこと
- サーバー構築が大変
- 手動でインフラ構築
- 秘伝の手順書
- インフラ構築手順：テスト未実施
- サーバー構築が大変
- 解決
- vagrantでサーバー環境の構築を自動化
- インフラの設定：SCMで管理
- インフラ構築手順：テスト実施
(1-5)CI in Test
- 課題
頻繁なテスト実行ができない。 - 困ったこと
- 問題切り分け：時間がかかる
- テストの継続的な変更と信頼性が問題
- テスト設計の変更に時間がかかる
- 解決
(2)生産性と自動テスト
(2-1)自動テストによる生産性改善
中身が分からない貯金箱より、目に見える貯金箱。
(2-2)自動テストの実装
(3)信頼性とアジャイルテスター
(3-1)アジャイル4象限
- 課題
バグの見落とし - 困ったこと
- 無駄なテストや重複するテストの実行
- 非機能テストの見落とし
- 解決
「誰の？」「どんな？」テストの価値を整理- ユーザストーリーテスト
- オペラビリティテスト
(3-2)スキルセット
- 課題
テストができるひと、やりたい人が少ない。 - 困ったこと
- テスト自動化エンジニア：新しい
- トレーニング不足
- 解決
- キャリアパスの明確化
- T字型のキャリア
- 新人研修
所感
現場で困っていることを挙げてあるべき姿を明確にしてから、「解決したい課題(品質)」→「解決方法(コンセプト)」→「実装」と目的から手段にブレークダウンする流れから、QC活動の良好事例に似ていると思いました。私の現場でも、課長や一部の同僚や私が「あるべき姿って何だろう？」と問いかけ、「何がボトルネックなの？」と課題を洗い出し、「じゃあ、どうする？」と課題に対する取り組みを進めています。私の現場では他社事例に触れることが少ないので、本発表の事例での問題解決の良いところを何らかの機会で紹介してみようと思います。
システムテスト自動化カンファレンス2015(4)「広告システム刷新よもやま話 -テストが当たり前となるまでにやったこと-」
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)目指したもの
- 3倍早い開発スピード
- 変わるべきは「自分たち」
- システム刷新は「結果」
(5)やったこと
(5-1)体制づくり
- リード役の配置
部付きで刷新活動に集中できる環境へ - 仲間づくり
同じ問題意識の人に声かけ。 - 部門長による宣言
刷新することをステークホルダや部内メンバに宣言した。
(5-2)プログラミング言語を変える
(5-3)テストできるアーキテクチャに
- テストできないときとは？ 動作するための準備が大変など
- 現行システム→サーバー分割とAPI化でWebに(?)
- Dependecy Injenction
(5-4)テスト向けのDSL採用(Spock)
- JUnit
Java言語でテストを書くことになるが、Java言語はテストを表現する手段がない。 - 記述言語は、JVM言語のgroovy
テストを記述するためのDSLが構築されている。 - IDE
eclipseからInteliJに変えた。
(5-5)CI/CD、静的解析
- Cloverによるカバレッジ計測
- Coverityによる静的解析
- Quality Advisor
NullPointerExceptionを検出。 - Test Advisor
- Quality Advisor
(5-6)インターフェイス定義言語(IDL)
- テストと別の観点で、開発効率向上と品質向上のため、インターフェイス定義言語(IDL)を選択。
- OSSを利用できないか検証したが、以下の理由で一から作った。
- バリデーションが表現できない
- ドキュメントが生成できない
(6)ふりかえっての所感
- 問題検出をできるだけ前工程にもってくる
- テストできないと言い訳される要因を潰す
- 未熟でも早めに適用/フィードバック受けて磨く
- 部門長サポートと仲間が大事
所感
開発における課題を乗り越えるため、技術的に工夫することも大切ですが、組織の中でも部門長の後押しが無いと、自動テストシステムの開発や保守が頓挫するので、仲間作りも軽視できないと思いました。また、組織の体制や役割も適切に機能しないと、技術的に工夫することが難しくなるので、どのように組織のマインドを変えるか、クリアすべき課題に取り組むことも大切と思いました。
システムテスト自動化カンファレンス2015(3)「自動家は見た ～自動化の現場の真実～」
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氏の立ち位置
- 開発チームの弱点を補う
- 自動テスト
- 自動的に回す環境作り
- 継続的インテグレーション(CI)や継続的デリバリ(CD)
- 開発チームの弱点を補う
(1-2)開発チームに参入
- 与えられた課題を実現。
- 8割：開発、2割：自動家の割合で進めるよう、オーナーから要望があった。
(1-3)状況が変化
方針が変わった。
- 開発規約の導入 WBS導入によるプロジェクト管理 詳細設計書の作成 *従来のアプリから、新機能を搭載するため別アプリとしてフォークされる。
- M氏
- フォークされた新アプリのソフトウェア構造の整理＆再設計をしていた。
- 非公認のレビュアーやリファクタリングも担当した。
- 自動家としての業務が縮小し、ついに離脱。
(1-4)自動化離脱後のふりかえり
「雇い主」と「お客さん」が望んだ場合に自動化の効果が最大になるのでは？
(2)マネージャ側＠みずのり
(2-1)パターン
「うるさい人がいなくなる」
(2-2)マネージャ
- コンフォートゾーン
- 自分の経験や知識があり、因果関係を予想できる範囲。それ以外は、理解するのは容易ではない。
- 自動化は、範囲外となることが多い。
(2-3)抵抗の6階層
- 問題
- 問題の存在に合意しない
- ソリューション
- ソリューションの方向性に合意しない
- ソリューションが問題解決できると思わない
- ソリューションの実行でマイナス影響が発生
- 解決策実現
- ソリューションの実行を妨げる障害がある
- その結果起こる未知のことへの恐怖
(2-4)本当に価値があれば
数値で説明できるメトリクスを持つことが大切。
(3)「自動家」を「仕事」にするには
(3-1)顧客サイド
自動化システムの成果物を得るには？
(3-2)マネージャサイド
- 組織でお金が儲かる
- ロジック検証
- 投資に対するペイバックどの位か？
(3-3)M氏(現場)サイド
- 本当に「売るべきモノ」は？
- 開発現場での制約
- 「社内スタンプラリーお遍路」
- 「内線番号の手配」
- 「役職クラス以上が見れる進捗閲覧システム」
- 「テスト自動化の道具を印刷して自前で再現」
- ネット禁止、OSS利用不可
- 開発現場での制約を打ち破るには？
- 自動家を増やす！
所感
自動テストを進める上の課題や問題点で自組織に該当するものもあり、現場とステークホルダの間の溝を埋められるよう、自動テストで実績をあげることが必要と思いました。また、「利益を増やす」「損失を減らす」の2点が両輪となるよう、問題提起と解決案を見つけることが課題として進める必要があると思いました。
システムテスト自動化カンファレンス2015(2)「テスト自動化のスキルを考えよう！ ～テスト自動化エンジニアに求められるスキル、期待される役割～」(後編)
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
所感
自動テストに関する知見が体系化されると、自動テストを進めるときに「何を考慮すると、プロジェクトが上手く進められるか？」「現状から次の目標を達成するために何から取り組むか？」「陥りやすい罠はどのようなシチュエーションか？」が考えやすくなると思いました。今後の動向を気にしながら、開発チーム内での取り組みを考えていこうと思います。また、最後の「言葉が定義できないと議論できない」は、様々な技術コミュニティの課題ですので、開発メンバーやコミュニティメンバーが共有できるように土台作りを進めようと思います。
