手動回帰テストマニフェスト
回帰テストを自動化することは必ずしも最適解ではない。2018 fall Online Testing Conferenceで、Brendan Connolly氏はこう主張した。彼は「手動回帰テストマニフェスト」を発表し、それを使うことで、機能テストと回帰テストを区別し、テストを自動化するかどうか決める方法を紹介した。 手動回帰テストマニフェストは、アジャイルマニフェストに示された価値をモデルにしている。これはオープンな目的の宣言であり、品質について話し合い、テスターがそれにどのように貢献するかを探るためのフレームワークだ。 Connolly氏は「テスト」の問題、特に回帰テストを解決する銀の弾丸がほしいという要望があるようだ、と述べた。適切なツールを購入し、すべてのテストを自動化し、それをAIにやらせたいわけだ。これらに価値がないわけではない。ただ、ウォーターフォール・ソフトウェア開発の時代
持続可能なソフトウェアとアジャイル
持続可能なソフトウェア(Sustainable software)は、変更をより短期間で顧客に提供するとともに、バグ可能性の低減、アプリケーションの総所有コストの削減、ビジネスアジリティの向上を可能にする。持続可能なソフトウェアの開発には、かんばんやスクラム、エクストリームプログラミングのプラクティスが利用できる。ソースコードの自動解析、専門家による技術的アーティファクトのレビュー、ベンチマークデータの比較を組み合わせることで、ソフトウェアの持続性を検証することが可能になる。 Software Improvement GroupでCTOを務める、“Building Maintainable Software”著者のJoost Visser氏は、Agile Consortium Belgium 2018カンファレンスで、持続可能なソフトウェアのアジャイル開発について講演し、Ventouris
マイクロサービスの強み弱み
マイクロサービスが最近話題になっており、噂も生まれている。10年以上に渡り、重たく、扱いにくいSOAソリューションが続いたが、マイクロサービスはそれを置き換える待望のソリューションなのだろうか。それとも単に一枚岩のソリューションズよりも単純なだけなのか。 この問題を議論する前に、マイクロサービスの定義を紹介しておいたほうがいいだろう。James Lewis氏とMartin Fowler氏はMicroservicesという記事でマイクロサービスという設計スタイルを以下のような手法として定義している。 小さなサービスの組み合わせによって単一のアプリケーションを開発する方法で、各サービスはそれぞれのプロセスで動き、軽量な仕組みで通信します。通常はHTTPです。また、各サービスはビジネスの可能性の周辺に構築され、完全自動化された配置の仕組みで独立して配置できます。最低限の中心的な管理システムがあり
マイクロサービスの開発とテスト
Agile Testing Days 2015でRedgate SoftwareのJose Lima氏が，マイクロサービスの開発とテストに関する自身の経験について講演した。InfoQは氏とのインタビューで，マイクロサービスを採用したプロダクト開発のメリットとデメリット，マイクロサービスによるプロダクトの品質向上，マイクロサービスのテストに必要なテスタのスキル，マイクロサービスの開発とテストから学んだことなどについて聞いた。 InfoQ: マイクロサービスを採用したことで感じたメリットやデメリットについて，詳しく説明して頂けますか？ Lima: 最初にお断りしておきたいのは，私が今回採用したマイクロサービスアーキテクチャは内部ユーザを対象に開発した，社内利用が中心のサービスだということです。私たちが“ユーザ”(私は社内開発チームに在籍していますので，ユーザの大部分はRedgate Softw
State of Testing 2015調査
State of Testing Survey 2015の目的は，テスト技術やプラクティス，自動テストなどの採用状況を調査し，テスト担当者が直面している課題に対する見解を提供することだ。テスト担当者がテスト担当者のために行うこの調査は，PractiTest社のJoel Montvelisky氏が，Tea-Time with Testersの協力を得て実施している。 State of Testing調査は2013年に初めて実施された。2015年の調査はその２回目になる。 私たちは皆，テストコミュニティをもっと理解したいと思っています。それが1年前，最初のState of Testing Surveyを行った理由です。その時の調査で私たちは，テストを担当する仲間に，彼らの仕事について，課題について，そしてプロフェッショナルとしての将来に対する考えについて尋ねました。(...) [第２回のSta
アジャイルで品質とベロシティを両立する
アジャイルソフトウェア開発チームは，開発した製品が十分な品質を持つことを保証しなくてはならない。一方でマネジメントからは，より多くの機能をより早くユーザに提供するために，ベロシティ(開発速度)の向上を同時に期待されることが少なくない。何人かの専門家が品質とベロシティの関連を検討し，その両方を向上するための方法を提案している。 Bob Galen氏は，開発速度を向上するという点におけるソフトウェア品質の重要性を，ブログ記事“Read my Lips - Agile isn’t Fast!”に書いている。 アジャイルは“品質競争”ですが，完全性や責任やバランスを競うならば，すばらしい“スピード競争”にもなり得ます。ただしそれ(スピード)は無償ではありません ... もしうまくプレイできなければ，アジャイルを採用したことで，かえって以前のアプローチよりも遅くなってしまうかも知れないのです！ チー
アジャイルにおける技術的プラクティスの重要性
アジャイルを採用している組織は，時として，期待したメリットが得られないことに不満を訴える場合がある。考えられる理由のひとつは，アジャイルの価値観と原則を支える技術的なプラクティスの実践に対して，十分に注意を払っていないことだ。 "The State of Agile Software Development"と題したブログ記事でMatt Badgley氏が述べた意見が，アジャイルコミュニティの中に，エンタープライズアジャイルとスケーリングアジャイルに関する議論を引き起こしている。 企業組織にとって，エンタープライズアジリティへの対応 - ビジネスあるいは市場の変化に対する，迅速かつ効果的な適応能力が必須であるというのは，衆目の一致するところです。エンタープライズアジリティのニーズを満たす- そのために大企業は，ソフトウェア開発や他の部門へのアジャイルプロセス採用を推進しています。エンタープ
自己組織化チームとは何か？
最後の疑問から始めることにしましょう。チームとは何か？ チームの専門家であるJ. Richard Hackman氏と同じく，私たちにとっても，多くの場合，まったく明確ではありません。これは自分の望むものをそこに見出すという，一種のロールシャッハテストのようなものです。チームに対する考えや意見が違えば，心に思い浮かぶものも違ってきます。現実のチームは多くの場合，いわゆる共同作業グループと混同されています。共同作業グループが互いに近距離で作業していても，それぞれの仕事を実施する上での依存関係がないことに対して，真のチームには４つの特徴があります。 第1に，切実な使命を果たすための共同作業。 第2に，情報の流れ，他の組織的単位との整合性，リソース，意思決定方針といった面での明確な境界。 第3に，この境界内において自己管理の権限，そして 第4に，合理的な期間にわたる安定性。 さらに，すべての組織単
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルプロジェクトにおけるパフォーマンスエンジニアリング
Missing Test Competencies in Agile
アジャイルで欠落するテストの能力
自動Android UIテストのためのGoogleストラテジー
従来型テストの先を行くアジャイル開発
モノのインターネットをテストする
テスト容易性のためのシステム設計
テストの独立性とアジャイルのコラボレーションのバランスをとる
アジャイルで成功を収めるための管理行動
エンタープライズ開発者のためのツール表集
Functional GUI Testing Automation Patterns
Eclipse Jubula: 機能テストの自動実行ツール