nihonbusonのブックマーク (453)

  • これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴 / How it might work when you take on something new

    Scrum Fest Sapporo 2020 での発表資料です

    これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴 / How it might work when you take on something new
    nihonbuson
    nihonbuson 2020/11/13
    非常に真っ当な話ばかりで良い。ただこの発表を聞くと、やれてるチームに「そんなの当たり前じゃん」と言われて、やれてないチームに「そうなるのは理想だけど…」と言われちゃいそう。(本当はそうじゃない)
  • トランプ氏、日本の首相に? ネット「虚構新聞」が話題 | 共同通信

    「敗北トランプ氏、『日初の外国人総理大臣』に意欲」―。バイデン前副大統領が勝利を確実にした米大統領選を巡り、架空のニュースを発信するウェブサイト「虚構新聞」の9日付の記事が、会員制交流サイト(SNS)などで話題を呼んでいる。執筆した社主のUKさんはトランプ大統領を「実際にやってしまいそうな面があり、『誤報』にならないよう気を配った」と話している。 虚構新聞は、滋賀県の塾講師のUKさんが2004年に立ち上げ、さまざまな分野の「虚構世界の現実」を、現実世界への風刺を交えながら週1~2回掲載。実際のニュースや日常生活からアイデアを書きためているという。

    トランプ氏、日本の首相に? ネット「虚構新聞」が話題 | 共同通信
    nihonbuson
    nihonbuson 2020/11/11
    虚構新聞について京都新聞が記事を書き、共同通信がその記事を配信したのか
  • 効果を維持しつつテスト工数を削減した話 〜改善結果の質問回答編〜

    QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QA にて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。 質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。 記事ではテスト設計改善に関する質問に回答します。 発表概要の紹介 改めましてこんにちは!ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。 私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。 発表スライドは下記となります。 また、当日の配信内容はYo

    効果を維持しつつテスト工数を削減した話 〜改善結果の質問回答編〜
    nihonbuson
    nihonbuson 2020/10/30
    先日の #D3QA イベントでの質問に答える企画の第3弾(最終回)です!今回は改善結果について。単純にテストケース数を1/3以下にした数値結果だけでなく、開発・QAチーム全体が歩み寄っている部分に注目してください!
  • 効果を維持しつつテスト工数を削減した話 〜テストマネジメント改善の質問回答編〜

    QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QAにて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。 質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。 記事ではテストマネジメント改善に関する質問に回答します。 発表概要の紹介 改めましてこんにちは!ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。 私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。 発表スライドは下記となります。 また、当日の配信内容

    効果を維持しつつテスト工数を削減した話 〜テストマネジメント改善の質問回答編〜
    nihonbuson
    nihonbuson 2020/10/29
    先日の #D3QA イベントでの質問に答える企画の第2弾です!今回はテストマネジメントについて。スケジュールや人だけではなく、テスト自体をマネジメントしようとしているところに着目してもらえると嬉しいです!
  • 採用を妥協すると優秀な人が疲弊する - Konifar's ZATSU

    採用を妥協していないという会社のツイートを見た。実際どうなのかはわからないけれど、そのマインドは素晴らしい。 逆に採用を妥協するとはどういうことかというと、今いるメンバーと同等もしくはそれ以上の成果が出せない人を入れるということだ。そうするとどうなるか。程度にもよるが、今までの自分の経験や聞いた話だと、まず他の優秀な人から疲弊していく。めちゃくちゃ雑な意見なのでツッコミどころは多いと思う スキルが追いついていないだけならそこまで大きな問題はない。問題になるのは、マインドや物事の考え方、それに基づく仕事の進め方などにあまりに差があるケースだ。論理的思考力や素直さと表現されることもある領域の話である。 新卒など若い人の場合は問題ない。これは採用を妥協しているわけではない。教育による伸びしろを想定しているからだ。 ある程度経験を積んだ人を採用する場合、妥協してはいけない。迷ったら採用しないのが正

    採用を妥協すると優秀な人が疲弊する - Konifar's ZATSU
    nihonbuson
    nihonbuson 2020/10/29
    "問題になるのは、マインドや物事の考え方、それに基づく仕事の進め方などにあまりに差があるケースだ。" / ホントそれ。スキル以上にマインドの違いは致命傷になる。
  • 効果を維持しつつテスト工数を削減した話 〜テスト設計改善の質問回答編〜

    以降では、このテスト設計改善の取り組みに対する質問に回答していきます。 テスト設計改善についての質問の回答 【質問1】テスト設計にあたって開発ドキュメントの参照はしないのでしょうか。開発ドキュメントがほとんど無い? 開発ドキュメントの参照はします。チケットの内容、開発ドキュメントだけでなく、その内容に対しての疑問点は実際に開発と議論しておきます。開発者との議論はテスト設計に着手する前、テスト観点出しを行う前後の活動です。 【質問2】テストと設計の比率を出していらっしゃいましたが(テストをいっぱいやるようにした)、数える単位は何ですか?人数?時間?その他? 説明資料では文字の大きさの都合上省略した形で書いていますが、比率を出していたのは「(開発の設計ではなく)テスト設計」と「テスト実施」の比率です。また、ここでの比率は感覚値ではありますが、工数比です。 【質問3】改善後の成果物サンプルやアク

    効果を維持しつつテスト工数を削減した話 〜テスト設計改善の質問回答編〜
    nihonbuson
    nihonbuson 2020/10/27
    先月の #D3QA イベントの内容紹介といただいた質問の回答について載せた記事の第1弾(全3回予定)ができました!今回はテスト設計改善について発表で伝えきれなかったことを詳細に説明しました。
  • テスト、正常系から書くか異常系から書くか - hitode909の日記

    今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値

    テスト、正常系から書くか異常系から書くか - hitode909の日記
    nihonbuson
    nihonbuson 2020/10/23
    以前にGoogleのテストエンジニア(TE)と数人のQAで似た話をしたことがある。QAが特殊なテストばかり挙げているのを聞いたGoogleのTEから、「ハハ、お前らもっと単純なテストをまず考えろよ」的なことを言われたなー
  • Re-collection of embedded software qa in the last decade

    JaSST東海2020の基調講演のスライドです。 この10年間の日の組込みソフトウェアの品質保証を振り返り、次の10年間できちんと進化していくために再構成を試みます。それによって、見たこともない新しいものに変化するのではなく、過去に乗り越えてきたハードルが形を変えて訪れてきたに過ぎないことを示すとともに、どのようにハードルを乗り越え新しいものに変化していくかの考え方を提示します。そして派生開発の名を借りた技術的負債増加型開発による「手が回らないQA」から、継続的カイゼンによる現場力向上という右利きのQAと、デジタルトランスフォーメーションによる左利きのQAとを同時に実現する「両利きのQA」に脱却できるヒントを、QualiTraxというフレームワークを用いて例示します。Read less

    Re-collection of embedded software qa in the last decade
    nihonbuson
    nihonbuson 2020/10/21
    "左利き(新しい技術による仕事)にばかり気を取られて右利き(慣れた仕事、改善による仕事の深化)が疎かになっている組織が実は多くある" / ホントそれ
  • 今年もJaSST Reviewを開催します! #jasstreview - ブロッコリーのブログ

    一昨年から始まりましたJaSST Reviewを今年も開催します。3回目の開催です! 記事では今回の発表内容をざっと紹介していきます。読んだ上で興味がある発表がありましたら、ぜひイベントに参加登録をお願いします! www.jasst.jp 目次 目次 JaSST Reviewとは何か 今回のJaSST Reviewのテーマ 講演1 : 専門書が出版されるまでの編集者の思考と行動 ~編集者はどのように校正・校閲しているか~ 講演2 : ソフトウェア設計における意思決定とそのレビューの秘訣 事例紹介1 : 刺激語カードを用いたソフトウェアレビューの実践について ~アイデアを刺激し意識外から観点を得る 事例紹介2 : レビューイの力を引き出すフィードバックのチューニング~チーム外からの支援で見えてきた、成熟度に応じた「問いかけ」の調整方法と各種レビューへの適用可能性 おわりに JaSST Re

    今年もJaSST Reviewを開催します! #jasstreview - ブロッコリーのブログ
    nihonbuson
    nihonbuson 2020/10/15
    今年の発表内容を簡単に紹介しました!今年もテーマに沿った良いコンテンツになったと思いますので、気になる方はイベントの参加登録もお願いしますー! http://www.jasst.jp/symposium/jasstreview20/query.html
  • Issues · cto-a/policy-proposal

    nihonbuson
    nihonbuson 2020/10/10
    「デジタル庁の創設に向けた提言」に対してissueを受け付けてるけど反映させる気がないのかな? issue#23の「AではなくBに読み取れるので文章の見直しを」→「Aのように読み取ってください」は対応としてどうなの…?
  • 組織にテストを書く文化を根付かせる戦略と戦術(2020秋版) / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition

    ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日(月) http://www.jasst.jp/symposium/jasst20niigata.html

    組織にテストを書く文化を根付かせる戦略と戦術(2020秋版) / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition
    nihonbuson
    nihonbuson 2020/09/28
    13ページまでの新規追加分が、「質とスピード」の発表であまり示されてなかった数値が出てきてて、2つの発表資料が良い具合にリンクしてる気がする
  • ビジョナリー・QA:グロービスQAチームの理想と3つのゴール|グロービス・デジタル・プラットフォーム

    「究極的には、QAチームは無いのが理想」と言い切るグロービスQAチームが少数精鋭で挑むチャレンジをご紹介します。アジャイル開発の品質のあり方、そして理想に至る短期・中期・長期のゴールとは? 結論ファーストはじめに、エントリーの要約を載せておきます。 スピードの速いアジャイル開発において、もはや品質はQAエンジニアやQAチームだけが保証するものではありません。企画からリリースまで関わるチーム全体で創り上げていくものなのです。ビジネス価値向上への貢献を使命とするグロービスQAチームは、開発チームから独立した立場でスピードと品質を両立すべく工夫したテストはもちろん、データドリブンの品質改善活動や、SM・POやステークホルダーへのアプローチを通じた上流からの品質向上および組織の品質文化醸成に取り組んでいます。QAチームがいなくても高品質のプロダクトが素早く提供される組織こそが、グロービスQAチー

    ビジョナリー・QA:グロービスQAチームの理想と3つのゴール|グロービス・デジタル・プラットフォーム
    nihonbuson
    nihonbuson 2020/09/22
    "QAチームがいない組織がQAチームの理想" / 私が目指している理想と同じだ…!この考えを持たないと、開発に品質の考え方を染み込ませるのが難しいと思ってる。
  • データベースをリファクタリングしたお話 - BASEプロダクトチームブログ

    基盤チーム所属の沖中( @okinaka )です。 「リファクタリング」という言葉、エンジニアのみなさんならご存知でしょう。 システムの振る舞いを変えずに内部を改善することを指す言葉です。 一般的に、コードの修正を指すことがほとんどですが、今回はデータベース設計のリファクタリングについてお話ししたいと思います。 絶版になってしまいましたが、データベース・リファクタリング という書籍に様々な手法が紹介されていて参考になります。英語で良ければ 原書 はまだ入手可能ですね。 データベース・リファクタリング 作者:スコット W アンブラー,ピラモド・サダラージ発売日: 2008/03/26メディア: 単行 Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler)) (

    データベースをリファクタリングしたお話 - BASEプロダクトチームブログ
    nihonbuson
    nihonbuson 2020/09/22
    細かい部分の修正かもしれないけど、リファクタリングの考えに則った、非常に良い修正の仕方だ…
  • テストコードが増えるとバグは減るのだろうか? / Does more test code mean fewer bugs? - Speaker Deck

    Transcript ςετίʔυ͕૿͑Δͱόά͸ݮΔͷͩΖ͏͔ʁ�� ʮ���ˠ������ʯͰݟ͑ͨੈքͷ࿩� גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦�J04νʔϜ� ໊औ�߂ฏ Copyright © ZOZO Technologies, Inc. © ZOZO Technologies, Inc. גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦� J04νʔϜ ໊औ�߂ฏ 2019೥2݄ΑΓݱ৬ɻ ZOZOTOWN iOSΞϓϦͷ։ൃΛ͍ͯ͠·͢ɻ झຯͰݸਓ։ൃ΋ɻ 2 © ZOZO Technologies, Inc. 3 ���ˠ������ ʹ ͜ͷ�೥΄ͲͰ૿Ճͨ͠ςετΧόϨοδͷׂ߹ © ZOZO Technologies, Inc. 4 ���ˠ������ ����� ˞ܭଌର৅͸͜ͷ�೥ͷ։ൃͰؔ༩ͨ͠ϑΝΠϧʹߜ͍ͬͯΔ © ZOZO Te

    テストコードが増えるとバグは減るのだろうか? / Does more test code mean fewer bugs? - Speaker Deck
    nihonbuson
    nihonbuson 2020/09/22
    「仕様の理解を深めるため」が最初のメリットに来ているのが非常に良い。デメリットを記載しているのも良い。あとは、既存のテスト技法とかを活用するとさらに良くなりそう。(既に使ってるかもしれないけど)
  • テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities

    以下のイベントの投影資料です。 https://d-cube.connpass.com/event/187308/ お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料内にあるURL】 ▽P2:書籍『Agile Testing Condense…

    テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
    nihonbuson
    nihonbuson 2020/09/17
    今回は突飛なプラクティスを実施したわけでなく、地道に見える改善を紹介しました。少しでも皆さんの役に立てれば幸いです!
  • 1GBあたりのモバイル通信料を世界228カ国で比較したランキングが発表される、日本は何位なのか?

    モバイルデータ使用料の多くは1GB単位であることから、契約上の通信容量やその残量を「ギガ」と呼ぶ人もいます。イギリスの通信会社Cable.co.ukが発表した「世界228カ国のモバイルデータ価格の調査結果」を見ると、日を含む世界各国の「ギガ」が一体いくらなのかを知ることができます。 Worldwide Mobile Data Pricing League | Cost of 1GB in 230 countries - Cable.co.uk https://www.cable.co.uk/mobiles/worldwide-data-pricing/ Cable.co.ukが作成した以下の地図では、1GBあたりの通信料が高い国ほど濃い色で表示されています。 228カ国の中で、最も安価だったのがインドで、1GB当たりの平均価格は0.09ドル(約10円)でした。インドのモバイルデータがこれ

    1GBあたりのモバイル通信料を世界228カ国で比較したランキングが発表される、日本は何位なのか?
    nihonbuson
    nihonbuson 2020/08/26
    ビッグマック指数で比較してみた。https://twitter.com/nihonbuson/status/1298293209974546432
  • 神コントローラーにテスト駆動開発で機能追加 - Mitsuyuki.Shiiba

    TDDBC オンラインの基調講演の録画を見た。とても面白かった。和田さんのセッションやスライドは何度も見て勉強してるので、それをひとつずつ再確認しながら見ることができて、とても良かった。話の流れが分かりやすくてすごいなー。 #tddbc みるー TDD Boot Camp 2020 Online 1 基調講演/ライブコーディング https://t.co/g4AkCkr429— Mitsuyuki Shiiba (@bufferings) August 8, 2020 最近実際にやったテスト駆動開発 その録画を見ながら、最近自分がテスト駆動開発で機能追加をしたことを思い出してた。今日は、それをだらだらと書いてみようと思う。プライベートメソッドに対してテストを書いてたりするのが、なんか泥臭くて面白いかなと思って。 背景 自動テストが全くないプロダクト God コントローラー(1000行以上あ

    神コントローラーにテスト駆動開発で機能追加 - Mitsuyuki.Shiiba
    nihonbuson
    nihonbuson 2020/08/21
    「リファクタリングするときにはテストを書こう」とよく言われるけど、この記事では、最初から沢山のテストを書くのではなく確認したい部分から徐々にテストを広げていく過程が分かって良い。
  • リファクタリングに関する何か - 日々常々

    リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。 自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング。 破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。 描いた時の経緯と言うか 該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。 とは言え。やったことがない、やってはいけない文化(動いているコードに触ってはいけない)に染められてしまっている、そのような方に「無意識にやれ!」と言っても、何の意味もないので言いません。むしろ害悪ですらある。 該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉

    リファクタリングに関する何か - 日々常々
    nihonbuson
    nihonbuson 2020/08/12
    "書籍「リファクタリング」では堅実なテストは事前条件とされています。" / 確かに書籍内で一言だけ書かれていたけど、テストコード等は明記されてないので、検証方法に関する議論が盛り上がってない気がする。
  • TODOリストの整理を通じて実行すべきテストを考える #tddbc / TDDBC 2020 Online LT

    以下のイベントの投影資料です。 https://tddbc.connpass.com/event/181973/ 【発表資料中のURL】 P2 Agile Testing Condensed Japanese Edition https://leanpub.com/agiletesting-…

    TODOリストの整理を通じて実行すべきテストを考える #tddbc / TDDBC 2020 Online LT
    nihonbuson
    nihonbuson 2020/08/02
    t_wadaさんの基調講演、 #tddbc のペアプロの体験をした皆さんにとってはふりかえりの機会に、それ以外の皆さんにとっては新たな視点になってもらえれば嬉しいです!
  • 「テスト駆動開発の『駆動』は誤訳なんじゃないか」と言われて改めて考えた話 - ブロッコリーのブログ

    先日、社内のSlackでこんなことを言われました。 TDDとかのdrivenを駆動って訳すの誤訳じゃないのかと思うんですけど、どう思いますか? 意味合いは駆動より操縦とか運転なんだと思うんですが そこで「駆動」の意味を改めて考えてみました。 辞書で調べてみる goo辞書では以下のように書かれています。 [名](スル)動力を伝えて動かすこと。「四輪駆動」「駆動輪」 書籍から考える 書籍『エクストリームプログラミング』の第2章には以下のように書かれています。 「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」 これがXPのパラダイムだ。注意して、適応して、変更する。 なぜ「駆動」が誤訳だと感じてしまったのか テスト駆動開発(TDD)は「test-driven developme

    「テスト駆動開発の『駆動』は誤訳なんじゃないか」と言われて改めて考えた話 - ブロッコリーのブログ
    nihonbuson
    nihonbuson 2020/07/08
    「駆動」という言葉について改めて考えてみました。