【翻訳記事】テストに対する考え方「Testing Manifesto」 - ブロッコリーのブログ
はじめに（Testing Manifestoを紹介するに至った背景） 既にこのブログでお伝えしたように、先日『Agile Testing Condensed』の日本語翻訳本を出版しました。 この書籍の中で、テストマニフェスト（Testing Manifesto）が紹介されています。 アジャイルソフトウェア開発宣言（Agile Manifesto）を元ネタにして作ったものだと思います。 この考え方は書籍を購入していない人にもぜひ知ってほしいと感じているので、この記事でも紹介することにしました。なお、記事に載せることについては、この画像の作者であるKarenとSamにメールを送り許諾を得た上で掲載しています。*1 テストマニフェスト 翻訳した画像はこちらです。*2 オリジナルの画像等はこちらにあります。 www.growingagile.co.za また、画像だけでなく文章も残しておきます。
ソフトウェアテストの手法と施策
製造業のための製品・サービス情報サイト「TechFactory」で掲載された主要連載や特集を、PDFの電子ブックレットに再編集してお届けする「エンジニア電子ブックレット」。今回は『ソフトウェアテストの手法と施策』をご紹介します。 複雑さを増す製品開発において、有効なソフトウェアテストの手法と施策 「ソフトウェアテストは数多くあるが、どれをどのように選ぶのか」――。この問題に対する唯一の解は「テストは製品とプロジェクトに依存する」である。身も蓋もない答えではあるが、ソフトウェアテストに唯一無二の正解はなく、製品やプロジェクト応じてテスト手法を選択し、それらを組み合わせて施策とするしかない。そしてそのためには、ソフトウェアテストに関する知識と経験、そして勘が必要とされる。 本稿では有効なソフトウェアテストの手法と施策を探るべく、「ソフトウェアテストの分類」「ソフトウェアテストの選び方」「ソフト
最近のテスト自動化の社内外動向
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。黒帯として、社内でのテスト自動化推進をおこなっておりますシステム統括本部の山口（@teyamagu）です。 ここ数年、ソフトウエア開発やソフトウエアテストのトレンドの1つとして、テスト自動化に注目が集まっています。Yahoo! JAPANもそれらのトレンドに沿う形でテスト自動化を強化しています。 そこで本日は、Yahoo! JAPANのモバイルアプリのテスト自動化環境と、私や同僚が参加した海外カンファレンスなどでの最近のテスト自動化の動向について簡単にご紹介します。 Yahoo! JAPANのモバイルアプリのテスト自動化環境 モバイルアプリのテスト自動化の環境として、AppleからXCTest/XCUITest、Goo
テスト計画の立て方 - Qiita
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
【速報】JUnit5 はこうなる!?【プロトタイプ】 | DevelopersIO
渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです（出版が2012年11月）。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを！ JUnit Lambd
テストカバレッジ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか？」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
クラウド型テスト管理ツール「Qangaroo（カンガルー）」
クラウド型テスト管理ツール 『Qangaroo（カンガルー）』 テストの進捗が見える。 開発がスマートに進む。 煩雑だったExcelなどによるテスト管理手法を刷新し、 チーム内での情報共有と円滑な調整をサポート。 ソフトウェア開発の流れがQangarooで変わります。 無料で試してみる Overview 徹底した見やすさと優れた操作性で、 テストの「見える化」を実現。 「テストはすべてExcelで管理していて、テストケースの管理がとても煩雑」 「Excelでテスト管理を行っているが、一目で状況を把握するのが難しく不便」。 ソフトウェア開発現場のそんな声にお応えし、 テストの「見える化」を促進するユーザーインターフェースや 機能性を高い次元で融合したテスト管理専用ツール、それがQangarooです。 見やすさと操作しやすさを徹底追求。クラウド型だから導入も簡単で、 チームの即戦力として信頼性
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
Wikispaces
We are sorry, but the site you are looking for no longer exists Wikispaces was founded in 2005 and has since been used by educators, companies and individuals across the globe. Unfortunately, the time has come where we have had to make the difficult business decision to end the Wikispaces service. We first announced the site closure in January 2018, through a site-wide banner that appeared to all
テスト自動化のROIの理論と実践
Hi there! I just wanted to share a list of sites that helped me a lot during my studies: .................................................................................................................................... www.EssayWrite.best - Write an essay .................................................................................................................................... www.LitR
TDD／BDDの思想とテスティングフレームワークの関係を整理しよう
TDD／BDDの思想とテスティングフレームワークの関係を整理しよう：いまさら聞けないTDD/BDD超入門（2）（1/3 ページ） TDD／BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、TestDoxを紹介する。 前回の「テスト駆動開発／振る舞い駆動開発を始めるための基礎知識」でも紹介があったように、さまざまなテスティングフレームワークがあります。例えばTDD自体は、Kent Beck（ケント・ベック）氏が著書『テスト駆動開発入門』（ピアソンエデュケーション刊）の中で述べているように、「分析技法および設計技法であり、実際には開発全てのアクティビティを構造化するための技法」です。 TDD（テスト駆動開発）／BDD（振る舞い駆動開発）を実践することと、特定テスティングフレームワークを採用したり開発したりすることを分けて考えておかな
しんすく流 テスト戦略策定手法 v1.0.2 - >& STDOUT
思いがけずソフトウェアテストという技術に触れてからはや10年が経ちました。あーでもない、こーでもない、と試行錯誤を繰り返しながらようやく自分なりのテスト戦略、ある製品のテストすべてを「任せた！」と言われた時に僕ならこうする、という型が出来てきましたので、まとめたいと思います。 いちばん大事にしているのは、品質定義とその水準の共有とテスト設計までのトレーサビリティです。 長いわりにオムニバスでは読めない形式となっておりますので、またどこか別の形にまとめ直したいと考えています。文章にできるところを全部書くとこんな感じ、というもはや自分用メモです。万が一読破した方が居られましたら是非 @snsk まで「読んだよこのやろう」と飛ばして下さい。謝ります。 お品書き 任意の品質モデルを選択して、対象製品にとっての特性に「言い換え」る 「PQM:プラクティカルクオリティモデル」の作成 「言い換え」た特性
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～ Presentation Transcript DevelopersSummit 自動改札機の 運賃計算プログラムのデバッグ手法 ～1040のパターンをいかにテストするか～14-B-3 幡山 五郎#devsumiB オムロンソーシアルソリューションズ ソリューション事業本部 Developers Summit 2013 Action ! １．自動改札機について 1. 自動改札機について 2. 間違えない自動改札機 2 １．自動改札機について自動改札機導入前の改札風景 3 １．自動改札機について磁気からＩＣへ求められる技術が変わってきた（高機能化→高信頼化） 2013年 ＩＣ乗車券全国共通化（北海道～九州の10種類） 2007年 ＰＡＳＭＯ導入、Suica+PASMO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Writing simple, readable unit tests | SAP Blogs
ソフトウェアテストの試練（後編）―IoTとAI、ビッグデータが愛したテスト
Great code is testable code | SAP Blogs
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
bitbucketの使い方
