どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
勉強会メモ:テスト設計コンテスト関西地域予選会の講演
2か月ほど前のはなしなのですが、個人的なふりかえり&復習のためのメモです。
2012/11月に実施されたテスト設計コンテスト@関西地域予選でのにしさん(電気通信大学 西 康晴氏)の講演のメモです。

タイトルは… てすとづくり −質の高いテスト設計の原理− です。

<>は自分のコメント。
それ以外は、講演を聞いた際に聞いた内容のメモからの抜粋です。
直接の内容とはずれている可能性もありますのでご了承願いますm(_ _)m
以下がお話の内容メモからの抜粋です。

-------------------------------
てすとつくりの話。
普通のエンジニアよりハイレベルな観客を想定した話、さらにハイレベルな話。

てすとつくりのレベル
レベル1:コピー&ペースト&モディファイ法レベル
 ※にしさんが提案したわけではなく、「発見した手法」(強調)
レベル2:機能一覧ぶら下げレベル
 とにかく機能一覧表を作る、そこに各機能に対するテスト項目をぶら下げる
レベル3:テストレベル・テスト技法単純適用レベル
 工程、実際のやり方を「入門書」として扱っている場合
レベル4:お仕着せテストタイプ
 まともにテストできるはず、本当に良いテストか?は微妙なケースも。
 語ることは出来るが、本当にまともな内容か?がわからないときも。
レベル5:テストエンジニアリングプロセスレベル
 テスト要求分析、アーキテクチャ設計でモデリングを実施する
 いきなり表を書くのではなく、その前に分析、モデリングをしている。

技術が発展する順序。<SECIモデルのイメージを感じました。>
本を読んだだけでは身に付きません、じゃあどういう流れか。

1.癒着 <全ての技術が暗黙知、Internalization的>
 KKDで質を確保している段階、規模が大きくなると困難に。ノウハウ伝達が困難。
2.剥離 <暗黙知を取り出す、頭の中の内容を出す。Socialization、Externization>
 専門分化、経験を蓄積可能にして、技術の質を高める。
 分割統治原則に従い、体系化、プロセスの整備が容易になる。
 「分ける」という行為で暗黙知を形式知として整理する。
 ※分け方は、世の中の分類を用いる方をおすすめ。
3.融合 <Combination、Internalization>
 分類した形式知を抜粋して組合わせて、技術者に統合する。
 ⇒その技術者に新しいレベルの高い技術が癒着する!

<上記を勝手にSECIモデルとの関連性として絵にしてみました>
…融合はもう少しExternizationの要素もありそうな気がしますが。
かってにSECI-NISI-Modelです。


今日は「剥離」の話。剥離して分類した話。
・テストは何のために行うのか?の整理
 テストとは行動⇒バグを見つけること。技術が蓄積されない。
 テストとは説明⇒保証のために行う。創造性が無く、質の向上が現れづらい。
  ※お客さんの依頼内容に従うことが目標になる。
 テストとは納得⇒技術と知性とまごころを尽くす。
  説明しやすい内容で、わかりやすく展開する。相手が納得する内容を提示する。

行動のために考えること、品質ゴール、スコープとか
説明するために考えること、MECE,論理的整合性、
納得してもらうために考えること、ストーリー性、俯瞰性、不安払しょく性

(参考:剥離の例)探索型という表現の剥離
 ふるまい、仕様、微妙な動きの違い、
 アーキテクチャの作り、不具合の出方、プロジェクト状況
 こういった内容から、バグのあるところを攻める行為。
 「探索的テスト」というが、上記のように剥離して説明できると
 分かりやすく、納得間のあるものになる。

技術が無い場合「説明無責任」に費やす。
「責任が無いこと」を説明することが「説明無責任」。


テストエンジニアリングプロセス
テスト計画、テスト戦略、テスト方式
⇒技術が癒着している。大体、勘と経験でゴニュゴニョしている領域。
乖離して、テスト要求分析・アーキテクチャ設計としている。

理解(要求分析)、構想(アーキテクチャ)、論理立て(詳細設計)、
現実化(テスト実装)、実証(テスト実施)

大事なこと
ゴール:テストで何を実証、説明すれば、相手に納得してもらえるのか?

テスト要求分析
わからないものに対して、どうやって説明できるような項目、構造を示すか。
何を考えるの?
「わかること」⇒テスト対象の理解とゴールの理解(わかること)
⇒多面性、詳細性、MECE性、抽象度妥当性が特に重要!

テストアーキテクチャ設計
どんなコンセプトに従って、実施しやすい、保証する内容に整理するか?
どうやって分けるの?
論理、現実化、実証が容易になるように分割・整理して全体像を構築する工程
⇒俯瞰性。大きさを整える。バランス、凝集度、結合度、保守性が特に重要。

テスト設計の品質特性(XXXというものを提示すべきか?)
達成したいテストケース群の目的(XX重視など)や実施方法に従って
分割したい項目を決める。

テスト詳細設計
どうやってテストしていけば、論理立てした説明が出来るか?

テスト実装
実施する人のスキルや、プロセス的に記載する粒度を決めるとか。
実際のテスト環境で実証を進めていくために、テストケースを現実化する工程。


行動⇒説明⇒納得の流れを考える。
理解・構想の中身を充実させる。
 各記法におけるメリットやデメリットを把握する。
 自然言語:自由度が高く、ばらつき易い。
 Excel大中小:の裏性、俯瞰性が低い。
 フレームベースマトリクス型記法(ゆもつよ、スープカレー表):
 ⇒モデルが必要。
 ツリー、ネットワーク型:
 ⇒ノード間の関係を明示する必要性がある。
  同じ構造が現れやすい。特定のサブツリーばかり熱心に詳細化に…。
 
 <メリットを生かして、デメリットをどのようにカバーするかを考える!>


記法と弱点を補完するプロセス、ルール。抽象化、モデリングスキルが必要。
組織で取り組むために考えることが大事。
-------------------------------

…という感じでした。

足りない部分に対するモヤモヤ感を突き抜けるきっかけになり、多数の気づき、活動に繋がっています。
咀嚼するにはまだ時間がかかりそうですが、何度も見返しながら自分なりに理解しようとしている最中です。
今回は自分の理解の強化のために写経してみた次第でした。

頂いた話をふまえて、自分のアウトプットや活動を強化しなきゃ!
| コミュニティ | 01:22 | comments(0) | - |









   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ