タグ

テストとプログラマに関するluccafortのブックマーク (4)

  • 『ZERO BUGS』を読んだ - r7kamura - Medium

    Amazonでケイト・トンプソン, 酒匂 寛, 小田 朋宏の{ProductTitle}。アマゾンならポイント還元が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽… 全体が78個の物語によって構成されており、それぞれの物語において教訓が紹介される。ZERO BUGS というタイトルの通り、どの物語もソフトウェアの不具合をテーマにしている。文章の内容は平易で、プログラマ初心者にもわかりやすく、しかしながら示唆に富んでおり、経験が浅いプログラマであれば「なるほど」、経験が深いプログラマであれば「あるある」とどちらも頷きながら読み進めていけるはず。 それぞれの物語は2ページ程度でとても短く、何かの合間にも少しずつ読み進めていける。出来る限りコンパクトに話を収めようという気持ちで書かれていることが文面から伝わり、とても好感が

    『ZERO BUGS』を読んだ - r7kamura - Medium
    luccafort
    luccafort 2017/09/24
    書店でパラパラ捲ったところベカラズ集的というか実践的でないと思って買わなかったが"最善のコードが書けないからといって、それが酷いコードを書く理由にはならない"みて考えが少し変わった。
  • 【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ~「テスト」という工程が必要な理由 | きのこる庭

    前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ

    【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ~「テスト」という工程が必要な理由 | きのこる庭
    luccafort
    luccafort 2014/11/20
    絵が何度見てもまずりんのノブ子にみえてしまって内容が入ってこないでござる。
  • ソフトウェアエンジニアに働く慣性の法則 - id:anatooのブログ

    なんでもいいのだけれども、例えばだけどバージョン管理システムつかって開発してないです、みたいな人がいた時に、傍から見たらすごく良くないことをやっているように見えるけど、当人からすれば今までこれで開発してきたし、別にバージョン管理システムなんか使わなくてもいいよ、みたいなふうな反応をされる。また、こういう反応はその当人だけじゃなくてその人の周りの人も同じ様な反応をする。 もうすこし卑近な例で言うと、コードの質なんかに関しても、汚いコードで書くのが普通で今まで数多くの案件をこなしてきました、みたいな場合だと、綺麗なコードなんて犬にわせろ的な態度を取って逆に綺麗にコードを書く人をすこし敬遠した態度を取るような人も見られる。そしてそういう人の周りには似たような態度を取る人が多い。そういう考え方みたいなものは、長い間過ごす同じ開発チームのなかで浸透していくからだと思う。 基的に綺麗なコードを書く

    ソフトウェアエンジニアに働く慣性の法則 - id:anatooのブログ
    luccafort
    luccafort 2012/12/19
    すごくよく分かる。開発「テスト書くようにしましょう!」営業「それだと工数増えるからやめて」開発「………」ということが過去に実際にあったしなぁ。
  • 何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops

    テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定

    luccafort
    luccafort 2012/04/09
    「まあこんな長文読んでくれる人は最初からちゃんとした報告くれるんだけどね!!」確かに!www
  • 1