ソフトウェアテストシンポジウム 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](https://cdn-ak-scissors.b.st-hatena.com/image/square/a0e7b168c14704a08805d332d8bb5b4e6e5b7b1e/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff22418e4e950449a8dda5db671d730ff%2Fslide_0.jpg%3F16399205)
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日(月) http://www.jasst.jp/symposium/jasst20niigata.html
メルカリWeb版のUIテスト自動化で目指している世界と、そのために作った Selenium Grid・Zalenium 環境 on Azure Kubernetes Service(AKS) メルカリの自動化&品質保証グループ(Automation & QA Group:通称AQA)の 根本 征 です。 私は普段、テスト自動化・CI / CD 改善・その他社内の生産性を上げるための自動化を行っています。 今回は、最近私たちが行なっているメルカリWeb版のUIテスト自動化と、その自動テスト環境についてご紹介したいと思います。 メルカリWeb版のUIテスト自動化について UI自動テスト環境に関する課題 Selenium Grid を Azure Kubernetes Service(AKS) 上で構築する Zaleniumを試す Azure Kubernetes Service(AKS)で受け
2018年は公私ともに忙しい年でした。このエントリを書いている時点でもう年が明けてしまいましたが、1年のふりかえりとして、またある種のポートフォリオとして、1年間のアウトプットをまとめたいと思います。 手元のスケジュールを確認したところ、講演/ワークショップを53回、インタビュー/対談/Podcast出演を5回、社内読書会ゲスト参加を3回、執筆、増刷作業を6回、主要OSSプロダクトのリリースを3回行っていました(小さなモジュールはカウント外)。これらが2018年のアウトプットです。 新作登壇(6回) 私は再演が多い講演者で、登壇依頼のほとんどは既存の講演/ワークショップの再演です。それでも2018年に新しいテーマの講演をいくつか行いましたので、それら「新作」がアウトプットの筆頭となるのではないかと思います。 技術選定の審美眼(2月15日) 2月15日に「技術の進化の歴史は振り子ではなく螺旋
先日、WebExtensions Meetup #3 が開催され、そこで「WebExtensions とテスト」というお話をしてきました。 この発表では、 WebExtensions のテストの方法と、Vim Vixen が取り組んでいることについてお話しました。 WebExtensions とテスト - Speaker Deck この記事では発表資料をかいつまんで、より詳しく説明してゆきたいとおもいます。 それでははじまりはじまり〜。 はじめに まずは自己紹介。 WebExtensions 歴は 1 年ちょいです。 メインで開発してる WebExtensions は「Vim Vixen」です。 Vim Vixen の開発をスタートしたきっかけは、XUL 製だった Vimperator が使えなくなったからです。 開発を始めて 1 年が経ち、現在はユーザー数も 10,000 を超えるほどに
iOSDC Japan 2018 で、ベストトーク賞2位をいただきました。タイトルは「iOSアプリの開発速度を170%に向上させたデバッグノウハウ」です。この記事では、スライドの紹介に加えて、スライドに書ききれなかった背景やレビュー体制などについてお話ししようと思います。 発表スライド スライドでは語られていない発表の目的 この発表は少し特殊な構成で組まれています。発表内で繰り返し出てくる「動作確認の自動化」とは、実のところ「テスト」のことです。しかし、私はこの発表でなるべく「テスト」というキーワードの使用を避けました。 この背景には、iOSDC ではテスト関連の CfP が通らないという経験則があります。私はこの原因を CfP 選考に関わる方たちに次のような人が多いからではないかと推測しました: テストをやったことがなくて興味がない テストに嫌な体験がある そこで、上記のような方にも受け
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類(small / medium / large)に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
テスト自動化の理論と技術と戦略:LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET(Software Engineer in Test)です。「SETタスクフォース」(以下「SETチーム」と表記)のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET(Software Engineer in Test)の伊藤 宏幸(Hiroyuki Ito)です。 2018年6月27日(水)に、電気通信大学の西 康晴さん(以下「にしさん」と表記)をお招きして、「
テスト書くのが当たり前、だけど・・・和田:次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
Qiita 週間ランキング1位を獲得しました Kuniwak です。ご愛顧ありがとうございます。 qiita.com さて、本題に移りたいと思います。 つい最近ですが、勤め先の別チームに向けて自動テストの導入を支援するための資料を作成しておりました。こちらを共有したいと思います。 speakerdeck.com 資料中にある「仕様化テストを推奨しない」という決断には賛否両論あるかと思います。仕様化テストを推奨しなかった理由は、仕様化テストにかかるコストは相当に高く、本当に余裕があるときでないと選べない選択肢だったからです。今回自動テストを導入しようとしているチームは、見るからに余裕のない状況だったので仕様化テストからやれとは言えませんでした。 もし、「自分だったらこうする」等のアドバイスがあれば、ぜひ参考にしたいと思います。コメントなどに書いていただけると嬉しいです。
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした: 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く