2013年3月24日日曜日

JaSST'13 Niigataに参加してきました。

2013/3/15に行われたJaSST'13 Niigataに参加してきました。
今回は参加している勉強会「すわにい」の成果発表で登壇もしてきました。
http://www.jasst.jp/symposium/jasst13niigata.html

遅くなりましたが、気づきのあった事を書いてみます。
ちゃんと内容理解できているか不安ですが。。。

2013/4/10追記
JaSSTのサイトにレポートがアップされました。スライドも見れます!
http://www.jasst.jp/symposium/jasst13niigata/report.html

基調講演
「仕様ベースのソフトウェアテストを上手に進めるには
~明文化された要求仕様に対して漏れなくテストするための観点とは~」
大西 建児さん

仕様ベースのテストで何がむずかしいか、を4つの視点からむずかしさを説明されました。「むずかしさ」を整理するポイントを教えて頂けたと感じました。

  • ISTQBとは、というお話から。JSTQBのFoundation Levelを持っているはずの私ですが、成果発表の資料の用語からしてISTQBの用語に沿ってない・・・・と焦りました(ーー; もう一度シラバスを読もうと思います。
  • 自然言語による仕様記述でのあいまいさ。言葉を尽くして表現しなくてはならない。
  • 情報が絡み合ってごちゃごちゃしている状態。情報の整理が必要。
  • 複数のテストアイテムに対するテスト条件がいっぱいあり整理できない。
  • テスト条件とは、テストアイテムについてテストしなくてはならないこと。
  • 現在ではユースケースが膨大になるのが当たり前。どこまで保証するか範囲を決めることになる。
  • 製品、サービスの領域に関する知識は持っている必要がある。すべてを知っている必要があるということではなく、テスト対象が目的を果たせるか確認するのに必要なことは知っている必要がある。

演習付きチュートリアル
「マインドマップを用いたテスト要求分析・設計エクササイズ」
鈴木 三紀夫さん

テスト分析、設計でマインドマップを活用する、、、の前にテストケースに至までのテストプロセスのお話がありました。また、講演自体をマインドマップで各自書いていく、という流れ。私は結局A3で2枚ぶんになりました。

  • テストレベルごとにテストプロセスがあり、そのプロセスがフェーズ(時間の流れ)の中に当てはまっていく。これははじめて絵をみてなるほどと思いました。
  • 視座、視野、視点を意識してテスト観点を列挙していく。
  • 演習ではある機能に対してどんなテストが必要かをマインドマップで考えるというものでした。
  • 情報交換会や打ち上げなどで他の人のものを聞いてみると、自分で気づかなかったところも多々あり。なるほどなあ、というところも多く、視野が狭いなあと感じました。

事例発表
「新潟ソフトウェア開発勉強会『すわにい』の活動」
すわにい

すわにいで行ったテスト設計の成果発表を行いました。あとは、参加者募集!の宣伝w
独自のテスト設計アプローチとして、利用者の安全をキーワードにアバター抽出とそれぞれに対するフローからポイントを洗い出す、というものでした。
ご講評として、大きく2点コメントを頂きました。アプローチ、手法という観点ではなるほどなあ、と感じ入りました。

  • アプローチでの結果の再現性。同じ事をやったときに同じ結果につながるのか?ということ。アバターの抽出、フローの作成ともに「気づき」を促すもので、再現性があるかというと乏しいと確かに感じました。
  • フローである事の意義。前述の通り「気づき」を促すものとしてフローではなくマインドマップなども同じような効果が得られそうです。


去年は参加できずのJaSST Niigataでしたが、一昨年同様多くの気づきを得ることができました。
やはり本やネットだけでなく、実際に聞いて話してみると感じる事があります。それを実際の開発にもつなげていけたらと思いました。
#オフィシャルのレポートが上がったらリンクを追記しようと思います。

0 件のコメント:

コメントを投稿

RedmineプラグインをGitHub Actionsでテストする

Redmine Advent Calendar 2019 の Qiita で書きました。追っかけで もう一つ 。 Travis-CIで行っていたRedmineプラグインのCIを、GitHub Actionsに変更したものです。 GitHub Actionsをやってみようという...