JaSST'18 総括
•Download as PPTX, PDF•
0 likes•420 views
私が参加したJaSST'18の総括になります。 前編から2つテーマと感想などを追加しました。 ・テスト設計 ・テストとアジャイル ・感想とか
Recommended
More Related Content
Similar to JaSST'18 総括
Similar to JaSST'18 総括 (20)
JaSST'18 総括
- 2. この資料について • 私が2018年中に参加した Japan Symposium on Software Testing (以下JaSST)から、印象に 残ったテーマを紹介するスライドです • 2018年は以下のJaSSTに参加してきました • Kyushu（長崎） • 2018/11/22 • Kansai（愛知） • 2018/12/7 • Tokyo（東京） • 2018/3/7～3/8 • Kansai（大阪） • 2018/6/15
- 3. ご注意 • 複数の開催地で同じテーマのものは纏めています (右上に開催地を記載) • この資料には個人的な意見・感想が多く含まれています • これまでの私の経験や知識ベースでの見識ですので、皆様の実情・実態に即してい ない見解があると思いますがご了承下ください • 前提知識無しでは何を言っているのか不明なこともあるかもしれません 資料のみ閲覧の方は、恐縮ですがGoogle等で検索して調べてみて欲しいです 直接会える人は一からジックリお答えしますので、遠慮なくご連絡ください • ご意見や訂正がありましたら、お知らせください • 一部、前編と同じ内容があります(自己紹介、テスト駆動開発、キャリアとテスト)
- 4. 自己紹介 • 川喜多 智信（かわきた とものぶ） tn_kawakita@innogress-jp.com • 株式会社イノグレス テクニカル・プロモーション事業部 部長 https://www.innogress-jp.com/ • 某江戸祭囃子保存会 会長 • 本気のオシャレは和装と心に決めている • 趣味 • 江戸祭囃子、江戸里神楽、阿波踊り • JaSSTに参加して呟くこと (Twitter @yuimaster1982) • 2020年にJaSST全国制覇を目論む • テスト業界に入って15年半 • 携帯電話・スマートホン 延べ10年くらい • ゲーム機 3年 • ネットワークキャプチャ製品 2.5年 • Webサービス (2019年～) • やってきたこと • テスト全般（設計～実施）、自動化 性能改善Prjにテストチームリーダーとして参画 • チームリーダー（5人～30人） • 直近6年くらいはただの作業員 • テスト自動化(色んなところで) • QAコンサルティング now! ↑ 横 笛 吹 い て ま す
- 7. 私のテスト駆動開発の失敗 テスト駆動開発についてちゃんと勉強していなかった頃。。。 (名前を聞いて想像して試そうとした) • 漠然とテストコードを書いてから実装すればいいと思っていた …φ(ー￣*)カキカキ_φ(*￣0￣)ノ[ノヽ”－力]ペタッ • テストケースを考えていたら考慮すべきことが溢れてしまい、何処から手を付けてよい のか分からなくなった。。。 • やり方がそもそも間違っている！ やめましょう！ なんちゃって テスト駆動開発！
- 9. テスト駆動開発とは • テストファーストの理念に基づく開発手法 • 最初にテストケースを書き、そのテストが通るようにコーディングしていく • Red→Green→Refactoring のサイクルを繰り返すことで、 品質の高いコードを積み上げて作っていくことが出来る • 詳しく知りたい人は「テスト駆動開発」を読んで欲しい • Kent Beck 著 和田卓人 訳 • https://www.amazon.co.jp/dp/B077D2L69C/ @Kansai
- 10. TDDのいいところ • すばやいフィードバック • コードを書く→テスト実行で直ぐに結果を得られる • コードの変更に対する恐怖心が小さくなる • 既存のテストケースが通ればモジュールの品質を保証することが出来る • 例えば、インターフェースはが変えないがロジックのアルゴリズムを変更したい場合 • テストコード＝詳細仕様 とみなすことができる ※オススメするわけではない • 「実装コードを読め」よりはヤサシイ • 難解な仕様書を読み解くよりも、メソッド毎に振る舞いが列挙されていれば分かりやすい @Tokyo @Kansai
- 11. TDDの悪いところ • 実装コードを書くだけのときよりも時間が必要になる • テストコードを各分＋テスト実行の分をちゃんと見積もっておかないといけない • 実装コードだけのときより2倍～2.5倍くらい必要らしい • テストケースの爆発 • だんだんテストケースが増えていく • テストコードが実装コードの1.5倍以上になることもあるらしい • 安定しているモジュールは適宜メンテナンスして減らす必要がある • テストケースが増えると自動テストの実行に時間が掛かる • 運用で実施するつとケースを減らすなど工夫する（リリースビルド以外は、半分ずつテストするなど） • 分散したりマシンパワー増強の力業で乗り切る @Tokyo @Kansai
- 12. やってみて • 出来上がるまでに少し時間はかかるが、ただひたすら リファクタリング か Red → Green にする方法を考えることに 夢中になれて、心地よい疲労感を得られた • 話に聞いていた、『書いたコードに自信が持てる』を実感 • 現場でTDDの布教をしたくなった
- 13. キャリアとテスト Tokyo & Kansai & Kyushuより
- 15. 動向 - 組込み系 • 2極化が進行中 • 上級者 • テスト設計やマネージメントできる人 • 自動化、プロセス改善できる人 • テスト実行者(オペレーター) • オフショア・ニアショアで安く外注 • 国内では低額でしか受注が難しくなってきている • 新人は早く上級者へレベルアップして欲しいという要求が強い @Tokyo @Kansai @Kyushu @Tokai 数年以上間から進行中ではあ るが、この2年～3年くらいで 差が開いた印象がある
- 16. キャリア - 組込み系 • テスト設計技術が重要 • 経験も大事だけど幅広い設計技法があると有利 • モデリングが出来ると適切な設計技法を選択がやりやすいので重要度高め • 経験が正しい設計技法を選択するときのヒントになる • テスト自動化のノウハウ • どこへ行っても強い要求がある • プロセス改善のノウハウ • とっても重宝される存在になる • 開発プロセス全体の改善提案ができると、QAコンサルタントへの道が拓ける @Tokyo @Kansai @Kyushu @Tokai 今これに近い仕事してます。 Web系だけど
- 17. 動向 - Web系 • そもそも、Webサービス系企業ではテスト部隊が無くなりつつある • TDD、CI、自動テスト、アジャイルのコンボでリリースサイクルの短縮を図って いる • こうした企業では横通しのテスト観点を注入するSET（Software Engineer in Test） という役が必要とされている • Web業界のテストエンジニアとしてやって行くならSETを目指すと良さそう • ただし、金融系や基盤系などはまだ組み込み系と傾向が似ている • いずれはDevOpsが主流になるかも @Tokyo @Kansai @Kyushu @Tokai
- 18. キャリア - Web (SETに必要なモノ) • Webサービス(ドメイン)に対する知識 • モデリングの知識・経験 • ソフトウェアテストに関する知識・経験 • 同値分割、境界値分析、デシジョンテーブ ルあたりは必須 • これらをテストケースに注入するだけでも、 テストの質がグンとアップする • エラー推測、カバレッジ、etc • テストの知識はあればあるだけ有利 • プログラミングの知識・知見 • 言語・フレームワークの特徴 • クセが分かると起きやすいバグもわかって くる • プログラミング経験もあると尚良し • TDDや自動テストのノウハウ • 自動テストしやすいモノ、しにくいモノを 見分けられ、テストケースに注入できると 自動テストがスムーズに進行するようにな る @Tokyo @Kansai @Kyushu @Tokai なんだかんだで、覚えることがたくさんある 全部一気に習得は難しいので少しずつ蓄える サービスのファンになるといい
- 19. テストに向いている人 Kansaiのセッションで紹介されたテストに向いている人の例 • バリエーションを考えられる人はいいと思う • 批判的思考は向いていると思う • ゴットハンドも無意識の多角的客観視点の一つか？ • テストエンジニアに向いている資質 • 推理小説が好きな人 → テスト設計や探索的テストに向いている • 市場の実情がわかる人 → テストの合理化（テストケースの取捨選択） • 他人の仕事に土足に踏み込む人 → 突破力!? • 否定ばっかりする人はよくない • ちゃんと対案が出せて建設的に議論ができるなら問題ない @Kansai
- 20. お給料を上げたいなら 自分の存在価値を上げる、そしてアピール！ • まずは技術力 • なんとなくではなく、なぜその技術を選択したのか説明できるといい • 経験は成功だけでなく失敗も大事 • ただ失敗した経験ではダメ • 「何が原因で失敗したか？」「次はどうしたら成功に近づけられるか？」を持って いないとダメ @Tokyo @Kyushu
- 21. 第三者検証会社の行く末 • 発注する方 • 技術力のある会社に頼みたい • 出来るだけ安い金額で発注したい • 受注する方 • 出来るだけ高い金額で受注したい • 出来るだけ低コストでテストをしたい 発注⇔受注で乖離が存在する ゼンゼンWin-Winなんかじゃないよ！ 技術力を持っているか客観的な判断が難 しい JaSSTや勉強会などを通して技術力のある 会社を探す 技術力をPRしないと新規顧客の獲得が難 しい（HP見ただけじゃ分からない） JaSSTや勉強会は技術力や向上心をPRでき いる場 技術で殴って効率化！ @Kyushu
- 22. 私の目指すキャリア • 暫くはSETやQAアドバイザーのようなポジションで現場に関わりたい • 貯め込んでいる知識を放出して、良質のエンジニアを育てる • 時々、開発をやりたいかなー ゴールはCTOや技術顧問のようなポジションで そこそこ高収入！
- 28. 同値分割・境界値分析 • シンプルであるからこそ、幅広く応用が利く • 使いこなせると強力な武器になる • よくバグが見つかる • 単体テストとも相性が良い • むしろ、単体テストでこの手のバグを潰してくれると後工程のテストがラク 強力、且つ、シンプルで覚えやすい テストエンジニア必須の技法と言っても過言ではない ただし、万能というわけではない @Kyushu 範囲を絞ったり、代表値だけ やったりとテストケースを減 らす工夫の余地が出来る ↓ 余ったリソースを別のテスト に振り分けることでさらなる 品質アップにつなげる
- 29. マインドマップ • マインドマップを用いてテスト観点を抽出する設計技法 • テスト対象の機能を中心に据えて思考を発散させて行き、 様々な状態や操作を検討してテスト観点を炙り出していく • Xmindなどのツールを使って、広げたテスト観点をカテゴライズし直したり、テス ト範囲を選定したりができて便利 マインドマップは簡単かつ手軽に描ける 色々なレベルのテスト設計にも使える 覚えて損のない技法 @Kyushu
- 30. デシジョンテーブル • デシジョンテーブル • 関連の強い入出力値の組合せをテストするときによく使う • 単体テストや結合テストレベルでxUnitや自動テストが済んでいるなら、 是非デシジョンテーブルでバグを潰してもらえると後工程がとっても助かる とはいえ、条件が増えるとパターンが爆発して泣ける、けど頑張って作ってる いい方法があったら誰か教えてほしい・・・ @Kyushu
- 31. 直交表・All-Pair法 • 直交表、All-Pair法 • 総合テストレベルでの組合せではよくお世話になる • 無神経にPictMasterなどで組合せパターンを作ると逆にテストケースが増えることもある • 特性を理解してパターンの導出できるようになるといい • 私がよく使う方法 • 因子が多い ⇒ シチュエーションなどで因子を絞って、他の因子とは代表パターンや境界値パターンなど で組み合わせる • 水準が多い ⇒ 同値分割・境界値分析と組み合わせる • 因子や水準の関係性が強い ⇒ その因子や水準だけデシジョンテーブルでテストした後、代表パターンと 組み合わせる • リスクなどをちゃんと検討してね！（ようは自責任で） @Kyushu
- 32. 時間に追われてるなら。。。 • 時間を掛けないテスト設計方法を考える • マインドマップ＋「それはあたる」エッセンス なんてどうだろうか？ • れ： 例示 ⇒ テストする機能の振る舞いや条件を例にして出す • あ： 間 ⇒ 例示で出した値やテストする機能の隙間条件(中間値、タイミング等)を出す • た： 対称 ⇒ 例示したことと反対の値や振る舞いを考える • る： 類推 ⇒ 例示したものから離れた値や振る舞いを考える • そ： 外側 ⇒ 仕様の外側を検討する(非機能要件とか) • は： 破壊 ⇒ テストする機能にとっての異常状態を考える JaSST’14 @Hokkaido
- 35. アジャイルでテストしてみて 1. テストの規模が大きくなると1スプリントに収まらなくなる • このスプリントは準備でイッパイイッパイ、次スプリントでテストなんてことが何度か • テストのスプリントが複数スプリントにまたがることも何度か • モノが出来上がるのがギリギリでテストが次スプリントになんてことも 2. テスト設計はやっぱり時間が掛かる • 少し大きいテストはテスト設計する • マインドマップ、境界値分析、デシジョンテーブルくらい • ちょっとした変更はアドホックテストで済ませている • マインドマップで変更点や影響範囲を洗い出して、テストポイントを抽出するくらいはやってる • 開発アイテムの大きさのバランスが取れてない？ @Tokyo @Kansai @Kyushu @Tokai
- 36. アジャイルとテスト設計の相性 • マジメにテスト設計するとある程度時間を要する • 開発と並行で作業を進めても、規模や影響範囲によってはテスト範囲が大き くなってテスト設計やテスト実施の時間が足りなくなる • 小さな変更や機能追加だけを追っかけていると、全体を見渡した時の影響を 追えていないように感じる • 1スプリント内で設計～開発～テストが終わらないとダメなの？ • そんなことないよね？ @Tokyo @Kansai @Kyushu @Tokai 注：個人的感想です
- 37. じゃぁどうする？ • 開発アイテムの粒度を揃える • 出来るだけ小さくする方向で揃え、テスト設計の時間を平準化する • 開発～テスト完了まで複数スプリントは認める • 最大でも3スプリント以内 • Googleやクックパッドみたいにほぼ全部自動化してなきゃ1スプリントは無理 • ガチなテスト設計が必要な場合はタスクを分離して別個に進める • 動作確認＋αくらいまでは開発アイテムの中でやっておく • 最初から躓いてバグ修正待ちなんて悲惨すぎる・・・ • テスト設計～テスト完了までは3スプリント以内を目標に • 自動化できるとこはどんどん自動化する • リグレッションテストなんかは自動化されているとだいぶ助かる @Tokyo @Kansai @Kyushu @Tokai アジャイルなんで 「みんなで合意して進める」 「みんなで協力して進める」 が大事 アジャイルに限らないかも 理想的すぎてなんか実現するのは大変な気がしてきた・・・orz
- 38. 最後に
- 39. 個人的な感想 • 和田(@t_wada)さんの講演はすばらしい @Kansai • 聞いているだけで、テスト駆動開発(TDD)の何たるかが分かってしまう不思議 • JaSST’14 Hokkaidoでも聴講しました • アジャイルはチームメンバーの連携が鍵 @Tokai • チームを破壊するヤツはパージしろ！(スクラム実践入門より) • 15分スプリントは平準化を極致！？ @Tokai • 究極まで単純化したタスクを高速にブン回す • チームで作業を極限まで平準化する • きょんさん(@kyon_mm) 解説ありがとうございました！
- 40. JaSSTを超推しする！ • JaSSTのいいところ • 数千円で参加でき、コストパフォーマンスが高い • 他のカンファレンスや技術展などと比べるとかなりリーズナブル • 遠方のJaSSTは移動や宿泊費が掛かるので、近場のから参加するのがお勧め • 業界動向や最新情報が手に入る • 基調講演や各種ワークショップやチュートリアルが充実 • 時の人から最新情報を聞ける！ • 参加者や実行委員も同じ様なことで悩んでいる or ヒントを持ってる • 多くの方と意見交換する機会があり、同じ悩みを解決した人からヒントを得られるかも知れません • 刺激を受けてモチベーションアップ！ • 特に知的好奇心が刺激される どこかのJaSSTで会いましょう！
- 41. JaSST’19の参加予定 • JaSST’19 Hokuriku • 参加できませんでした。・°°・(＞_＜)・°°・。 • JaSST’19 Tokyo • ゼ・ッ・タ・イ 参加する！ • JaSST’19 Niigata • たぶん欠席 • JaSST’19 Tohoku • 気になる・キ • JaSST’19 Kansai • テーマ次第では参加したい • JaSST’19 Hokkaido • たぶん欠席 • JaSST’19 Kyushu • たぶん欠席 • JaSST’19 Tokai • テーマ次第で参加したい • JaSST’19 Shikoku • たぶん欠席 ※上記は予定であり、気分次第で変更する場合がございます