32号：わたしは、リスクベースドテストが嫌いです｜Kouichi Akiyama
≣ はじめに「わたしは、リスクベースドテストが嫌いです」と言ったら、「じゃあ、なんでブログに書くの？ 好きで楽しいことだけを書いたらいいじゃない？」と言われると思います。 まったくその通りです。ぐぅの音もでません。ただ、嫌いなくせに、「リスク」や「リスクへの対応」の話はしているので、ひょっとしたらツンデレなのかも？ とも思います。 ということで、自分がどう考えているのかを書き出してまとめることで、一歩進めないかな？ とそんな期待をもって書き始めています。ですから、今回のエントリーは「単なる意見（思い込み）」であって、「普遍的な何か（証明済みの真理）」ではないことを初めにお断りします。 ≣ リスクベースドテストとは『ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03』では、「リスクベースドテスト」をテスト戦略のひとつ（分析的
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
COCOAが反応したんだが…
それは先週金曜日のことだった。 「COVID-19にさらされた可能性があります」 ヒヤッとするポップアップが携帯に表示される。 慌ててCOCOAを起動して確認するも、「陽性者との接触は確認されませんでした」との表示が。 新型コロナウィルス流行後、いわゆる三密に相当する施設は避けてきた。 買い物に行くときも、自家用車を利用してきた。新型コロナに感染するような覚えは全くない。 さっきの通知は何だったんだ？そういえば、COCOAはバグがいろいろ残っているというし… 急いでCOCOAの不具合について調べると、似たような現象に直面している人はいるらしい。 どうやら、携帯の設定項目をたどると、接触ログを記録したjsonファイルが書き出せるので、 そのログの中を検索し、Match Countという項目が0以外になっている箇所があれば濃厚接触があったという事らしい。 jsonファイルをPCに転送し、エディ
テストを自動化するのをやめ、自動テストを作ろう
July Tech Festa 2020 TrackB https://jtf2020.peatix.com/
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
「Aを轢けばBが助かる」そのとき自動運転車は誰を殺すのか？――「トロッコ問題」が提起する倫理的ジレンマ | AMP[アンプ] - ビジネスインスピレーションメディア
自動運転車の開発が本格化している。トヨタは2020年の東京オリンピックで“お披露目”すると発表、ホンダはグーグル傘下のIT企業ウェイモと提携し、2025年までにはレベル4（システムによる主導運転）の自動運転車を開発すると名言している。 ドライバー不在でも、私たちの望む場所へ運んで行ってくれる夢のような車。以前なら、ドラえもんのポケットからしか出てきそうになかったようなシロモノの実現が目前に迫っている。 しかし、もしこの「夢の車」が殺人機になる可能性があるならば…あなたはどうするだろう。購入するか、それとも買い控えるか。そして、車が起こした殺人は誰の責任になる？ 2014年、自動運転車の「倫理観」を問う興味深い実験が行なわれた。もし誰かを犠牲にしなければならない場合、自動運転車はどのような選択をすべきか。いわゆる「トロッコ問題」である。 「Aを犠牲にしてBを救う」トロッコ問題とは？ 「トロッ
![「Aを轢けばBが助かる」そのとき自動運転車は誰を殺すのか？――「トロッコ問題」が提起する倫理的ジレンマ | AMP[アンプ] - ビジネスインスピレーションメディア](https://cdn-ak-scissors.b.st-hatena.com/image/square/eb04e96ec345c88b3aaaa54bd2cc156f115edf75/height=288;version=1;width=512/https%3A%2F%2Fampmedia.jp%2Fwp-content%2Fuploads%2F2018%2F12%2Ftrolley-problem1.jpg)
テストを書きたくない話 / I don't want to write tests
2019/10/11に行われた「「テスト」の話を聞いてみようの会」での登壇資料です
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？ 今年、2019年5月20日から3日間にわたりスペイン バルセロナで開催されたKubeCon＋CloudNativeCon Europe 2019の基調講演では、SpotifyがミスによってKubernetesのクラスタを消去してしまった経験を振り返るという非常に興味深いセッション「Keynote: How Spotify Accidentally Deleted All its Kube Clusters with No User Impact - David Xia」（基調講演：SpotifyはいかにしてKubernetesクラスタの全削除というミスにもかかわらず顧客への影響を引き起こさなかったのか？）が行われました。 障害が起こることをあらかじめ計画とし
車の運転って難しすぎない？ なんで社会で許されてるの？ - 拝徳
車が暴走して親子を跳ねた、バスが歩行者を跳ねた、幼稚園児を跳ねた、踏み間違えて突っ込んだ、そんな痛ましい事故が日々おきて悲しい気持ちになる。 そしてつくづく思うのは車の運転とは難しいということだ。 都内に住んでるとびっくりするくらい車に乗る機会がない。免許こそもっているが乗る機会がほとんどない。たまにレンタカーのるけど、あまりにも乗らなすぎてわからないことある。 誰かが言っていたけれど、東京都内は移動の概念が時間に変わった、都市だと言っていたけれどそうだと思う。僕ももう10年近く東京に住んでいてここから渋谷まで何キロ、東京まで何キロって言われてもわからないけれど、ここから渋谷までは電車で40分という時間はわかるので距離が時間の概念に変わっている。渋谷まで何キロって言われると全然距離感がわからない。 そして何より車の運転は楽しくない。スマホ触れない、寝れない、お酒飲めない、事故リスクもある。
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
gccは第三者検証を通せる．しかし壁がある．
JAXAのH2Bロケットに搭載されたTOPPERS/HRPカーネルでの開発環境構築を基にした，高信頼環境におけるgccの能力と，立ちはだかる壁のお話．
自動運転 修正に規制…搭載プログラム 国が安全確認し許可 : テクノロジー : ニュース : 読売新聞オンライン
読者会員限定です 読売新聞の購読者は、読者会員登録（無料）をしていただくと閲覧できます。 読売新聞販売店から届いた招待状をご用意ください。
勤労統計問題の原因は「COBOLプログラムのバグ」 – アゴラ
厚生労働省の毎月勤労統計調査についての特別監察委員会の報告書が出され、樋口委員長の記者会見が行われた。疑問も残るが、おおむね事実関係は明らかになった。焦点になっている東京都の大企業の抽出調査については次の通り： 2003年5月22日付の事務連絡に「事業所規模５００人以上の抽出単位においては、今回から全国調査でなく、東京都の一部の産業で抽出調査を行うため注意すること」と書かれている。この事務連絡は雇用統計課長の決裁をへて他部局にも公式に伝達されており、隠蔽の事実はない。 当時の担当課長は「抽出調査としたことについて、覚えていないが当時自分が決裁したと思われる決裁文書を見たらそのように残っていたのでそうなのだと思う。ただ、抽出していたとしても労働者数に戻す復元を行っていれば問題ない」と供述しているが、この復元が行われた形跡がない。 システム改修を行った担当係によると「外部業者等に委託することな
「品質“実質”無料キャンペーン」を開始しました - pixiv inside
みなさんこんにちは！ピクシブで唯一のテスト専任エンジニアの @shimashima です。 今日は昨年10月に全社向けに発表を行なった「品質“実質”無料キャンペーン」についてご紹介しようと思います。 キャンペーン開催の経緯 昨年10月より、それまで所属していたpixiv運営本部からコーポレートエンジニアリング部という間接部門に異動し、社内システム改善を行うとともに社内全般の品質向上を目指して動くことになりました。 入社した当時はソフトウェアテスト・品質を専門としているエンジニアは私一人でした。ピクシブのサービス全般についての品質向上を目的として入社したものの、社内での私自身の認知度もまだまだで、品質に関する相談もかなりまばらな状態でした。需要が少ないということもあるかもしませんが、まずは「社内に品質について相談する人・窓口がある・居る」ことを認知してもらおうと思っていました。そのとき、コー
テストエンジニアの観点を持ってテスト書いていくぞな話 - kariadの戯言
ごきげんよう。かりあどです。 12/15~16に開催されたWACATE2018 冬 〜C’mon baby ジドウカ〜 に参加してきました。 そこでテストエンジニアの方々と色々議論できたのでそれを書きます。 またt_wadaさんによる講演もとても素晴らしかったので感想を書きます。 WACATEそのものの感想よりも議論の内容を書きたいので、WACATEって何?という方はこちら。 wacate.jp 当初の予定は参加レポートだったのですが、議論した内容があまりにもよかったのと、個人的に振り返りたかったので急遽予定変更です。 なおこちらの記事はOisix ra daichi Inc. Advent Calendar 2018の18日目となります。 前日の弊社スーパーSREエンジニアの@morihaya55さんの記事はこちら adventar.org 開発者とテストの関わりについて 私は普段iOS
ASTER-テスト設計コンテスト'21-テスト設計チュートリアル テスコン編
テストと呼んではいるものの、曖昧で抜けだらけの発注先の仕様をなぞるだけの、意図の分からない単純労働に膨大な時間を費やしていませんか。 品質保証と呼びながら、一体どんな品質を保証しているかの全体像すら誰にも説明できない苦境に陥ってはいませんか。 こうした質の低いテストから脱却するためのチャレンジの場として、NPO法人ASTERではテスト設計コンテストを開催しています。 このチュートリアルでは、過去のコンテストの応募作を基にして、意図がきちんと分かり全体像を説明できる質の高いテストを設計するための考え方を解説します。 なお、昨年度のテスト設計コンテストの応募作の解析も取り入れた内容になっておりますので、過去に聴講したことのある方でも参考になるものと思います。多くの方々のご参加をお待ちしています。 本チュートリアルは、昨年までテスト設計コンテスト OPENクラスチュートリアルとして実施していたも
テスト設計コンテストOPEN東京チュートリアルまとめ #テスコン - Togetter
Yasuharu NISHI @YasuharuNishi って資料に書くの忘れたorz RT ちなみにU30の資料もOpenの資料も、VSTePの説明をしているわけではないです。単に、説明したいことを一貫して説明するために概念が比較的揃っている（メタモデル上のスーパーセット）だけなので、各現場で使っている方法論に合わせてその概念に落 2018-10-04 21:32:49
日本企業が「カオスエンジニアリングやっていく宣言」を出せた理由 (1/2)：クックパッドに直撃 - ＠IT
クックパッドが2018年8月2日に公開したブログエントリ「Chaos Engineering やっていく宣言」に大きな反響があった。米国を中心に多くの企業で実践されているが、疑似的とはいえ本番環境に障害を起こさせるというカオスエンジニアリングを日本で実践するのは、まず不可能という向きが多かったからだ。なぜ、クックパッドでは実践することが可能になったのか。 今、エンジニアの間で注目を集めているキーワードが「カオスエンジニアリング」だ。動画配信サービスを提供するNetflixが導入したことで着目されるようになった手法で、本番サービスであえて疑似的な不具合を引き起こし、システムがどのように振る舞うかを把握する。ひいては、マイクロサービスを採用した大規模システムの安定性、可用性向上につなげていくことを目的とした取り組みだ。 カオスエンジニアリングについては、いちエンジニアとして「面白そう、やってみ
CIとTest Sizesの話 - asterisc
はじめに 前回 akito0107.hatenablog.com どちらかというとこっちが本編。 前回の記事ではTest Sizesについて紹介したが、今回の記事はその分類が実際の開発にどう役に立っているのかをまとめたいと思う。もちろん用語の統一も大きな意味を持つが、それ以外のことを書いていきたい。 具体的には、CIでテストのパイプラインを組む時にこの分類どおりに組んでいくと綺麗に整理でき、CI全体のスループット向上にも効果がでているという話だ。今回の話は僕たちのチームに特化した内容になるが、1) Test SizesごとにTestの起動コマンドを分ける、 2) Smallから順に実行していき、落ちるべきテストはできるだけ早期に落とす、というポイントはどこにでも使えるものだと思う。 コンテナ技術とテスト 僕たちはローカルの開発環境だけではなく、本番環境やCI環境でコンテナ技術（主にDock
開発者視点のテストとユーザ視点のテストの違いについて｜Tsuyoshi Yumoto
この原稿は、2009年6月に発売された、システム開発ジャーナルvol10の特集「特集1 困ったら読む! 困る前に読む! 今すぐ使える エンジニアのためのソフトウェアテスト術」の総論（最初のまえがきみたいなもの）の後半部分として執筆したものです。この特集は私が豆蔵に在籍していたころに、大西さんと私で企画したもので、多くのイケてる技術者の方々にお願いして各パートを執筆してもらったものです。以下が目次です。 総論 ソフトウェアテストの現状と知っておくべきこと Part1 独立したテストチームとしてのテスト計画・テスト設計仕様 テストをスムーズに行う?管理者のための“段取り”術 品質を向上させるためのインシデントレポートの書き方 テストツールの活用 自動化できる/できないの判断のコツ Part2 開発者による開発者のためのDeveloper Testing OSSのツールを使って静的テストを自動化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
