モーニングセッション: Agile Testing Days 2019 参加レポート

参考資料
- Agile Testing Days 参加報告 #D3QA #AgileTD / Report on Agile Testing Days
- Agile Testing Days 公式サイト
毎年11月、ポツダムで行われるカンファレンスの紹介です。
- 期間はなんと 6日間 !!
  - チュートリアル2日＋本会議 (セッション) 4日
  - 基調講演は14件!！セッションなんと100件以上 !!
- 参加費 約30万円 !!
  - なんかもうスケールが違うや……
- 参加人数は JaSST' Tokyo と同じくらい
  - 私は JaSST 参加経験が無いのでどれくらいのものかわからず＞＜

どんなセッションがあったのか

テスト戦略の話から 自身のガン検知の話 まで！!
- テストの範囲に止まらない多彩なテーマがあった模様
T型人間
- 最近日本のビジネス界隈でも話題になりがちなT型人材の話ですが……
- T型だと自分のラベルがひとつだけになってしまう
- 人間はT型ではなく 壊れた櫛 と捉えてみよう
  - 壊れている箇所は人によって違う、だからチームになるとうまく噛み合うのだ
「カンファレンス嫌いなんだよね」 から話し始めた登壇者
- 黙って聞いてるのではなく、交流しようよ !! ということらしい
学習パートナーシップ を組んだ話
- ドイツと南アフリカという遠距離にいるふたりが、オンライン会議などで一緒に学習した
- 「遠くにいても一緒に勉強していると、毎日カンファレンスに来ているみたい」
- 距離を言い訳にせずに、会議や会話からの関係を築きましょう

現地での出会い

ホテルのロビーで交流
- フリードリンクあり (夜はビールも!! いいなぁ……)
発表以外のコンテンツ
- KeyNote の前に We Will Rock You をみんなで踊る
- コスプレパーティ
- ボードゲーム大会

感想

国内の勉強会も回りきれていない自分にはまだまだ雲の上の話……
- まずは JaSST' Tokyo 行くぞ !!
ちなみに海外カンファレンス参加にあたって一番気になっていることをツイートしたところ、
発表者のブロッコリーさんからコメントいただきました。

費用よりも言葉に不安が…英語…英語やるか… #WACATE
— よーや (@yoya_k) December 15, 2019

自分も英語が不自由でしたが、ノリで何とかなる雰囲気だったのもAgile Testing Daysの良さですね。
あと、ドイツでやってるので、母国語が英語でない人が多く、みんなも四苦八苦しながら会話している印象です。
「英語を話さないと」というよりは、「共通言語として使おう」という感じです。#WACATE https://t.co/OAgWVxZ2JT
— broccoli (@nihonbuson) December 15, 2019

セッション4: アジャイルとテスト

資料
- スライド
- アジャイルソフトウェア開発宣言
  - アジャイル宣言の背後にある原則

アジャイルとは

変化の早い世の中
- 10年前スマホを持ってた人はどれくらい？と考えると……
ニーズの拡大、多様化
- Googleマップは使い方によって求められる性能が異なっている
  - 道に迷った → すぐ起動してほしい
  - 良さそうな店を探したい → アプリの速度はあまり求めてない
アジャイルに向いているシステム
- 外部要因に大きく影響をうける
- 不確実性が高い
「アジャイルソフトウェア開発宣言」 を改めて読んでみよう
- ソフトウェアは歴史が浅い
  - みんな手探り状態
  - やっと方向性が見えてきたくらいだ、と書かれている
- 対話して決めていこう
- 契約交渉よりも協調
  - 顧客も、丸投げじゃなくて一緒に考えよう
さらに アジャイル宣言の背後にある12の原則 を読んでみよう
- 要求の変更は対応するだけでなく 歓迎する
- ふりかえり、やってますか？
  - ふりかえりの時間は意識的に設けないとできない
進化的設計 という考え方
- 大枠をまず作ること
  - ギターの例
  - 最初のステップで手に取ることができることが重要 (playできなくても)

アジャイル開発でのテストの位置づけ

アジャイルのテストはフィードバックを得るためにある
- 開発の方向性が合っているか
頻繁なコミュニケーションが必要
- アジャイルは まず会話 !!
  - チャットでもちょっと遅いと感じる場合がある
  - Face to Face
  - ステークホルダー、チームメンバーと積極的に対話する
    - 喋りやすい座席の配置になっているか
    - 仕様に対して、品質観点で意見する
  - 詳細なドキュメントは残らない という点への対応
    - わからないところは対話して解消するしかない
    - 悩むと短時間でもロスが大きい
      - 2週間のイテレーションだとすると、1日の遅れは……
ペアプログラミング、モブプログラミング
- 教えているのではなく対等な関係
- ひとりで実装するのとどちらが効率いいか
  - 場合によるけど……
  - 仮にひとりでプログラミングして、レビューで根本的な指摘をされたら手戻りが大きい

テストファーストアプローチ

開発する前にテスト設計をする
- TDD: テスト駆動開発
- BDD: ふるまい駆動開発
- ユーザーストーリー
達成するべき目標の明確化
- このイテレーションで何ができればいいんだっけ？

自動テスト

自動テストは、テストを 積み重ねる という考え方
顧客の意見に左右されにくく、変更に強い UnitTest の割合が多い

探索的テスト

知識を持った テスターが行う
- テストの技術知識
- プロダクト知識
テストチャータを用意する
セッションベースの場合は時間きっちり
アドホックにならないようにする
- 思いつきでやらない
- 結果を想定してから着手すると探索的になる
  - 境界値を見る
  - ここを操作するとこうなるはずだと想定する　など

ワーク

お題
- アジャイル宣言の背後にある12の原則をもとに、普段の業務のやり方を見直してみよう

自分の場合、以下2点の原則が守れていないと感じました。

要求の変更はたとえ開発の後期であっても歓迎します。

ちょっと嫌な顔しちゃったかも
そのくせ、こちらがギリギリのところで改善案を出してしまうこともある

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

ふりかえり、全然できてないです
- 個人では簡単なふりかえりをしている
- チームで共有する時間が持てていない

まとめ

アジャイルはアジャイル宣言に沿っていればアジャイルだ!!
最近の傾向
- DevOps または DevSecOps
- マイクロサービス
  - 小さい組織にして決定権を分ける
最新のやり方に従う必要はないけど、学んで積み重ねてみるといいですよ

感想

アジャイルソフトウェア宣言、エンジニアとして駆け出しの頃に読んだきりでした。
アジャイルがメジャーとなった今、改めて基本に立ち返るのも良いですね。

えっと、午前のセッションこれで終わりじゃないんですよ……でも一旦区切ります。