テスト技法について古典から改めて学んでみる - Qiita
普段なにげなくしている「テスト」 しっかりと学んでいる機会がなかったので、「ソフトウェアテスト」の古典として 長く使われている基本的な技法やテストの哲学について語られているJ・マイヤーズの名著、 『ソフトウェア・テストの技法 第2版』を読みました。 本著は米国で1979年に出版され、その翌年には日本で翻訳版が出版されました。 その後本日まで長い間語り継がれてきました。 JUnitなどのツールを紹介した本、その時のテスト技法について紹介する本は 雨後の筍のようにあります。ですが、 「そもそもテストとはなにか」 「テストをする際のエンジニアとして抑えておくべき姿勢・哲学はなにか」 という根本的な問に対して答えを出している書籍だからこそ、 時勢に流されずに長い間読まれてきた書籍なのかなと思いました。 Amazonのレビューを読んでいただいても、確かに翻訳に少し違和感があると言われれば有ります。
なぜ「システムが無事に動いている」ことの価値は理解されないのか
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
Webサービスを開発してリリースしてわかったこと〜半年前の自分へ〜｜ガッシー｜Repsona
Repsona LLCの@GussieTechです。ひとりで、理想のプロジェクト管理ツールを作っています。 ワクワクして、ニヤニヤして、夢中で開発して約8ヶ月。ドキドキしながらアクセス制限を解除して、世にオープンしました。そしてわかったことを、半年前の自分へのメッセージとして残しておこうと思います。 最初の計画はどんな感じだったか ・みんなに内緒でコツコツとすごいの作って、あっと言わせる ・Google Adsで集客。キーワードプランナー見積り上は費用対効果OK ・海外サービスの逆輸入のような感じで、日本に颯爽と現れる ・TechCrunchから取材依頼がきて、特集記事が掲載される （ふふふ） どうなったか 「内緒でコツコツ」はどうだったか自由な技術選定とチャレンジができたこと、全行程全領域をひとりでやっているので、コミュニケーションコストがない分、とにかく早い。作ってる時は（ふふふ）状態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
