雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
ユーザーの目的をユーザビリティテスト用のタスクシナリオにしよう
現実的なタスクシナリオを書くことで参加者を関与させ、行動を促そう。また、そのインタフェースがどのように利用されるべきかは明かさないようにしよう。 Turn User Goals into Task Scenarios for Usability Testing by Marieke McCloskey on January 12, 2014 日本語版2014年2月4日公開 あるインタフェースで何が機能し、何が機能してないかを理解する最も有効な方法は、それを利用しているユーザーを観察することである。これがユーザビリティテストの本質だ。適切な参加者が現実的な活動をしようとしているとき、ユーザーが苦労する原因になりそうなことについての定性的知見は得られる。こうした知見はデザインをどのように改善すべきかを決定するのに役立つ。 また、サイト全体のユーザビリティを明らかにする手段として、ユーザーがタス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
