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

0

Azure、ASP.NET、C#、F#、ALM、Visual Studio、そしてさらに。あすから Advent Calendar はじまります♪

  今年があと1カ月で終わりだなんて、信じたくないっ!     と叫びたいところですが、いよいよ明日から12月。 マイクロソフトの開発者コミュニティの皆様が、年のしめくくりにと各種 Advent Calendar を企画されています。   読むのはもちろん、書くほうとしてもぜひ参加くだいませー♪   ◆ Windows Azure Advent Calendar jp: 2012 ~サンタさん日本にデータセンターをください   ◆ One ASP.NET Advent Calendar 2012 ~ ASP.NETに関するネタはなんでもOK!   ◆ Visual Basic Advent ~ Visual Basicが絡めば.NETでもVBでもOfficeでもOK!   ◆ C# Advent Calendar 2012 ~昨年に引き続き C# アドベントカレンダーでございます。   ◆ F# Advent Calendar 2012   ◆ ALM Advent…

0