長崎ＩＴ技術者会 第９回勉強会 「長崎QDG2015 & 盛岡ソフトウェアテスト勉強会 合同報告会」

2015年12月5日 @ 大森文化の森

すずき しょうご

長崎QDG2015参加報告(仮)

公開版

• 2015年8月12日に開催された 「長崎SWQuality&DevelopmentGathering2015」に参加した。

• 当日の様子やセッションの概要などをお話しする。

http://kokucheese.com/event/index/307158/

今日のお話しの内容

• はじめに

• 参加の動機

• 当日の様子

• 懇親会

• さいごに

• 付録

• 観光報告

はじめに

• 参加の動機

• USDMについて学べる機会

• 演習が複数人でできる機会は多くない

• 都道府県踏破カバレッジの向上

• 一度行ってみたかったｗ

前日の天気・翌日の天気

2015年8月11日＠大浦天主堂 2015年8月13日＠出島

当日朝の様子

http://news.yahoo.co.jp/pickup/6170303

当日のコンテンツ 時間 タイトル スピーカー

12:00 ～ 12:10 オープニング「開会の挨拶」 池田 暁 氏

12:10 ～ 14:40 要求仕様記述手法「USDM」ってどんなの？ ～明日から使えるUSDMのエッセンス～

清水 吉男 氏

14:40 ～ 15:05 SQuBOK読破会活動紹介とSQuBOKにおける 派生開発

藤沢 耕助 氏

15:05 ～ 15:25 Ｖ字モデルのテスト工程のインプットが USDMだったときに慌てないために

池田 暁 氏

15:25 ～ 15:55 テスト自動化の現場から 浦山 さつき 氏

15:55 ～ 16:00 休憩 -

16:10 ～ 16:10 コミュニティアピールセッション 投稿者

16:10 ～ 16:35 クロージングトーク 派生開発とUSDMの今後を語ろう

清水 吉男 氏 池田 暁 氏

16:35 ～ 17:45 クロージング「閉会の挨拶」 池田暁 氏

「オープニング」 • 長崎SWQuality&DevelopmentGathering2015(長崎QDG2015)の説明

• ソフトウェアの「品質」「開発」を取り上げるイベント

• 第一回のテーマ「派生開発」

• 参加者の住んでいるところ(都道府県)の分布

• 半分以上が、九州以外からの参加

• 長崎IT技術者会の紹介

• 池田さんの地域振興推進と地元愛(^^

• これまでの活動実績

• JSTQB AL テストアナリスト勉強会

• マインドマップ勉強会

• 第1回長崎QDG2015

• TPI NEXT 日本語版 勉強会

• ソフトウェアテストことはじめ

興味ある方は、Facebookグループ「長崎IT技術者会」に参加を！

「要求仕様記述手法「USDM」ってどんなの？ ～明日から使えるUSDMのエッセンス～」

• トラブルの多くは仕様の問題

• 仕様漏れ：仕様が明示されていない

• あいまい表現：読み手に伝わらない

• 設計ドキュメントには、「機能名」「仕様」は 明記されるが、「要求」は表現されていない。

• 機能の満たすべき「枠」を表現できない

• 「仕様」を拾いきれない、見落としてしまう。

USDMで解決可能

日本語をがんばれ

明文術 明文術 伝わる日本語の書きかた(NTT出版)

そこで、USDM です

• 「仕様」は、要求の中の「動詞」と「目的語」に存在する

• 階層構造で、仕様漏れしにくい構造になる

• 要求と仕様

• 上位要求と下位要求

• 1つの要求に対して、イベント(複数の動詞)が存在する。 動詞が「枠」を作る。

• 「理由」をつけて「要求」を相手に伝える

• 「理由」をつけることで「要求」を理解しやすくなる

• 「理由」から「仕様の引き出し」や「設計方法」を考えることができる

• 仕様として妥当かどうか？を考える方法

• ベースライン設定後の仕様変更率

• 品質を織り込む技術

• ISO 25010 からの評価の視点 (例：時間効率性、修正性)

• 品質要求も「要求」として表現しなければ実現されない (例：保守性、移植性)

• 品質を織り込む設計技術が不可欠

• データ構造、アルゴリズム

• モジュール分割、クラス分割技術、尺度 など

変更仕様数

総変更数× 𝟏𝟎𝟎 ≤ 𝟓%

• USDMを利用することで、派生開発を効果的にする 「変更要求仕様書」を作成できる

• 要求と仕様の階層表現ができる

• 要求と仕様を分けて表現する

• 要求に理由をつける

• 実現内容の認識を特定(Specify)することが大事

すべての変更を扱う要求仕様書を 「Before」「After」(差分)で表現することで、 変更の要求意図を把握し、 仕様漏れや影響範囲に気付きやすくする

再演セッションをご覧ください

• SQuBOK読破会活動紹介とSQuBOKに おける派生開発 (藤沢 耕助 氏)

• Ｖ字モデルのテスト工程のインプットがUSDMだったときに慌てないために (池田 暁 氏)

「テスト自動化の現場から」

• 自動化した事例の紹介

• 店舗ポータルサイト・顧客管理システム

• ほったらかしのテストケース

• テストしていないところから バグ発見(デグレード発生)

• テストの草刈り

• 担当者の撤退

• 自動化が引き継がれない

自動化スクリプトに保守性を考えることは非常に重要。

• 自動化あるある事例

• 自動化の認知度が低い

• 急に動かなくなる自動テスト

• チケットの後回し 構造化されていないスクリプト

• 修正が追い付かない

• サーバのパンク (テスト結果出力でストレージ枯渇)

クロージングトーク 派生開発とUSDMの今後を語ろう

• 変更情報から、どのようにテスト対象を絞り込むか

• なぜその箇所を変更するのか？

• その方法しかないのか？

• 影響箇所についてどこまで考えたのか？

• 影響が発生する個所について、根拠や理由は明確か？

• その他の箇所に影響が発生しないことなぜなのか明確か？

懇親会 • 人数が多すぎず少なすぎなかったせいか 非常に内容の濃い交流ができた。

• 仕事や生き方（?）に関する 心構え的な何か。

• USDMとリスク管理 など

• 清水さんのお話しは非常に興味深かった。 ぜひ、機会があればまたお話ししたい。

所感

• 人数は多すぎず、少なすぎずという感じで、密度の濃い講義や議論ができた。

• USDMの講義や演習は非常に興味深かった。

• 要求と理由が明確になっている点

• 「仕様グループ」を要求や理由ごとに明示できる点

• 仕様の漏れに気づきやすくなる点

• USDMを使うためには、訓練が必要。

• テスト自動化は、けっこう泥臭い。 保守性をはじめから考慮に入れておかないと失敗する。

さいごに

2016年10月7日(金) 次回開催予定!!

10/10まで連休!!

http://nagasaki-it-engineers.connpass.com/event/21303/

観光の足跡(^^;

• 三菱重工 長崎造船所

グラバー園

オランダ坂

亀山社中の跡

若宮稲荷神社

稲佐山

平和記念公園

長崎原爆資料館

浦上天主堂

出島

めがね橋

関連サイト

• 【開催レポート】長崎QDG2015 http://swquality.jp/2015/08/qdg2015.html

• 長崎SWQuality&DevelopmentGathering2015のハイパーなレポート http://mhlyc.hatenablog.com/entry/2015/08/24/000734

• 長崎旅行記 http://masskaneko.hatenablog.com/entry/2015/08/23/133246