極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
最低限知っておくべきデバッグリスト : LINE Corporation ディレクターブログ
こんにちは。ライブドアでディレクターをしている渡辺です。 今回はウェブサイト開発で必須のデバッグ項目について紹介したいと思います。 携帯コンテンツのデバッグに関しては『ケータイコンテンツのデバッグ事情』で述べられているのでご覧ください。 一口にデバッグと言っても、コンテンツによって確認すべきポイントは異なってきます。 そこで、ここではコンテンツの内容に左右されずによく行われている、デバッグの基礎的なものをまとめました。 そもそもデバッグの目的はコンテンツを本来の仕様にすることです。 そのため、心がける点は一般ユーザーの視点よりは、「どこかにバグがあるんじゃないか？」と厳しい目でサービスをチェックしてくれるユーザーの視点に立って行うことです。 修正点を見つけたら、すぐマークアップエンジニアさんやプログラマーさんに伝えて対応してもらうことになります。 【01】異なるブラウザで確認する まずはブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
