しろココ
タグ 20代大学生制作編集口コミ増えすぎ売上の高い会社売上高外資系企業多い大手出遅れ女性安い将来性就活就活サイト就活時期就職平均年収初心者内定出るのが早い後悔レバテックキャリアメーカー系メールメイテックネクストやばいやめとけランキングランクレバテックルーキー入校面談レベルワークポート上場企業中小企業人気ベンチャー作り方信頼できる儲かる職種平均転職回数情報システムマイナビIT AGENT超大手種類稼げる仕事第二新卒給料編集制作落ちた評判転職社内SE転職エージェント転職サイト転職ドラフト辛い辞めたい闇隠れた優良企業離職率社内SE転職ナビ相談先指名なし株式会社キャリアデザインセンター文系料金断られた新卒既卒早期選考企業未経験株式会社クリーク･アンド･リバー社登録方法機械学習エンジニア比較派遣社員炎上無謀特定技術派遣独立系理系大学院マスメディアンホワイト企業30代アプリWEBエンジニアWebデザイ
Google Adsenseで簡単にA/Bテストを行う方法 - UXエンジニアになりたい人のブログ
最初にAdsenseみたときから疑問だったことがあるんです。テキスト広告って押すやついるんか？って。 なんかすごい地味だし、どうもスペース無駄に使ってるような気がするし、押したくなるような煽り文句があるやつも少ないし。。。。絶対ディスプレイ広告の方がいいだろ、と思い、ある時期からGoogle先生の勧めを無視してディスプレイ広告オンリーに設定してました。 すると、Google先生から ヘイヘーイ、ディスプレイとテキスト両方オンにした方があと10％儲かるよ？前から言ってんじゃん？嘘だとおもうんなら試してみなよ という煽りとともに「テスト」なるいわゆるA/Bテスト的機能を紹介されたので、それを紹介したいと思います。 設定方法 まず、公式のヘルプはこんな感じ。 設定方法ですが、まず「広告の設定→テスト」と選択します。 テストの種類選択 ここで、テストの種類を選びます。種類は2つです。 広告の許可と
直帰率が0.5%改善したよ！→誤差では？→検定しましょう
使い方 AとBのサンプル数と比率に値を入力して計算ボタンを押すと、検定統計量を計算して検定を行い、比率Aと比率Bに差があると言えるかかどうかを結果に表示します。 例えば施策前後の直帰率の比較を検定する場合は、施策前をA、施策後をBとして、サンプル数に訪問者数、比率に直帰率を入力します。コンバージョンのA/Bテストを検定する場合は、パターンAをA、パターンBをBとして、サンプル数に訪問者数、比率にコンバージョン率を入力します。 有意水準とは、検定に使う確率のパラメータで、この確率が小さいほど差があるかどうかの判定が厳しくなります。通常は5%でいいでしょう。検定統計量とは、入力値からある公式によって計算される値で、この値が棄却域内に入る確率と有意水準を比べて有意差検定します。検定方法は、二群の比率の差の検定で、z分布を使った両側検定をしています。検定方法の統計的な説明については下の囲みを参照し
分散テスト実行システムRRRSpecをリリースしました - クックパッド開発者ブログ
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
Better Specs { rspec guidelines with ruby }
translations Documentation RSpec is a great tool in the behavior-driven development (BDD) process of writing human readable specifications that direct and validate the development of your application. On the web there are many resources that give complete overview of _what_ you can do with RSpec. But there are fewer resources devoted to how to create a great RSpec test suite. Better Specs tries to
私はRSpecでテストをこんな感じで書いてる - アジャイルSEを目指すブログ
私がRSpec使ってテスト書く時はこんな感じで書いてるよ〜ってのを書いてみた。*1 テストを書く順番について TDDでコードを書く場合、先にテストを書く事になります。 そして、そのテストを書く順番ですが、私は下記のような順番で書くように意識しています。 設計する describe を書く itを書く subjectを明確にする before(context)を明確にする その他に、気をつけている点はこんな感じ 別のメソッド呼ぶ時は基本的にstubなどで潰す contextは「〜の場合」、it は「〜であること」になるようにする 一つずつ、詳細を書きます。 設計する テストを書き始める前に、まず実装しようとしてるクラス、メソッドを簡単に設計します。 少なくとも、「クラス名」「クラスメソッド or インスタンスメソッド」「メソッド名」「メソッドの戻り値」ぐらいは決めます。 describe を
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門：ユカイ、ツーカイ、カイハツ環境！（21）（1/4 ページ） CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI（継続的インテグレーション）ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins（Hudson）は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe
Google Website Optimizer でサイト最適化をはかる - Web Analytics Latte
2011/01/06現在、以下のサンプルコードは旧式の記述ですので、GWOサイトに表示される最新版コードでテストしてください。新型と旧式の違い等はこちらの記事を参考にしてください。 Google Website Optimizer という無料サービスがあって、意外と使い方に突っ込んだ記事がないので書いちゃいます。 Google Website Optimizer ウェブサイト最適化、という話です。 Google Website Optimizer でできること A/Bテスト（えーびーてすと） 多変量(MVT)テスト（たへんりょうてすと：通称えむぶいてぃーてすと） ABテスト この方法では、ページの完全に異なるバージョンの掲載結果を比較します。下記の点がテストの内容に当てはまる場合は、この方法を使用します。 新しいページを公開して、既存のページと比較テストする。 ページの新しいレイアウトや全
第1回 PHPUnit入門 | gihyo.jp
はじめに 皆さん、テストしてますか？ 近年、システム開発を発注する顧客や利用ユーザーの品質に対する要求レベルは格段に向上しています。そのため、システムの品質を保証するための「テストフェーズ」はますます欠かせなくなってきています。 ここで、一口に「テスト」といっても、フェーズによって以下のような様々なテストがあります。 ユニットテスト・単体テスト 結合テスト・システムテスト 総合テスト 受け入れテスト 負荷テスト セキュリティテスト 筆者の経験上、一般的なシステム開発でもっとも大きな工数を占めるのは、この「テスト」フェーズと考えています。なぜなら、テストフェーズは例外なく「繰り返し作業」だからです。前述の様々なテストフェーズで共通することですが、テストフェーズは「テストで発見されたバグ・障害を修正して再度テストを行う」という作業を何度も繰り返し行うフェーズです。あとのフェーズで不具合が発見さ
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ グーグルでTest Engineering Directorを務めるJames A Whittaker氏が書いたエントリを紹介した先日の記事「グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？」が非常に好評で、「続きがあれば読みたい」というコメントをいただいていました。 Whittaker氏がそのエントリの続き「How Google Tests Software - Part Threeを公開していますので、ご要望に応えて紹介することにしましょう。 品質は開発の問題であってテストの問題ではない 品質とはどのように実現するものなのか？ という問いに対して、Whittaker氏は次のように書いています。 The simple solution to this con
コードカバレッジのまとめ - ソフトウェアテストの勉強室
単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。 2008/03/12更新 サンプルプログラムで解説を追加 サンプルプログラムは、以前例題として作成したテニスのスコアボードについて [例題]テニスのスコアボード ステートメントカバレッジ 命令網羅。テスト対象となるプログラム中のステートメント（命令文）をどれくらい実施したかどうかをあらわす基準。すべてのステートメントを最低1回実施した場合に、ステートメントカバレッジ100%という。もっとも基本的なカバレッジ基準で
第2回 境界値バグは上流で潰したい | gihyo.jp
ソフトウェアテストの最も基本の技法といえば、境界値分析と、同値クラス分割の名前が挙がります。今回はその境界値のお話しです。 境界値分析はテストの際の基本中の基本ともいえる考え方です。なぜか。実際境界値付近は「バグ多発地帯」だからです。 さて、G.マイヤーズが、古典的名著『ソフトウェアテストの技法』の中で、同値クラスと境界値（限界値）テストの有効性を高々と掲げてから、はや30年以上が経過しました。にもかかわらず、今なお、境界値近傍が「バグ多発地帯」であり続けているはなぜでしょうか。いい加減、根本的な対策法が開発されて、いいようなものなのに。原因を1つに絞り切ることはできませんが、やはり大きな原因は「人間の側」のミスがあとを絶たないからだ、と思います。 ソフトウェアテストの本を読んでいても、『境界値付近はバグが多い。なぜならif文の条件で「＜」や「≦」などを取り違える可能性が高いからだ』と書
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
