読者です 読者をやめる 読者になる 読者になる

Galapagos Engineering Blog

株式会社ガラパゴス エンジニアチームによるブログです。

テスト分析とテスト設計勉強会に参加しました!(前編)

こんにちは!テストチームとのの(TW:@tono2587)です。
先日2017/02/03、「テスト分析とテスト設計勉強会」に参加してきました!
同日〜翌日のJaSSTには参加できなかったのですが、この勉強会はわたしにとってたいへん学びがありましたので、参加レポートとしてまとめたいと思います。

f:id:glpgsinc:20170210160415p:plain ふむふむふむふむ

■「テスト分析とテスト設計勉強会」

2017年2月3日(金)@日本大学駿河台キャンパス
め、めずらしいつくりの建物でしたよ(迷ってないよべつに全然)

https://connpass.com/event/47938/connpass.com

教室がけっこう埋まっていたように見えたので、参加者は多く感じました。

■参加前の気持ち

動機や興味、自分のなかでの課題や知りたかったことのイメージです。
・業務でテスト設計することが増えてきた
・あんまり上手く設計できていない気がする(レビュー戻り多い)
・絶対もっとなんかいい方法があるはずだ
・「初心者向け」←わたしのことか。呼ばれている

■勉強会の内容(前編)

□秋山さん:JSTQBのテストプロセスについて
・「プロセス」とは何か
 相互関係のある活動のセット。(活動は入力を出力に変換すること)
活動の例:<(入力)お湯にパスタを入れる>−[(活動)煮る]−<(出力)柔らかくする>
プロセスは、このような[活動]のセット
JSTQBのいう「テストプロセス」とは何か
 基本的には、
 [①テスト計画とコントロール]−[②テスト分析と設計]−[③テスト実装と実行]−[④終了基準の評価と報告]−[⑤テスト終了作業]
によって構成される。
・これらの①〜⑤のテスト活動は、開発と整合している必要がある。
 システムテストレベルでいうと、
プロジェクト計画と同時にシステムテスト計画を始め、
要求仕様→システムおよびアーキテクチャ設計仕様→コンポーネント設計仕様と並行してシステムテスト分析および設計をおこない、
…以降も開発の活動と並行して行う。

・テスト分析、テスト設計とは?
 ・テスト分析とは:テストベースを分析すること。テスト条件を識別する。
入力:テストベース…仕様書、議事録などテストをつくるもとになるもの。これはドキュメントで、レビュー済みの整ったものをつかうのがよい。
活動:テストベースとテスト目的を分析する…ユーザーはなにをしたいのか(目的)など
出力:識別されたテスト条件…いろんな粒度で定義することが望ましい。画面(粗)、画面の部品(細)、など

 ・テスト設計とは:
入力:テスト条件
活動1:テスト条件をどうやって網羅していくかなどを決めていく
活動2:テストケースをつくる。どういうテスティングで確認するのか、どういう環境でどういう期待値で…
出力:テストケース

・構造化分析と構造化設計について
 開発と同じでテストも、いきなりコードを書いていたが、ループするところとかは構造化しましょう、となっていった

『構造化分析とシステム仕様』トム・デマルコ 著 によると、
 ・分析とは、行動をとる前に実施する、問題の調査である
 分析の最も重要な生産物は「仕様書」である。分析をすることで具体的にしていき、それが「仕様」になる
 分析の後に続く行動とはそのシステムを構築することである。

 ・設計とは、手続き的な部分(順序)と、階層的な部分を決めて、構築することである
 トップダウンで分割して順番と階層を決めて、ものをつくっていく

ーー質疑応答より
・「テストは条件次第」
 テスト対象に従って、どんな要求があるのかを確認して決めていく。
 →先にものさしを決める。

・テスト条件が様々な粒度で定義することが望ましい理由は?
 人によって(立場などによって)みているものが違うので、お互いに合意をとるためにも必要になるから。
 (共通言語みたいなもの、というイメージでしっくりきました。)

□藤沢さん:テスト分析・設計について、釈然としないところ

・テスト分析も、設計も、要するにどんなことを言うのか?→わけなくてよくない?
・仕様書のコピペはばぜだめなのか
→仕様書に書いていないことをテストに入れるべきだ
・「テスト」も「分析」も曖昧だからくっつけてもわかんないのでは?
・「分析」ってなんだ?…理解できるようにわけることなんじゃないか。
*分析 のアウトプットが曖昧ではないか?どこまでやれば「分析」が終わっているのかわからない
・分析しないと困ることは?
 ・分析しないと仕様が曖昧だから、必要なテストが漏れる
 ・なにをテストしたのかわからないことになる

・藤沢さんのいまの感じの定義
分析:グループにわけてわかりやすくすること
設計:テストケースの元ネタをつくること
実装:元ネタ(設計)からテストケースを作成すること

・テスト設計をしないと困ることは?
 ・仕様書のコピペでテストケースをつくると、なんでこのテストケースなのかわかりづらいし、説明が不足する
 ・なんでこのテストで十分なのか説明できない

・分析と設計、どっちかが欠けるとかはなく、セットなのでは???
・どこからどこまでが分析/設計なの?

・結局、分析/設計はなにがしたいかようわからん!!

■前編までの気持ち

秋山さんのお話で、教科書的な「テスト分析」と「テスト設計」を知ることができました。
テスト分析やテスト設計といった言葉の意味自体ぼんやりとしていたので、お話を聞いて形がつかめてきた感じがします。
それをふまえて自分の仕事を振り返ると、テスト分析が全然できていないこと、テスト設計も上手くいっていないことがわかりました。
だからレビューの戻りが多いし、時間もかかるのだと思いました。

なんとなくつかんできたと思っていたところでしたが、藤沢さんのお話にはなんだか説得力があって、
「どこまでが分析なんだ」みたいなところはとくに(ああ…たしかに…??)と納得してしまい
(((分析)))や(((設計)))がまたもやもやしたものに…
このお話があったお陰でこのあとすごくスッと話が頭に入ってきたのですが、この時点では正直もやもやした理解しかありませんでした。

後編へつづく