システムテスト自動化カンファレンス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
所感
自動テストに関する知見が体系化されると、自動テストを進めるときに「何を考慮すると、プロジェクトが上手く進められるか？」「現状から次の目標を達成するために何から取り組むか？」「陥りやすい罠はどのようなシチュエーションか？」が考えやすくなると思いました。今後の動向を気にしながら、開発チーム内での取り組みを考えていこうと思います。また、最後の「言葉が定義できないと議論できない」は、様々な技術コミュニティの課題ですので、開発メンバーやコミュニティメンバーが共有できるように土台作りを進めようと思います。
システムテスト自動化カンファレンス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 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会
以前書いた記事
masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
今回は、セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」です。
4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
(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 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会
以前書いた記事
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"で基礎を固めるとよいと思いました。
