JaSST'20 RejectConに行ってきた

ピースオブケイクさんで、JaSST Tokyoに残念ながら落ちてしまったプロポーザルを供養するイベントがあったので、供養に参加してきました。イベント概要はこちら。
connpass.com

noteでのテスト自動化に関する取り組み(ピースオブケイク・増原さん)

※ちょっと遅れて到着したので、講演途中からのメモです。

  • MagicPod使ってる
    • クラウドシミュレータでシナリオが作れる
    • サポートが速い

 

  • 分かったこと
    • エンジニアを巻き込むの大事→はまりどころに二人で立ち向かえる
    • PR単位のFBになると実行時間長め
    • リリース前のテストで変更箇所に集中できる

Flow理論に学ぶレベルアップの鍵(Mark Wardさん)

リベラル・アーツの世界

リベラル・アーツはRIPPAなものを作るのに必要
フローはレベルアップの鍵。
強い状態(フロー)

  • 楽しさ、幸福感
  • 集中
  • 複雑さ:込み入った問題を解くこと

→フロー状態は能力と挑戦が釣り合っている状態。釣り合ってないと不安だったり退屈だったりする。

  • メンタルステート図
    • 挑戦と能力の度合いによって、心理状態にどう変化があるか
    • 挑戦ルート:不安→覚醒→フロー。フローに至るまでの速さは、理解の速さやスタート地点の差による
    • 能力ルート:くつろぎ→幸福→フロー。コントール感があるが、時間がかかる

→頑張れないなら、頑張り方を変える必要がある。それには組織の理解と協力が必要

WebアプリケーションE2Eテスト自動化の3つの壁(末村さん)

自動化の現実

自動化は進んだものの

  • バグを検知できない
  • 思ったより高頻度で実行できない
  • どうでもいいところでコケまくる

バグ検出できないことへのアプローチ

  • 網羅性が低い
    • スナップショットテスト:HTMLの差分を比較(Jestとか)
    • ビジュアルリグレッションテスト:スクショを比較(CodeceptJSとか)
    • 実行時エラーを検知

実行速度問題へのアプローチ

  • テストデータをAPIやコマンドで作る
  • 通信部分だけ実行する
  • 状態をキャッシュする:ログインを毎回やるのはつらい
  • 並列実行(Zalenium、Selenoidなど)
    • 注意点:何度実行しても同じ結果になるようシナリオを作っておく必要あり

安定性へのアプローチ

  • 失敗したステップをリトライする
  • シナリオをリトライする
  • 不安定性を可視化する(Allure Reporterがいい)

まずはE2Eは難しいことを理解する

  • E2Eでしかできないことに注力しよう

おまけ

プロダクト開発におけるアジャイルQA活動(生井さん)

不採択の理由を踏まえる

  • 品質は健康診断*アジャイル開発→最近QAとお医者さんの話題も上がってるし着眼点は悪くなかった
  • 査読コメント
    • チームに展開した結果はどうだったかの事例がききたい(説得力)

伝えたかった事

  • 開発に終わりはない:プロダクトは成長・複雑化していくが、テストリソースは同じ勢いでは増加しない
  • 広さ*深さに加えて時間
    • 広さ:品質特性を軸にどこを見るか
    • 深さ:どこまで見るか
    • 時間:適切に発見できるか
    • 時間*深さ 素早く検査できるか、頻度を意識する必要がある
  • ソフトウェアテストの海はとても広い
    • 物量が膨大になった中でどう理想に近づくかが腕の見せ所

当たり前のことを当たり前にやる

テスト?自動化?それよりもQA/QCの業務とは(仮)(gremitoさん)

プロダクトに最もあう品質チェック作業を模索または最適化

QA/QCのリーダーシップ
QA:品質保証
QC:品質管理

終盤にいくら頑張ってもバグをつぶせない

  • 開発メンバとのコミュニケーションはとっていたか
  • テスト計画は開発の序盤あたりから始められていたか
  • 開発のMTGに参加して状況を把握しているか

開発チームの中にQAメンバがいる
QAは初めの方から参画する
品質チェックに入る前にテスト計画とテストケース作りを終わらせる
→開発チームの一員

ウォーターフォール(V字)開発でモブ設計してみた(t_isekiさん)

問題点

  • 開発者が特定のモジュールを設計、開発する
  • システムテストフェースで後戻りが大きすぎる

実現したかった事

  • やり直しを減らしたい

なぜモブか?

  • ファシリテーションが難しい(めくら承認、設計した人が悪者に)
  • 作業管理が面倒
  • 問題 vs 私たちの構図にしたい

モブ設計

  • 準備
    • 主担当が章立てを容易
    • 章立てに対して気になることや注意点などを参加者がメモ
  • 実施結果

<Good>

  • 要件や設計思想の統一認識
  • ドキュメント整備
  • テスト設計のシフトレフト
  • 当事者意識が芽生えた

Improve

  • 長時間やるとだれる

感想

テストに対して、リベラルアーツや自動化やチームのお話など、色々な切り口からの発表があって、どの発表も楽しめました! 本当にこれRejectなのかと思うほど、素敵な内容でした。企画、登壇者、スタッフの皆様ありがとうございますー!