さっそく更新されてました。
前回の続きで第10条から感想などを書き留めておこうと思います。
何らかのツールで業務フローとそれに対応する機能、その機能が触るリソース類、をサクサクと参照できるようなツールがあると良いのですが。
リリースから間が無いものだったら良いですが、数年前にリリースされた機能に対する修正なんかだと、ドキュメントの品質がものを言う（しかも大概において足りていない）んですよね。
記事の中の見出しにあった中の
難しいときほど用意周到になろう
というのが何を意味するのか？難しいときほど用意周到にってのは当たり前の話で、単なる誤記なのかな？記事の内容自体は反論の余地はありません。
可能であれば、テストケースは前工程の担当者が設定するべきでしょう。例えば、業務要件・事務要件のテストケースは開発依頼側のユーザー担当者が作成し、開発受託担当部門のサポートを得て自分でテストを実施するのが望ましいのです。
これが理想なのですが、実際はこうはいきません。
各フェーズの設計書には常にテストケースを記述する欄を設けて、それが埋まらなければ設計書の完成としないような仕組みを用意するくらいの事ができればよいのですが。さらに、以下の点が重要ですし意識してやっていくべきですから、「要件」「それに対するテストケース」を対で用意し、記入するのは別の担当者で、それぞれでレビューして始めて設計書が完成、という手順を踏むようにするとか？…は面倒ですね、現場からは不満ぶーぶーですね。それでも強制しないことには実現が難しいですしね。
TestLinkとかも試して見ましょうかね。
システムテストケースは自分が受け取った前工程のドキュメントから設定し、テストデータを作成
回帰テストは当たり前の事ですが、各個人にまかせておくとまず実現できませんから、ちゃんと意識してチェックする必要があります。とはいえ、常に全試験を…ともイカンでしょうから、第10条に書かれている「修正時の影響分析は有識者の経験やツールを駆使して入念に行う」によって範囲を絞る必要があります。全てを自動試験できるのであれば、毎回全部流しても良いのでしょうが、人間のUIがから内容はそうはいかんし、一番悩んでるところではあります。
影響範囲については極力「要求：機能：影響対象リソース：関連機能」を管理し、そこから引っ張れる影響範囲は必ず試験対象にする、というようなことを行うことがまず最初の一歩ですかねぇ。このあたりをうまく機械的にできている、仕組みを持っているところの手法を紹介して欲しいですね。
急がば回れ、が大事ですね、極力、常に一から構築できるような仕組みを用意しておく事が必要だと思います。自動化できるところはできるだけ自動化しておくほうがいいですね、自動化に手間がかかるとしても、自動化できるのであれば手間をかけてでも自動化するほうが良いです。自動化できる事は幸せなことですから。
あと、何か起こった時の調査には、地道にひとつひとつ調査、という事が大事です。これも急がば回れですね。
17条以外にももうひとつ菊島先生の記事の紹介を。
0 件のコメント:
コメントを投稿