技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
読書メモ『実践アジャイルテスト』 - 妄食転寝 as a QAエンジニア
書籍「実践アジャイルテスト」について、実際に読んだのはだいぶ前で、今年(2010年)3月下旬から5月にかけて、読書会に参加してたのですが、まとめを何も書いてなかったので今更ながら僕なりの読書メモを公開します。 本の概要 いわゆるアジャイル開発プロセスの中で、テスト担当者・QAエンジニアの役割や、テストがどう設計され、実施されるべきかを網羅的に説明した内容です。アジャイル関連の本はいくつも出ていますが、その中でテストをメインテーマに据えたものは和訳本ではこれがはじめてなのではないかと思います。 前半はアジャイルプロセスやテストの概要など大枠の話が多いですが、後半にはいろんなレベル(単体、API、GUI)での自動テストや、反復の各フェーズで実施する作業内容など、だいぶ具体的なプラクティスまで説明されています。 ちなみに読書会は、自分含め 9 名の参加者で、(当然ながら)テストが主な仕事の方が多
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
