品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
第8回 Perlによる大規模システム開発・設計のツボ（3） | gihyo.jp
技術的負債の「見える化」 どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を、「技術的負債」と言います。 mixiでは技術的負債は長らく、コードレビューや技術力の高いエンジニアによる新機能リリース時の修正などで対応を行ってきました。しかし、これまでに紹介した「わかりやすいコードの指針」や「アーキテクチャパターン」をレビューや教育だけで維持することは、ソフトウェアが巨大になり、開発者数が増加するにつれて難しくなります。そのため現在では、ソフトウェアの設計品質評価を自動化するツール群を開発し、それらを用いて技術的負債を見える化し、計画的に解消していく試みを行っています。 コ
Perlのメトリクス計測 - WebService::Blog->new( user => ’hide_o_55’ )
ソースコードの品質向上のための効果的で効率的なコードレビュー にメトリクス計測ツールがでてきますが、Perlにももちろんあります。 Perl-Metrics-Simple-0.18 - Count packages, subs, lines, etc. of many files. - metacpan.org またPerl::Metrics::Simpleを使用したテストモジュール Test-Perl-Metrics-Simple-0.1 - Use Perl::Metrics::Simple in test programs - metacpan.org もあります。 循環的複雑度(Cyclomatic complexity)がしきい値を上回ったらテストが失敗するようになっています。 use Test::Perl::Metrics::Simple -complexity => 25;#
ConQATを利用してソースコードの品質をチェックする - 達人プログラマーを目指して
ある程度プログラマーとして経験を積めば、ソースコードを読んだときに、そのソースコードの良し悪しというものは、嗅覚を使って直感的に嗅ぎ分けることができるものです。実際、そのように体の感覚を使ってこのコードは不吉だと感じるところは実際大いにあり、コードの臭い（code smell)として知られています。 コードの臭い - リファクタリングの必要性を示す兆候 これはファウラーの名著 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見るでも紹介されており、こういった不吉な部分を適切に嗅ぎ分け
IE7もサポート終了へ、グーグルが変えた業界の慣習
昨年Internet Explorer（IE）6のサポートを打ち切ったグーグルが、今度はIE7のサポートまで打ち切ることを表明した。同社のブログによれば、8月1日をもって「Firefox 3.5」「IE 7」「Safari 3」のサポートを打ち切り、これらのブラウザーではGmail、Google Calendar、Google Talk、Google Docs、Googleサイトといった同社のクラウドサービスを使うとトラブルが起こる可能性がある。最終的にはこれらのアプリケーションが使えなくなるという。 IE6については、開発元のマイクロソフト自身が「腐った牛乳」と表現しており、サポート期限までまだ3年あるにもかかわらず、「The Internet Explorer 6 Countdown」というWebサイトを開設し、IE6の使用停止を呼び掛けている。Webアプリケーション開発者からも「早く
第1回 テスト管理システムとは何か？ | gihyo.jp
はじめに TestLinkとは、オープンソースのテスト管理システムです。TestLinkは、Francisco Mancardi氏、Andreas Morsing氏、Martin Havlat氏を中心としたコミュニティで開発されています。元々は海外で作られていたソフトウェアでしたが、最近は日本でも徐々に浸透してきているようです。 本連載では、TestLinkの日本語化に携わっているTestLink日本語化部会の私たちが、このTestLinkの基本機能について順次ご紹介していきます。 今回はTestLinkのご紹介する前準備として、「テスト管理システムとは何か」「では、そもそもテスト管理とは？」といったことについて考えてみましょう。 テスト管理システムとは何か 「テスト管理システム」と言う言葉を聞いたことはありますか？ もしかしたら、「バージョン管理システムやバグ管理システムなら聞いた
ソフトウェアテストの展望 (application/pdf オブジェクト)
© DebugEng Debug Engineering Institute DebugEng http://www.debugeng.com/ 2 © DebugEng Debug Engineering Institute 1. 2. 3. 4. 5. 6. © DebugEng Debug Engineering Institute 1 � 4 © DebugEng Debug Engineering Institute � 5 © DebugEng Debug Engineering Institute �SW 6 © DebugEng Debug Engineering Institute � � 1. 2. 3. © DebugEng Debug Engineering Institute 2 � 8 © DebugEng Debug Engineering Institute
63-ユーザの操作ミスを防止する - やさしいデスマーチ
「プログラマが知るべき97のこと」の63個目のエピソードは、ユーザビリティに関する話です。残念な事ですが、画面デザインに関して自分の仕事ではないと考えているプログラマは少なくありません。勿論、すべての分野のプログラマに必要なスキルではないかと思いますが、ユーザビリティを考慮したインターフェイスを設計する事はプログラマに求められるスキルの１つです。アイコンや画像を描くようなデザイナの仕事と考えてはいけません。情報の入力フォームであれば、入力値の妥当性のチェックはプログラマの仕事です。ユーザの操作が迷わないように誘導したり、不正な操作をすることを防止する手を打つのもプログラマの仕事です。論理的に考えた上で最適な形を提供する必要があります*1。 このエピソードでは、そんなユーザビリティに関する内容で特にエラーチェックに関する事が書かれています。 「入力して欲しいのはあくまで情報であり、データでは
岡崎市の被害届，学力崩壊，悪夢を形に，石原都知事 - カレーなる辛口Javaな加齢日記
岡崎市の被害届 このまま放置すると，日本のIT業界の黒歴史に岡崎市の名を再び刻むことになると，岡崎市民の皆さんは理解しているんだろうか． 「大学でアルファベットを教えて何が悪い」 http://hamusoku.com/archives/4123267.html http://d.hatena.ne.jp/gorotaku/20110219/1298093855 http://togetter.com/li/102569 キッチリと悪いですねえ， 大学は高等教育機関であり研究機関．そんな落ちこぼれ中学生むけ学習塾みたいなもののために存在しているわけじゃない． ある段階で何らかの理由によりつまづいたら、よっぽど幸運にすばらしい教師に巡り合う場合を除いて、その後ずっと落ちこぼれ続ける。積み上がらない。 んなわけない．努力すればそのくらい挽回できる．TOEIC 700点くらいは独学で十分到達可能
autotestの結果を伺かに喋らすver.α - もち
画像が重くてゴメンナサイ． SSTPを使う事で，より柔軟に色んな出力を伺かでNotifyする事が出来るようになりました*1． そこで，暫定的ではありますが，autotestの結果を伺かに喋らすスクリプトを公開します． 暇な人は，是非一度試してみてください． .autotest これは，#{RAILS_ROOT}/.autotestに書くスクリプトです．別に，gem/ZenTest-*/lib/autotest/の下にukagaka.rbとか作って，.autotestにrequire'autotest/ukagaka'とかでも良い． require 'ukagaka_io' # とりあえずlocalhostに接続しておきますよ UIO = UkagakaIO.open('127.0.0.1', 9801) class Autotest::Ukagaka def self.ukagaka(ms
脱Excel！ TestLinkでアジャイルにテストをする
今回はTestLinkをテスト工程でどのように使うのか、テスト特有のマネジメント手法や概念を、TestLinkの機能に合わせて詳しく説明した。 【1】TestLinkの概要 TestLinkはPHPで作られたテスト管理Webシステムである。最新版はVer 1.8.3 （2009年6月）で、GPLで公開されている。WAMP、LAMP環境で動作する。 主な機能は下記である。 （参考：「きちんと学びたいテストエンジニアのためのTestLink入門」（gihyo.jp）、「簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト」） 数千から数万のテストケースを一括登録して貯蔵できるので、テストケースを再利用できる テストケースとは別に、テスト実施結果を履歴として残せる テスト実施結果をいろいろな観点で集計できる テストケースからバグ管理システムと連携してバグ修正
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
ソフトウェアテストのプラクティス — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
フレームワークごとの生産性の違いを定量的に計算する方法があったらいいのにな - 達人プログラマーを目指して
アーキテクトの重要な仕事の一つに、フレームワークの選択があります。そこで上流の方から毎回必ずと言っていい程求められるのは、選択肢となるフレームワークごとの生産性の違いがどのくらいあるか「定量的に」教えてほしいというものです。たとえば、Strutsの工数を100とした場合、Spring MVCなら70になるというようなことを事を答えとして求めてくるわけです。今、あるプロジェクトの提案書作成の支援をしているのですが、元請のマネージャーから提案書に生産性比較の定量的な評価を載せたいと言われてしまいました。まあ、いつものことですけれどね。 この業界では理科系の発想のできる人は少ないと言われていますが、なぜか数値化や定量化だけは良いことと信じられており、数字なら信じてしまう、（あるいは数字しか信じない）という人が多いようです。もちろん、性能の見積もりにしても、DBの容量見積もりにしても、定量化できる
定量的なソフトウェア品質管理（pdf)
日科技連とSQiPの取り組み 1980年、日科技連では、日本におけるソフトウェア製品の品質向上と効果的開発の方法論の確立を目指して、「ソフトウェア生産管理研究委員会」（SPC, Software Production Control）を設置しました。 以来、「TQMとソフトウェア工学の結婚」を標榜し、日本的品質管理をソフトウェア生産に適用するための調査・研究・普及を行ってまいりました。 2007年に、この活動が「ソフトウェア品質に関する活動」であると分かりやすくすることと、ソフトウェア技術職という専門的職業の矜持を大事にしたいという思いから、SQiP(Software Quality Profession)に改称しました。 1980年の設立当初は、メインフレーマーで培われたソフトウェア品質技術・施策を議論する場でしたが、現在はソフトウェア産業に関わるすべての方々が議論できる場になっています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger
JUnit 4.7 : テストごとのルール
Trac発車オーライ
Google Developer Day 2010 Japan: ここちよい Android - おもいやりの UI デザイン (adamrocker, 矢野りん)
