Cydn Jasst07

608 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
608
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cydn Jasst07

  1. 1. ソフトウェアシンポジウム報告会 サイボウズ株式会社 品質保証部 伊藤 彰嗣
  2. 2. 目次 <ul><li>ソフトウェアシンポジウムとは? </li></ul><ul><li>セミナー内容紹介 </li></ul><ul><ul><li>基調講演 </li></ul></ul><ul><ul><li>テスティングライブ </li></ul></ul><ul><ul><li>受講した講演内 Topics </li></ul></ul><ul><ul><li>講演資料内 Topics </li></ul></ul><ul><li>今後の課題 </li></ul><ul><li>議論 </li></ul>
  3. 3. ソフトウェアシンポジウムとは <ul><li>ソフトウェアテスト技術を中心 とした大規模セミナー </li></ul><ul><ul><li>http://www.jasst.jp/index.html </li></ul></ul><ul><li>日本で開催されるテストセミナーとしては、最大規模 </li></ul><ul><ul><li>2日間延べ参加人数 1500 人 </li></ul></ul><ul><li>基本的な項目から、最先端のテスト技術まで様々 </li></ul><ul><ul><li>2日間 総計 45 件を超えるセミナーあり! </li></ul></ul>
  4. 4. 基調講演 <ul><li>Ed Yourdon 氏 </li></ul><ul><ul><li>Death March Project </li></ul></ul><ul><ul><li>http://www.amazon.co.jp/Death-March-Yourdon-Press-Computing/dp/013143635X/ref=pd_bbs_sr_1/503-2459524-2451947?ie=UTF8&qid=1172745883&sr=8-1 </li></ul></ul>
  5. 5. Death March にならないために <ul><li>3原則 </li></ul><ul><ul><li>◆ プロジェクト全体のステークホルダを早期に把握すること。 </li></ul></ul><ul><ul><li>◆ トレードオフの交渉を行う際は、必ず過程を </li></ul></ul><ul><ul><li> ステークホルダと共有し、リスクを軽減していくこと。 </li></ul></ul><ul><ul><li>  ⇒ 工数の単純計算は、外部からの影響を強く受ける! </li></ul></ul><ul><ul><li>◆  必ず証拠となるドキュメントを残す。 </li></ul></ul><ul><ul><li>  ⇒ 適宜合意内容は見直すこと。 </li></ul></ul><ul><ul><li>-> 試験は『プロジェクト』。 </li></ul></ul><ul><ul><li>-> 「交渉」・「見積もり」・「進捗管理」に、誠実に取り組むこと。 </li></ul></ul>
  6. 6. テスティングライブ <ul><li>実際にサービスとして提供されているシステムの </li></ul><ul><li>  バグを、30分間でいくつ見つけられるかを競う! </li></ul><ul><li>対象製品 </li></ul><ul><li>   ChangeVision 社 THICHORD( トライコード) </li></ul><ul><ul><li>にこにこカレンダー </li></ul></ul><ul><ul><li>実際の製品に、バグを埋め込んだ物。 </li></ul></ul>
  7. 7. 製品の背景 <ul><li>仕様書は、細かい物は作っていない </li></ul><ul><ul><li>ネットサービスは、スピード命 </li></ul></ul><ul><ul><li>機能を世の中に問うてみて、製品を出す! </li></ul></ul><ul><li>agile 開発なので、機能概要で十分 </li></ul><ul><ul><li>細かな仕様書は策定されていない。 </li></ul></ul><ul><ul><li>画面仕様書を真とする。 </li></ul></ul>⇒ どんなテスト戦略が有効か?
  8. 8. 優勝したチームの戦略 <ul><li>ユースケースを想定し、シナリオベースで試験 </li></ul><ul><ul><li>仕様書は、(最終的には)役に立たない </li></ul></ul><ul><ul><li>ユースケースを想定し、利用できない状態を不具合と定義 </li></ul></ul><ul><ul><li>検出された不具合(例) </li></ul></ul><ul><ul><li>画面上に表示する日付の範囲が、異なっている (既知:埋込) </li></ul></ul><ul><ul><li>日付のメニューがドラッグすると一緒に動いてしまう  </li></ul></ul>⇒ 未知の不具合
  9. 9. Bug Seeding の効果 <ul><li>長所 </li></ul><ul><ul><li>仕様を見直すきっかけに繋がる </li></ul></ul><ul><li>短所 </li></ul><ul><ul><li>バグを仕込む際の影響範囲が特定できない </li></ul></ul><ul><ul><li>⇒ 仕込んだバグ15件に対し、全体で28件の不具合報告。 </li></ul></ul>不具合の傾向分析などの探索型試験に、 効果的な手法  (ご利用は計画的に?)
  10. 10. <ul><li>「品質リスクの予測」への展望 </li></ul><ul><ul><li>www.jasst.jp/archives/jasst07e/pdf/B2-1.pdf </li></ul></ul><ul><ul><li>テストの完了基準 </li></ul></ul><ul><ul><li> ⇒ 「テストを継続しないこと」に対するリスクを評価する こと。 </li></ul></ul><ul><ul><li>カバレッジは、検証基準のある側面を切り出したものであり、 </li></ul></ul><ul><ul><li> 目標にはなりえるが、「目的」にはなりえない。 </li></ul></ul><ul><ul><li>⇒ 他のプロジェクトと比較し、現状を把握することが重要 </li></ul></ul><ul><ul><li>(特に、プロジェクト序盤から、中盤にかけてチェックするべき) </li></ul></ul>講演 Topics
  11. 11. 講演 Topics <ul><li>品質レビュー専門家は何を見ているか? </li></ul><ul><ul><li>www.jasst.jp/archives/jasst07e/pdf/B2-2.pdf </li></ul></ul><ul><li>品質エンジニア = IT業界の「医者」 </li></ul><ul><ul><li>推論に頼るのは、「 NG 」! </li></ul></ul><ul><ul><li>具体的な事象を観察し、診断をしていくことが重要! </li></ul></ul><ul><li>インシデントレポートのレビューポイント </li></ul><ul><ul><li>担当する人間が、力点を置いている部分を見つける。 </li></ul></ul><ul><ul><li>行間を読む癖をつける。 </li></ul></ul>
  12. 12. 講演資料 <ul><li>報告会の資料を2部購入してきました </li></ul><ul><ul><li>開発本部本棚にあります。 </li></ul></ul>
  13. 13. 講演資料内 Topics <ul><li>Apache Jmeter 入門 </li></ul><ul><ul><li>負荷試験のイロハが分かりやすく解説されています。 </li></ul></ul><ul><ul><li>基礎試験の実施 </li></ul></ul><ul><ul><li> ⇒ 実施している負荷試験が、限界性能に対して </li></ul></ul><ul><ul><li>どの程度の負荷を与えているかを把握しながら試験を実施 </li></ul></ul><ul><ul><li>早めに実施する </li></ul></ul><ul><ul><li> ⇒ 負荷試験で発生した不具合は、 </li></ul></ul><ul><ul><li>   多くの場合で戻りの原因になってしまいます。 </li></ul></ul>
  14. 14. 今後の課題 <ul><li>不具合対応フローの見直し </li></ul><ul><ul><li>不具合調査過程の記録 </li></ul></ul><ul><ul><li>業務フローに関する学習( ITIL , SWEBOK , JSTQB ) </li></ul></ul><ul><li>ステークホルダとの交渉 </li></ul><ul><ul><li>改善計画をたてていく </li></ul></ul><ul><li>テストツールに関する学習、メンテナンス </li></ul><ul><ul><li>ノウハウの整備・調査の継続 </li></ul></ul><ul><ul><li>専属対応が必要か? </li></ul></ul>
  15. 15. <ul><li>ご清聴ありがとうございました </li></ul>

×