みなさまこんにちは。
エコモットの板橋です。
前回は「1文節1仕様を導入してみた」について記載しました。
これは主に、要件定義や設計書に記載する内容について、可能な限り曖昧な記述を排除するための対策として導入した手法でした。
今回は、トレーサビリティに関して書いていきたいと思います。
今まで書いてきた記事の中でも、少し匂わせぶりに書いてきましたが、それは「とっておき」だからではなく、どのように書いたら分かりやすいかなぁ、、、と悩んでいました（苦笑）
では、今回も文章量多めですが、進めていきましょう。
こんにちは！早く夏になって毎日アイスを食べたい、SJC共同開発推進室の對島です。
早いもので、4月からはついに3年目がスタートし、エンジニアとして丸2年が経ちました。嬉しいことに去年同じ部署に後輩が一人増え、「教わる側」から「教える側」としての責任も感じています。また、最近は見積もりや設計といった「上流工程」に関わる機会も増え、仕事の重みを改めて実感しています。
そんな節目の今だからこそ、あえて書き残しておきたいテーマがあります。
それは、1年目の新人の頃から今日まで、ずっと泥臭く向き合い続けてきた「テスト」についてです。
正直、最初は「テストなんて、確認してチェックをつけるだけでしょ？」なんて思っていました。その甘い考えが上司からのレビューによって打ち砕かれた「記録」をここに残しておこうと思います。このブログが、皆さんにとっても今一度テストについて考えるきっかけになれば嬉しいです。
皆様、こんにちは。
エコモットの板橋です。
前回は「バグ分析のすすめ」という事でバグ分析の価値について書いたのですが、このままだと、ただの理想論で終わってしまいますので、今回は具体的にどうやって導入したのかや、苦労した話などチームに定着させるまでのリアルな話をしたいと思います。
この記事は下記の記事の続編として記載しており、その内容を前提として進行していきます。
まだ読んでいない方は、先にお読みいただくことで、より理解が深まると思います。
バグ分析のすすめ
