JaSST'20 Tokyo RejectCon参加メモ

JaSST'20 Tokyo RejectCon

イベントの説明

• Connpassより引用
  • 2020年3月9日(月)～10日(火)に実施される日本最大級のソフトウェアテストシンポジウム JaSST'20 Tokyo の一般公募セッションで、残念ながら選外となってしまったセッションを発表する場です。
  • ※本イベントは有志で行われるものであり、JaSST'20 Tokyo 実行委員会様やASTER様などとは関係していません。実行委員会様などへのお問い合わせはご遠慮下さい。

会場＆Special Thanks

• 会場：株式会社ピースオブケイク
  • 107-0061 東京都港区北青山3-1-2(青山セント・シオンビル4階)
• Special Thanks(懇親会の飲食提供)：オーティファイ株式会社

講演

①増原さん（ピースオブケイク）「noteでのテスト自動化に関する取り組み」

• 株式会社ピースオブケイク
  • note
    • つくる、つながる、とどける
    • マガジン機能を使って有料の連載が可能
    • 今日はiOSアプリについて
  • note開発チームの話
    • Webは毎営業日デプロイしてる
    • iOSは月一くらい
      • リグレッションテスト効率化したい
  • ゴール：iOS
    • Magicpod
      • がっつりな環境構築不要
      • サポートメールの返信早い
  • ハマりどころ
    • 新機能の部分とリグレッション用でシナリオが分かれる
    • 最新版のappがどれだかわからなくなる
  • わかったこと
    • エンジニアを巻き込んでやるのは大切
      • iOSエンジニアの力を借りることができるのは大きい。はまりどころに2人で立ち向かえる
    • プルリク単位のフィードバックとなると実行時間が長め
    • リリース前のテストで変更箇所に集中できる
  • 採用情報は懇親会の時にぜひ
  • Webはmablを使っている。そしてこのリンクからその発表の参加レポに飛べる

感想

• 私もエンジニアと一緒にやろうと思った

---

②Mark Wardさん「リベラル・アーツの世界〜Flow理論に学ぶレベルアップの鍵〜」

• ソフトウェアテスト一切関係ありません
• European Testing Conference 2020に行くから明後日飛行機に乗る
• 節分は立春の前日
• 豆を撒くのは「魔滅」
• 本題へGO
  • 基礎の上にRIPPAなものができる
  • エンジニアは、一生勉強する職種である
  • 圧倒的成長してる？チームメンバーはどう？
  • レベルアップの裏には何があるだろう？
  • Flow
    • ミハイ・チクセントミハイ
    • ハイパーつよつよ状態、これがレベルアップのかぎ
      • ①楽しさ、幸福感Happiness
      • ②集中Concentration
      • ③複雑さComplexity
    • 『フロー体験 喜び の現象学』
      • 不安と退屈の間の能力と挑戦が釣り合っている部分がフローチャンネル
      • フローに基づいた成長のメカニズムの話
    • メンタルステート図の話。『フロー体験とグッドビジネス』
    • 過去のやり方に囚われず、嘆く前に適切なやり方を探そう
    • フロー理論は挑戦の地図。もう頑張れないなら頑張り方を変える必要があるかもしれないし、そしてそれは組織の理解と協力が不可欠かも
    • 挑戦ルートを取り入れる組織は多いが、レベルアップしにくい人もいる。モチベーションを下げてしまう前に、やり方を見直す必要があるかも
    • 能力ルートが常に最適というわけでもない
    • 「この混迷と成長の時代に　フローする個人とフローする組織が増えて、どんどんレベルアップしていきますように。」

感想

• 久々に大学の図書館に行って、ミハイ・チクセントミハイの本やその周りにある本を読んでみようと思った。
• スライドのお作法(本の名前などネタや情報の出どころを明記するなど)も参考になる

---

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

• オーティファイ株式会社
  • アジャイルチームのための QA自動化プラットフォーム

• 理想

  • アサーションを自動化し、リグレッションの見落とし防げる
  • 高頻度で実行
  • BDD、ADD

• 現実の3つの壁

  • 1.バグ検知できない：バグ検出
    • 網羅性が低い
    • アサーションがないところにバグ出ガチ
    • →基本的には「広く浅く」
      • スナップショットテスト：HTMLの差分を比較
        • jestjs
      • ビジュアルリグレッションテスト：スクショを用いて差分を比較
        • codeceptjs
      • 実行時エラーを検知：クライアントサイドやサーバーサイドのエラーを取得する方法
        • Sentry：エラーをまとめて捕捉できる
        • TestCafe：JavaScriptの実行時エラーを検知すると、テストを中止する
          • Seleniumはログ取得のためのAPIを廃止したっぽい
  • 2.思ったより高頻度で実行できない：実行速度
    • 重くなる
    • 暗黙の「待ち」が多いSPA
    • 実行環境によってはネットワークレイテンシが強烈
    • アプローチ
      • テストデータをAPIやコマンドで作る
        • フロントエンドとバックエンドの通信部分だけを実行する
          • F12からのcopy as fech
      • 状態をキャッシュする
      • 並列実行
        • 複数のマシンやブラウザで並列に実行させる
        • テストシナリオに「ベキ等性」を持たせる必要がある
          • シナリオに順序を持たせてはいけない
        • コンテナによる並列実行環境
          • Zalenium
          • セレノイド
  • 3.どうでもいいところでコケまくる：安定性
    • リトライは全てを解決する
      • 失敗したステップをリトライする
        • 要素の表示を賢く待つよりも、リトライさせた方が様々なケースに対応できる
          • ローリングスピナーが邪魔、とか
        • リトライ回数を設定しておくと吉
      • 失敗したシナリオをリトライする
        • 外部サービスとの接続性の問題など
        • リトライ回数を設定しておくと吉
      • 不安定性を可視化
        • Allure Reporter

• E2Eでしかできないことをやろう

  • E2E＝UIではない
    • Playwright
    • Ultrafast Grid
    • UIテストが実機の縛りを抜けて、シンプルに実行できるようになってきている

感想

• E2Eでやらなくていいことをやっているからこそしんどい、というのはなるほどな〜と思った

---

④「プロダクト開発におけるアジャイルQA活動」

はじめに

• チームスピリット株式会社
• 健康診断とアジャイル開発
• ふりかえり：査読者はしっかり読んでくれている
  • 「事例」×「説得力」を踏まえてエントリーシートを書くことが重要
• 結果としてJaSST'19 Hokkaidoに活かされた
• パクリではないですよ

伝えたかったこと

• アジャイル開発のQAの場合、
  • 1.開発に終わりはない
  • 2.「広さ×深さ」に加えて「時間」でみる
  • 3.ソフトウェアテストの海は広い
• 1.開発に終わりはない
  • プロダクトは成長・複雑化していくが、テストのリソースは同じ勢いでは増加しない
• 2.「広さ×深さ」に加えて「時間」でみる
  • 成長し続けるプロダクトコードに対して、継続的なテストを考える必要がある
  • 時間と広さでみると、次を見据えてテスト計画時にテスト準備をする
    • 最低限にしてしまうと、要求を満たせない
  • 時間と深さでみると、「頻度」でみる
    • 仕組み自体も考える必要がある
• 3.ソフトウェアテストの海は広い
  • 物量で負けた状態で、どうやって理想に近づくかが腕の見せどころ

現在とまとめ

• 私たちの場合
  • ひとつひとつ、積み上げることでプロセスを形成していく
  • 銀の弾丸は存在しない
  • 当たり前のことを一生懸命努力する。根気よく、粘り強く、理想に近づける

感想

• 「次を見据えてテスト計画時にテスト準備をする」は明日から実践する！

---

⑤gremitoさん「テスト？自動化？QA/QCの業務について（仮）」

• 「QA業務が大変」

  • 模索、最適化
  • ベリサーブナビゲーションとか読んでる

• まとめ

  • 開発チームの中にQAエンジニアがいる組織づくり
  • QAははじめの方から参画するの大事
  • 品質チェックに入る前にテスト計画とテストケースを終わらせるといい
  • 開発チームの一員であり、各メンバーと足並みを揃えることが前提

感想

• いい環境やいい風土とは何かというのを考えながら日々の業務に取り組んでいこうと思った。

---

⑥t_isekiさん「ウォーターフォール（V字）開発でモブ設計してみた」

はじめに

• テストフェーズで後戻りが多い。なんとかしたい。
• WFの弱点の保管
• チーム全員での使用理解

なぜモブなのか

• レビューだと、ファシリテーションが難しい
• 進捗管理が面倒
• 一緒に設計すると、一体感が出る

ウォーターフォール開発とは

• 上流から下流へ
• メリットデメリットも周知の通り
• V字モデルとか

モブテスト設計

• ペアプロ・モブプロ応用してみた
• 2ヶ月、4人
• 基本設計
  • 主担当者に章立てを用意してもらってた
  • 作るものの目的や機能を明確にしてもらった
• 詳細設計
  • 随時やってた
    • 設計者が不安になったタイミング
    • 設計書を読んで理解できなかったタイミング
    • 処理が複雑になったところ
    • 俺の嗅覚
• 良かったこと
  • 統一認識ができた
  • ドキュメント整備ができた
• 改善すべきところ
  • だれてくる
  • 若手の発言の心理的安全性のとりにくさ
  • 基本設計で細かいことが気になって進まない

感想

• 「俺の嗅覚」を磨くには何を意識して経験を積んでいけば良いかを考える。