見出し画像

#33 開発×テスト LT会 参加レポート

きっかけ

今回は「株式会社ラクス」さんが運営している「開発×テスト LT会」に参加しましたので、個人的に気になった点をメモがてら「参加レポート」を書いていきたいと思います!


Flutterの紹介とFlutterでのテスト方法

・FlutterとはAndroid/iOS用のアプリを作成できるGoogle社が開発したフレームワーク
・4つのテストが可能!(Unit/Widget/Integration/Golden:画像差分など)

感想:めちゃくちゃ便利!基本的に別々のテストツールを扱う場合も多いと思うので統一されているのが良い。

絶対にテストコードを書かないチームのテストルール

・テストを書かないと不具合を出して顧客の信頼不振に繋がる
・テストケース・プルリクエストのテンプレート化などフローを作成していってバグを削減

感想:開発のフロー改善は重要。一つ改善することで、改善以上の効果が出ることも。色々なテンプレートの見直しも効果的!

ローンチ1年目プロダクトのテストコード事情

・ユニット作成指針がふんわりしているのが悩み。特にコアな機能以外。
→カバレッジ指標の策定。テスト指針を守ることをレビュー観点に追加。

感想:2番目の発表と同様で、テスト運用が大事。確かに、コア機能は細かくテスト基準は決めるけど、それ以外の機能に関しては追及されていないことが多いのかもしれない。

テスト嫌いなプログラマがテストを語る

・嫌いなことこそ「丁寧に」
・専門職は大事でテストの専門家を増やしていきたい

感想:嫌いなものこそ「嫌い」なりの視点があり、簡略化させる考え方ができると思うので重要だと思いました。

ISTQB/JSTQBシラバスから学ぶAgileTesting

・アジャイルプロジェクトは、チーム全体が品質に対して向き合う
・リスクを分析しよう。リスクが高いモノほど手動テストに加え、自動テスト・ブラックテストを厚めに。
・自動テストを作るときは「ストーリーボード」を活用すると良い

感想:JSTQBは現場でもすぐ扱える知識が詰め込まれているので、QAエンジニアであればシラバスに目を通しておきたい。個人的にも読み直しておこうと思いました(自戒)

「混沌化の実装にテストを入れよう体験談(現在進行形)」

・クラスの肥大化による、負債を改善していきたい!→テスト入れていきましょう
・大きいクラスには「機能テスト」レベルでも効果的

感想:自動テストのピラミッドでも単体テストの方が優先的に作るべきとされていますが、ピラミッドがないよりは全然良いと思う派です!大きいシステムには機能テストのアプローチがやはり適していると思いました。

意外とカンタン!?テストコードの改善から始めるシステム開発の効率化

・テストの精度が下がるとテンションが下がる→読みやすいテストコードが重要(RSpec)
・適切にケース分けをする→可読性が上がり、気づきが増えることがある
・エラーメッセージを関数で定義しない(ベタ書きしてしまう)
→プログラマではなくても何をしているかが分かる

感想:単体テストの運用の経験はあまりないのですが、非常に参考になりました!E2Eテストでも同じように使えそうなテクニックで当てはめて考えてみようと思いました。無駄をそぎ落とすの重要!

単体テストゼロからテスト文化を醸成させた話

・Jest/TestingLibraryを導入→ドキュメントさえ読めばテストを懸ける状態に
・モック関数を用意して、共通化を実施
・読書&発表・ボブプロ&ペアプロ

感想:テストの文化作りが上手で、読書やモブプロを通じての文化醸成は中々パワーがかかるものなので、素晴らしいと思いました...本読もう。

Webアプリの自動テスト戦略について考えてみた

・テスティングトロフィ―と呼ばれるROIに関するモデル化した図がある
→インテグレーションテストが費用対効果が高い
・E2Eは一見インテグレーションテストを包括しているようにみえるが、変更が多いので保守が大変

感想:テスティングトロフィ―というモデル図を初めて知りました。今までは自動テストのピラミッドを参考にしていましたが、こちらも参考にしていきたいところ。


いいなと思ったら応援しよう!

ダ・ヴィンチの手帳@somekichi
よろしれけばサポートよろしくお願いします!クリエイターとしての活動に活用させていただきます!