32号：わたしは、リスクベースドテストが嫌いです｜Kouichi Akiyama
≣ はじめに「わたしは、リスクベースドテストが嫌いです」と言ったら、「じゃあ、なんでブログに書くの？ 好きで楽しいことだけを書いたらいいじゃない？」と言われると思います。 まったくその通りです。ぐぅの音もでません。ただ、嫌いなくせに、「リスク」や「リスクへの対応」の話はしているので、ひょっとしたらツンデレなのかも？ とも思います。 ということで、自分がどう考えているのかを書き出してまとめることで、一歩進めないかな？ とそんな期待をもって書き始めています。ですから、今回のエントリーは「単なる意見（思い込み）」であって、「普遍的な何か（証明済みの真理）」ではないことを初めにお断りします。 ≣ リスクベースドテストとは『ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03』では、「リスクベースドテスト」をテスト戦略のひとつ（分析的
テストを書きたくない話 / I don't want to write tests
2019/10/11に行われた「「テスト」の話を聞いてみようの会」での登壇資料です
gccは第三者検証を通せる．しかし壁がある．
JAXAのH2Bロケットに搭載されたTOPPERS/HRPカーネルでの開発環境構築を基にした，高信頼環境におけるgccの能力と，立ちはだかる壁のお話．
勤労統計問題の原因は「COBOLプログラムのバグ」 – アゴラ
厚生労働省の毎月勤労統計調査についての特別監察委員会の報告書が出され、樋口委員長の記者会見が行われた。疑問も残るが、おおむね事実関係は明らかになった。焦点になっている東京都の大企業の抽出調査については次の通り： 2003年5月22日付の事務連絡に「事業所規模５００人以上の抽出単位においては、今回から全国調査でなく、東京都の一部の産業で抽出調査を行うため注意すること」と書かれている。この事務連絡は雇用統計課長の決裁をへて他部局にも公式に伝達されており、隠蔽の事実はない。 当時の担当課長は「抽出調査としたことについて、覚えていないが当時自分が決裁したと思われる決裁文書を見たらそのように残っていたのでそうなのだと思う。ただ、抽出していたとしても労働者数に戻す復元を行っていれば問題ない」と供述しているが、この復元が行われた形跡がない。 システム改修を行った担当係によると「外部業者等に委託することな
「品質“実質”無料キャンペーン」を開始しました - pixiv inside
みなさんこんにちは！ピクシブで唯一のテスト専任エンジニアの @shimashima です。 今日は昨年10月に全社向けに発表を行なった「品質“実質”無料キャンペーン」についてご紹介しようと思います。 キャンペーン開催の経緯 昨年10月より、それまで所属していたpixiv運営本部からコーポレートエンジニアリング部という間接部門に異動し、社内システム改善を行うとともに社内全般の品質向上を目指して動くことになりました。 入社した当時はソフトウェアテスト・品質を専門としているエンジニアは私一人でした。ピクシブのサービス全般についての品質向上を目的として入社したものの、社内での私自身の認知度もまだまだで、品質に関する相談もかなりまばらな状態でした。需要が少ないということもあるかもしませんが、まずは「社内に品質について相談する人・窓口がある・居る」ことを認知してもらおうと思っていました。そのとき、コー
プログラムのわからないえらい人「バグのないプログラムを書くことはできないのか？難しいかもしれないが、十分に気を付けていれば防げるのではないか？」にどう返したらいいのかわからない
バグは人のミスなんだから、理屈的には正しいような気がする だけど未だかつて人類はこれを達成できていないという観測的事実がある、何故そうなるのかを説明することは可能だろうか
ASTER-テスト設計チュートリアル ちびこん編 ‘21
1. テスト観点（テストすべきこと）を整理して、網羅的に挙げよう テストすべきことを挙げきることは、バグを防ぐために大切な考え方です。ここではテストすべきことを網羅的に挙げるとはどのようなことか、どのように行ったらよいかについて、Myersの三角形問題を題材にして具体例を挙げながら説明します。また、テストは網羅的に行うことも必要ですが、効率的にバグを見つけるためにピンポイントでバグを狙って検出する、というテスト設計も必要です。ピンポイントでバグを狙うためのテスト観点やその導き方についても合わせて紹介します。 2. テストフレーム（テストケースの構造）を考えよう テストすべきことをテスト観点として列挙したら、それらをまとめてテストケースにしていきます。その時にテストケースの構造を考えると、網羅しやすいテスト設計になります。ここではテストケースの構造とはどのようなことか、どのようにまとめていっ
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
ソフトウェア開発の品質と、ソフトウェアの品質は、分けて考えたほうがいいんじゃないか - きしだのはてな
ふと「ソフトウェア品質のxxx」みたいな文章を見つつ、基本としてはソフトウェアがいかに仕様どおりになっているか確認する話だったので、これってソフトウェア品質じゃなくて、ソフトウェア開発品質だよなーと思った。 実際、ソフトウェア開発の品質と、ソフトウェアの品質には相関はあると思う。とくに1990年代まで、まだITという言葉があまり使われず、OA、つまりオフィスオートメーションがソフトウェアの主な開発対象だったときには、データがちゃんと入ってデータがちゃんと届けられるということが主な処理だったため、ソフトウェア開発の品質と、ソフトウェアの品質はほぼ一致していたと思う。 そういう中で、ソフトウェア品質として、ソフトウェア開発の品質が研究された。 実際、ソフトウェア開発プロセスの基本コンセプトのひとつは、「よいプロセスがよいソフトウェアを作る」ということで、ソフトウェアプロセスの本を見ると必ずとい
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Migraine Pain Relief Best Mortgage Rates music videos All Inclusive Vacation Packages Healthy Weight Loss Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
Tom Gilb & Kai Gilb : Testers Bill of Rights
Testers Bill of Rights Please suggest your own Testers Bill of Rights! Testers have the right to unambiguous and clear Requirements, Qualities must be quantified. Testers have the right to be a party to setting the quality levels of process and documents inputs, and to their product outputs. Testers have the right to sample the process and document inputs, and to reject inputs of poor quality. Te
NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
ウノウラボ Unoh Labs: テスト担当者のモチベーション
こんにちは！やまもと＠テスト番長です。 一般人に向かって自己紹介するとき、 「一応サラリーマンです。WEBサイト作ったりとかしてます。」「専門はテストです。」というと 「出来栄えをチェックする人だから、エライ人なんですねー」 と若干良い方に誤解されがちですが、 同業者に「専門はテストです。」というと「あー、大変っすよねー」と必ず同情されます。 テストというのはどうもモチベーションが上がりにくいお仕事のようです。 今回は来るべき五月病シーズンに向けて、特に新人に近い立場の方がモチベーションを失わずに居られる方法を幾つか考えてみましょう。 テスト担当を押し付けられたとき 新人を安易にテスト業務に割り当てるケースがあります。 新人はまだ経験と信頼性が足りない故に他の作業で使いづらく、そうなりがちです。 もしプログラミングの方に興味があるなら、そういう意向をアピールしておくべきです。
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
