Skip to content

Latest commit

 

History

History
28 lines (23 loc) · 8.19 KB

testability.ja.md

File metadata and controls

28 lines (23 loc) · 8.19 KB

Testability check

Part of the Multi-team Software Delivery Assessment (README)

Copyright © 2018-2019 Conflux Digital Ltd

Licenced under CC BY-SA 4.0 CC BY-SA 4.0

Permalink: SoftwareDeliveryAssessment.com

Lisa Crispin氏 と Janet Gregory氏による書籍 Agile Testing , Jez Humble氏とDave Farley氏による書籍 Continuous Delivery , Steve Freeman 氏 と Nat Price 氏 による書籍Growing Object-Oriented Software , Michael Feathers氏による書籍 Working Effectively with Legacy Code, Ash Winter氏と Rob Meaney氏による書籍 Team Guide to Software Testability と Webサイト TestabilityQuestions.com に基づいて評価基準を作成しています。

目的:ソフトウェアシステム内のテストおよびテスト容易性へのアプローチを評価

方法:Spotify Squad Health Check のアプローチを使用して、次の質問に対するチームの回答を評価する:

質問 うんざり (1) すばらしい (5)
1. テストファースト(クラス) - メソッドとクラスのテストをテストファーストで書く時間の割合はどれくらいですか? 多くの場合、テストファーストのアプローチを使用する時間がない。 常にテストファーストのアプローチを使用している-それが良いソフトウェアを入手する唯一の方法だ!
2. テストファースト(機能) - どのくらいの割合で、機能と動作のテストをテストファーストで書きますか? 多くの場合、テストファーストのアプローチを使用する時間がない 常にテストファーストのアプローチを使用している-それが良いソフトウェアを入手する唯一の方法だ!
3. ユニットテスト % - どのくらいのコードカバレッジレベルで、ユニットテストが成功したとみなしますか? ユニットテストは10%のカバレッジで成功とみなす。 ユニットテストは80%以上のカバレッジで成功とみなす。
4. 機能テスト % - どのくらいの機能カバレッジレベルで、機能テスト(またはビヘイビアテスト)が成功したとみなしますか? 機能テストは10%のカバレッジで成功とみなす。 機能テストは100%以上のカバレッジで成功とみなす。
5. 機能カバレッジ - 機能テスト(またはビヘイビアテスト)でカバーされるコード内の機能の割合はどのくらいですか? 機能の50%未満に対応する機能テストがある すべての機能に、対応する機能テストが少なくとも1つある
6. テストデータ - スクリプトから生成され、データストアに自動的に挿入されるテストデータの割合はどのくらいですか? テストデータを設定するための手動プロセスがある すべてのテストデータはスクリプトから生成され、自動テストの一部としてデータストアに挿入される
7. デプロイメント - デプロイメントパイプラインコードのどの部分に、ビルドとデプロイの動作をカバーするテストがありますか? ビルドおよびデプロイスクリプトをテストしない ビルドおよびデプロイスクリプトの主要部分のテスト(デプロイ検証テストなど)があり、コードはモジュール式で適切に構造化されている
8. テスト容易性 - ソフトウェアをテストを可能にするためにあなたの時間のどの割合が費やされていますか? ソフトウェアをテスト可能にするための時間を費やしいない ソフトウェアをよりテストしやすいものにするために、定期的にリファクタリングする-スプリントまたは週ごと
9. CDCs/Pact/SemVer - コンシューマ駆動契約(CDC)/ Pact / Semantic Versioningなど、inter-team testing approachesをどの程度使用していますか? 各コンポーネントまたはパッケージの最新バージョンを使用している コンシューマ駆動契約(CDC) / Pactを使用して、インターフェイスの変更をテストする。 セマンティックバージョニングを使用して、重大な変更を含む変更の意味を伝える。Tolerant Readerパターンを使用して、重大な変更を一切行わないよう努めている。
10. その他のコード - ポートフォリオ内の他のチームからのコードについて、あなたがうまく使える(ただし、実装はしない)自信はどれくらいありますか? 他のチームのコードは非常に不安定で予測ができない。 包括的な自動テストスイートにより、他のチームのコードは安心して使える。