普通に会社名義で出たので会社ブログを書けという話だが、個人の学びとして他の人の発表で感じたことメモしておきたいので書く。
MagicPodでFlutterアプリをテストする
Flutter から遠い生活をしているので特に思ったことはないが、サポートできる Platform を増やすことは E2E Test SaaS ベンダーとしては重要だが、Flutter という Native から1段階 wrap しているものをサポートするのはかなり苦労があるんだなーと思った。
MagicPodで始める がんばらない回帰試験の自動化
- 自動化の導入コストは当然かかる
- MagicPod のベストプラクティスは知らなかった
- 実際に経験してみて自動化が難しいものとそうでないものを切り分けられたのは良い学びだと思う
- kintone 普通に metrics を食わせて表示できるんだーってのがびっくり
- 後の自分の発表言うことないな、ってなっちゃった
- issue ちゃんと書いているの大事
『スタディサプリ 中学講座』における E2E Test の運用と計測による改善
所属チームのこれまでの軌跡が話されてよかった 合わせてブログ書きたい 「開発チームが自ら自動テストを書き、メンテしている。QA はサポート」というのはもっとアピールしたい。 質疑でも補足したけど tatto さんの丁寧なサポートと品質リードへのファシリテーション、そういった役割を踏まえて組織したマネジメントが合わさって成し遂げられていることだと思う
自分の資料はこっち
「計測されていると、改善したくなる」が一番言いたかったことかもしれない。
あと Web だからか、E2E が15分ってめっちゃ短いほうなのね、ってわかったw
そういえば Duration seconds 的なのも API で取れると嬉しいと言う話をして issue を書いてもらった。
みてねの安定リリースを支えるMagicPod活用状況
- QA からはじめて開発チームに認知が広がったのはいい話
- 共有ステップを使いこなすのすごいと思うけど、副作用もあると思った
- 共有ステップの管理とその周知はどうやっているのだろう
- QA チームが少人数だとコミュニケーションでうまくやれるのかもしれない
高い開発生産性を実現するために取り組んだMagicPodの利活用
- 実行方法の整理は見事で、特にデプロイ前と定期実行でテストケースを分けている点は見習える点があるなと思った
- Jimbo さんと懇親会でも話したけど、デプロイ前はマジで重大障害につながるクリティカルなところだけにすることで、開発速度を止めない
- 逆にそれ以外定期実行の「最悪3時間」で気づけるものはデプロイブロックしない、というのは言うは易しというか、うまく問題起こさずにできているのはすごいと思う
- CI で PR マージ前実行でも5分ならまぁ我慢できるなと思う
自動テストを社内へ浸透させた話
- 手動テストと自動テストをどう棲み分けるのか、そのガイドなり考え方なりを発信するのは大事だと思う
- 100% は無理
- 特にレコチョクさんの扱うような音楽再生みたいな、メディアが関わるものは難しいですよね
まとめ
懇親会も楽しかったです。ありがとうございました。 発表させて、といって当日までつなげてくれたコミュニティマネージャの田上さん、懇親会で会話させていただいた伊藤 CEO 他みなさんありがとうございました。
引き続きよろしくお願いします。何かあったら Issue 書きます。
