|
1 | | ---- |
2 | | -title: 雑にエージェントにテスト設計をさせてみて考えたこと |
3 | | -tags: |
4 | | - - test |
5 | | -private: true |
6 | | -updated_at: '' |
7 | | -id: null |
8 | | -organization_url_name: null |
9 | | -slide: false |
10 | | -ignorePublish: false |
11 | | ---- |
12 | | -# 雑にエージェントにテスト設計をさせてみて考えたこと |
13 | | - |
14 | | -## はじめに |
15 | | - |
16 | | -AI利用への距離感を測るための実験をしてみた結果です。 |
17 | | - |
18 | | -## 方法 |
19 | | - |
20 | | -IssueおよびPRを指定し、既定のフォーマットへテスト設計をさせてみた。 |
21 | | - |
22 | | -## 前提 |
23 | | - |
24 | | -業務システムを対象とした。 |
25 | | - |
26 | | -## 結果 |
27 | | - |
28 | | -それっぽいテスト設計がされたが、実用性は低かった。 |
29 | | - |
30 | | -## 課題 |
31 | | - |
32 | | -- 業務や操作方法に関する情報量が不足しており、実際との乖離が大きい。 |
33 | | -- 実装だけを基にしたテスト設計の場合、AIによる補完の割合が大きい。 |
34 | | -- 補完割合が大きいとレビューに掛かる工数の方が大きくなってしまう。 |
35 | | - |
36 | | -## 考察 |
37 | | - |
38 | | -システム利用に関する基本的な情報がないと期待値に近いテスト設計はできない。 |
39 | | - |
40 | | -## 改善 |
41 | | - |
42 | | -システム利用に関する基本的な情報を与えれば、期待値に近いテスト設計ができるかもしれない。 |
43 | | - |
44 | | -## 対策 |
45 | | - |
46 | | -- 仕様駆動や受け入れテスト駆動開発により仕様を明示する。 |
47 | | -- マニュアルやリリースノートなどで外部仕様や変更仕様をする。 |
48 | | -- 内部仕様や非機能要件に関しては仕様詳細などとして別途定義する。 |
49 | | - |
50 | | -## 今後 |
51 | | - |
52 | | -システム全体をAI利用を前提とした作りにして変えていく必要がある。 |
53 | | - |
54 | | -## 余談 |
55 | | - |
56 | | -CI/CDなどのシステム的な変更に関しては、業務システムよりは実用性があった。 |
57 | | - |
58 | | -## 予想 |
59 | | - |
60 | | -開発とQAの役割はより近い内容に変わっていくと予想される。 |
61 | | - |
62 | | -## おわりに |
63 | | - |
64 | | -AI利用への距離感はまだあるが、克服可能な範囲であると考えられる。 |
65 | | - |
| 1 | +--- |
| 2 | +title: 雑にエージェントにテスト設計をさせてみて考えたこと |
| 3 | +tags: |
| 4 | + - テスト |
| 5 | +private: true |
| 6 | +updated_at: '2025-12-15T19:51:01+09:00' |
| 7 | +id: d1f6a3f5acfb23f102d1 |
| 8 | +organization_url_name: null |
| 9 | +slide: false |
| 10 | +ignorePublish: false |
| 11 | +--- |
| 12 | +# 雑にエージェントにテスト設計をさせてみて考えたこと |
| 13 | + |
| 14 | +## はじめに |
| 15 | + |
| 16 | +AI利用への距離感を測るための実験をしてみた結果です。 |
| 17 | + |
| 18 | +## 方法 |
| 19 | + |
| 20 | +IssueおよびPRを指定し、既定のフォーマットへテスト設計をさせてみた。 |
| 21 | + |
| 22 | +## 前提 |
| 23 | + |
| 24 | +業務システムを対象とした。 |
| 25 | + |
| 26 | +## 結果 |
| 27 | + |
| 28 | +それっぽいテスト設計がされたが、実用性は低かった。 |
| 29 | + |
| 30 | +## 課題 |
| 31 | + |
| 32 | +- 業務や操作方法に関する情報量が不足しており、実際との乖離が大きい。 |
| 33 | +- 実装だけを基にしたテスト設計の場合、AIによる補完の割合が大きい。 |
| 34 | +- 補完割合が大きいとレビューに掛かる工数の方が大きくなってしまう。 |
| 35 | + |
| 36 | +## 考察 |
| 37 | + |
| 38 | +システム利用に関する基本的な情報がないと期待値に近いテスト設計はできない。 |
| 39 | + |
| 40 | +## 改善 |
| 41 | + |
| 42 | +システム利用に関する基本的な情報を与えれば、期待値に近いテスト設計ができるかもしれない。 |
| 43 | + |
| 44 | +## 対策 |
| 45 | + |
| 46 | +- 仕様駆動や受け入れテスト駆動開発により仕様を明示する。 |
| 47 | +- マニュアルやリリースノートなどで外部仕様や変更仕様をする。 |
| 48 | +- 内部仕様や非機能要件に関しては仕様詳細などとして別途定義する。 |
| 49 | + |
| 50 | +## 今後 |
| 51 | + |
| 52 | +システム全体をAI利用を前提とした作りにして変えていく必要がある。 |
| 53 | + |
| 54 | +## 余談 |
| 55 | + |
| 56 | +CI/CDなどのシステム的な変更に関しては、業務システムよりは実用性があった。 |
| 57 | + |
| 58 | +## 予想 |
| 59 | + |
| 60 | +開発とQAの役割はより近い内容に変わっていくと予想される。 |
| 61 | + |
| 62 | +## おわりに |
| 63 | + |
| 64 | +AI利用への距離感はまだあるが、克服可能な範囲であると考えられる。 |
| 65 | + |
0 commit comments