InfoQ ホームページ テスト に関するすべてのコンテンツ
-
OracleがRustで書かれたコンテナランタイムを含むオープンソースのコンテナユーティリティをリリース
Oracleは3つのオープンソースのコンテナユーティリティを発表した。Smithは、Open Container Initiative (OCI)のイメージに準拠したイメージビルダであり、単一の実行可能ファイルと依存物で構成される"マイクロコンテナ"を作成する。Crashcartはマイクロコンテナのデバッグツールで、Linuxバイナリのイメージを既存のコンテナにサイドロードできる。RailcarはRustベースのコンテナランタイムでOCIランタイム仕様を実装している。
-
QCon New York 2日目 – Developer Experienceトラックのまとめ
QCon New Yorkの2日目、Developer Experienceトラックが行われた。開発プロセスをシンプルにする方法、摩擦を取り除くためのアイデア、コードからプロダクションまでの時間を短縮する方法、開発プラクティスにおいてより効果的になる方法について検討された。
-
自動受け入れテストは継続的デリバリをサポートする
自動受け入れテストは、継続的デリバリのスタイルを持つテスト戦略に欠くことのできないコンポーネントであり、システムの振る舞いに対して、異なった重要な洞察を与えるものだ。Dave Farley氏の主張によると、開発者は、受け入れテストが動作して通ることに責任を持たなければならない。開発チームとは別にQAチームを持つのは望ましいことではないだろう。
-
Google Chrome DevToolsのアップデート
Chrome DevToolsの次のバージョンには、開発者が高速なWebページを構築するのを助け、複雑な非同期コードのデバッグを容易にする、数多くの新機能が含まれている。Google I/O 2017で、Paul Irish氏がこれら数多くの新機能について紹介した。
-
MicrosoftがApplication Insights Support for Azure Functionsを発表
Microsoftは先頃、Application Insights for Azure Functionsの初期プレビューを発表した。2つのサービスを統合することにより、インスツルメンテーションコードの組み込み、コードのパフォーマンスをトレンド表示するポータルなどが実現する。アラートや外部Webフックへのコールアウトを生成する監視しきい値の設定も可能だ。
-
自動受け入れテストに関する実用的ヒント
同値分割、境界値分析、リスクベーステストのようなテスト技術は、何をテストして、いつテストを自動化するかを決めるのに役立つ。InfoQは、様々な種類のテスト、十分によい受け入れテストを書くこと、テストの自動化を決める基準、テスト自動化の適用方法と実行可能な仕様の作成方法について、Adrian Bolboaca氏に話を聞いた。
-
プログラマブルインフラストラクチャをテストすることは可能か？Matt Long氏はQCon Londonで答えが"イエス"であると裏付けた
QCon Londonにて、OpenCredoのQAコンサルタントであるMatt Long氏は”Testing Programmable Infrastructure with Ruby”のプレゼンテーションを行った。重要なポイントには、プログラマブルインフラストラクチャを単体、結合、受け入れのレベルでテストすることは可能である、ということが含まれていた。Rubyは結合、受け入れテストのためのプログラミング言語として十分な能力があり、それはテスターとシステム管理者の両者から理解されていることが多い。
-
継続的デリバリによるITパフォーマンスの改善
継続的デリバリのもたらす大きなメリットのひとつはリリースのリスク低減である – 包括的な自動テスト(Comprehensive test automation)と継続的インテグレーションとは、ITのパフォーマンスに最も大きな影響を与えるプラクティスだ。継続的デリバリとITパフォーマンスに関する調査から、継続的デリバリのプラクティスの実践はより高いITパフォーマンスにつながるだけでなく、ハイパフォーマによるテンポの向上と高レベルの安定性を実現することが明らかになった。
-
テスタにはマーケティア思考が必要である
テスタはストーリを共有し、自身の懸念について語ることによって、自らの仕事に対する人々の関心を得ることが必要だ。これからのテストはテスタに対してマーケティア(marketeer)の思考を求めるようになる。そのためにはブログや記事、講演、ビデオといった物作りや物書きから始めて、それを共有する、という方法がある。
-
TDDはアーキテ���チャに悪影響を与えるか？
Uncle Bobとしても知られ、Agile Manifestoの共著者でもあるBob Martin氏は、TDDがアーキテクチャに悪影響を及ぼすかどうかについての評価を最近公開した。この議論の大半を、テスト駆動アプローチに従うことで、高レベルの設計と実装コードの一般的な保守性の両方に否定的なインパクトがあるかどうかに割いている。
-
アジャイルテストの習得
一般的に、アジャイル開発プラクティスを採用すると、ソフトウェアのデリバリーを高速化できると受け取られている。しかし、開発プロセスにQAプラクティスを直接組み込んでおかないと、プロダクトの品質低下は避けられない。たえず高品質を実現するためには、最後にテストするのではなく品質を作り込めるように、仕事のプラクティスとチームの役割の両方を変える必要がある。
-
分散開発を成功させるには
分散開発には効果的なコミュニケーションが重要である – それには健全で多様なコミュニケーション手段を追求し、フィードバックを促進するための共感を双方向で確立し、モチベーションを注視し続けることが必要だ。分散型チームでは、アイデアから製品までの完全なデリバリに対する当事者意識と責任感を共有することによって、チームメンバがより積極的で創造的になることができる。
-
TextTestを使った承認テスト
承認テスト(Approval Testing)は、現在のコードの出力を、“承認済”バージョンのものと比較するテスト技術だ。承認済バージョンは、事前にテスト出力を調査して、その結果を承認することによって作成する。要件が変更された場合でも、承認済バージョンを再検討することで簡単に更新することができる。テキストベースのオープンソース機能ツールであ���TextTestは、この承認テストをサポートする。
-
デッドコードは取り除かなければならない
デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。それは考え方と文化の問題だ。
-
自分が課した限界を取り除く
ひとは困難にぶつかると限界を感じることがある。スローダウンしたり、トライしなくなったりする。これは現実にある問題かもしれないが、実際には想像上のものかもしれない。時として、あなたを抑えているのは、あなた自身しかいないのだ。Joep Schuurkes氏はそう語る。生存のルールが邪魔をすることもある。そのときはルールを破る必要がある。