Developers Summit 2023での発表資料です。 ソフトウェアテストを専門としない人が、どんな本で、どんな順番にソフトウェアテストを勉強すればいいのかについて、主観のみで語っています。
この原稿は、2009年6月に発売された、システム開発ジャーナルvol10の特集「特集1 困ったら読む! 困る前に読む! 今すぐ使える エンジニアのためのソフトウェアテスト術」の総論（最初のまえがきみたいなもの）の後半部分として執筆したものです。この特集は私が豆蔵に在籍していたころに、大西さんと私で企画したもので、多くのイケてる技術者の方々にお願いして各パートを執筆してもらったものです。以下が目次です。 総論 ソフトウェアテストの現状と知っておくべきこと Part1 独立したテストチームとしてのテスト計画・テスト設計仕様 テストをスムーズに行う?管理者のための“段取り”術 品質を向上させるためのインシデントレポートの書き方 テストツールの活用 自動化できる/できないの判断のコツ Part2 開発者による開発者のためのDeveloper Testing OSSのツールを使って静的テストを自動化
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の）若手は、将来も働き続けるための力を付けるための組織内での教育が、（昔ほど）なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業
はじめに 面倒なWEBブラウザの定型作業を自動化したくて。 WEBブラウザの自動操作には定番のSeleniumを利用する。 Seleniumは主にウェブブラウザのテストに利用されているが、テスト用途以外でも利用はできる。 なおウェブスクレイピングが目的であれば、scrapeとかgoqueryなどを利用するほうが簡単。 それでもSeleniumを利用するのは、 実際のブラウザが利用できるという点であり、以下のような利点があると思っている。 IEなど特定のブラウザのみをサポートしているサイトの自動操作 ごりごりのJavascriptやFlashを利用されているサイトの自動操作 証跡として画面のスクリーンショットを取得できる 前提知識 WebDriverを介することで、スクリプトとしてJava,C#,Pythonなど多くの言語から利用できる ブラウザごとにWebDriverが用意されており、１つ
テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ
PHPカンファレンス2016 レポート 和田卓人さん、PHPで堅牢なコードを書く—例外処理、表明プログラミング、契約による設計 〜PHPカンファレンス2016 2016年11月3日にPHPカンファレンス2016が開催されました。本稿では、ゲストスピーカーである和田卓人さんによる講演「PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計」についてレポートします。 PHP7では例外や表明の機能が大幅に見直され、強化されました。この講演では、例外処理を設計する際の基本的な考え方や、表明（assertion）の使い方、そして表明と例外を使い分け、堅牢なコードに導くための設計手法「契約による設計（Design by Contract）」の考え方を説明しました。 導入 はじめに、和田さん自身が監訳に関わった『SQLアンチパターン』に掲載されているコードを、よりひどくさせた
秋のJavaScript祭 in mixi 〜秋のJavaScript収穫祭〜 2016-10-15 https://javascript-fes.doorkeeper.jp/events/52089
ジョエル･テストとは、面接時に求人応募者が面接官に聞くものとして広く受け入れられている「12個の役立つ質問」のことです。このテストはJoel Spolsky氏が考案しました。彼のブログは開発者の間では有名で、この12の質問も広く知られていました。そして、スタック･オーバーフロー（創設者の1人がJoel Spolsky氏）によって、さらに普及することになります。スタック･オーバーフローの求人ページでは、求人を出す側の企業向けにこの質問を使ったチェックリストが用意されています。以下がそのジョエル･テストです。 ソース管理の仕組みを導入していますか？ １ステップでビルドを行えますか？ ビルドは毎日実行していますか？ バグデータベースを持っていますか？ 新しいコードを書くまえにバグを修正していますか？ 最新スケジュールを常に社内で共有していますか？ 仕様書を持っていますか？ プログラマは静かな作業
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
>>> $ py.test ../tests/test_webapi.py =============================================================================== test session starts =============================================================================== platform darwin -- Python 2.7.5 -- py-1.4.31 -- pytest-2.7.0 rootdir: /Users/*****, inifile: pytest.ini plugins: cache, django, pep8, pythonpath collected 2 items ../tests/test_webap
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
こんにちは。投稿推進部ディレクターの新里です。 私はディレクターとして、動作確認に積極的に関わるようにしています。その理由は、担当したサービスをより多くのユーザーに快適にご利用いただきたいという思いからです。 せっかくサービスを使おうと思っていただいたユーザーがいるのに、不具合をきっかけに不便だなと思ったり、使わなくなったりするのは、私だけでなく開発しているメンバー全員にとっても、すごく残念なことだと思います。 そんな状況を少しでも減らすために、私が普段の業務の中で動作確認を行う時に心がけていることをご紹介したいと思います。 心がけていること6つ なるべく実機で確認する 条件を組み合わせる タイミングを狙う あえて余計なことをやる エンジニアに聞く きちんと管理する 1.なるべく実機で確認する シミュレーターで動作確認することも可能ですが、実際にユーザーが使うのに近い状態で画面を見て、違和
昨日のエントリでも書いたきょんくんとの会話なんだけど、なんとなく、コメントとテストは同じように扱えるんではないかという認識のもとで話がすすんでた。もちろん、コメント書けばテスト書かなくていいとかそういうのではなくて。 テストは、書きやすい対象と書きにくい対象がある。関数的に計算を行うコードの場合はテストが書きやすい。一方で、関数的ではなく副作用のあるコードはテストが書きにくい。データベースを扱ったり通信したりUIがあったり。 そして、そのようなテストを書きにくいときに、コメントはテストのように品質のために使えるんではないか。 で、問題は、どのように品質のために使うかということなんだけど、コードレビューのときの指針として使えばいいんじゃないかなと思った。 コードレビューのとき、コードだけを見ていると、名前付けとかコードの順番とか条件文の使い方とか、体裁的なものだけのレビューになりがち。そこで
© NISHI, Yasuharu 同値分割ってなんだろう？ 九州ソフトウェアテスト勉強会（仮） Vol.7 2014/5/28（水） 電気通信大学 大学院情報理工学研究科 総合情報学専攻 経営情報学コース 西 康晴（Yasuharu.Nishi@uec.ac.jp, http://qualab.jp/） © NISHI, Yasuharu 2 Profile Assistant professor: the University of Electro-Communications, Japan (also providing consultancy service to industry on testing and TQM) President: Association of Software Test Engineering, Japan (ASTER) President: Jap
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
