コード品質の向上(その1)~ Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「コード品質の向上(その1)~ Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>> << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   開発プロジェクトにおける最大の成果物は “動くソフトウェア” であり、またその “ソースコード” でもあります。 一方で全く同じように “動くソフトウェア” であったとしても、「ユーザーからのフィードバックを受け、継続的に価値を提供し続けていく」という視点で考えた際に、メンテナンスが容易な “ソースコード” と、冗長なコードが多かったり、メソッド名がわかりづらい “ソースコード” では、ソフトウェアのライフサイクルを勘案した時に前者のほうがより価値があるのは明らかです。 今回のソリューションシナリオでは、「コード品質の向上 ~その1~」と題して、ソースコードの品質を向上し、よりメンテナンス性の高いコードを書くための Visual Studio 2012 の支援機能を紹介します。   開発チームにおいてコードのメンテナス性に関する取り組み姿勢や基準を共有しないままプロジェクトを進めてしまうと、以下のような問題が発生します。 チームメンバーそれぞれが勝手な命名規則や、独自のコーディングルールに基づいてコードを書いてしまい、プロジェクト全体としてのまとまりがなくなってしまう。また、そのためにコードの可読性が大幅に落ちてしまう。   メンバーによって「メンテナンス性」、に対する意識が異なるために、チーム全体としての基準があいまいになってしまう。またプロジェクトが進むにつれ、どうしても「甘い」基準に引きずられてしまう。   場当たり的なコーディングにより、コピー&ペースト等で似たようなコードが散在してしまい、問題が発生した際に修正個所が複数個所にまたがってしまう。   開発プロジェクトにおいてはアプリケーションのライフサイクルの観点から長期的な視野に立ち、メンテナンス性もソフトウェアの品質の一部であるととらえ、コードの品質を向上させることが重要になります。   コードのメンテナンス性、品質に関する課題に対し、以下のようなプラクティスを推進することで、コードの品質の向上への取り組みを進めることが可能です。   コーディング規則やコーディングのプラクティスを活用しよう チームで開発を行う場合、それぞれの開発者が自分の基準で命名を行ったり、コードの見た目を変更したりすると、コード全体としての統一性がかけてしまい、保守性が犠牲になってしまいます。コードの共同所有を進め、チーム全員でコードのメンテナンスがスムーズに行えるよう、標準的なコーティング規則を定めておきましょう。 また、過去の経験から得られた知識や守るべきガイドラインをまとめておき、共有することでチーム全体でのコード品質に対する意識やナレッジを高めましょう。 例えば、MSDN…

0

手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>> << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   開発プロジェクトにおける手動テストは、開発者が行う単体テストや結合テストと異なり、ユーザーの代弁者としてアプリケーションに対する操作を通じて品質検証を行う活動です。従ってアプリケーションに対しては技術的な視点よりも、ビジネス的な視点に立って検証を進める必要があります。   このソリューションシナリオでは、手動テストの実施に当たって、どのようなことを考慮することで手動テスト自体の品質向上を図っていくことができるのか、またその中で Visual Studio 2012 のどのような機能を活用できるのかを紹介します。   開発の現場において手動テストを実施する際には、経験豊富なテスト担当者によって用意されたテストドキュメントをもとに、担当者が実際にアプリケーションを操作しながらアプリケーションの検証を進める、といったスタイルがとられることが多いのではないでしょうか? この過程においては、以下のような課題が発生しがちです。   経験豊富なテスト担当者に依存しがちになり、他のメンバーにとって十分なドキュメントが用意されていなかったり、品質基準の定義があいまいなままテストが進んでしまう。   手動テスト(特に探索的テスト)においてバグに遭遇した場合に、再現性のあるシナリオの特定に手間がかかってしまう。   手動テストによってアプリケーションのどれだけの割合がテストできたのかが把握しづらい。   いくつかの条件の組み合わせが必要なテストシナリオの場合、アプリケーションの操作が長くなってしまい、テスト途中における操作の抜けや誤りによって、再度テストを初期状態からやり直す必要がある。   同様の場合に、操作の誤りに気づかないままテストを続けてしまい、間違ってアプリケーションのバグを報告してしまう。あるいは、アプリケーションのバグに気づかずにアプリケーションをリリースしてしまう。   自動化が行いやすい単体テストや負荷テストと異なり、手動テストは人による関与が大きいため、設定したテストシナリオによってアプリケーションの品質が十分に検証できるのか、テストにおけるアプリケーションの操作自体に誤りがないのか、等の基準があいまいなまま、担当者の経験に依存して実施されることが多くあります。   このような問題を解決し、手動テストの品質を向上するには、以下のようなプラクティス(行動)の実践が挙げられます。   手動テストの実施環境を整えよう 手動テストにおいては、特別な実施環境を用意することなく、テストシナリオが書かれたドキュメント(多くの場合は Excel や Word に書かれた操作手順)と、アプリケーションを使用するであろう一般的なユーザーと同様のPC環境でテストを実施することがほとんどです。 しかし、テストにおけるアプリケーション操作の間違いを最小化し、またバグ(あるいはその可能性)を発見した際に、再現性のあるシナリオ特定をスムーズに進めるためにも、テスト担当者に対する支援環境を用意し、テストメンバー全員が同じ手順で、同じ品質基準をもとにテストを実施できる環境を用意すべきなのです。 手動テストの実施環境としては、(1) アプリケーション操作を間違わないためにもわかりやすくシナリオ(操作手順)を伝える環境、(2) テスト実施時の操作やアプリケーションのふるまいを効率的にまとめることのできる環境、(3)…

0

チーム開発における単体テストの実践~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「チーム開発における単体テストの実践~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>>   << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>> ソフトウェア開発において、「開発者テスト」とも位置づけられる「単体テスト(Unit Test)」は、Java における JUnit、.NET 開発における NUnit、また Visual Studio 2005 から提供されている Microsoft Test、といった様々な Unit Testing Framework の登場により、開発現場において広く受け入れられるようになってきました。 また一方で、Test Driven Developmenr (TDD)に代表される方法論の浸透により、単体テストは単なる「テスト」という位置づけではなく、「設計」ツールの一部としても活用されるようになりました。   通常のコードに加えてテストを書く必要のある単体テストの実践は、一見すると、書くべきコードが増え、生産性および保守性の両面でマイナスの影響を与えるように思われがちですが、実際には洗練された設計とコード変更に対する自信をもたらし、開発者に多くのポジティブな影響をもたらしています。     このソリューションシナリオでは、チーム開発における単体テスト実践の際にどのようなプラクティスがあり、また Visual Studio 2012 の機能をどのように活用できるのかを紹介します。   単体テストは手軽にできるテストである反面、チーム開発においては以下のような課題が発生しがちです。       チーム開発においてはメンバー間でのテストに対する「レベル感」の違いがあり、テストの抜け、漏れが起こったり、あるいは必要以上のテストを用意してしまい余計な工数を消費してしまう。   現場においては、新規のコードに新規のテストを書く、というだけでなく、既存のコードに対する単体テストのニーズや、異なる…

0

受け入れテストのリスクコントロール~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「受け入れテストのリスクコントロール~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>>   << ”Visual Studio 2012 ソリューションシナリオ” では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>   ソフトウェア開発において、受け入れテストがなぜ重要なのでしょうか?   受け入れテスト、は開発チームが実施してきた開発プロセス~要求定義、開発、そしてテスト~の最後の活動として、ユーザーによって実施される活動です。受け入れテストが完了することにより、開発チームの努力が具体的なものとして認められ、そしてその価値をユーザーに届けることができる、重要な区切りとなるのです。   このソリューション シナリオでは、受け入れテストにおけるリスクコントロールのためにどのようなプラクティスがあり、Visual Studio 2012 がどのようにその実践を支援するのかを紹介します。   受け入れテストにおけるビジネス上の課題、リスクにはどのようなことがあるのでしょうか? 例えば、以下のようなことが起こりがちです。   要求で明示されていない事柄に対する期待値と実現内容のギャップが存在する(例:表形式の一覧情報の表示画面において、任意の項目をキーにしたソートができない、等必要な機能が実装されていない)   要求と実際の開発のギャップに開発後期で気づくため、スケジュール的に後戻りできず、また責任の所在もあいまいなまま不十分なソフトウェアを受け入れてしまう。   これらの原因の一つは「あいまいな要求」によって引き起こされます。   「ソフトウェア開発」は、ユーザーと開発チームの共同作業であり、その認識を如何にすり合わせることができるか、が成功のカギを握っています。 「あいまいな要求」をそのまま放置し、お互いに「行間を読む」ことで、自身に都合のよい内容を「期待」しつつ、ギャップを埋める努力をせずに開発を進めていると、受け入れテスト間際や、あるいは受け入れテストのその瞬間に、ギャップが顕在化し、問題になってしまうのです。   このような問題を解決し、受け入れテストにおけるリスクをコントロールするための本質的な方法は、ユーザーと開発チーム(および、関連するその他の関係者)の認識を早期からすり合わせ、ギャップの顕在化を早めに行うことです。 これを実現するための代表的なプラクティス(行動)として、以下のような項目が挙げられます。   早期から、頻繁にユーザーを巻き込み、要求の定義と検証を段階的に行おう。 「あいまいな要求」への対策としてはいくつかの方法が考えられますが、「ユーザーを巻き込む」というのが最も本質的で、かつ効果的な対策といえるでしょう。 もし、「顧客があまりに多忙で、そもそもこのソフトウェアを「なぜ作らねばならないのか」といったプロジェクトの本質を説明する時間すらさけぬだと知ったら、本来そんなソフトウェアは作られるべきではない」のです(※)。まずは、開発の予算だけでなく、プロジェクトに関わろうとするコミットをユーザーから得ましょう。そして、要求定義を一度だけ行うのではなく、プロジェクトのチェックポイントを設定し、段階的に要求の定義と検証を行うようにしましょう(アジャイルプロジェクトであればイテレーションやデリバリーごとに。ウォーターフォール型であっても各フェーズ毎に見直すことは可能です)。 ※ 「アジャイルサムライ ― 達人開発者への道」 ISBN978-4-274-06856-0 P.70…

0

Visual Studio 2012 の Update 1 がご利用いただけるようになりました。

※ 本 Blog ポストは、Microsoft において開発ツール製品(Visual Studio / .NET Framework)の開発チームをリードする Somasegar (ソマセガー)の Blog ポスト 「Visual Studio 2012 Update 1 Now Available!」 を簡易翻訳したものです。     “最初に”、非常に興奮しています。 この興奮は、他者との競争によって感じているものではありません。この興奮は、むしろ、自身とのあるいは過去の自分たちとの競争によるものだ、といってよいでしょう。そして、我々がなしえてきた事、あるいはなしえてきた方法についてそれらを日々改善し、さらに良いものと届けようとしてきた事、また、我々が提供する開発ツールを使っていただいている開発者の方々や開発チームの皆様に対して提供することのできる価値に対して興奮しているのです。   9月に行われた Visual Studio 2012 と .NET Framework 4.5 のローンチイベントにおいて、私は継続的に価値を届けること(Continuous Value Delivery)に対して固い約束をし、またより短い期間で Visual Studio のアップデートを提供する新しいアプローチについてお話をさせていただきました。         そして、お約束したアップデートの最初のリリースとなる Visual Studio 2012 Update 1 が本日からご利用いただけることになったことをお知らせできることに興奮しています。   Visual Studio 2012…

0

ソフト開発未来会議に新しい記事:開発現場の要請で生まれたアーキテクトチーム

ソフト開発未来会議の「開発者のためのケーススタディ」に新しい記事が掲載されました。 http://developerscafe.jp/future/casestudy/vol02_necsoft.html 今回は、NECソフトのアーキテクトチームのインタビュー記事です。 NECソフトでは、顧客の業種にあわせた縦軸と、テーマ別の横軸の2つの組み合わせによるマトリクス型の組織構造をとられています(マトリクス型組織にかんしては、たとえばこのあたりを参照ください)。今回取材させていただいたチームは、このうちの横軸の分類によって位置づけられているチームで、技術的な専門知識を提供することを一つのミッションとされているチームです。 たとえば、ある業界に属する顧客Aのプロジェクトが立ち上がると、業種別の縦軸側で分類されるチームメンバーと、横軸側で分類されるチームメンバーがプロジェクトチームとして活動するのですが、その中で技術的な観点からシステムの設計や、技術検証に携わる、といったイメージでしょうか?  (マイクロソフトも顧客軸で分類されたチームと、製品/技術別に分類されたチームの組み合わせで動くので、その辺はよく似ているなぁ、と思いました)  今回の記事もとてもおもしろい記事になっていますので、ぜひお読みいただければ、とおもいます。 http://developerscafe.jp/future/casestudy/vol02_necsoft.html では!

0

Visual Studio 2008 のホワイトペーパーを一挙公開&目次ページの公開

Visual Studio 2008 に関するホワイトペーパーを一挙公開し、これにあわせてこれまで公開していたホワイトペーパーもまとめて目次のページを用意させていただきました。 http://www.microsoft.com/japan/msdn/vstudio/using/paper/ 米国にて公開されていたホワイトペーパーの翻訳を中心に公開しています。今回は Team System 系のドキュメントが多数翻訳されていますので、ぜひ参照いただき、気になったホワイトペーパーはダウンロードや印刷をいただき、ご活用いただければ幸いです。 特に以下の3つのドキュメントについては、ぜひ一度ご覧ください。 アジリティ (俊敏性) 向上のためのツール ( XPS / PDF ) XPの提唱者 Kent Beck がアジャイル開発におけるツールへの期待について書いたホワイトペーパーです。  Web アプリケーションのパフォーマンステストガイダンス( XPS / PDF ) Patterns & Practices (通称PAG(パグ)チーム)による Web アプリケーション開発におけるテストの設計、実施、分析の実践ガイドです。 Team Foundation Server を利用した アプリケーション開発概観( XPS / PDF ) マイクロソフト日本法人のコンサルティング部隊(マイクロソフト コンサルティング サービス(MCS))による、Team Foundation Server を利用したチーム開発の概要説明です。   それでは!

0

Think IT での Team System の記事(by 長沢さん)

この Blog の右側でも「ALM大好きエバンジェリスト 」として紹介させていただいている長沢さんが Think IT にて Team System の連載記事を書かれています。  http://www.thinkit.co.jp/article/26/1/ テーマは「バグの管理」で、長沢さんらしいやさしいトーンの記事です:-) まだご覧いただけていない方は、ぜひご覧ください。 それでは!

0

Visual Studio Team System 2008 のトレーニングについて。

以前、パートナー様向けトレーニングである mstep(エムステップ)についてエントリさせていただきましたが、いよいよ11月27日(火)から、Visual Studio Team System 2008 に対応したテストのコースが開始されます。 Visual Studio Team System 2008 によるテスティング実践 このコースでは、Visual Studio 2005 におけるテスト機能はもちろん、Visual Studio Team System 2008 にて強化された機能を含む形で、テストに関して1日かけて包括的に学んでいただけるコースとなっています。 また、エバンジェリストによる訪問セミナー Microsoft On でも Visual Studio Team System 2008 の以下のコースを実施しています。 開発者テストからはじめるチーム開発の実践 Visual Studio Team System の活用エッセンス 実は Microsoft On に関しては非常に人気が高く、今年開催分に関してはすでに申し込みを終了させていただいております。来年1月、および2月開催分については12 月 3 日 (月) 10:00 から 12 月 7 日 (金) 17:00 までの期間、受付を行わせていただきますので、ご興味をお持ちいただけた場合は Microsoft…

0

ステップ7 “アプリケーション品質の向上編”の公開を開始しました。

マイクロソフトの提供するオンライン ラーニング系コンテンツにおいて、300秒シリーズ、10行シリーズに続く技術系コンテンツに位置づけられているものとして 「ステップ7」シリーズがあります。 「ステップ7」シリーズは、Webcast(ビデオ)とハンズオンラボを組み合わせることで、Webcast によって概要をつかんでいただいた上で、ハンズオンラボにより実際に手を動かしながら、新しい機能を学んでいただくという位置づけのコンテンツです。 今回、約1年ぶりにこのステップ7シリーズにおいて新しいコンテンツとなる「Visual Studio 2005 Team System によるアプリケーション品質の向上編」の公開を開始しました。 http://www.microsoft.com/japan/msdn/thisweek/step7/#VSTS_Quality 今回の「アプリケーション品質の向上編」では、チーム開発において必要となるタスクに対し、Team System が提供するさまざまな支援機能を紹介します。 第一回は Webcast のみの提供ですが、この後、毎週水曜日公開、というペースで全5回にわたり展開予定です(Database Professionals の機能も取り上げます)。 なお、今回のコンテンツは、mstep の「Visual Studio Team System によるテスティング実践」コースを担当いただいております、NRI ラーニングネットワークの荒木様、および矢嶋様にご協力いただいております。(mstep コースの 2008 対応版、「Visual Studio 2008 Team System によるテスティング実践」も11/27(火)に東京にて開催されますので、ぜひご利用ください。詳しくは –> http://www.microsoft.com/japan/partner/developer/default.mspx) ご活用いただければ幸いです。 それでは。

1