Agile QA Night #2 参加レポート
このブログ内で「〜やります！」とか「いつかまとめます」とか書いていますが、なかなか進んでないマーガリンです。
今年も半分が過ぎてしまったので、そろそろ本格的に取り組んでいこうと思う次第であります。
さて、久しぶりに社外イベントに参加してきました。
今回参加したイベントは下記になります！
Agile QA Night!! 2
はじまりました！#D3QA
— マーガリン (@Y_MAGARI000) June 20, 2019
ちなみにtwitterでのまとめ（toggeter）は下記になります。
私（@Y_MAGARI000）も呟いておりますよー
＊ブロッコリー🥦さんには大変感謝です。
さて、今回はAgileにおけるQAのあり方について、今回は３名のゲストが登壇してくれました。
えっちゅーさん、コヤマンさん、まつさん
前回の第一回は満員だったため出ることが出来なかったので大変楽しみでした。
えっちゅーさんの発表はこちら
今回の発表は私も参加した、「wacate2018冬」で発表されたものを一部修正したものでした。
某複合機メーカ、X社で組み込みマニュアルテスターのえっちゅーさんがWeb系の自動テストエンジニアになったお話でした。
- 組み込み系の第三者評価をしていた。開発体制はウォーターフォール開発
- スクリプトテストのマニュアルテストしかしていない
- プロジェクトの期間も長く、テスト工程が２〜３ヶ月あることも。
- 「自動化をやりたい！」でWeb系企業に転職。開発体制はアジャイル開発。
実は私も前職でえっちゅーさんと同じ現場で仕事をしていたの、この組み込み系の話はとてもよくわかりました。（辛いこととか苦しいこととか。。。）
そして私も転職後は同じ自動化エンジニア。（エンプラ系ですけどね）
転職後に思ったことが、とても似ていたこともあり、非常に面白い発表でした。
前職と現職の違い
ざっくり表にまとめて見ました。
| 前職 | 現職 | |
| 開発体制 | ウォーターフォール | アジャイル・TDD(BDD)で開発 |
| サイクル | リリースまで１年くらい *テストは2ヶ月くらい |
基本的には、週１回 |
| 対象 | 組み込み系 | Web系 |
| テスト手法 | マニュアルテスト | 自動テスト＋マニュアルテスト |
| テスト内容 | チェッキング | リグレッション系は自動テスト 探索的テストはマニュアル |
| 仕様書 | 機能別に仕様書がある... | ドキュメントは少なく、 自動テストの記述内容が仕様書 |
転職して気づいたこと
前職と現職では、対象システム・開発手法の違い・仕様書の有無・テスト手法の違いなどが大きいという発表でした。
大きく環境が変化しても、JSTQBに書かれているようなテストの基本となる考え方は変わることなく、環境は変わってもテストへの関わり方は変わらないということには強く共感しました。
私自身も同じようなキャリアを経ていますが、今までテストについて勉強してきたことは、アプローチは違えど、基本的に適用することが出来ていますし、なんとかやってきています。
全然色の違うプロジェクトであろうと、以前経験してきたことが思いも寄らないところで活用できたりと、むしろ別の分野を経験したことが＋になることが多いとも思っています。
この発表は同じようなキャリアの人には「だよね〜」ってなるし、
一社しか経験していないとか、一つのプロジェクトにずっと関わっている人には、とても有意義な発表だったのではないかと思います（なぜ上から目線なんだ...⬅︎）
コヤマンさんの発表はこちら
コヤマンさんは先日のJaSST東北で基調講演をされていた大物（体も大物...！）です。
私も短い期間でしたが、陸上自衛官をしておりましたので、なぜか勝手に親近感が湧きました。
さらにさらに、某複合機メーカX社で一時期働いていたこともあったとか。。。
えっちゅーさん、コヤマンさんとはなんだか似ているキャリアだなぁと発表中に思っていたマーガリンです。
さて、今回の発表は、えっちゅーさんとも共通することがありましたが、次のようなものになっていました。
ウォーターフォール型とAgile型の違い
| WF | Agile | |
| プロセスと役割 | 会社標準で決まっていた →計画重視 |
できること全部 →価値・スピード重視 |
| 周囲の意識 | 計画重視 | ユーザーの価値を重視 |
| 時間の使い方 | 調査 | 議論・会話・探索 |
これは本当にそう思いました。
以前は社内でそれぞれ、誰が何を担当することが明確に決まっていました。
テスト設計はテスト設計者が。テスターはテストを。開発は開発だけを。
全員の共通目的は納期までに社内標準で決まった項目をパスしてリリースすること。
認定スクラムマスターを取得するのにあたり、受講した研修では、
何に重きを置くのかを考えさせられる時間があり、目から鱗が落ちる気分でした。
そのプロジェクト・機能をリリースしてどうしたいか。
上から言われたからなのか、それとも利用してくれるエンドユーザーのためなのか。
話を聞いている最中は、こちらも同意しかありませんでした。
WFとAgileで変わったこと、変わらなかったこと
- テストをすること！
- 製品の目的・存在意義が大事であること
- テストは状況次第
- 「開発チームの認識の外側をフォローする」こと
特に最後の１行は大切だと思います。
とある機能に対して、開発は「正しく動くこと」に意識が向くかと思います。
これに対して、QAは同じく「正しく動くこと」を見ているだけではいけない。
そうコヤマンさんはお話されていました。
意識が向いていない分野。例えば、その機能で〇〇はどうなるんだろう？とか
どのような影響を与えるのかを発言することで、喜ばれるし、そのような関係になるべきと。大大大大賛成です。
コヤマンさんのお話で、改めてQAとは？と考えるキッカケになりました。
まつさんの発表はこちら
テスターちゃんの生みの親である、まつさんは唯一同じ現場（某X社）を経験していない方だったので、とても新鮮な内容でした。
まつさんが経験してきたAgile
【 餅つき型 】
— マーガリン (@Y_MAGARI000) June 20, 2019
機能できました！
⇅
テストします！
の繰り返し
（これは疲弊するなぁ）
| # | 名称 | 概要 | その他 |
| 1 | 餅つき型 | 開発⇄テスト 機能ができらたテストをする。その繰り返し。 切れ間なくテストが続く |
繰り返しやるので、トラブルが出るとお互いに疲弊する |
| 2 | 管理メイン型 | スプリント前半：開発 スプリント後半：テスト 工程が分かれているので、管理が容易 |
スプリント内で小さなWFが回っている。 なんちゃってAgile |
リリースサイクルが早いのが問題。どうテストをするのか・・・
まつさんの改善策
最初はJSTQBに記載されているテストプロセスを適用。
だが、これではやる作業が多く、早く回っているスプリントでは時間が足らず、
辛くなってくる。（辛いことは続かないのよ〜）
そこで！下記のような一連の流れで進めた！
- 仕様書をみんなで読む
- みんなでテスト観点を出す（出なかったら赤いテスト会s...(自重)
- テストケース作成
- 探索的テスト（１回目）
- スクリプトテスト
- 探索的テスト（２回目）
- リグレッションテスト（自動化）
- リリース後テスト
詳しくはツイッターを見てもらえるとわかりやすいかも（体力切れ）
まとめ
久しぶりイベント出たけど、外に出て話聞くと"気付き"が得られて良いですね。
— マーガリン (@Y_MAGARI000) June 20, 2019
モチベが上がる。
うまく言語化できないけど、外に出て、いろんな事例や発表を聞くことで、
いつか「これ進◯ゼミでやっったこと（聞いたこと）あるやつやー！」って思えることがあるかもしれない。
また、自分の今の立ち位置（レベルとか）も計測できるし、やること・やるべきこと・やってみたいことが見つかるのかも。
何がいいたんだろう。。。まとめになっていない。。。
ニポンゴムツカシイ。。
発表者のそれぞれの発表は準備など考えると大変な作業だったかと思います。
時間をかけて作ってくれた資料に込められた熱意の全部は難しいかもだけど、
一部分でもいいので、自分のものに落とし込めればなと思いました。
今度は自分が発信して、世のためになりたい！ と密かに思っていますので、
その時がきましたら、何卒よろしくお願いします。
