You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス(保守)が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 1つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理(例えば特定の URL に遷移する処理)の繰り返し実装するのを避けるために before and after
本記事では、Creative Content Lab Tokyo(クリエイティブコンテンツラボトウキョウ)が作成した結合テスト計画書のテンプレートをご提供しております。 テスト計画を立てたことがないという方もいらっしゃるかもしれませんが、この計画は品質に直結する内容となるため、なんとなくテンプレートに沿って、書いていけばよいと考えているかたは、要注意です。 非常に重要な作業となりますので、計画書の各章に記載すべき内容や何のための項目なのかをしっかり理解してから記述するようにしてください。 また、テスト計画書については、外部結合テスト以降の工程では、自社だけではなく他社も含めて検討するべき事項やお客様の運用を考慮した運用テストの内容なども盛り込んでいく必要があるため、しっかりとコミュニケーションをとって、抜けもれなく計画書に盛り込むようにしましょう。 結合テスト計画書(章立て) 今回は、結合
一般的にはどうなのか?が気になる人は後半にある「一般的には(参考)」に先に目を通してもらったほうがいいかもしれません。 サンプルダウンロード サンプルのダウンロードはこちらから。 作成してみる では、作成していきましょう。 作成方針・ポイント 内容としては、まずテストのサマリを報告し、必要に応じてそれぞれのテストの詳細やエビデンスを記載するのが一般的かなと思います。 構成(目次)を考える 今回は下記のような項目を記述してみました。 テスト結果 全体サマリ 機能テスト:単体テスト結果サマリ 機能テスト:結合テスト結果サマリ 非機能テスト:全体サマリ エビデンス(各テスト) 記述例(サンプルから抜粋) では、サンプルの主要なページについて少し解説したいと思います。 表紙 特に補足はありません。 目次 こんな感じ。 テスト結果 全体サマリ まず、テスト計画で実施を定義したテスト全体の結果をサマリ
10月のアップデートで機能が複数追加されたようなので後ほど追記しておきます。 概要 今までテスト管理をExcelやスプレッドシートで行っていたのですが、そろそろスプレッドシートの管理に限界が来ていると思ったのでテスト管理ツールをプロジェクトに導入したいと思ってきました。 自分が入る前はそもそもテスト仕様書すら作っていなかったので作るよう運用変更した ツール選定 自分が以前いた会社ではExcelで管理していたのでテスト管理ツールの知見が全くなく、また周りの方に相談してもスプレッドシートで管理していたりテスト仕様書すら作っていない有様していたのでしょうがなく自分で調査しました。 探している最中にちょうどスタートアップや小規模チームのテストケース管理には「Qase」がいいかもしれないの記事を発見したのでQaseを使ってみることにしました。 Qaseの使い方 Qaseを使ってみたので各種ケースに応
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか?という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか?組み合わせテスト技法と上手に付き合う方法 | DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか?条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
きっかけ あるとき、○○ちゃんに、「SQLの単体テストケースってどうやって考えればよいの?」と問われ、「うっ」となりました。 SQLの単体テストケースの考え方 そんなことも答えられないのに、「網羅的なテストぉー!」だとか、「カバレッジはどのくらいを狙っているの?」などと偉そうに言ってきましたが、なんとなくを整理して、改めて理解してみます。 どこから手を付けるか? テスト対象はDDLなのか、DMLなのか。日常よく使うSELECT文を単体テストケースの考え方の対象とします。SELECT文を概念的に(内部実装は置いといて)、「1.構成する要素(○○句)と実行順序」、「2.その要素の挙動」に整理、理解して、「3.単体テストケース」を考えます。 調査 書籍「プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに」をメインにSELECT文の実行順序と挙動を調査。 SELECT文の挙動調査元ネ
概要 試験工程をスプレッドシートで管理していたがそろそろ脱却したいと思ったので色々探してみました。 すると、同じことを考えている先駆者さんがいらっしゃったので参考にさせていただきました! 導入に至った経緯 QA体制が未成熟 3名までなら無料で利用できる テスト計画・テスト結果をエクスポートできる 入力項目が整理されているので試験表の質を一定にできる 自動化したテストケースを管理できる 手動テストと自動テストの結果を併せて一覧できる APIにより自動テストの実行結果を自動的に反映することができる etc これは、中々良いツールなんじゃないか!? ということで導入してみました 実際の導入方法を説明していきます 事前準備 以下からサインアップしてください サインアップ完了後、ダッシュボードに遷移した状態からスタートとします それぞれの設定方法は以下を参照してください 新しいプロジェクトを作成 プ
最近、golangでプログラムを書く機会が増えてきた。golangでTDDをする場合、標準のtestingパッケージを使うのが一般的なようだ。ただし、標準パッケージだけだとちょっとテストが書きづらいので、stretchr/testifyを使っている人も多いと思う。 関数のテストをしたいときは標準パッケージなりtestifyを使うなりで良いのだけど、振る舞いをテストしたい、つまりBDDをしたいなーと思った時にちょっと調べらたらGinkgoというのが良さ気だったので、ちょっと試してみる。 Ginkgoとは 表現力があって包括的なテストを効率良く書くためのBDDスタイルのテストフレームワーク。GomegaというMatcherライブラリと併用すると良い感じらしいけど、単体でも充分使えるらしい。 今回はドキュメントに従い、GinkgoだけでなくGomegaもインストールした。 インストール go g
Firestoreのセキュリティルールをテストする方法としてコンソールから使えるシミュレーターが以前からありましたが、今回発表されたのはローカルで実行できるエミュレーターです。 これを使えば、CI上でセキュリティルールのテストをルールをデプロイせずにできます。 試した環境は firebase-tools 6.0.1です。 最初は6.0.0で試してみたのですがどうやら日本語環境ではエミュレータがエラーになるようで6.0.1で一旦デフォルトで英語になるように修正されました。 ローカルエミュレーターローカルエミュレーターはFirebase Summit 2018で発表された手元の環境でFirebaseのデータベースであるRealtimeとFirestoreのセキュリティルールをテストすることができます。 今までセキュリティルールをテストしようと思うとコンソール上のシミュレーターで手動でテストをす
はじめに こんにちは。NIKKOエンジニアのS.TKです。 皆さん、テストはしていますか?最近の開発手法であれば、ほぼ確実にテストが考慮されているので嫌でもしていますよね。ただ、テストって実は結構難しかったりします。特にテストコードを書くとなると、プロダクトコードの設計によってはかなり苦労させられます。 そこで、今回はユニットテスト(単体テスト)に焦点を当て、テストコードを楽に書くためにMock(モック)を利用する方法をご紹介します。私はGMO MARS DMPの開発・運用を担当していますが、今回ご紹介する内容は普段の業務で実践している内容になります。 言語はJavaで、テストフレームワークはJUnitを使うことにします。 ユニットテストを書こう まず最初に、ユニットテストを書くことの意義について再確認してみたいと思います。今更感がすごいですが、ちょっとだけお付き合いください。 一番期待さ
単体テスト 結合テスト システムテスト(機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト(シナリオテスト) 運用テスト 現場(案件)によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト(Integration Test)以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く