なぜQAエンジニアが仕様を書いたのか - トレタ開発者ブログ
この記事はトレタ Advent Calendar 2019 21日目の記事です。 こんにちは。QAエンジニアの坂田です。 トレタに入社して1年が経ち、既存サービスのエンハンス開発やいくつかのリニューアルプロジェクトに携わってきました。プロダクト品質向上やメンバーへの貢献を模索するなかでQAエンジニアが仕様を書くという試みをテーマの1つとして行ってきましたので、今回はその話をしたいと思います。 なお、本記事では「プロダクトの外部的な振る舞いを定義したもの（UI仕様）」のことを「仕様」と呼びます。テストの仕様ではありませんのでご注意ください！ そもそもなぜ仕様を書くのか 仕様を書く目的を私なりにざっくり表現すると、以下のような感じになります。 リリース前：プロダクト設計の不明瞭さや矛盾を早期検知・解決するため リリース後：プロダクトの振る舞いが本来どうなっている（べき）か確認するため リリース
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
デザインドックで学ぶデザインドック | フライウィール
エンジニアの太田です。 皆さん、デザインドックはご存知でしょうか？いわゆる設計書ですが、エンジニアによって書かれ、書いた本人またはチームによって実装される点と、技術的な詳細を明確にし技術的な議論をすることにフォーカスがある点が特徴です。他人に開発を依頼するための設計書や、既存のシステムを解説するための文章とは性質が異なります。 デザインドックを書くことの利点としては以下のような点があります。 開発を始める前に全体のシステムを考察する機会を得る文章化することで、曖昧な部分が明確になる早い段階でチームメイトや専門家、関係者からフィードバックを得る機会を得るシステムの設計について明確な承認を得られる新しいメンバーがシステムの概略を理解する手助けになる弊社でもすでに多くのデザインドックを利用しており、エンジニア間での議論の活発化を担っています。 具体的にどのような内容を書けばいいのでしょうか？今回
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
