タグ

CIとquality assuranceに関するvanbraamのブックマーク (9)

  • JaSST'18 Tokyo 基調講演「Advances in Continuous Integration Testing at Google」 質疑応答 #JaSST

    broccoli @nihonbuson ハードウェアの自動化に良いアイディアはあるか? どれだけデジタル化が進んでいるかによる アルゴリズムのみをテストするならば可能だと思う #JaSST 2018-03-07 10:52:44 broccoli @nihonbuson トランジションの話の前提として、どれぐらいのカバレッジが達成できているのか? 別のシステムを設けて、カバレッジを測定している。 コードカバレッジはチームに寄って違う。 80%以上のチームもあれば計っていないチームもある 収入が高いチームはカバレッジが高い。成熟度によって変わる #JaSST 2018-03-07 10:54:23 broccoli @nihonbuson テストができている段階の話をしていたが、どういうテストを作るというような指針はあるか? 一般的なルールは、コードレビュー時に同時にテストコードをサブミッ

    JaSST'18 Tokyo 基調講演「Advances in Continuous Integration Testing at Google」 質疑応答 #JaSST
    vanbraam
    vanbraam 2018/03/17
    UI/UX試験:UIはWebDriverを自動化,UXは手動;"変更していないコードにはFBが来ないようにしている"<レポートがnoisyになるのを避ける為?
  • GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ

    はじめに FLAKYの内容が今はっきりした!#JaSST— broccoli (@nihonbuson) 2018年3月8日 と書い(てしまっ)たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。 JaSST'18 Tokyoについては以下のページを参照してください。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo お知らせ この記事の内容を4/11に発表しました! nihonbuson.hatenadiary.jp 発表スライドはこちら speakerdeck.com 目次 はじめに お知らせ 目次 Micco氏のお話 ICSTでの話 基調講演「Advances in Continuous Integration Testing at Google」 講演資料 テスト文化について (3ページ付近) 回帰テスト (4ページ付近) Mil

    GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST - ブロッコリーのブログ
    vanbraam
    vanbraam 2018/03/14
    "実行していない自動テストは、決定的でない代わりに、確率論を用いる","チームとしてはリスクを持ってリリースする"<結局覚悟の問題.リスク0にと非現実的要求をする日本企業の経営者とは腹の据わり方が違う
  • JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ

    はじめに この記事はJaSST'18 Tokyo(ソフトウェアテストシンポジウム)のパネルセッションを書いたものです。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo 自己紹介 バックグラウンドが違い、コンテキストが違うことがある そこで自己紹介時に、どれくらいの頻度でDeployしているのか、どれくらいの頻度でリリースしているのかを踏まえて話してほしい。 荻野 恒太郎(以下、荻野) 楽天 テスト自動化とDevOpsのマネージャをしている。 デプロイは毎日数十回実施 1週間に数回リリースしている 天野 祐介(以下、天野) サイボウズ kintoneの開発チームに所属 エンジニアが10数名、QAなどを含めると30名ぐらいのチーム 2015年にチームリーダーになった 今はスクラムマスター中心 最近、WaterFallからAgile開発に変更していっている 今は1イテレー

    JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ
    vanbraam
    vanbraam 2018/03/14
    "デプロイ"と"リリース"の定義がよくわからない.Productionへのデプロイ=リリース?(反例:Micco氏の発言);Googleの規模だと全テストを実行できない,というのは衝撃;インフラ起因でflakyならリトライ;"日本では経営者への説得が大変"
  • 実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ

    技術部の taiki45 です。 以前「サービス分割時の複雑性に対処する: テスト戦略の話」という記事で、サービス間のインテグレーションテストにおける問題について紹介しました。現在のクックパッドではこの問題の解決のために Pact というツールを導入して運用しています。この記事では、その運用の知見を紹介できればと思います。 Pact Pact は Consumer-Driven Contract testing (CDC testing) を実現するためのツールです。"Consumer"、"Provider" という見慣れない単語が出てきますが、この記事ではだいたい「Consumer = Web API クライアント」、「Provider = Web API サーバー」と対応ができます。この記事では具体的な Pact の利用例を通じて CDC testing がどういうものなのかについても

    実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ
  • Netflix Billing Migration to AWS

    The journey to the cloud at Netflix began in 2008, and after seven years of diligent effort, we have finally completed… For a company, its billing solution is its financial lifeline, while at the same time, it is a visible representation of a company’s attitude towards its customers. A great customer experience is one of Netflix’s core values. Considering the sensitive nature of Billing for its di

    Netflix Billing Migration to AWS
    vanbraam
    vanbraam 2016/06/22
    Cloud移行に伴いコードとデータをシンプル化(refactor&cleanup);DBMSも分割&移行(Oracle->Cassandra+MySQL);読んで感じたけどこれ外注請負ではリスク高すぎる.やるとしても方式検討(委任) ->simulation(委任)->実施(請負)だな
  • テスト書きすぎ問題を避ける - Qiita

    新しい職場で提案したら歓迎されたので投稿しておく。 テストコード開発方針 漫然とテストコードを書いていると、以下のような問題が発生することがある。 テストに時間がかかりすぎ、待ち時間が発生したり、テスト結果を見なくなったりする テストコードの開発とレビューに時間をかけたが、そのコストに見合う利益を得られない このような問題を避けるため、以下の方針を定める。 ビジネス上の価値に比例したテスト コードの価値をビジネスへの影響や回避方法の有無により以下のようにランク付けする。 メジャー サービスの主たる機能に影響する 再現条件が広い 回避方法がない/あっても自明でない マイナー サービスの副次的な機能に影響する 再現条件が限られる 回避方法がある トリビアル サービスには影響しない 違和感はあるが、不便を感じない 回避する必要がない 複数のランクに該当する場合、より多く該当するランクに分類する。

    テスト書きすぎ問題を避ける - Qiita
    vanbraam
    vanbraam 2016/04/21
    たぶんこれ具体的な基準よりも,予めこの種の基準を設けてからテストを書く,という方針の方が大事だし役立つと思う
  • 再テスト工数を抑えられるテスト自動生成技術を富士通が開発、アジャイルに適用

    Fujitsu Laboratories of Americaと富士通研究所は、ソフトウエアの単体テスト(ユニットテスト)において、ソフトの改良や変更に伴う再テストの工数を減らせるテスト自動生成技術を開発した。バージョンの異なるオープンソースソフト(OSS)で検証したところ、従来技術と比較してバージョン変更に伴うテストコードの増分を1/24に抑えられたという。 頻繁に仕様の変更が発生するアジャイル開発にも適用しやすいテスト自動生成技術として、富士通の顧客向けアジャイル開発プロジェクトなどに適用した上で、2016年度中の実用化を目指す。 今回開発した技術では、ソフトの更新に伴う既存テストケースのコード変更を最小限に抑えることで、テスト結果の確認などにかかる手間を減らし、アジャイル開発にもテスト自動生成を適用しやすくする テスト自動生成技術とは、あるソフトウエアの関数やサブルーチンについて、ソ

    再テスト工数を抑えられるテスト自動生成技術を富士通が開発、アジャイルに適用
    vanbraam
    vanbraam 2016/03/31
    parameterizeするべき部分を自動で見つけ出すのか.ただテストは余り共通化すると情報のlocalityが低下し(framework化して)可読&可理解性が落ちるので,やりすぎると危険な気がする.テストコードこそ最も可読性が必要
  • たった1人から始める社内テストコード文化

    # -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================

    たった1人から始める社内テストコード文化
    vanbraam
    vanbraam 2016/03/16
    遅いテストは悪,というのは実感としてわかるのだが,ちゃんとテストしようと思うとどうしてもテストケース増→時間かかる,となる.この辺良いテスト並列化の仕組みがほしい;リリース優先=テスト書かない,は本当に悪手
  • マイクロサービス時代を乗り越えるために、Rack::VCRでらくらくアプリケーション間テスト - クックパッド開発者ブログ

    新規アプリケーションの構成 Rack::VCR リクエストの記録 リクエストのモック リクエストの再生 おまけ: Androidアプリのテスト 弊社での利用例 未来 こんにちは、会員事業部の小室 (id:hogelog) です。気づけば弊社に入社してから2年と2ヶ月が経っていました。 今回はその2年2ヶ月で初めて会社プロダクトを rails new したRailsアプリケーションと、そのアプリケーションで利用したRack::VCR (https://github.com/miyagawa/rack-vcr) について簡単に解説します。 新規アプリケーションの構成 今回私が新規に作成したRailsアプリケーションは仮にここではomoikane(仮)と呼ぶことにします。omoikaneはリクエストがあると社内の汎用APIサーバにアクセスし、APIサーバから取得した情報を元にレスポンスを返すアプ

    マイクロサービス時代を乗り越えるために、Rack::VCRでらくらくアプリケーション間テスト - クックパッド開発者ブログ
    vanbraam
    vanbraam 2016/03/03
    今一つメリットが理解できなかった.モックを簡単に作れるのは嬉しい事だが;サービス間連携のCIは実アプリをステージング環境にデプロイして実行するのが結局一番確実だと思う
  • 1