容量偽装USBメモリ検出アプリ『ValiDrive』が登場。偽物かどうかを簡単に判別 | ニッチなPCゲーマーの環境構築Z
容量を偽装した偽物の大容量USBメモリを検出するフリーソフト・アプリ『ValiDrive』が登場しました。 『ValiDrive』がどういったものか、制作者のGibson Research Corporationは以下のように述べています。 私は格安で売られていた1TBおよび2TBのUSBメモリを12台購入しました。しかし、そのすべてが容量を偽装した偽物でした。 偽物のUSBメモリはPC上では1TBおよび2TBとして認識されます。しかし、実際には64GBしかありませんでした。使用量が64GBを超えると、新しいファイルは保存されなくなります。PC上ではファイルが存在するように見えますが、ストレージ上には存在しないためファイルを開いても中身は空っぽです。 ValiDriveは、こういった容量を偽装したUSBメモリを見分けるために、ストレージスペース全体にわたってランダムな検査を実行します。 購
1. 始めに こんにちは、morioka12 です。 本稿では、バグバウンティの入門として、主に Web アプリケーションを対象にした脆弱性の発見・報告・報酬金の取得について紹介します。 1. 始めに 免責事項 想定読者 筆者のバックグラウンド Start Bug Bounty Bug Bounty JP Podcast 2. バグバウンティとは バグバウンティプラットフォーム Program Type Private Programs VDP (Vulnerability Disclosure Program) Asset Type 3. プログラムの選び方 Scope OoS (Out of Scope) 4. 脆弱性の探し方 (初期調査編) Subdomain Google Dorks Wayback Machine Wappalyzer JS Analyze [Blog] Java
Findy Team+でフロントエンドエンジニアをしている 川村(@peijun333)です。 Findy では、フロントエンドのコード品質と安定性を確保するために Jest などのテストフレームワークを積極的に活用しています。通常、Jest は CLI から実行してテスト結果をコンソールで確認しますが、コマンドを用意する手間や、テスト経過のデバッグのために都度 console.log などでその内容を確認しなければならずとても不便です。 そこで、今回はテストの自動化とリアルタイムなフィードバックを提供する JavaScript の統合テストツールである Wallaby.js を紹介します。Wallaby.js を導入することで、開発効率の向上が期待できます。 Wallaby.js とは？ 前提条件 VS Code でテストの修正 Wallaby.js はリファクタリングに強い スナップシ
「テストを書こうとしたけど、どう（いつ）書いたらいいかわからない」初心者向けガイドライン！ - HIKKYフロントエンドガイドラインより
本稿では、自動テストについての「ちょうど一歩くらい」進んだ内容について、述べていきます。 「テストを実施したいけど、どう書けばいいかわからない」という全人類は、これを読んでください。 損はさせませんよ！ これを読めば、「一歩目の知識」「初めてのテスト作成」「テストの初歩概念」を得ることができ、「次になにをすればよいか」がわかるようになります！！ 対象読者: 実際にテストを実装してみようと思ったけど、とっかかりがつかめなかった テストの概要はわかった（単体テストと結合テストガイドラインを読んだ） テストのTipsに興味がある なお本稿は株式会社HIKKYフロントエンドチーム向けのガイドラインであるものの、内容については筆者に一任されており、株式会社HIKKY及びその意向等とは無関係です。 テストってどういうフローで開発していくの？ どのタイミングでテストコードを書くの？ おおまかには以下の、
テストプロセスが自走するチーム体制をめざして QA が取り組んでいること - Techtouch Developers Blog
はじめに 前提情報 プロダクトチームの体制 Four Keys の Elite を目指して 品質保証の課題 1. テストの重複 2. 刻々と変化するチーム体制 3. 属人化したテストケース管理 改善策：テストプロセスの変更とテストケース管理ツールの導入 1. テストプロセスの改善〜Test It Yourself〜 2. テストマネジメントツールの導入 おわりに はじめに こんにちは、テックタッチで QA PM (Quality Assurance Project Manager)をしている shutty です。先日はテストエンジニア向けの合宿型ワークショップ WACATE2023 冬に初めて参加してきました。実行委員をはじめとして参加者全員の熱量を全身に浴びてきました。 この記事では最近テックタッチの開発チームで行なっているテストプロセスの改善について紹介します。 前提情報 プロダクトチ
「線虫がん検査つぶし」であらわになった、PET検診の不都合な真実
きはら・ひろみ／宮城県出身。大学在学中にコピーライターとして働き始め、20代後半で独立してフリーランスに。西武セゾングループ、松坂屋、東京電力、全労済、エーザイ等々、ファッション、流通、環境保全から医療まで、幅広い分野のPRに関わる。2000年以降は軸足を医療分野にシフト。「ドクターズガイド」（時事通信社）「週刊現代?日本が誇るトップドクターが明かす（シリーズ）」（講談社）「ダイヤモンドQ」（ダイヤモンド社）などで、企画・取材・執筆を深く、楽しく手掛けてきた。2012年、あたらす株式会社設立（代表取締役）。近年は医療系のWebサイト、動画制作（企画・ライティング・プロデュース）にも力を入れている。 ＆慢性痛～知っておきたい慢性痛のホント（横浜市立大学ペインクリニック内科との協働制作） https://www-user.yokohama-cu.ac.jp/~mansei2/ あるペインの少女
ペーパーテストだけで選抜した子の人生～のヤツ
追記 2023/11/14 ツッコミくれた増田やいろいろ教えてくれた増田本当にありがとう！ こういう知らないこと知れるってのはマジで脳汁でるな！！！特に「逆だと思う」って教えてくれた増田！指摘読んでてうっひょーーーなるほど！指摘嬉しい！！ってなったぞ！本当にありがとう！！！！ オラはＸとかインスタ？とかやってないから、ネットの流行りははてなとトゥゲッターとスラドでしか知れない程度の情弱ボッチだけど、書いたことに対してみんなにいろいろツッコミ受けて、新しいこと知れるのやっぱ楽しいな！って久々に実感した！改めてありがとう！ ----- オッス。オラ英語成績が２だった上に底辺工業高校卒なので、多分誤読してるかも。みんなの知識をオラに分けてくれ！ 「ペーパーテストだけで選抜した子」の人生を35年間追跡調査すると、ペーパーテストで劣った子と比較してクリエイティビティ・芸術の分野でも上回っていたという
Red Hat Linuxの開発者であるリチャード・M・W・ジョーンズ氏が、Linux v6.4の起動時にハングアップするバグがあることに気づき、Linuxを29万2612回も再起動するテストを行ったそうです。 I booted Linux 292,612 times | Richard WM Jones https://rwmj.wordpress.com/2023/06/14/i-booted-linux-292612-times/ Dev Boots Linux 292,612 Times to Find Intel, AMD Kernel Bug | Tom's Hardware https://www.tomshardware.com/news/dev-boots-linux-292612-times-for-1-in-1000-kernel-bug ジョーンズ氏が起動時のハング
【翻訳】なぜ、最悪のUXを持つプロダクトが市場を制するのか？（Meelis Ojasild, 2022） - 体験とデザイン、スタートアップについて
meelis-ojasild.medium.com 企業がユーザーエクスペリエンスに基づいてソフトウェアを選択するというのは神話です。しかし、PMは主にUXに注目しています。では、実際はどうなっているのでしょうか？ ソフトウェアの選定プロセス これが一般的なソフトウェア選定の仕組みです。 人々は問題とそれを解決する可能性のあるソフトウェア・カテゴリーを認識します。 ソフトウェアのカテゴリーを広くグーグル検索しています（例えば「ベストCRMツール」）。 彼らは、Googleで上位に表示されるいくつかの結果を閲覧します Googleのトップページで最もよく使われているソフトウェアソリューション（Salesforce、Hubspot、Pipedriveなど）を（精神的または物理的に）メモしておくのです。 安いものから試していく（HubspotとPipedriveとします）。 テストでは、1つのコ
XUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜 の登壇資料です。 https://findy.connpass.com/event/306451/
Tech Dept. 基盤グループエンジニアの @tenkoma です。 BASEには50以上のPHPプロジェクトのプライベートリポジトリがあります。 (アプリケーションは十数個で、残りの多くが、アプリケーションが依存するライブラリです) 過去4年ほどの間に新規に作られたリポジトリにはほぼ最初からPHPStanが導入されていますが、それ以前から開発していたリポジトリには導入されていないものが多数ありました。 それらのリポジトリにPHPStanを導入していったので、なぜ導入したか、導入方法、得られた効果について紹介します。 PHPStanとは PHPコードを実行せずに、実行時にエラーになりうる箇所を検出するツールです。PHPStanを利用しCIに組み込むと、テスト実行せずに検出できるバグの一部は、PHPStan解析で指摘してくれるので、コードレビューの負担が減ることが期待できます。 なぜPH
サバンナ便り ～ソフトウェア開発の荒野を生き抜く～ 第7回テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ 開発の現場では、既存のテストコードから仕様を読み解く機会がよく訪れます。そのようなとき、テスト対象の仕様やテストの意図を読み解きやすいテストとそうではないテストがあることに気付きます。今回はテストコードの読み解きやすさに寄与する要素を考えます。 認知資源と認知負荷 人間は何かを読み解くときに脳のリソース（脳内のワーキングメモリ）を使います。リソースの量は有限で、個人差があります。このような脳のリソースは「認知資源」と呼ばれています。 人間が何かを読み解くときに認知資源が何にどのくらい割かれているかという概念を「認知負荷」と言います。「どのくらい」は状況に左右されます。たとえば、読み解く対象を知っているかどうかで認知資源が割かれる量は変化します。「何に」も状
入社1ヶ月目でやったこと 〜ソフトウェアテストプロセスに基づいたテストケース作成を行ってみた〜 - ブロッコリーのブログ
はじめに この記事は10X 創業6周年アドベントカレンダーの15日目の記事になります。 昨日はアプリケーション開発部のjojoさん*1が、「10Xに入社した、そして4ヶ月後…」という記事を公開しています。 本記事では2023年5月に10Xに入社した私が、入社1ヶ月目に実際に行った、ソフトウェアテストプロセス（以下、テストプロセスと表記）に基づいたテストケース作成についてお話しします。 目次 はじめに 目次 テストプロセスに基づいたテストケース作成を行おうとしたきっかけ 前提：プロセスとは何か？ プロセスの例 テストプロセスを考えよう 今回定義したテストプロセス テスト分析 テスト対象分析 テスト要求分析 テスト設計技法の選択 テスト設計 テスト実装 記事冒頭の例が分かりづらかった理由 実際に適用した例 レビュー内容 今後の展望 おわりに テストプロセスに基づいたテストケース作成を行おうとし
Web アプリケーション開発での VRT 導入は、ちゃんと運用するとなると以下のような多くの検討事項を伴います。 Storybook のストーリーベースで比較するか？それとも実アプリケーションの URL ベースで比較するか？ CI 上でアプリケーションをビルドして dev server を立ち上げるか、それともデプロイ先のアプリケーションにアクセスするか？ スクリーンショットの比較はどのように行うか？比較時の閾値はどのように設定するか？ 比較元のスクリーンショットはどのように用意するか？例えば Amazon S3 などのストレージ や GitHub Actions の actions/cache を使用する場合など コミットハッシュを用いて比較元のスクリーンショットを特定する場合、マージ先のコミットハッシュに紐づくスクリーンショットが存在しない時の対応は？ VRT の結果で差分が出たが、そ
自分の回線速度は遅いのか速いのか1時間ごとにインターネット接続速度をテストし最大30日間分を記録して分析できる「MySpeed」レビュー、WindowsやLinuxでセルフホスト可能なオープンソース
MySpeedは継続的にインターネットの回線速度を計測・記録してくれるツールです。どんなアプリなのか、実際に使って試してみました。 gnmyt/myspeed: A speed test analysis software that shows your internet speed for up to 30 days https://github.com/gnmyt/myspeed 今回はWindowsで動作を試すので、「Installation」の項目にある「Windows」をクリックします。 Windowsマシンへのインストール手順が解説されているので、この手順に従って進めていきます。 最初にNode.jsのインストールが必要とのこと。Node.jsの公式サイトへ行き、「LTS」と書かれたバージョンのボタンをクリックします。 実行ファイルがダウンロードされるので、ダブルクリックして実
Secretlint v7でCommonJS からES Modulesへの移行を行いました。 Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し この記事では、CommonJS(CJS)からES Modules(ESM)への移行を行った経緯と、移行する方法について紹介します。 CJSからESMへの移行は、率直に言えば単調な作業で、メリットが見えにくい作業です。 しかし、将来的にCJSよりもESMが主流になることは間違いないので、移行することは必要です。 移行の作業は、移行方法が決まれば大部分は機械的な書き換えが可能です。 では、実際にどうやって移行したのかを紹介します。 ESMへの移行の影響は依存元へと連鎖する Secretlintのリポジトリはmonorepoになっていて、だいたい40コぐらいのパッケージが含まれています。 そしてパッケージ間で依存関係があ
Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った
Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。
はじめに こんにちは。QCの佐藤です。 月日が経つのは早いもので、QCメンバーも増え、多くのメンバーがブログを書いてくださっており嬉しい限りです😊*1 ANDPADで韻を踏む - ANDPAD Tech Blog アンドパッドラップの作り方 - ANDPAD Tech Blog QAがGoで始めるテストデータ作成の自動化 - ANDPAD Tech Blog ANDPADのQualityControlを紹介します！2023 - ANDPAD Tech Blog 私がブログを書いたのはもう2年前...（徐々に間隔が長くなっている...） 今回は私の担当しているプロジェクトでの、E2Eテスト管理・運用方法についてお話します。 以下のような課題ってE2Eテストあるあるですよね (´;ω;｀) E2Eテストの運用が属人化してしまっている... むか～しに作ってからはただ回しているだけ... テス
改正された障害者差別解消法の施行が迫りつつあり、企業にとってウェブアクセシビリティへの対応は急務といえる状況です。 また、アクセシビリティは法律だけの問題ではありません。Webサービスを展開している企業であれば、サービスを誰でも不自由なく使える状態にしていくためにも、アクセシビリティに向き合っていく必要があります。 今回は、アクセシビリティのテストと自動化における各企業の取り組み事例について、4名のパネリストにLT形式で発表していただきました。本記事では、テストの自動化やツール選定、普段の開発への組み込み方など参考になる情報が盛りだくさんだったトーク内容をご紹介します。 ■パネリスト 安田 慎さん/@syasuda90 株式会社サイバーエージェント AmebaLIFE事業本部 開発局 フロントエンドエンジニア 2016年に中途でサイバーエージェントに入社。フロントエンド開発を担当する傍らア
Web フロントエンドのテストと持続可能な方針の組み立てを考える | Offers Tech Blog
Offers を運営している株式会社 overflow の あほむ でございます。 今回はプロジェクトで Web フロントエンド領域のテストを書くにあたって方針を決めた際の ADR をブログ向けに再整理したものをお届けします。 テストコードを書くべきか書かざるべきか 逃げ切りが確約された作り捨ての納品プロジェクトでもなければ、継続的なメンテナンスを前提にテストコードは書くべきが現代のソフトウェアエンジニアにおける共通了解でしょう。 急がば廻れ、ほとんどの場合においてテストコードを書くメリットがデメリットを上回るものと捉えられています。ここでは書かなくても良いケースをあえて論じることをしませんが、個別具体でテストが不要と断定できるときはそうすればよいでしょう。 テストを整える工数をどう捉える TDD (Test Driven Development テスト駆動開発) に代表される、テストコー
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。続いて、自動テストのテストサイズについて話します。 自動テスト内の分類基準は明解ではない 和田卓人氏：次に、テストサイズという考え方にいきます。自動テストにも「〇〇テスト」というやつがいろいろあるんですよね。 特に我々ソフトウェアエンジニアにとって馴染み深い名前はユニットテストとか、単体テストとか、インテグレーションテストとか、システムテストとか、エンドツーエンドテストとか。「〇〇テスト」というやつがいろいろあります。それらの分類基準は、実は言うほど明解で
確定申告の時期なので、米国の一風変わった(?)所得申告システム(Information Return)と連携するアプリケーションを開発した話について書こうと思う。 米国の所得申告 所得申告システム、FIRE 不思議なファイルフォーマット みよ、これがメジャーの仕様書だ レスポンス(多分速達のほうが早い) 初心者には厳しすぎるテスト環境 FIREへの申告自動化ツールを開発する おわりに 米国の所得申告 米国で申告義務のある人は、だいたい1月 - 4月の間に確定申告(Tax Return)を行う。この際、所得申告に関する数々の書類を提出する。例えば、雑所得がある場合は 1099-MISC、ギャンブルの収益は W-2G といった具合だ。 書類には膨大な種類がある じゃあこの書類は誰が用意するのかというと、支払った側になる。例えば契約社員は1099-NECという書類が申告に必要になるのだが、これを
近年優秀なエンジニアに対して報酬を多く支払う企業が増えてきています。 実際アメリがのAmazonも大幅な賃上げを行い、話題となりました。 日本国内でもエンジニアの年収が高い企業を知りたい！と思っている エンジニアの皆様お待たせいたしました。 年収1000万以上の求人をまとめてみましたので、参考までにご覧ください。 フリービット株式会社 【募集ポジション/年収】 エンジニアリングマネージャー候補：1000万円〜1500万円 【求める人材】 当社の Vision に共感いただき、プロダクトの継続的な成長を支える開発体制を実現するため、エンジニア組織の強化を担っていただける方を募集しています。 組織づくりや人員のマネジメントなどの組織拡大を一緒に担っていただける方を探しています。 【具体的な業務内容】 ・エンジニア組織としての課題発見・解決、及び成長戦略の立案・実行 ・開発チームの体制構築と、そ
C言語でWASMインタプリタを実装した話
概要 公式のcore testが全て(UTF8, WAT, SIMD関連のものは除く)通るWASMインタプリタをC言語でフルスクラッチで実装した。自作WASMランタイムで省略されがちなValidation Stageも実装した。この記事はWebAssembly Advent Calendar 2023の三日目の記事である。 目的 このWASMランタイムを実装するにあたり、「できるだけ仕様に従って実装する」ことを心掛けた。WASMの仕様書は以下のissueが立つほど読みにくいものとなっているが、ランタイムをどのように実装すべきかが詳しく書いてあり、一応仕様書を頑張って読めばランタイムが作れるようになっている。 この自作WASMランタイムの目的は、できるだけ仕様に従った実装を与えることで、仕様の理解を助けることである。早さや効率性よりも分かりやすさを優先しているため、実用には向かない。仕様書を
以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。 上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。 その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。1 今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。 前提の確認 本題に入る前に、レビューとテスト分析とは何かという確認から行います。 「レビュー
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここで和田卓人氏が「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版） 」をテーマに登壇。まずは、セッションテーマと学習用テストについて話します。 本セッションのレギュレーション 和田卓人氏：よろしくお願いします。みなさん、こんばんは。和田卓人です。今日は「サバンナ便り」というタイトルで、自動テストに関する知見についてお話ししたいと思います。 まず今日のレギュレーションといいますか。どんどん話していくんですが、オンラインの講演はライブ感とかリアルタイム感とか、そういったところがとても大事になってきます。 なので、みなさんもTwitterで「Qi
スクラムでの見積もり - Qiita
はじめに スクラムでの見積もりは意外とさらっと書かれている事が多く、作業見積もりと規模見積もりがごちゃごちゃの状態でスクラムを進めていた結果、チームの中で見積もりに対する不信感が強くなり「このままではいけない」と感じたため、まとめました。 また、似たような記事があまりネット上で見かけなかったため、ここにざっくりと分かるように集約しました。ぜひ、自分のようにごちゃごちゃになってしまっている方に届けば嬉しいです。 まず何のために見積もるか アジャイルのチームにとって、作業を見積もることは、良い予測を追求しようとするだけではありません。チームが要求を深く理解し、開始する前に何を構築しようとしているのかをより深く考え、一定時間内にチームで協調して取り組むことで、構築しているものに対して大きな価値を生み出すことを促します。 (アジャイルメトリクス p40より) 見積もりによってプロジェクトの状態が見
WEBアプリのE2Eテストを自動化 ~ Playwrightの機能紹介とコード例 | DevelopersIO
npm init playwright@latest 実行すると @playwright/testがインストール playwrightの設定ファイル(playwright.config.ts)が追加 サンプル用のテストコードが追加 が行われます。 テストコード自動生成 playwrightにはブラウザ操作でテストコードを生成する機能があります。 package.jsonのscriptsに以下を追加してnpm run test:genするか、 "test:gen" : "playwright codegen" npxでも実行できます。引数のURLは任意です。 npx playwright codegen http://localhost:3000/
Storybook 腐らせない
この記事は 株式会社ゆめみの23卒 Advent Calendar 2023 8日目の記事です。 現代のWebフロントエンド開発において、コンポーネントの効率的な管理と可視化が求められる中、Storybookは開発者にとって欠かせないツールとなっています。Storybookは、コンポーネントをアプリケーションから隔離して単体で表示できるツールです。 しかし、このように有用なStorybookが「腐ってしまう」ことがあります。この記事で「腐る」とは、コンポーネントをStorybookに表示するための設定であるStoryが最新の状態に更新されていない、またはプロジェクトにとって負債になっている状態を指します。例えば、以下のような状態が「腐っている」状態にあたります。 npm run storybook するとそもそもエラーがでて表示されない Storyの存在しないコンポーネントやコンポーネント
From Spring Boot 2 to Spring Boot 3 with Java 22 and Jakarta EE
この記事は NTTコムウェア AdventCalendar 2023 5日目の記事です。 自己紹介&動機 高鶴と申します。NTTコムウェア コーポレート革新本部で、プログラム設計～コーディング～ユニットテストにかかわる技術の社内標準化をやっております。 プログラムの静的な解析で早期にバグを発見・修正することで、後工程でのバグ対処コスト削減（ウォーターフォール開発の場合）や、技術的負債の早期解消（アジャイル開発の場合）を目指す、というのが私のチームの仕事の大きな一部となっています。 静的な解析で早期にバグを発見するツールには、オープンソースでも商用でも様々なものがあります。しかし、ソフトウェアの品質をより抜本的に良くしていこうと思うと、「プログラミング言語を何とかする」というところを考えたくなってきます。 Rustであれば、そのような期待に応えてくれるのではないかと期待し、調査・検証を始めま
個人開発してるWebサービスの API のシナリオテストに runn を使ってみたけど、とてもよかった - えいのうにっき
「個人開発してるWebサービス」というのは Pixela のことで、runn とは @k1loW さんが開発しているオペレーション自動化ツール/パッケージです。 pixe.la github.com Pixela は、そのユーザーインターフェースとして基本的に Web API のみを提供しているサービスで（サービスを利用するための各種操作は基本的にすべて Web API に対する HTTP リクエストによって行う必要がある）、現在そのローンチから6年目を迎えるサービスです。 blog.a-know.me ありがたいことに、世界中のユーザー（特に、プログラミング初学者の方によくご利用いただいているようです）に継続的に使っていただけているサービスになっており、登録ユーザー数はもうすぐ7万人に到達しようとしているところです。開発・メンテナンスに係る私の人件費を除けば、黒字運営を続けることもできて
Testcontainersを用いてテスト実行前の docker compose up を無くし、Goで並列テストする | フューチャー技術ブログ
春の入門祭り2024の1記事目です。 はじめにTIG真野です。 Testcontainers を用いて、単体テスト実行前に docker compose up -d 無しで、PostgreSQLにアクセスする単体テストを行う、入門記事です。 恩恵は次のような開発者体感の向上が個人的にあります。 テストを実行するうえで、別プロセスのサービスを起動しておく必要があるといった前提条件を考えなくても済むため、テストを行うビジネスロジックに集中できるdocker compose up -d 打たないだけだが、テストに必要なコンテナを考慮しなくても済む停止し忘れて、別のリポジトリの開発するときに混乱しなくても済む並列テストしやすくなるので、テストの実行速度が向上するGoにおいて、複数のパッケージを同時にテストするとき、 -p 1 で絞らずに済むTestcontainers とはhttps://test
『詳解 Terraform 第3版』を翻訳しました 2023-11-21 『詳解 Terraform 第3版』という本が本日2023年11月21日、オライリー・ジャパンから出版されました。米O’Reillyから出版されている『Terraform: Up and Running, 3rd edition』を私が日本語訳したものです。この本は原著の初版が出版された頃からぜひ自分で翻訳したいと思っていたので、やっとここに至れて個人的にとても嬉しいです。 目次（詳細はオライリーのページへ） 第1章 なぜTerraformを使うのか 第2章 Terraformをはじめよう 第3章 Terraformステートを管理する 第4章 モジュールで再利用可能なインフラを作る 第5章 Terraformを使うためのヒントとコツ: ループ、条件分岐、デプロイ、その他のつまずきポイント 第6章 シークレットを管理す
ウェブサイトやモバイルアプリの、エンドユーザーからみた動作を確認するテストはE2Eテスト（End-to-End Test）と呼ばれ、このE2Eテストの自動化ツールは、アジャイル開発の普及もあって、今では多くの開発現場で活用されるようになりました。ブラウザ操作の自動化ツールSelenium（セレニウム）は日本でも有名になり、ご存じの読者も多いでしょう。しかし近年、E2Eテスト自動化の世界では、Seleniumに代わる新たなツールがたくさん登場し、急速に利用者を増やしています。この記事では、これらの新しいE2Eテスト自動化ツールのトレンドについて紹介します。 E2Eテスト自動化トレンドの変遷 筆者はテスト自動化ツールを作る仕事にもう15年近く関わっていますが、これまでのトレンドを見ていくと、「非OSS（非オープンソースソフトウェア）の時代」「Seleniumの時代」「多極化の時代」の3つに分け
As your web app matures, it becomes challenging to ensure your GUI doesn’t break with any given update. There are a lot of browsers and devices, and countless states for every one of your components. Unit tests ensure your code remains consistent, and E2E tests will ensure your system remains consistent, but neither will catch visual anomalies, layout issues, or platform compatibility issues. Ente
結合テストの自動化にQAはどうかかわっていったか - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズの永田です。 私は、サイボウズの開発本部、アジャイル・クオリティで、アジャイルの品質を探求する活動をしています。 この記事では、2023年3月9日、JaSST Tokyo 2023のテクノロジーセッションで発表させていただいた内容を、より解説を入れながら紹介します。 結合テストの自動化にQAはどうかかわっていったか 今回取り上げる事例では、kintoneのフロントエンド刷新プロジェクト（フロリア）で結合テストの自動化を決定した際に、QAメンバーがどのように関与し、困難に直面しながらも、信頼性の高いテストコードを作成するに至るまでの過程をご紹介します。 フロリアについては次のブログをご覧ください。 blog.cybozu.io テストのポリシー ~このミッションにおけるQAのチャレンジ~ フロリア内で新しく3つのチームが立ち上がった際、各チームのテスト戦略の中心を、自動
2024年3月14日より開催された「JaSST'24 Tokyo」の登壇資料です。 https://jasst.jp/symposium/jasst24tokyo.html ▼関連資料 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 https://speakerdeck.com/visional_engineering_and_design/developer-experience-day-2023 ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 https://speakerdeck.com/takabow/devopsdays-tokyo2022-huakutokarashi-merugai-shan-apuroti-leantodevopsfalseke-xue-woshi-
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"
開発者はコーディングよりもビルドとテストの待ち時間が長く、チームの協力でコード作成が高速に。すでに92％がAIを仕事に活用。GitHubによる米国の開発者500人の調査
GitHubは、現在の開発ツールやワークフローが開発者の体験にどのような影響を与えるかについて、米国に拠点を置く企業のソフトウェア開発者500人を対象に調査した結果を発表しました。 その内容は、開発者がコーディングの時間よりもビルドやテストなどのCI待ちの時間が長いと感じていること、チーム内の協力によってカバレッジやコード作成が改善されること、そしてすでに92％がAIを仕事に活用していることなど、興味深い内容が明らかになっています。 ポイントとなるグラフをいくつか紹介しましょう。 ビルドの待ち時間が長すぎる！ 開発者の典型的な1日の仕事の中で何に時間が費やされているのか、個々の開発者に時間の長い上位3つまでの時間の使われ方と1日の中でのその割合を回答してもらい、それを集計したが下記のグラフです（分かりやすいように、オリジナルの英語のグラフを一部を加工して日本語を埋め込んでいます。以後すべて
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バグバウンティ入門(始め方) - blog of morioka12
Wallaby.jsを使ってフロントエンド開発のテストを効率化しよう - Findy Tech Blog
Linuxの起動を29万2612回も繰り返して1000回に1回発生するバグを見つけることに成功
テストコードを負債化させない上手な付き合い方 / Test Code Management
10年開発してきたPHPアプリケーションにPHPStanを導入した - BASEプロダクトチームブログ
第7回 テストコードの認知負荷 ～テストの名前、構造、情報量を工夫する～ | gihyo.jp
GitHub Actions のみで、actions/cache も使わない最軽量の VRT
CommonJSからES Modulesへの移行する方法。トップダウンかボトムアップか
E2Eテストの運用を属人化しないための3つの取り組み - ANDPAD Tech Blog
ウェブアクセシビリティ テストと自動化における挑戦と失敗 - Findy Engineer Lab
自動テストの種類の曖昧さが少ない「テストサイズ」という分類 スコープとの掛け合わせでわかる“コスパの良いテスト”
あなたのしらない米国所得申告システム - tomoima525's blog
年収が1000万円以上のエンジニアの求人をまとめてみた - Qiita
テストプロセスを詳細化した話 - レビュー・テスト分析 - Qiita
和田卓人氏が教える、自動テストの使い方 学びを自動テストとして書く「学習用テスト」という考え方
Postmanでつくる決済システムの非同期処理テスト
プログラミング言語Rustになぜ注目するのか - Qiita
『詳解 Terraform 第3版』を翻訳しました
E2Eテスト自動化ツールの最新トレンド──Playwright？ ノーコード？ Seleniumから多極化の時代へ！
Ultimate Guide to Visual Testing with Playwright
テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 / JaSST'24 Tokyo