- 2024/2/15
- https://event.shoeisha.jp/devsumi/20240215
- https://codezine.jp/devonline/archive/17
- 2日間通してAIとつくセッションが多いのが印象的でした
- それ以外だとテストの話(これはAIが絡むものも多い)と開発プロセスの話(アジャイルなど)も多くありその辺を中心に参加しました
- 相変わらず人が多いので昔みたいに個人スポンサーがあれば迷わず買ってたと思います
我々はなぜアサーションするのか～現場に寄り添うANA DXの取り組み～
スクラム開発
チーム開発
- 対ユーザ
- 毎回ユーザ部門が変わるのでwhyをよく聞く
- 現場見学したり
- お互い意見を出し合って改善
- チーム内
- 個人ではなくチームで進める
- みんなが全部知ってる状態でs進める
- コミュニケーション
- 納得共感するまで話をする
- 中途半端にすると後々困る
アサーション文化
アサーション文化と開発チーム
チーム内で率直に発言できる土台作り
- デイリー
- 1日3回(朝昼夕)
- 会議のアジェンダ確認
- 課題や気になること中心
- 昼夕はコンパクト
- 困りごとモヤモヤ確認
- レンジャー
- 9人が3x3でチームを組む
- 常に3人で動く
- ずっとカメラマイクon
- 視覚で伝わる情報が多いから
- 常にモブでワーク
- springごとにシャッフル
- 苦手分野も勇気を持って取り組める
- ふりかえり
- 日常的に感謝を伝える
- 失敗やもやもやを共有
- 認知判断意図しない行動による失敗
- チャレンジ検証による失敗
- モアモヤ
会社の契約関係を越えたコミュニケーション
WebシステムやモバイルアプリにおけるUIからの自動テスト事例3選
- 浅黄 友隆さん[ヒューマンクレスト]
- https://speakerdeck.com/tomasagi/websisutemuyamobairuapuriniokeruuikaranozi-dong-tesutoshi-li-3xuan
自動テストの山
- 山が2つ
- 始める山
- 初期構築を素早く
- 継続する山
- テストをリファクタできるか
- 始める山
環境の変化
- WFからアジャイルへ
- 自動テストしないと気づかないバグが発生してしまう
- ツールの変化
- テストへの期待
- 実施するものではなく実行されているもの
- テストはバグを見つけるものではなくフィードバックを得るもの
事例1
- Webアプリ(PHPとJava)
- 課題
- リグレッションテストがうまくできてなかった
- 思い
- アップデートでデグレがないか確認したい
- 毎日自動テスト動いてる状態にしたい
- ユーザに提供してる基本的な機能をテスト
- Seleniumで
- テストピラミッド的にもUIのテストで詳細までやらない方がいい
- 最初の1ケースが回り始めるまでに3週間
- 100ケースすべて作るまでに2ヶ月
- テストは毎日1回
- 失敗時はSlackへ概要とスクショを送信
- とにかく1テストケースが毎日実行される実行環境を最速で作る
事例2
- CASIO WATCHES
- アプリ
- デグレを中心に自動テストを実施したい
- 工数削減
- 本番リリース後のチェック
- 284ケース
- 1日2回
- Mac miniに実機繋いでテストする
- bluetoothでつなぐので実機じゃないと
- jenkinsのパイプライン
- appiumの起動チェックとかもやってる
- テスト失敗時の調査修正が数時間かかる
- 1ケースの実行時間が長い(10〜30分)
- 再実行->途中で落ちるとかあるので修正確認も時間かかる
- 画面単位のテストケースを分割した
- テストが安定した
- 継続のポイント
- まずは属人化させる
- 失敗テストを放置しない
- 不安定なテストは捨てる
- テストのリファクタする
- 開発など他のメンバーとコラボレーションする
自動テスト歴0年でもできる！テスト工数を46時間/月削減した方法 ～1年目で得られた成果と展望～
- おだしょー(小田祥平)さん[mabl]
- 三上 鹿さん[ビットキー]
mabl
- テスト自動化プラットフォーム
- UI,API,モバイルのテスト
- a11yとかパフォーマンスの計測もできる
- a11yは何やってるんだろう?axe実行してるとか?
bitkeyの事例
- 機能拡充でリグレッションテストが増加した
- mablを選んだ
- ノーコードローコードで自動テスト作れる
- (他と比べて?)レスポンスが速くて動作が快適だった
- 1年で約25%自動化
- 月1回回してる
Kubernetesは怖くない！開発者のためのインフラトラブルシューティング入門
- 高橋 あおいさん
- https://speakerdeck.com/aoi1/kuberneteshabu-kunai-kai-fa-zhe-notamenoinhuratoraburusiyuteinguru-men
kubernetesの特徴
- 障害時に各コンテナ設定復旧を簡単にする
- 障害から自動復旧してくれる
- コンテナの仕様の管理を簡単にする
- ファイルで設定を管理できる
- Infrastructure as Code
- 複数台サーバでコンテナ起動し最適な起動先の決定を簡単にする
- 設定書くだけで細かいこと設定しなくても勝手にやってくれる
kubernetesのアーキテクチャーを知る
- Control Plane
- etcd
- データベース
- kube-apiserver
- APIサーバ
- kubctlでkube-apiserverを叩いてデータがとれる
- etcd
- Worker Node
何が起きてるか知る方法を知る
- kubernetesを使うと見る場所や味方が集約される
- ログ
- kubectlで全てのコンテナのログが見れる
- ログは永久保存ではない
- 別のサービスにログ転送してたらその見方を覚える必要はある
- kubernetesのEvents
- リソースごとに何が起こったか見ることができる
- kubectlを使えるように
リソース
- Pod
- コンテナを起動する最小単位
- ReplicaSet
- Podを複数管理するリソース
- Deployment
- ReplicaSetを複数管理するリソース
- Service
- Deploymentで作成した複数Podへのアクセスをルーティングするために使うリソース
トラブルシューティングのコツ
- 狭い範囲から調査
- Podからきりわけていく
- 仮説検証を繰り返す
- 証拠をたくさん集める
- kubectlを駆使する
- 証拠をたくさん集める
AIを活用した誰でもテストが自動化できるプラットフォームの実現に向けて
- 松浦 隼人さん[オーティファイ]
Autify
- E2Eテストを自動化するサービス
- ノーコード
- 実際の操作をリプレイしてテストする
- Web/アプリ
- いろんなOS/ブラウザでテストできる
- アプリはエミュレータ
- ノーコード
AIの活用
- 要素の特定
- クリックした対象の特定
- 特徴情報を記憶して特定している
- HTMLも見ている
- アプリの場合は画像情報に頼ってる
- テスト対象が変わった時も壊れないように
- セルフヒーリング
- チェックボックスの認識
- 見た目や実装が多様すぎる
マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB
- 香西 俊幸さん[イオンスマートテクノロジー]
- https://speakerdeck.com/aeonpeople/developers-summit-2024-tidb-sponsor-session
TiDB
TiDB Cloud
- PingCat提供のDBaaS
- AWSとGoogleCloudで提供されている
- ServerlessとDedicated
TiDB Cloud検討
- 現状の課題
- スケーラビリティ
- シャーディングによる運用コスト増加
マイクロサービスの課題
- 0からマイクロサービスで作るのはアンチパターン
- 大きくなってから分割するのがいいらしい
- 分散トランザクション
- 設計や実装難易度が高い
- 発生した時点で設計敗北
- サービスとリンクしていない組織設計
- devとopsが分かれていた
TiDB Cloud導入でどう変わる
- 自動シャーディング/バージョンアップ
- アプリケーション側での実装不要
AI時代を乗り切るための実装力をつけよう
- きしだ なおきさん[LINEヤフー]
- https://speakerdeck.com/kishida/get-avility-of-implementation-beyond-ai-era
AI時代にプログラマは必要か
- コードはChatGPTが書いてくれる
- プログラムの外とのつながりはプログラマが設定する
- 処理をちゃんと書けることが大切
逐次実行
- ループ処理での状態遷移
- Streamを使えると順番に処理を読めばいいからわかりやすい
- 逐次実行はプログラムカウンタの状態遷移
- 状態遷移のコードは意図が分かりづらい
- 正規表現であらわせるとわかりやすい
まとめ
- ライブラリの使い方はAIがわかる
- 処理を発想できること把握できることが大事
ゼロから大規模アジャイル組織への進化～推進者が語る立ち上げ背景と開発生産性～
なぜアジャイル開発センターが設立されたのか
アジャイル推進の過程での課題と役割
- 課題
- 複数案件掛け持ち
- いろいろスキルや人材不足
- ビジネスマインド
- ゴールの定義/共通意識
- 必要な役割
- スクラムマスターに似た感覚を常に持つ
- オープンマインド
- 視点視座
- スクラムマスターに似た感覚を常に持つ
生産性
- 生産性を見える化することが重要
- 改善が見えるから
- メンバーに気づきを促せる
- 開発生産性工場のアクション
- Findy Team+
- 透明性が向上した
- 指標の全体を俯瞰
- サイクルタイム
- レビューリードタイム
- Findy Team+
今後の組織づくりにおけるトライ
- ここの強みをもっと活かす
- 成長速度を加速する仕組み
- Reteamingのベストサイクル
- 楽しいの追求
AI時代のソフトウェアテストの現在と未来
- 和田 卓人さん
- 川口 耕介さん[Launchable]
- 近澤 良さん[オーティファイ]
テストが定着してきた？
- 自動テストの認知が進んできてるかも
- 自動テストを書くことの大切さを技術者以外の人に伝わるようになってきた
- 統計のデータとかが出てるのでそれが説得材料になる
国内のテスト事情と海外のテスト事情
- 海外
- 日本
- 自社で開発を取り組もうとしてる人からの関心が高まってる
- 継続して成長させたい
- スキルのある人はいないから準委任みたいな形も増えてる
- 自社で開発を取り組もうとしてる人からの関心が高まってる
開発でのAI活用の浸透
- copilotやChatGPTは日本も海外もみんな使ってる
- 現場で使ってるツールはあるがその次をみんな模索してる
ソフトウェアテストでのAI活用の浸透
- AIを使ったサービスがいろいろある
- AIを使った機能が部品としてあるのが当たり前になってきてる
- ソフトウェアの開発はAI活用で生産性向上した
- AIを組み込んだサービスの不確実性が増してテストは難しくなった
- LLMの作ったものをLLMでテストするような取り組みが進んです
