TEF-DO

TEF北海道テスト勉強会「TEF-DO」


テーマ:
藤田です。

2016年4月8日に
「問題-解決ぐるぐるまっちんぐ 『小さな工夫』を持ちよって、みんなの『困った』を解決しよう!」
を行いました。

参加者は、TEF道メンバー外の参加者を含めて8名

全体の流れはこんな感じ
(1)実務で困っていること改善したいことをマインドマップを使って具体的に落とし込む
(2)各マインドマップを参加者で共有して解決への手段や意見があれば追加する
(3)参加者全員で「イイね!」と思うマインドマップに投票し、人気シートを決める
(4)人気シートについて、問題と解決手段の捉え方を書いた人から聞く
(5)ホワイトボードにポイントを書き出し、内容のポイントと不明点の明確化した後参加者で共有する


(1)実務で困っていること改善したいことをマインドマップを使って具体的に落とし込む
 ・「実務で困っていること」
 ・「改善したいと思っていること」
 をお題としてマインドマップに書き出しました。
 その中から、最も解決したい悩み一つを選びました。

(2)各マインドマップを参加者で共有して解決への手段や意見があれば追加する
 「ぐるぐるマインドマップ」の形で行いました。
 これは、複数人で人数分の「マインドマップ」を一定時間で区切って「ぐるぐる」と手渡ししながら書くというものです。
 個人がマインドマップに書き出した悩みを、参加者全員のアイデアを追加して書き込み、共有・解決を促します。
 ぐるぐるマインドマップの流れはこんな感じ
  ・自分が解決したいことを中央に書いて、時間がきたら横の人に渡す。
  ・横の人から回された紙に書いてある「解決したいこと」に対する解決策やヒントを書く。
  ・時間がきたら横の人に渡す。
  ・自分が解決したいことを書いた紙が手元に戻ってくるまで繰り返す。
  ・自分が解決したいことに対する、他の人解決策やヒントを見ることができる。

(3)参加者全員で「イイね!」と思うマインドマップに投票し、人気シートを決める
 ぐるぐるマインドマップ後に出来上がったマインドマップを参加者全員で見て回り、
 主観で「イイね!」と思うものに色つき●シールを貼って行きました。
 ●シールが多いものが人気シートとなります。

(4)人気シートについて、問題と解決手段の捉え方を書いた人から聞く
 参加者個人の悩みが「お題」なので詳細説明は割愛しますが、人気のあったシートはだいたいこんな感じでした。
  ・仕事が予定通りに進まない
  ・新しいコンテンツの立ち上げで困った
  ・コミュニケーションで気になることがある
 ぐるぐるマインドマップで盛り上がったものが選ばれてます。

(5)ホワイトボードにポイントを書き出し、内容のポイントと不明点の明確化した後参加者で共有する
 マインドマップの内容を背景・問題・解決策・期待する結果などに分けてホワイトボードに書き出し、
 問題と解決策を分けることを意識しながらポイントを明確にした後、参加者全員でワイワイ議論しました。
 ここでは問題がさらに掘り下げられ、より具体的な解決策が出てきました。

 最後に
 今回、マインドマップに悩み(問題)と小さな工夫を書き出して、改善のヒントを得ました。
 ホワイトボードにポイントを整理することで、問題の掘り下げと具体的な解決策が出てきました。
 この課題と方法と結果を整理するやり方は、論文書く時やシンポジウム等の発表に使える。
 ということを教えてもらいました。

以上、レポートでした。

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

テーマ:
おばんです。
中岫です。

2月13日(土)に開催された第1回Advanced Level<テストアナリスト>試験。
その受験後、記憶が新しいうちに復習会をやりました。

復習会には、受験者7名、未受験者2名。

まず受験者どのように学習、対策をしたかを共有。
・シラバスベースの勉強
 学習時間に合わせて、学習配分を調整
 K2、K3、K4レベルを参考に知識の深堀度合を調整
・JSTQBの例題による演習
・スクエアリングサービスを利用(有料)

#自分の勉強方法の確認をしたかったため、今回は(?)有料サイトを使わなかった
#ケチったわけではないので、念のため。


次に、実際に出た問題を覚えてる限り書き出し、
それをみながら、参加者で振り返る。

◆テスト問題の全体的な印象
・テストケース数を導出させる問題が多かった。
 たとえば、
 -ペアワイズ(1ワイズ、2ワイズ)によるケース数
 -デシジョン(完全なデシジョン、簡略したデシジョン)によるケース数
 -状態遷移(0スイッチカバレッジ、1スイッチカバレッジ)のケース数

 # 境界値分析や状態遷移図と状態遷移表など、技法の使い方を正しく理解していないと厳しく、
 # 「知っている」だけでは、解けないことが良く分かった。

・長文問題が多く、様々なシステムのテストのケースを導く。
 # 問題のシチュエーションを読み込むのが大変で、頭の切り替えも大変。
 # テスト後半になると、時間に追われたり、疲労で問題を流し読みして、
 # 問題の意図を読み取り間違えた気がする。

◆問題を振り返って、みんなで答え合わせ
 思いのほか解答が結構ばらつく。
 意見交換すると問題のとらえ方が違う点が多々あった。
 # これは一人だと気づけない点があって、勉強になった。

 たとえば、

 とある物理システムで機能A、機能B、カラーをそれぞれパラメータが設定できるとする。
 この物理システムの機能のテストの組み合わせはいくつあるか?
 というような問題。
 機能のテストなので、この場合はカラーが機能に直接影響しないから、
 組み合わせからは除外されるだろう
 とか、

 Webサイトでも複数のパラメータ設定が同一画面で設定できるのか、
 各パラメータが別画面で設定できるのか、で組み合わせ数は変わるはず、
 とか、

 # 後半は問題を読むのがゆるくなかったわぁ


今回の振り返り会の感想として、大きくは2つ
・受験に関係なく、受験していないメンバーも含め良い勉強になった
・技法を一から勉強し直そうと思った
・(試験結果への)自信を失った

以上、復習会のレポートでした。
次の受験をがんばるど~!!←再受験する気満々(汗

~ 記 ~
実施日時:2/23(火)19:00

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

テーマ:

TEF道のねもとです。

 

今回は11月に実施した勉強会のレポートになります。

 

11月は小楠君による「オブジェクト指向分析を学ぼう~ユースケース駆動開発実践ガイド~」になります。今回はUMLを要求分析に用いるというワークです。(設計じゃないよ!)

お題はこちら。

 

 

 

 


ワークの流れ

 

架空の出張手配予約システムを題材にして行っていきます。

・ドメインモデリング

  - まずは名詞を洗い出す。

  - クラス図に載せてみる。

  - 曖昧な名詞は集約する。

  - 汎化、集約でドメインモデル間の関係をはっきりさせる。

・ユースケースモデリング

・ロバストネス図を記述

 


ドメインモデリングとは?

ドメインオブジェクトを洗い出し、クラス図で表現する作業。

集約、発散、関連、派生を考えながら表現することで、オブジェクト間の関連や曖昧さ、重複が減り、隠れていたオブジェクトが見つかる。

プロジェクトで使う用語辞典を作成する作業ともいえる。

プロジェクトメンバー間での正確なコミュニケーションを可能とする。

 

 なるほどと思ったところ!!

 

ドメインモデリング

◇ドメインモデリングの作業について

ドメインモデルはDDDでいうところのユビキタス言語を作っていくのと似た作業になるな~と思いました。例えば今回の仕様書からは、"社員"、"出張者"、"予約者"などのなんとなく似たような単語が出ていて、これらは一体何を意味するのか、またどういう関係なのかを意識する必要があります。そうしないと顧客とチームのみならず、チームのメンバー内でも齟齬が起きますよね。

 

◇ドメインモデリングのポイント

時間をかけすぎない。「ユースケース駆動型プロセスではドメインモデルは不完全だと仮定しており、何が不足しているかを見つける仕組みを提供しています。」とのことです。

 


ユースケースモデリング

◇ユースケースモデルの必要性

今までユースケースモデルの必要性を感じたことがあまりなかったけど、自社の業務だとアクターが少ないし、決まってるからあまり必要なかったんだな~と思いました。アクターが増えたときなどはユースケース図あると見やすいし、図を見ることで様々なステークホルダーが認識を共有できると感じました。

 

 


ロバストネス図を記述

◇ロバストネス図の必要性

今までロバストネス図を描いたことがなかったので、結構苦戦しました。

どうやらユースケースモデルとシーケンス図をつなぐ役割をしているらしいです。なるほど。


 


◇ロバストネス図の注意点

バウンダリ同士を繋いではいけない。


 

感想

◇図で書くことのメリット

自分が思ったメリットを挙げていきます。

・人間にとって分かりやすい

・関連が分かる

・多重度が分かる

・文章より少し曖昧さが減る(気がする)

・要求にはない、ユースケースが見つかることもある

 


文章を書くことで思考が整理されるというのがあると思いますが、

UMLを書くとさらに曖昧性が排除されていいですね。

 


色々な図を描いて、まだ表現されていないオブジェクトを見つけるわけですが、

メンテナンスなどを考えると、実務でどう使うかはキチンと考える必要がありそうです。

自分としては要求を整理し、共有するという目的に絞って、図は使い捨てで描いていくのが良いと思っています。

 


馴染みのない人は自分が担当している身近なシステムのUML図を描いてみることから始めてみませんか?

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

      たくさんの芸能人・有名人が
      書いているAmebaブログを
      無料で簡単にはじめることができます。

      公式トップブロガーへ応募

      多くの方にご紹介したいブログを
      執筆する方を「公式トップブロガー」
      として認定しております。

      芸能人・有名人ブログを開設

      Amebaブログでは、芸能人・有名人ブログを
      ご希望される著名人の方/事務所様を
      随時募集しております。