タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;
ソフトウェアテストに関する知識をもう少し言語化したいなと思い、「はじめて学ぶソフトウェアのテスト技法」を読んだ。 はじめて学ぶソフトウェアのテスト技法 作者:リー コープランド日経BPAmazon この本では主に良いテストケースの作成手法について学べた。良いテストケースとは「最小の時間と労力でほとんどのエラーを検出する可能性がもっとも高くなるようなテストケース」のこと。これにできる限り近づけられるようにテストケースを工夫する。 良いテストケースを作るためにどういう技法があるかをこの本はいくつも教えてくれる。自分がこれまでテストを書いていると「こういうテストの方がなんとなくベターだよな...?」みたいに感覚的に考えていたところを、言葉として定義してくれることで構造化できるのはありがたかった。たとえば 同値クラステスト 同じグループのテストが、以下を満たせば同値クラスを形成する 同じ機能をテス
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
入社1ヶ月目でやったこと 〜ソフトウェアテストプロセスに基づいたテストケース作成を行ってみた〜 - ブロッコリーのブログ
はじめに この記事は10X 創業6周年アドベントカレンダーの15日目の記事になります。 昨日はアプリケーション開発部のjojoさん*1が、「10Xに入社した、そして4ヶ月後…」という記事を公開しています。 本記事では2023年5月に10Xに入社した私が、入社1ヶ月目に実際に行った、ソフトウェアテストプロセス（以下、テストプロセスと表記）に基づいたテストケース作成についてお話しします。 目次 はじめに 目次 テストプロセスに基づいたテストケース作成を行おうとしたきっかけ 前提：プロセスとは何か？ プロセスの例 テストプロセスを考えよう 今回定義したテストプロセス テスト分析 テスト対象分析 テスト要求分析 テスト設計技法の選択 テスト設計 テスト実装 記事冒頭の例が分かりづらかった理由 実際に適用した例 レビュー内容 今後の展望 おわりに テストプロセスに基づいたテストケース作成を行おうとし
Notion AIを用いて機能仕様書からテストケースを自動で作成した話 - Commune Engineer Blog
はじめに コミューンでQAをしています金丸です。 最近QA界隈でAIを用いたソフトウェア開発が注目を集めています。 www.kzsuzuki.com 多くはChatGPTを用いたものですがちょうど先月にNotion AIがリリースされたので今回Notion AIがソフトウェア開発のテスト部分に対して有用に使うことができるかについて記事を書いていきたいと思います。 結論から言うと、実用としての運用は未だ難しいがQAの補佐的な位置付けとしては十分な働きをしてくれることがわかりました。 はじめに NotionAIとは 機能仕様から同値分割・境界値分析・フローチャートを自動で作成 機能仕様の修正もNotionAIにやっていただいた 終わりに NotionAIとは NotionAIは、Notion Labs, Inc.によって開発された人工知能モデルです。個人や仕事に関するタスクの作成、整理、管理を
テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
以下のイベントの投影資料です。 https://d-cube.connpass.com/event/187308/ お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料内にあるURL】 ▽P2：書籍『Agile Testing Condense…
Goのテーブル駆動テストではテストケースの定義位置を知りたいのでライブラリを書いた - 詩と創作・思索のひろば
Go言語でテストを書く際のベストプラクティスとして、テーブル駆動テスト（Table dirven tests） というのが推奨されている。ようはデータとふるまいを分離しましょうという話で、正直わざわざ名前をつけるようなものでもなかろうという気持ちもないではないが、まあ話がはやくていいね。 けどみんなほんとにこれで満足してるの？ と疑問に思うところはある。テストが落ちたときに表示される行番号がテストケースによらず一定で、どのテストが落ちたのかを探すのに一手間かかってしまう。 たとえば以下のコードをテストする際、 package eg import "testing" func TestExample(t *testing.T) { testcases := []struct { name string a, b int sum int }{ {"1+1", 1, 1, 99}, {"2+2"
この記事はモバイルファクトリー Advent Calendar 2020 7日目の記事です。 こんにちは、ブロックチェーンチームのソフトウェアエンジニア id:odan3240 です。湯船に浸かるのが楽しい季節になってきました。 以前テストに関するこの記事が話題になっていて、読んだときに最後の部分が目に留まりました。 blog.sushi.money テストを先に書いてから実装を書くか、先に書いた実装のテストをあとから書いているか、という場合でも違いが出てきそう。 以前までの自分は先に実装を書いてからテストを書くことがほとんどでした。理由としては、性格的にコードを書くのが好きで、頭の中にあるコードを急いで書き出したくなるため、作業に入ると先に実装を書いていました。 しかし、開発時に実装より先にテストケースから書き始めるとうまく実装が進むことに気付いたので、共有します。 割り算を行う関数 d
LINEが定期的に開催する、Kotlinをテーマにした技術者向けのミートアップ「LINE Developer Meetup for Kotlin」。今回は「LINEにおけるServer Side Kotlinの導入事例と開発裏話」をテーマに開催します。ここで登壇したのは、「Messaging API」のサーバーサイドを開発している川田裕貴氏。システムの改善における取り組みについて発表しました。全2回。後半は、「Messaging API」のテスト環境について。前回はこちら。 End to EndでテストができるテストケースをKotlinで書いている 川田裕貴氏：前半はMessaging APIの話をしてきましたが、後半はちょっと話を変えます。Messaging APIの中ではテストをいろいろ動かしているのですが、テストケースも全部Kotlinで書いています。普通のユニットテストではなく、E
pytest でテストケース毎に DB を自動的に初期化して、テスト開発体験を向上させる - SalesNow Tech Blog
概要 Web バックエンドのテストコードを書く場合、その多くは DB に依存していることが多いです。 DB 関連のテストは、テストデータの準備やテストケース毎の DB 処理化を適切に行うことが重要ですが、手間がかかる場合あるため、Mock で擬似的にテストしてしまうことも多いかと思います。 ただ、Mock を使ったテストは本質的な問題を検知できない意味のないテストになってしまう可能性があり、可能な限り DB の Mock を行わずに、実際の DB を使用してテストすることが望ましいと考えています。 本記事では、pytest、sqlalchemy、PostgreSQL を使った場合に、テストケース毎に DB を簡単に初期化しつつ、テストケース毎の前提データ登録も簡単うことでテスト開発体験を向上させる方法を紹介します。 前提環境 本記事では、以下の環境を前提として説明いたします。 python
はじめに 本記事は、ソフトウェアテストの小ネタ Advent Calendar 2022の19日目の記事です*1。 本記事では、テストケース*2で具体的な代表値を使うときに気をつけている「2以外の一意の素数を使う」という方針について書きます。なお、この方針は私の個人的経験及び主観に基づいたものです。「必ずしもこのやり方が正しい」と主張したい訳ではないことをご了承ください。 記事では、この方針をさらに「2を使わない」「一意の数を使う」「素数を使う」の3つに分割して説明します。 目次 はじめに 目次 テストケースの具体的な代表値に2を使うのを避ける テストケースの具体的な代表値は一意の数を用いる テストケースの具体的な代表値に素数を用いる 注意：今回の考えはあくまでも代表値の場合の話です おわりに 補足：厳密な素数を選ぶわけではない 1. 「691」という数字が素数であるか判断が難しいため 2
Goによるrsc.io/scriptパッケージを用いた独自スクリプトでテストケースを記述するテスト手法紹介 - tomato3713’s blog
本記事は、はてなエンジニア - Qiita Advent Calendar 2024 - Qiitaの11日目の記事です。昨日は、 id:Windymelt さんの esbuildでScala.jsをビルドして呼べるようにするプラグインを作った話 - Lambdaカクテル でした。 Goでユニットテストを書くときは、Table Driven Tests が頻繁に使われています。Table Driven Test によって一定程度読みやすいテストコードを書くことができますが、入力の数が多かったり比較項目が複雑になるとアサーション部分で条件分岐が起きてしまい書きにくくなることがあります。 そこで柔軟にテストケースを記述できる script-based test cases を導入したテスト手法を紹介したいです。 script-based test cases とは、 research!rsc:
ペアワイズ法(またはオールペア法)という、パラメータが多いテスト対象のパラメータをいい感じに生成してくれる手法と、その考えをもとにパラメータを生成してくれるPICTというコマンドラインツールがあります。 今回はそのPICTをEmacsから使うパッケージを作ってみたよというお話をしましょう。 Emacs 29以降を使っていればインストールはめちゃくちゃ簡単。 この式を評価するだけでおしまいです。 PICTコマンドは別にインストールする必要がありますが、macOSユーザーなら brew install pict だけで入ります。他のOSのユーザーは各自適当にぐぐってインストールしておいてください。 ペアワイズ法について どんなときにペアワイズ法とPICTが役に立つかは、Web上に情報があるので各自お読みください。 筆者はテストとか詳しくない… 俺たちはプリキュアで学んで雰囲気でPICTを使って
AIにコード書かせるとき、テストケース渡しておくと確実なんじゃないかという仮説の話→「テスト駆動開発」「AIへの指示の仕方が重要になりそう」
しのゆー𝕏酒クズエンジニア @shinoyu そういえばふと思ったんだけど、AIにコード書かせるとき、テストケース渡しておくと確実なんじゃないかと思った。テストケースはいわば完了条件。 まずはテスト仕様書食わせてテストコードを作成させて、後はこれ通るように実装してね、って渡せばかなり精度の高いアウトプットが得られるんじゃないか説ある どこかで試すか 2024-06-26 17:37:06
ホワイトボックステストにおけるカバレッジとテストケース(C0, C1, C2, CDC, MC/DC, MCC) - ろぐれこーど
ホワイトボックステストでよく用いられる網羅率(coverage)について、違いがよくわかっていなかったためまとめてみました。間違いあれば更新します。 網羅率(coverage, カバレッジ)とは カバレッジ基準 命令網羅 : statement coverage (C0) 判定条件網羅 : decision coverage(C1) 条件網羅 : condition coverage(C2) 判定条件/条件網羅 : condition / decision coverage(DC/CC, CDC) 改良条件判定網羅 : modified condition/decision coverage(MC/DC) 複合条件網羅 : multiple condition coverage(MCC) 経路組み合わせ網羅 : path coverage まとめ 参考 網羅率(coverage, カバレッ
「テストケース数やバグ検出数は妥当？」こんな悩みをゾーン分析で解決してみた - asoview! Tech Blog
はじめに こんにちは、アソビューでQAエンジニアを担当しております、石川和尚です！ 私は主に品質改善プロセスの立案やテスト設計、実行を担当しており、テストの効果的な実施と品質向上に向けて日々取り組んでいます。 その中で、今回はテストの妥当性評価について焦点を当てていこうと思います。 テストの妥当性評価とは、テスト活動が製品の品質評価に対してどれだけ効果的で信頼性があるかを確認することです。しかし、適切なテストケース数やバグ検出数が見えてこないと、やみくもにテストケース数を増やすことになり、リソースを無駄に消費する恐れがあります。また、必要な不具合が十分に発見されているかを評価する基準がない場合、テスト後も潜在的なリスクが残っているのではないかという不安がつきまといます。このような課題に直面する中で、プロジェクトごとに適切なテストケース数やバグ検出数を導き出す方法が求められていました。 これ
ソフトウェアを開発するときは、テストケースが重要になってきます。この記事をお読みの方はまさに今、テストケースの設計にお悩みかもしれません。私はこれまでウェブエンジニアとしてソフトウェアの開発に携わってきました。この経験をもとに、テストケースとは何か、作り方や書き方、項目の洗い出しについて解説します。 この記事は、ソフトウェアのテストケースを設計する方、特にテストケースの設計経験が少ない方を対象としています。また、私はウェブエンジニアなので、その文脈でまとめています。テストケースを設計するときの参考になればうれしいです。
AIソリューション ソフトウェアテスト・ 品質保証 セキュリティ UI/UX DX カスタマーサクセス コンサルティング Our Services サービス AIソリューション
こんにちは！チケット領域でQAを担当している青柳です。 今回は、生成AIを活用したテストケース作成の事例を紹介させていただきます。 現状のテスト設計における課題 課題解決のために 生成AIにテストケース作成を任せてみた どの部分を切り出してテストケース作成させるのが効果的か 因子間の組み合わせテスト デジションテーブルのテストケース作成 成果・今後に向けて 最後に 現状のテスト設計における課題 ソフトウェア開発において、テスト設計は重要な工程であり、品質を保証するために欠かせない部分であると思います。しかし、テストケースの作成には時間と手間がかかるため、効率的で精度の高い方法を検討しなければ、日々成長するプロダクトの品質担保・精度向上が難しくなってきてしまうと感じていました。 課題解決のために 自身の課題でもあったテストケース作成工数、精度向上を図るため、近年話題となっている生成AIを活用
0.はじめに テストとは、責任追及から逃れるための証跡 である。 普段から、質の良い証跡・アリバイ作り を心がけましょう。 本記事では、やるべきことはやった を論理的・機械的に示せる、テストケース算出手法 を紹介します。 1. テストケース設計の重要さ ソフトウェア開発におけるテストの手段は、年々高度になっています。 特に、単体テストやE2Eテストといった工程では、フレームワークや自動化ツールの進化によりテストを「どう実行するか」の部分が格段に効率化されました。 しかしその一方で、「何をテストするか」という根本的な問い、すなわちテストケースの設計は、いまだに人間の経験と勘に依存しているケースが多いです。 これは属人的であるがゆえに、漏れや責任問題につながりやすい領域でもあります。 脳死である程度のカバレッジを担保できる設計手法があるのであれば、それを使わない手はありません。 本記事では、こ
APIテスティングツールに必要なのはテストケースごとのIDなのではないか #cicd_test_night - Copy/Cut/Paste/Hatena
先日、機会をいただきましてCI/CD Test Night #7でAPIテスティングツール*1を開発している中で考えていることをお話しさせていただきました。 testnight.connpass.com 詳細はスライドをご覧ください。 speakerdeck.com APIテストはスモールテストと比べて効果は大きいがコストも大きい 私はAPIテストの一番の課題はこれだと思っています。 APIテストは、「APIに対してリクエストを投げてそのままテストする」というわかりやすさがあります。 また、テストあたりにおけるカバレッジの広さというメリットもあります。 なので、できればデメリットであるコストの大きさをなんとかしたいわけです。 この課題の解決には2つの方法があります。 コストを小さくする 範囲を広げて効果を大きくする 先に、範囲を広げる方法について考えると 作ったテストをそのまま負荷テストに
概要 cypressを初めて使う筆者が cognitoを認証基盤に利用するwebアプリに ログインするテストケースを作った際にハマったポイントまとめ 先に結論 ここのコードに解決策が全部入ってるからこれ見ればok https://gist.github.com/vittorio-nardone/a9b388ff7388a4ae7343cd6a2758bc4b 背景 最初、cypressをcognitoに使った事例探したらクラメソさんの記事があって、 https://dev.classmethod.jp/articles/amplify-console-cypress/ 助かったー、と思いつつ参考にして実践してみたがだめだったので、色々と試行錯誤した軌跡 ハマったポイント セレクタで入力フォームを取得できない ログイン画面を表示させて、inputタグに入力すべくセレクタで指定したが、見つから
Google Chrome+QualityForwardでテストケースを多言語化 - ANDPAD Tech Blog
ごあいさつ アンドパッドのQualityControlの冨士川です。 入社して2年半経過し、現在はQCチームのリーダーやっています。 道の駅をめぐることにハマっていて写真は千葉県館山市の道の駅「“渚の駅” たてやま」の「さかなクンギャラリー」で撮った写真です。魚魚魚～！ ※QualityControlについては弊社のTech Blogをお読みください この記事の目的 皆さん、海外メンバーと開発する時にテストケースの翻訳はどうしていますか？ 「Google Chrome」とテスト管理ツール「QualityForward」を組み合わせて使ったところ、 簡単にテストケースを多言語化できたのでご紹介します。 テストケースを多言語化した背景 弊社はベトナムにグループ会社「アンドパッドベトナム」があり、ベトナムメンバーと連携してQC活動を行っています。 日本メンバーがテストケースを作成し、ベトナムメン
【QAチームブログリレー4日目】 こんにちは！ エムスリーエンジニアリンググループ QAチームの城本（@yuki_shiro_823）です。普段は担当しているBIR（Business Intelligence and Research）チームで品質向上のためにあれこれしています。 今回はE2Eテスト自動化サービスmablを利用してテストケースを作成・運用していく際に、レビュールールを作った話を紹介します。 前提 ルールの必要性 ルールの作成プロセス ルールの詳細解説 命名規則 作成上のルール レビューフローのルール ルールの運用と効果 まとめ We're hiring！ 最近撮った雨の日のアジサイ。スマホカメラにしてはうまく撮れて気に入ってます 前提 エムスリーではテスト自動化にローコード自動化サービスmablを利用しています。 mablとはブラウザの操作を記録することにより、ローコードで
Gradle経由でのテスト実行時、コンソールに失敗したテストケースの情報を出力する - たごもりすメモ
`./gradlew test`とか`./gradlew build`とかしたときに失敗したテストの情報はこの`index.html`を見てね! っていうのがめんどくさくて、なんでデフォルトで失敗したテストの情報を出してくれないんだっけ、と思っている人、主に俺の問題を解決する。 ていうかデフォルトでそうしてくれればCIサービスの設定時にテスト結果の保存とかを個別にやらないと何が失敗したかもわかんなくなってて困る、みたいな状態にならなくてすむのにね。 調べてたら「とにかくコンソールに全部出したい!」みたいなのがいっぱいひっかかるけどそうじゃないんだよなー、そういうのはtoo muchなんだよ。 で、これ。 stackoverflow.com のうち一番下の回答(TestLoggingを使う)が簡単に調整できそうだったので、手元プロジェクトで以下のようにした。Kotlin DSL使ってるんで`
AIソリューション ソフトウェアテスト・ 品質保証 セキュリティ UI/UX DX カスタマーサクセス コンサルティング Our Services サービス AIソリューション
こんにちは。株式会社プラハCEOの松原です TL;DR デキる人は完成形を見せてから詳細を進めていく 30%ぐらい完成したタイミングで完成イメージを一度見せて、齟齬がないことを確認すると良い コードも完成イメージを一度レビューしてもらってから細部を実装した方が良いのではないか テストケースだけ先に見てもらうと良いんじゃない？ 仕事がデキる人はなぜ〇〇なのか 「仕事がデキる人はなぜ〇〇なのか」みたいなビジネス書によく書いてあるテクニックがあります。それは 頼まれた仕事は30%ぐらい完成したタイミングで一度依頼主に見せて、認識齟齬がないことを確認すること よく出てくるのがプレゼンの例です： 仕事がデキないパターン 上司「今度の企画案を部長に説明するためのプレゼンを作っておいてくれ。プレゼンは1週間後ね」 部下「わかりました！」 〜1週間後〜 部下「できました！」 上司「なにこれ！全然思ってたの
RSpecでは、before do ... endを使うことで、各テストケースの前に共通して行う処理を記述できる。これを使ってテストデータを投入する処理などを書いておくと、テストケースが書きやすくなる。 しかし、例えばデータが1件もない状態での挙動をテストしたいときなど、一部のケースではbeforeをスキップしたいという場合もある。そのための直接の機能はRSpecにはないが、以下のようにすると実現させることができる。 describe 'test_case' do before do |example| unless example.metadata[:skip_before] ... end end context 'condition A' do it 'needs before procedure' do # beforeが実行される ... end it 'not need bef
Notionだけで、初めてのテスト仕様書~テストケースを作ってみる - Uzabase for Engineers
こんにちは。ソーシャル経済メディア「NewsPicks」でエンジニアをやっております、崔（ちぇ）です。最近では検索だけではなくもっと広範囲にシステム開発に携わっております。今日はQAエンジニアではない私が、初めて総合テストを設計段階からチャレンジした話をしてみようと思います。 弊社は社内ツールとしてNotionを利用しており、最初から最後までNotionだけを使うという試みをしてみました。総合テストの設計が初めての方はもちろん、Notionの活用事例が気になる方も読んでいただけると幸いです。 この記事はNewsPicks Advent Calendar 2024の13日目の記事です。昨日は桐畑さんによる 「システム障害を素早く解決するための考え方・工夫について」でしたので、ぜひ一緒に読んでみてください！ tech.uzabase.com NewsPicksの動作を担保するテストケースを作る
【FastAPI】テストケース毎に独立したDBデータを使用する（GitHub Actions付き） - Qiita
ORMと連携した機能のテストを行う際、テストケース(= テスト関数)毎にクリーンなデータベースが欲しい（テストケース間の依存関係が生まれてほしくない）。 この点についていい感じの方法が実現できたためご紹介する。 参考（一部重複内容あり） FastAPIでテスト用のクリーンなDBを作成してpytestでAPIのUnittestを行う 本記事のソースコード：skokado/fastapi-tutorial 環境 Python: 3.8 fastapi==0.68.2 SQLAlchemy==1.4.25 SQLAlchemy-Utils==0.37.8 pytest==6.2.5 factory-boy==3.2.0 アプリケーション準備 ユーザ認証とブログ管理を行う簡単なアプリケーションを用意する。 ※アプリケーション本体のコードは割愛するためリポジトリを参照 ※ディレクトリ構成 . ├──
chokudai(高橋 直大)🍆@AtCoder社長 on Twitter: "ABC175-C問題から。こんなソースコードを書いてWAが出ちゃいました。どうしよう？って時、当然最初は普通にデバッグするんだけど、間違ってるテストケースが見つけられない時の手法を説明するよ。… https://t.co/g83RLOQ858"
ABC175-C問題から。こんなソースコードを書いてWAが出ちゃいました。どうしよう？って時、当然最初は普通にデバッグするんだけど、間違ってるテストケースが見つけられない時の手法を説明するよ。… https://t.co/g83RLOQ858
本記事は 【Advent Calendar 2023】 19日目の記事です。 🎄 18日目 ▶▶ 本記事 ▶▶ 20日目 🎅 こんにちは。社会人2年目、新米エンジニアの國弘です。 配属後から今日まで、開発業務として一番時間を費やした工程はずばり テスト だ、と言っても過言ではないと思っています。 開発の検証作業としてかかせないテストですが、テストケース作成のポイントとして、 「だれにでも『わかりやすい』記載であること」 が挙げられます。 今回は、自身の経験を踏まえて、テストケース作成について『わかりやすい』記載という観点で気を付けたいポイントをまとめてみました。 『わかりやすい』記載に求められる2つのポイント 1.打鍵者が迷いなく実施できること 2.確認ポイント・方法が明確であること テストの目的が『わかりやすい』か？ 3.テストの目的を読み取れること まとめ 『わかりやすい』記載に求
ことの発端 新卒2か月目にして、早速開発者テストで考慮漏れを発生させた私。 「顧客が組んだ計算式の動作を担保するUT（ユニットテスト）を書く」という防止策の対応が急務でした。 無限に増えていくテストケースとの格闘、PICTやテスト手法の学習等、色々あった結果、全ての網羅は出来ないという結論にたどり着きました。 最低限担保する部分を決めてテストケースを出してみると46,000件になりました。 46,000件のテストケースを実行しなければならない 今回のテストケースとしては、実行する式、取りうる引数の値、期待する計算結果の3つを保持しておく必要がありました。 保持する方法としては、以下の2つを考えた結果 protobufを使用する方法 golangコードを生成する方法 binaryファイルにすると型情報が欠落してしまい上手くテストケースを表せなかったことから、golangコードを自動生成する方
テストケースを変えない工夫 | 品質向上ブログ
※本稿はソフトウェアテスト Advent Calendar 2020 24日目の記事です。 こんにちは、Magic Podの開発をしている脇坂です。好きなものは単体テストとリファクタリングとテニスです。 さて、今日はリグレッションテスト、機能テストの文脈で話をします。テストケースを変えない工夫というのは、継続的にテストケースを実行する上で必要不可欠なテクニックです。このテクニックは自動テストの文脈で語られることが多いですが、手動テストにおいても応用可能だったりします。 話すこと テストケースを変えるべきではない理由テストケースを変えずに済ませる工夫 話さないこと フレーキーテスト問題に対するシルバーブレッド非機能要件のテスト 目次 背景テストケースの変更単体テストの場合Web/Mobile E2Eテストの場合Webは詳細手動テストの場合Web/Mobile E2Eテスト自動化サービスの場合
こんにちは。QAチームのmiyagiです。 QAで最近導入したTestRailというツールについて、導入の背景や、スプレッドシートからこのツールに乗り換えて変わったことについて書いていきたいと思います。 TestRailとは TestRailは、主にテストケースの作成・更新やテストの進捗管理ができるテスト管理ツールです。 ツールの開発元はドイツのGurock社で、日本ではテクマトリックス株式会社が販売代理店となっており、同社から日本語でサポートも受けられます。 テスト管理ツールを導入した背景 テスト管理ツールを導入した理由は大きく分けて2点あります。 1点目はテストケースのデータベース化を実現するためです。具体的には以下の内容を行うためのツールが必要でした。 テストケースのマスタを作る テストケースのマスタから実行するテストケースのセットを条件に合わせて抽出する TestRailへの移行と
生成AIでテスト作業（要件の品質評価→テストケース抽出→コード生成→実行→洞察）まるっと自動化がスゴい - Qiita
はじめに テストのための生成AIを搭載した「UiPath Autopilot for Testers」が2024年7月に一般公開されたので、個人の学習目的で期限なく無料で使えるUiPath Community版で、さっそく体験してみました。第一印象、何これ？スゴいの一言です！今後、テスト市場に新風がくるかも？と感じたので広く知ってもらうためにブログを書くことにしました。既にグローバルでは轟いているそうです。 本ブログを見て興味ある、体験してみたいと思った人向けにUiPath Autopilot for Testersの簡単なチュートリアルも書いたので、こちらも是非ご覧ください。 全体像（何ができるのか） これまでのAI搭載テスト自動化ツールは、テスト実行のみにフォーカスされていたことも多かったと思います。（既に過去形）そこから、ちょっと進んで、生成AIを使ったテストコードの自動生成ぐらいで
テストケース自動生成器をつくる
はじめに プログラムから自動的にテストケースを生成するテストケース生成器を作ってみます． プログラミング言語は Scheme, 処理系は Gauche を使います。 プログラムの構文 プログラムの構文は次のようにします。S式です。 変数は整数型だけとします。 文は5種類用意します： skip (set! 変数 式) (if 条件 文 文) (while 条件 文) (block 文 ...) 式は前置記法で、次の演算子を用意します： and or not = > < >= <= + - div しくみ 基本的な考え方： if 文の条件に着目する プログラムからテストケースを作るときは，if 文に着目して，その条件が成り立つ場合と成り立たない場合をそれぞれテストケースとします． この条件を，プログラムの入口の方に向かって変換していって，プログラムの先頭で成り立つべき条件が得られれば，それがテ
func TestSplitN_A(t *testing.T) { type args struct { s string sep string n int } tests := []struct { name string args args want []string }{ { name: "-1", args: args{ "A,B,C,D", ",", -1, }, want: []string{"A", "B", "C", "D"}, }, { name: "0", args: args{ "A,B,C,D", ",", 0, }, want: nil, }, { name: "1", args: args{ "A,B,C,D", ",", 1, }, want: []string{"A,B,C,D"}, }, { name: "2", args: args{ "A,B,C,D"
【Prismaとテストシリーズ】jest-prismaでテストケースごとに隔離されたトランザクションで快適にテストできるか試してみた | DevelopersIO
【Prismaとテストシリーズ】jest-prismaでテストケースごとに隔離されたトランザクションで快適にテストできるか試してみた 「前のテストケースで追加されたレコードのせいで他のテストが失敗した」、「自分でレコードのクリーンアップをするのは厳しい」、「いい感じにテストケースごとにDBのトランザクションはる方法がないかな」というモチベーションで試してみました。Rspecで表現すると `use_transactional_fixtures` に該当すると思います。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。 PrismaはTypeScriptでも利用できるORMの一つです。 私もよく利用させていただくのですが、DBが絡むコードのテストの時には以下のようなことを気にしませんか？ Docker（コンテナ）を使ってモッ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
テストケース、仕様を書くか実装に合わせて書くか - Mobile Factory Tech Blog
なぜLINEは600以上のテストケースをKotlinで書くのか？ “とにかく便利なテスト”を実現する、kotestのお役立ち機能
テストケースの具体的な代表値には2以外の一意の素数を使おう - ブロッコリーのブログ
デスクトップ版「Power Automate」がテストケースに対応 ～2025年3月アップデート／デスクトップフローが期待通りに動作しているかどうかを検証できる
PICTでEmacsからテストケースを生成する - Qiita
テストケースの作り方・書き方の例【項目の洗い出し】
テストケースとは？書き方や満たすべき要件について解説｜ソフトウェアテストのSHIFT
テストケース作成に生成AIを導入した効果と課題 - asoview! Tech Blog
テスト漏れによる責任追及を回避するための自己防衛術（テストケース算出手法の紹介とtips） - Qiita
CypressでCognitoにログインするテストケースを通すのに苦労したポイント - Qiita
E2Eテスト自動化サービスmablでテストケースを作成する際のルールを作った話 - エムスリーテックブログ
テスト仕様書の書き方～テストケース作成のポイント～ ｜ ソフトウェアテストのSHIFT
盛大な手戻りを防ぐため、先にテストケースだけレビューしてもらう開発手法
【Rails】RSpecで特定のテストケースだけbeforeをスキップする - りんごとバナナ
わかりやすいテストケース作成のために気を付けたいポイント - NRIネットコムBlog
46,000件のテストケースでgo testのビルドを高速化する - Qiita
テストケースの管理をスプレッドシートから「TestRail」に移行した - Gunosy Tech Blog
Go言語のテストケースの一覧性を高める - Qiita
ja.wikipedia.org
share.google
michihiroosada2391.hatenablog.com
ja.wikipedia.org
www.smartnews.com
mainichi.jp