今日の運動は腹筋ローラー,腕立て,縄跳び(両足跳),散歩,ジョギング,ハンドグリップをした。統計を 運動の記録 にまとめる。

qa テストの設計⌗

システムや機能が複雑になった後の qa テストをどう設計するか。先日 Full Stack Testing を読んで考察 したりしていた。テストでもっとも工数がかかるのはデータや設定も含めてテストできる環境を構築すること。gitlab ci/cd で3つのテスト環境を構築しているものの、それらと qa テストのテストケースとどうやって関連させるか、またはテストの依存関係をどのように表現するかといったことを設計の重要事項として考察していた。

これまで google sheets の1ファイルですべてのテストケースを管理していた。しかし、機能が増え、テストケースが増えていくにあたり、この1ファイルにより管理は破綻しかけていた。id 連携という、複数のシステムまたはモジュールを介してデータをやり取りするというアプリケーションの特性上、テストの依存関係は google sheets の1ファイルでは表現できない。そこで「ステージ」という概念を導入し、google drive のフォルダや階層構造で依存関係を表現することにした。ステージ1のテストが成功しない限り、ステージ2のテストが成功することはない。業務における本質的な難しさである依存関係を人間にとってどう管理していくかが重要になる。急にこれらの qa テストをすべてできるわけではないが、ステージを3つまで定義した。最後の手動探索テストを issue の創発という、課題管理にとって重要な位置づけにおさめたのが個人的にお気に入り。実際に手動探索テストをどのように実施できるか？というのはまだまだこれからの課題ではあるが。

  • ステージ1
    • 2つのシステム間におけるテスト
    • 特定モジュールの振る舞いの検証
    • ui 周りのテスト
  • ステージ2
    • 複数のシステムをまたがるテスト
    • 機能横断的な要求テスト
      • 可用性に関するテスト
      • エラー制御に関するテスト
    • アプリケーションの機能が動作した次にある高度な要件
      • セキュリティテスト
      • パフォーマンステスト
      • アクセシビリティテスト
  • ステージ3
    • 手動探索テスト
      • issue の創発