『龍が如く7』は進化を続け、自動バグ発見どころかほぼ全自動のバグ取りシステムを構築。これぞ無職から勇者に成り上がるデバッグだ！【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
本記事では、1日目におこなわれた『龍が如く7 光と闇の行方』（以下、『龍が如く7』）のデバッグに関するセッション“「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム”をリポート。 セッションには、セガのQAエンジニア・阪上直樹氏と、ビルドエンジニアの粉川貴至氏が登壇した。 バグをハグしたくなる自動システム！ まずは阪上氏が開発者たちへ向けて、「バグは好きですか？」という質問からセッションがスタート。最初に龍が如くスタジオの各タイトルで、バグを発見した数の推移が公開された。ゲームの規模が大きくなるにつれ、バグも増加傾向にあるという。 そして全自動バグ取りシステムを運用した『龍が如く7』では、なんと25000ものバグが発見されたという。こう見るとネガティブな印象を受けるかもしれないが、バグ発見数が多ければ多いほど、ゲームクオリティがアップするということだ。 バグとい
決め方を知らずに生じる無駄、ソフトウエアテスト実行の順番 | 日経 xTECH（クロステック）
ソフトウエアテストの実行がうまくいくかどうかは、いかに準備できるかにかかっている。予定した日までにきちんとテストを完了させるための、テスト実行の順番を決定する方法とスケジュール作成のコツを紹介しよう。 ワカテ：テスト実行準備は作業工数の見積もりまで終わりました。あとは何をすればいいのでしょうか。 センパイ：ここまで終わったら、次はテスト実行の順番を決定して、テスト実行スケジュールを作成するよ。 ワカテ：順番ですか？テストケースがあるので、上から順にやればいいと思っていました。スケジュールも改めて立てないといけないですか？ センパイ：そう簡単にはいかないんだ。上から順番にテストするだけだと、余計な手間がかかってしまう可能性が高い。テスト実行の順番の決定、スケジュールの作成にもノウハウが必要なんだよ。 テスト実行フェーズでは、テスト環境でテストケースを消化していく「テスト実行」の前段階として「
WebdriverIOでE2Eテストを行おう - freee Developers Hub
こんにちは こんにちは。人事労務freeeのアプリケーションエンジニアを担当しています、@futoase です。 今回の記事では、「WebdriverIOを利用し、E2Eテスト環境を整える」を目的に書き進めていきます。 WebdriverIO WebdriverIOは、Selenium WebDriverを利用したE2Eテストフレームワークです。Node.jsで作られています。Webアプリケーションだけではなく、mobileアプリケーションに対してもappium1を利用することでE2Eテストを実施することができます。 記事の記載内容について $ ls こちらの記載は、iTermやrxvtなどのターミナルにて入力したコマンドを指します。 この場合はlsとなります。$は、プロンプトの表示となります。 こちらの記事が公開された時点での情報のため、 閲覧日時によってはすでに古い情報の可能性がありま
State of Testing Survey 2018 | QA Intelligence
Sponsored by OF STATE TESTING Report | 2017 3 6 2 9 12 15 18 21 22 Share © 2017 - PractiTest & Tea-Time with Testers. All rights reserved. Sponsored by -2- 4 2017 QA 2016 60 1600 * 1600 State of Testing Survey Share © 2017 - PractiTest & Tea-Time with Testers. All rights reserved. Sponsored by Lalit & Joel 0.3% 1.5% 44.3% 4.2% 7.8% 8.6% 37% 44.3% * EU / 1.2% 4.3% 27.7% / -3- DevOps Share © 2017 -
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
テスターが要件定義のレビューからプロジェクトに参加する現実について｜Tsuyoshi Yumoto
最近、ソフトウエア開発にて、テスト技術者が要件定義からレビューに入る件について、いろいろ話を聞いたので、まとめておきます。 これは、ちょっとかっこよく言うと「Wモデル」という、テスト担当者の作業と開発の作業を同時並行で行っていくVモデルの進化した開発モデルが目指すゴールの一つです。ただ、話をしてくれた人は、Wモデルという言葉を知っているわけではありません。 その人の組織では、1980年代後半から、独立したテストを行っているとのことです。開発したものの統合テスト以後のテストだけを請け負うテスト専門部隊です。 Windowsが出る前はCOBOLで作った会計プログラムを対象にしていて、それがWindowsが出たころに全てWindowsアプリになり、それが今では全てWebアプリになり、クラウド上で動くようになっているという感じです。今では、そこの組織では、要件定義の段階からドキュメントをテストチー
納得できるテストをつくるアプローチ（JaSST'17 Kansai向け）
自信をもってプロダクトを送り届けるために、また、心配なステークホルダに説明するために、自分も相手も「納得できる」溜めのテストを考える、整理する方法を紹介してみます。
モダンなテスト管理プロセスのためにテスト管理ツール３つを比較検討したはなし | メルカリエンジニアリング
こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。 テスト自動化をすすめるにあたり、効率のよいテストを作るために、既存のテストケースについて調べる機会がありました。その過程で現状のQAプロセスも確認したのですが、以下のようなテストケース管理の課題があることがわかりました。 それぞれのテストエンジニアが、それぞれの方法で、それぞれのテストケースを管理しているため、ナレッジが横につながりにくい。 共有されているリグレッションテスト項目の更新が追いついておらず、情報が古くて使いにくい。 人数が増えてきて、ふりかえりや改善がやりにくい。 １については、現在、職能横断的なチーム構成になっているため、プロジェクトやプロダクトに集中できる環境である反面、それぞれのチームにいるQAエンジニアどうしのつながりが薄れてしまうことが原因に感じ
『本当にメンテナブルなSeleniumについて考えてみた』 参加レポート #selenium_cybozu - ブロッコリーのブログ
スライド speakerdeck.com 自己紹介 赤坂翔太 一休.com 宿泊事業本部宿泊システムチーム ここでいうテストって リグレッションテスト 予約・購入できないと甚大な被害 メンテナブルなSelenium＝PageObjectPattern？ 正解の一つ 本当に大事なことはリグレッションテストの自動化をより長く続けること 実装した後の運用が大事 一休のリグレッションテスト事情 30ケース8並列 実行時間 5~7分（本番環境） 8~10分（ステージング環境） PageObjectパターンで作成 メンテナンスデキる人が1人しかいない やったこと 全体向けに説明会 アウトプットは要所要所 自分でメンテナンスは我慢 開発フローに組み込む 全体説明会 Selenium WebDriverの概要 様々な環境での実行方法 Jenkinsからの実行方法 ChatOpsからの実行方法 Seleni
TestPyramid
The test pyramid is a way of thinking about how different kinds of automated tests should be used to create a balanced portfolio. Its essential point is that you should have many more low-level UnitTests than high level BroadStackTests running through a GUI. For much of my career test automation meant tests that drove an application through its user-interface. Such tools would often provide the fa
サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ
技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(本体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに本体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、本体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの本体アプリケーションや、新規にあるいは本体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この本体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに
Consumer-Driven Contracts: A Service Evolution Pattern
Since the original publication, there are some updates to this article. There is an updated version in the Thoughtworks Anthology and occasional blogs. Evolving a Service: An Example To illustrate some of the problems we encounter while evolving services, consider a simple ProductSearch service, which allows consumer applications to search our product catalogue. A search result has the following s
Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 元記事: Five ways to write a flaky test 原文公開日: 2016/10/21 著者: Kir Shatrov（@kirshatrov） 2017/05/08: 初版公開 2023/03/01: 更新 不安定なテストは、日々の苦労を台無しにしてくれる技術上の負債の一部となります。テストが不安定だとCIが赤信号になってしまい、それだけのために新しいコードのリリースを中断してビルドをやりなおすはめになります。実際のコードはどこもおかしくないのに、どこかがおかしいのではないかという疑念が湧くと、ストレスの元になります。 数百人の開発者と5万件のテスト項目があるような大規模案件1では、不安定なテストが混入する可能性がさらに高まります。 本記事で扱うデモの中には、テストの実行順序に関連するものもありますが、そうでないものも
Running Selenium with Headless Chrome
UPDATE: This article is updated regularly to reflect the latest information and versions. If you’re looking for instructions then skip ahead to see Setup Instructions. NOTE: Be sure to check out Running Selenium with Headless Chrome in Ruby if you’re interested in using Selenium in Ruby instead of Python. Background It has long been rumored that Google uses a headless variant of Chrome for their w
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
The Inquiry Method for Test Planning
Hi Anthony, Thank you for this comprehensive article around test planning and considerations for writing test plans. We should also consider the source document based on which the test plans are constructed. The source documents are usually functional specification documents. I have seen test teams lay more emphasis on the test plan templates and organization and tend to ignore the content within
Where do our flaky tests come from?
Interesting, yet not so surprising that larger tests are more flaky. Here are a couple of quick thoughts: 1) I'm not so sure that the linear trend is a good fit, given the large variance for larger tests (looks rather heteroscedastic to me). 2) It's surprising to me that very small tests (unit tests) are flaky. Is there a pattern in these small flaky tests? 3) The analysis of Android emulator is i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://alisterbscott.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/
WebdriverIO - Test Runner
WebdriverIO - WebDriver bindings for Node.js
