テストアーキテクチャって必要？

あきやま🍠 @akiyama924

とうとう、みっきーさんもテストアーキテクチャ派になってしまったのか。 (ﾉ_･､)ｼｸｼｸ テストアーキテクチャ無い方が良い派はわたしだけに。

Yasuharu NISHI @YasuharuNishi

理由ぷりーず RT @akiyama924: …テストアーキテクチャ無い方が良い派はわたしだけに。

あきやま🍠 @akiyama924

@YasuharuNishi テストにバグを作りたくないから。

鈴木三紀夫 @mkoszk

@akiyama924 SIerのエンプラ案件ならば、テストアーキテクチャ設計のような大げさなものはやらなくてもいいんじゃないかなあ、という意見は変わりありません。

あきやま🍠 @akiyama924

@mkoszk どういうものには必要と考えていますか？ 大規模銀行システム？

Yasuharu NISHI @YasuharuNishi

意味が分かりません。詳しくお願いします。m(__)m RT @akiyama924: テストにバグを作りたくないから。

あきやま🍠 @akiyama924

@YasuharuNishi テストアーキテクチャも人が作るものですから作り間違える（作り間違えた結果としてできたテストアーキテクチャ上の欠陥をバグと書きました）。 私はテストは出来るだけ単純にしてテストに間違いが無い方を優先したいのです。

鈴木三紀夫 @mkoszk

@akiyama924 テストタイプ一覧を持っていない組織は必要だと思います。 テストタイプ一覧を持っている組織ですと、プロジェクトの制約（マネジメントからのテスト要求）を加味して一覧からテストタイプを抽出し、実施順序で並べるので、テストアーキテクチャ設計よりはテスト戦略に近いと考えています。

Yasuharu NISHI @YasuharuNishi

それは、特にテストレベルやテストタイプは考えない、という意味ですか？ RT @akiyama924: テストアーキテクチャも人が作るものですから作り間違える（作り間違えた結果としてできたテストアーキテクチャ上の欠陥をバグと書きました）…

あきやま🍠 @akiyama924

@YasuharuNishi はい。HAYST法ではそうしています。

Yasuharu NISHI @YasuharuNishi

そうすると、ある程度以上の規模のテストを設計しようとすると、数が多くなりすぎて収拾がつかなくなりませんか？ RT @akiyama924: はい。HAYST法ではそうしています。

あきやま🍠 @akiyama924

@mkoszk にしさんへのリプライで書いたけど、HAYST法ではテストタイプを捨てたいと思っているから。

あきやま🍠 @akiyama924

@YasuharuNishi 数とは、テストケースの数ですか？

Yasuharu NISHI @YasuharuNishi

はいそうです。 RT @akiyama924: 数とは、テストケースの数ですか？

鈴木三紀夫 @mkoszk

@akiyama924 @YasuharuNishi HAYST法は主にシステムテストを対象にしているので、テストレベルの必要性が低いのでしょうか？

あきやま🍠 @akiyama924

@YasuharuNishi 数を比較したことはありませんが、（というか、実際にテストタイプを廃止するに至っていませんが）、私は少なくなると思っています。 というのは、機能テストのテストケースの中で振る舞いまでテストするから。

鈴木三紀夫 @mkoszk

@akiyama924 う〜む。僕はテストタイプは固定観念として持っているからなあ。無い世界を想像できないかも。

Yasuharu NISHI @YasuharuNishi

なるほど。モノリシックデザインですね。規模が大きくなると、段階的詳細化が不要な天才にのみ可能な方法だと思います。 RT @akiyama924: 数を比較したことはありませんが、（というか、実際にテストタイプを廃止するに至っていませんが）、私は少なくなると思っています…

あきやま🍠 @akiyama924

@mkoszk @YasuharuNishi HAYST法では、ユニットテストと、システムテストと、受け入れテストの3つのレベルしかありません。 かつ、ユニットテストは開発者が開発中に実施するものですし、受け入れテストはユーザーが実施するものですので、テスト担当者が行うテストはシステムテストしかありません。

鈴木三紀夫 @mkoszk

@akiyama924 @YasuharuNishi 昔、にしさんがそれに似たアイデアを言っていたことを思い出しました。機能テストも非機能テストも区別しない方法だった気がします。

Yasuharu NISHI @YasuharuNishi

混ぜてるだけだよ。確かにそうすればオーバーヘッドは減るからね。 RT @mkoszk: @akiyama924 う〜む。僕はテストタイプは固定観念として持っているからなあ。無い世界を想像できないかも。

Yasuharu NISHI @YasuharuNishi

やだやめて。そんな工学的原則に反したことを言った覚えはないよ RT @mkoszk: @akiyama924 昔、にしさんがそれに似たアイデアを言っていたことを思い出しました。機能テストも非機能テストも区別しない方法だった気がします。

Yasuharu NISHI @YasuharuNishi

まぁリーナスとタネンバウム先生の例もありますからね。工学的原則が常に正しいとは限りません。普通の人にとってはほとんどの場合、工学的原則は成立しますけど。

あきやま🍠 @akiyama924

@YasuharuNishi 段階的詳細化と言いますか、システムの分割ですね。確かにみなさんFV表で目的機能に分割することができるまで訓練が必要です。 でも、天才でなくてもできる人はサクサクと。

鈴木三紀夫 @mkoszk

@YasuharuNishi @akiyama924 あら。誤解していたのかもしれません。 最短のテスト期間を考えるときには、機能テスト、性能テストと分けるのではなく、機能テストの中で性能も見れば、期間短縮に繋がるというの話をされていたのを、区別しないと理解していました。