並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 4 件 / 4件

新着順 人気順

テストファーストの検索結果1 - 4 件 / 4件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

テストファーストに関するエントリは4件あります。 テストarticleマイクロサービス などが関連タグです。 人気エントリには 『マイクロサービスの開発とテストファースト/テスト駆動開発 【Mercari Gears Lecture Series】 | メルカリエンジニアリング』などがあります。
  • マイクロサービスの開発とテストファースト/テスト駆動開発 【Mercari Gears Lecture Series】 | メルカリエンジニアリング

    こんにちは、Mercari Gears事務局です! この記事では、動画公開以来とても反響のある Mercari Gears Lecture Series #47〜#49「マイクロサービスの開発とテストファースト/テスト駆動開発」の動画の内容を記事に起こしたものです。 今回の実際の動画はこちらになります、興味があればぜひご覧ください! MERCARI GEARS Lecture Seriesとは? MERCARI GEARS Lecture Seriesは、株式会社メルカリをはじめとするメルカリグループ各社が、これから目指す方向や、これから取り組む技術的なチャレンジについてご紹介するエンジニア向けのレクチャー動画シリーズです。 MERCARI GEARS Lecture Series お話する人の自己紹介 株式会社メルペイ 柴田芳樹 九州工業大学 情報工学修士 1984年 富士ゼロックス 入

      マイクロサービスの開発とテストファースト/テスト駆動開発 【Mercari Gears Lecture Series】 | メルカリエンジニアリング
    • 第9回 テストファーストな管理で、品質を落とさず素早くソフトウェアをリリース(前編) | gihyo.jp

      テストで行うおもなプロセス 今回からは4回にわたって、ソフトウェアテストを進めるにあたって考えることを取り上げていきます。ソフトウェアテスト(以下、テスト)は、ソフトウェアの欠陥を見つけ品質を評価する大事な作業です。まず、テストはどのように進めていくかおさらいしてみます。 テストの開始から終了までのおもな活動について、ソフトウェアテストライフサイクル(Software Test Life Cycle:STLC)と呼ぶテストプロセスでは表1のように定義しています。STLCのプロセスはどれもテストを進めるために必要な活動だと思います。テストを実行することはもちろん、何をどのようにテストするか計画を立てなければテストは進められませんし、テスト結果を分析・評価しなければソフトウェアがリリース可能か判断できないからです。ですがこのプロセスどおりにテストを愚直に進めようとすると、筆者には「⁠“⁠要件定

        第9回 テストファーストな管理で、品質を落とさず素早くソフトウェアをリリース(前編) | gihyo.jp
      • 第10回 テストファーストな管理で、品質を落とさず素早くソフトウェアをリリース(後編) | gihyo.jp

        前編ではソフトウェア開発のボトルネックになりがちなソフトウェアテスト(以下、テスト)を変えるプラクティスとして、「⁠テストファースト」と「継続的テスト」を提案しました。後編ではテストを継続して実施するための基盤となるテスト管理ツールを紹介します。 Excel・スプレッドシートを使ったテスト管理の限界 筆者自身、テスト管理にはExcelのようなスプレッドシートを使っていました。テストケースをマトリクスやリストで作りそれらのテスト結果を記入するのに適していましたし、またテスト結果を参照してグラフなどの統計情報を作ることもできます。必要であれば、画面のキャプチャをエビデンスとしてシートに添付することもできます。単純にテストを設計し、テスト結果を記録し、分析レポートを作るのであればスプレッドシートを活用することはとても便利でした。 ですが、ソフトウェアのリリースまでの期間が短くなり、テストファース

          第10回 テストファーストな管理で、品質を落とさず素早くソフトウェアをリリース(後編) | gihyo.jp
        • rswagを使ったテストファーストなAPI開発のフローを確認する - Qiita

          今回のゴール チーム開発に必要な API 仕様をコードと乖離せずメンテナンスしていくフローの検討です。 rails で API を作る場合、controller にメソッドを定義してルーティング設定するだけで簡単にできますが、 チーム開発等ではフロントエンジニアにソースを確認してもらうのは現実的ではないため、その API の仕様をドキュメントで共有するかと思います。 方法としては swagger.yaml を書いて swagger ui で確認するというのがあります。 ただし swagger の書き方は若干慣れが必要ですし、API が修正されると実態とずれてしまうリスクがあります。 そこで rswag という rails で spec をかけばそれをもとに swagger.yaml を生成してくれる gem を使えば問題が解決するのではと考えました。 ここではその手順を記録していきます。

            rswagを使ったテストファーストなAPI開発のフローを確認する - Qiita
          1

          新着記事