ソフトウェアテスト入門 / 2022-08-30 software testing
■参考 ・JSTQB ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 ・業務でも活用できるソフトウェアテストの7原則 ・Agile Testingのエッセンス ・TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング ・テスト駆動開発 ・BDDとATDD ・The BDD Books - Discovery (Japanese Edition) ・リーダブルテストコード ・テストコードにはテストの意図を込めよう ・組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） ・質とスピード（2022春版、質疑応答用資料付き） ・【翻訳記事】テストに対する考え方「Testing Manifesto」 ・マネジメント向けアジャイル開発概要 ・The Software Testing Ice Cream Cone ・Goo
仕様は確認しないし、運用テストもしません 全部出来上がってから確認します（＠IT） - Yahoo!ニュース
ソフトウェア開発における「ベンダーの専門家責任」は、恐らくベンダーが考える以上に重い。 開発失敗の責任を争う裁判では、ユーザー企業の不作為や非協力、非見識でさえも「ベンダーがITの専門家としてユーザー企業をリードしなかったためだ」と厳しい判断を下されることもある。本連載でごく初期に取り上げた平成16年3月10日の裁判は、ユーザー企業が要件変更を繰り返してプロジェクトが破綻してしまった責任を、「ユーザー企業の要望を断ったり、追加見積もりをしたりするなどして、プロジェクトの安全を図らなかったためだ」としてベンダーに負わせる判決が下され、当時私も末席を汚していた東京地裁のIT調停委員の間で話題になった。 無論、全てのプロジェクト破綻の責がベンダーにあるというわけではなく、ユーザー企業がしかるべき時期に必要な判断を下さない、必要な情報提供を行わないなどがあれば、「ユーザーの協力義務違反」という不法
アジャイル・DevOps時代の テストと品質保証 （完全版） / Testing and Quality Assurance in Agile and DevOps Era
この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか？ 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
9. I/Oボトルネックの計測 | Oracle 日本
9. I/Oボトルネックの計測 Webシステム環境で、CPU処理能力に次いで性能ボトルネックの根源になりやすいシステムリソースは、I/O(入出力)処理です。とりわけ、データベース等のファイルアクセスが頻繁に行われるアプリケーションでは、I/Oの振る舞いがシステムの応答性能に大きな影響を与えることになります ただ、I/Oボトルネック追求はある意味、局所的なアプローチであり、システムテストの段階で初めからこの部分だけを気にしてチェックしていても全体像の視点が無ければ問題把握がしにくいことは事実です。本章では、これらについての総合的な視点で段階的な計測手順と見極め方について整理します。 I/Oボトルネック発見と分析の手順 1. 著しい応答遅延の計測 まず、ユーザーの使用に支障をきたすような著しい応答遅延が存在するかどうかを確認します。どの程度の負荷でこの応答性能の劣化現象が発生するかを把握して、
負荷テストアプローチ別の目標設定と指標の考え方 | Oracle 日本
8. 負荷テストアプローチ別の目標設定と指標の考え方 7. 負荷テストの評価基準には何 を使えばよいのか? に戻る はじめに 一般的に負 荷テストには、目的に応じて以下の4種類のアプローチがあると言われています。 * 性能テスト - スループット * 性能テスト - 応答時間 * 限界テスト * 耐久テスト 負荷試験はシステムに対する客観的評価手法の 一つですが、何をもって判定基準や達成目標にするかという明確な指標を伴わずに、漫然と一定量の負荷をかけて問題が起きなければそ のまま完了とするスタンスには問題があります。 実行時に明確な目標と指標が無い場合には、採取したデータも活用の出来ない 意味の無い客観データになりやすいですし、また、テスト時に可能である潜在的な性能問題の発見／改善のせっかくの機会を見逃すこと になります。 本編では、これらアプローチ毎の目的設定と指標の考え方について整理し
結合テストは、ほぼテトリス
全消しで大量のお邪魔仕様が発生、相手に大ダメージを与えます。次回は「サイバースペース」です。 →他の用語解説も読んでみる ■「結合テスト」：おすすめ記事・超まとめ 「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？（＠IT 自分戦略研究所 2010年7月） システムのテストには、単体テスト、結合テスト、システムテスト、運用テストなどがあります。それぞれのテストは開発工程に対応しています JUnitとEclipseを使って学ぶ、“テスト”の常識（＠IT Test & Tools 2009年7月） 何となくテスト項目を作成して実施するのでは、作成したWebアプリの品質が低かったり、開発コストが高くなったりと後々、後悔することになります テスト自動化の3つの目的とROIの必要性、定義（＠IT Test & Tools 2014年6月） 自動テストを導入する目的は何でしょうか？ テスト実
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
