2021年のエンジニア新人研修の講義資料を公開しました - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。開発本部 オンボーディングチームの酒井（@sakay_y）です。社内のオンボーディングコンテンツを、どんどん社外へ公開することを夢見ています。 2021年もエンジニア新人研修を行いましたので、軽い紹介と、講義資料および一部講義動画（New!）を公開いたします。 2021年のエンジニア研修について 講義資料公開 Webアプリケーション基礎 HTTP/DNS ソフトウェアライセンス ソフトウェアテスト テスト自動化 アクセシビリティ Docker Chrome Developer Toolsの使い方 サイボウズのアジャイル・クオリティ デザインの役割と関わりかた データベース CI/CD セキュリティ モブに早く慣れたい人のためのガイド ITコミュニティ文化と情報発信に共通する成長と貢献の要素 正規表現 Kubernetesを使った開発入門 モニタリング入門 gRPC入門 日本語話
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15 ※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています P17 概説テスト分析 http://www.slideshare.net/takashiyamasaki378/ss-55384920 P29 システム/
仕様整理のためのテスト設計入門をJaSST'21 Tokyoで発表しました | BLOG - DeNA Engineering
はじめに 品質管理部の河野です。先日、 ソフトウェアテストシンポジウム 2021 東京 の企画セッションで「仕様整理のためのテスト設計入門」というタイトルで発表してきましたので、本ブログでは発表に至った経緯や発表の感想などを報告いたします。 発表の経緯 まず、タイトルを見た方は、仕様を整理するためにテスト設計を使うのか？ と考えられたと思いますが、その通りでテスト設計はテストケースを設計する行為なのですが、実はテストケースを設計する過程で仕様を整理していることが多いです。ということで、テスト設計のための技術である、テスト設計技法を理解しながら、演習を交えて仕様の整理を実感できるような構成でチュートリアル形式で90分の発表を行いました。 それで、このようなテーマを思いついたきっかけは、私が以前作成したテスト設計の入門のテキストを近くの開発者の方に「開発者向けにやったら需要ありますか？」と質問
xUnit Test Patternsから学ぶ12個のユニットテストの原則 - Qiita
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
VSCodeでTypeScript/Node.jsの開発環境を作る（UT・カバレッジ・ログ出力・リリース手順含む） - Qiita
Visual Studio CodeでTypeScriptの開発環境を作る手順を調べてみました。 Node.jsで動く簡単なCLIツールを作る前提で進めていきますが、他の開発にも応用できるかと思います。 なお、Visual Studio CodeとNode.jsはインストール済みの前提です。 Windows 10環境で以下のバージョンで確認しています。 C:\>node -v v8.10.0 C:\>npm -v 3.10.6 C:\>code -v 1.21.1 79b44aa704ce542d8ca4a3cc44cfca566e7720f1 x64 mkdir ts-sample cd ts-sample npm init -y mkdir .vscode src test config npm i -SEB config log4js npm i -DE typescript ts-
依存性注入(DI)の解説とやり方 - Qiita
依存性注入 (Dependency Injection) は、クラスを単体テスト可能にするために使われるテクニックです。 これが意識されていないが故に単体テストが全くできないコードをよく見かけます。 単体テストの際には必ず必要になる知識なので、解説しておきます。 以下のサンプルでは PHPUnit を利用しています。 悪い例: 単体テストができないケース 以下のような Foo クラスの play() メソッドは、単体テストケースが書けません。 class Foo { public function play() { $bar = new Bar(); if ($bar->getSomething() === 1) { return true; } return false; } } play() 内で外部クラス Bar をインスタンス化しています。つまり Foo::play() メソッドは
ゼロから始めるJavaScript生活 - Qiita
（訳者注: これは、JavaScript Stack from Scratchを翻訳し、まとめて読めるように1ファイルにしたものです。元の翻訳と各種ファイルについては、日本語訳forkリポジトリを参照してください。また、原文が活発に更新されているため、訳文も追従して更新されます。ご了承ください。） モダンJavaScriptスタックチュートリアル、ゼロから始めるJavaScript生活へようこそ。 ⚠️️ このチュートリアルのメジャーアップデート版を3月初旬に公開する予定です。ご期待下さい! より詳しく(英語). これはJavaScriptスタックを使い始めるための最短最速のガイドです。このガイドは一般的なプログラミングの知識とJavaScriptの基礎を前提としています。これら全てのツールを一緒につなぎ合わせることにフォーカスしており、各ツールについて可能な限りシンプルな例を提供します。
フロントエンドにテストを導入 - Qiita
2016-8-8 ※webpack単体の記事を書きました。よろしければこちらもどうぞ step by stepで始めるwebpack 2016-5-16 ※karma単体の記事を書きました。よろしければこちらもどうぞ step by stepで始めるKarma 本記事は画面のJavaScriptのテストとかまったくやったことない方 Mocha？webpack？karma？それぞれの解説記事はよく見るけど全体像がよくわからんという方向けです。（数日前の自分です） 全体を通して導入の流れを解説した記事があると全体像が理解しやすいのではと思い書いてみました。 前提 Nodejs,npm,chromeが導入済みであること 流れ Step 表題 目的
噂の新テスティングフレームワーク"Quick"を試してみよう！ - Qiita
「Quick」は去年リリースされた注目のテスティングフレームワーク。 Spec系統のフレームワーク(RSpecとか)を意識して作られているらしい。 Spec系については、RSpecについて調べてみると参考になるかも。 ただ、あまり深い追いすると際限ないのでほどほどに。。 Spec系の特徴を簡単にだけ。 読みやすい TDD(BDD)を意識した作りなっている 使ってみよう インストール Installing Quick (公式) 「git」「CocoaPods」「Carthage」の３パターンあるっぽい。 ※ Carthageがちょっと気になったので調べてみた→[Swift] CocoaPodsとCarthageの違い 普通にcocoapodsでやってみる。 下準備 cocoapodsのバージョン0.36以上が必要とのこと。 なのでupdateから始める。
安定したリリースを継続するためのテストとテストレベルの話 - クックパッド開発者ブログ
こんにちは。技術部の松尾(@Kazu_cocoa)です。 安定したリリースを継続して回す為には、開発プロセスや実装も大事ですが、その中でどのような確認、テストを継続して行うかも大切になります。そこで、開発プロセスにおけるテストをどのように切り分けて、構築していくかという考え方に関して少し整理してみようと思います。 これにより、実施されているテストによって検出できる/できない不具合がどのようなものか、それが開発中のどこで防ぐことができるのかを整理できるようになってくると思います。また、安定したリリースを実現するためのボトルネック解消に向けて、どのレベルでテストを充実させると効率的にそれが達成できるかという所も考えることができるようになります。 テストレベルによるテストの区分け テストレベルという言葉にも様々な定義がありますが、ここではざっくりとテスト対象となる範囲や領域を意味することにします
Webアプリケーション負荷試験実践入門
2015年2月24日 ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less
PAGE NOT FOUND!
Sorry, but the current page is not working right now. Thank you!
TDD／BDDの思想とテスティングフレームワークの関係を整理しよう
TDD／BDDの思想とテスティングフレームワークの関係を整理しよう：いまさら聞けないTDD/BDD超入門（2）（1/3 ページ） TDD／BDDの思想に触れ、フレームワークとしてxUnit、JBehave、xSpec、Cucumber、Turnip、TestDoxを紹介する。 前回の「テスト駆動開発／振る舞い駆動開発を始めるための基礎知識」でも紹介があったように、さまざまなテスティングフレームワークがあります。例えばTDD自体は、Kent Beck（ケント・ベック）氏が著書『テスト駆動開発入門』（ピアソンエデュケーション刊）の中で述べているように、「分析技法および設計技法であり、実際には開発全てのアクティビティを構造化するための技法」です。 TDD（テスト駆動開発）／BDD（振る舞い駆動開発）を実践することと、特定テスティングフレームワークを採用したり開発したりすることを分けて考えておかな
テスト駆動開発／振る舞い駆動開発を始めるための基礎知識
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」（Test Driven Development、以下「TDD」）は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 本稿では、そうしたTDDの発展や、振る舞い駆動開発（Behavior Driven Development、以下「BDD」）など他のテストファースト手法への展開についても解説します。 ※編集部注：ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
テスト分析・テスト設計入門
© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会（ASTER） 理事 JaSST東京実行委員（2003年～） 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員（2006～） テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長（2011年～） Wモデル研究会 主査（2011年7月～） 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員（20
「Mockery」を使ってサクッとPHPのテストを書いてみる
ごあいさつ はじめまして。アライドアーキテクツの石川と申します。 2月に入社してから早くも３ヶ月がたとうとしています。 私は前の職場ではほとんどjavaで開発していたのですが、 アライドに入社してからは主にPHPで開発をしています。 私の回では、その時その時に関心のある技術情報を発信していければ、と思っています。 皆様どうぞよろしくお願いいたします。 今の自分の課題はとにかくUnitテストを書くことなので、 今回はPHPのモッキングフレームワークである「Mockery」について書きたいと思います。 Mockeryって？ padraic / mockery こちらで御座います。 static methodのモック化が出来たり、テスト対象のメソッド内部で生成されるインスタンスをモック化したり、 PHPUnitでやろうとすると一手間かかることをサクっと出来てしまいます。 Let’s インストール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Seleniumを使用したテスト自動化の取り組みを紹介します
ChangeLog を支える英語
