TestonoBlog

Softwaretest,QA

WACATE 2日目終わった!

WACATE 2018夏 の2日目が終わりました!!

WACATE2018 夏 プログラム内容 - WACATE (ソフトウェアテストワークショップ)

しおしおになったので後夜祭を泣く泣く見送りましたが、ちょっと休んで復活してきたのと、きのうはその日のうちに記事アップできたから今日もできる!と思ってかきはじめました。
加速!!!ビュン

早起きの思い出

WACATEは1日で終わらない。2度めの早起きの試練。。。
起きれた!えらい!!!!!

f:id:tonono:20180617215156j:plain:w400
おむすび

がっつりワークの思い出

今日はとにかくとにかく班でワークをやりました。

  1. お題発表
  2. 成果物はこれ出してね
  3. スタート!!!

(あっはじまった)

具体的にやったことはすでに なそ さんがまとめていらっしゃいました、ありがとうございます。

devtest.hatenablog.com

ワークしつつ思ったことは、

  • 1回自分で仕様を読んだつもりでも、他の人の「気になる」ところを聞くとまた自分でも「気になる」ところが出てくる
  • 気になるところの全部を解決しなくても、先にすすむことはできる
  • 必要な角度で、必要な分だけ区切って見る(捉える)のができていない?
  • 0スイッチカバレッジ!!!!!
  • やっぱり頭のなかだけではわからないことだらけだな

具体的にどういうことかっていうと、

1回自分で仕様を読んだつもりでも、他の人の「気になる」ところを聞くとまた自分でも「気になる」ところが出てくる

ワークのはじめにもメンバーにはちょっと言ったのですが、わたしは端から端まで仕様書を読む みたいのは要らないと思っているフシがあります。
「必要になったタイミングで、必要なところだけ読めばいいのでは?」と…
あまり深く考えずに言ったら、「状態遷移図を書いたりするには、やっぱり1回全部読まないと書けないよ」と言われて、
たしかに図とかを書こうと思ったら、いちいち仕様書と照らし合わせるよりも全部を読むほうが早いか〜〜となって、全部読もうと思いました。
(伝わらないかもしれないですけど、めちゃくちゃ納得して全部読んでますよ?!)
各自で読む→みんなで丁寧に読む、と続くなかで、仕様はしっかり頭に入った!と思っていたのに他の人の「気になる」点からどんどん(あ、そっか)(ならこれは?)(???)みたいにどんどん気になってしまって、
(全然仕様把握してないやんけ!!!)とあわあわしました。

ただ、仕様把握のために端から丁寧によみ続けて、全〜〜部気になることを出しきればいい!とはなりませんでした。

気になるところの全部を解決しなくても、先にすすむことはできる

あとからわかったのですが、これです。
気になることはたくさんあがった中で、「決め」が発生してテストにつかったのはごく一部でした。
ひとつずつ解決しないとテストできないと勝手に思ってしまっていたので「決めなくてもいい」ことがわかったのは気づきでした。
論理的ではないかもしれないしうまく言えるかわからないんですが、
全体を読まないとつくりはじめられないんだけど、切り口によってはどうでもいい(考えなくてもよい)仕様があって、不明点がたくさんあるから仕様わかってない→モデル作成もテスト作成も無理→ではなくて、不明点に全部付き合わなくてもいい、というか。。
だめです、書いても整理できないという悲しい能力を発揮してしまいました。さらなる気付きがくるまでそっとしておいてください。。

強引に次へ

必要な角度で、必要な分だけ区切って見る(捉える)のができていない?

状態遷移図でイベントをみんなで出し合ったときに、わたしの考えたイベントは必要ないものばかり揃ってしまいました。(オフライン、とかメアド取得、とか)
システムの内部?外部?のことを考えすぎててまた「それはいま考えなくていい」状態でした。
同じお題で2種類の状態遷移図を描いた班もありました。同じモデルでも要るものといらないものもあるし、モデルが別だから要るものいらないものもあるっぽいので、完全に自分のなかでそれらがとっちらかって区別できてないことがわかりました。
これって単に練習あるのみなんでしょうか?
まだ解決できてない問題があるのでしょうか?
これについてもひきつづき考える必要がありそうです。

0スイッチカバレッジ!!!!!

前日の話の中で、「Nスイッチカバレッジ」の話で急に なんのこっちゃわからん になってしまっていました。
なので基準を決めよう、という段階になったときはハラハラしました。わからないんですもの〜〜
ループがある場所はNスイッチを検討したほうがよい?
隣り合う状態が問題ないことをぜんぶたしかめるのが0スイッチカバレッジ
「なんのためにその基準を選ぶか」を考えたほうがいい
など説明してもらいつつ進めていて、
「このテストで大事なところ」と「その状態同士が隣り合ってる」が重なったとき、0スイッチカバレッジだけはほんのちょっとわかった気がします!!!たしかにピンときた瞬間があったんです!Nスイッチはもうちょっとかかります!!

やっぱり頭のなかだけではわからないことだらけだな

そして、ワークで気づいたことはつまりこれなんですが、
意見出し合ったり、モデルを描こうとしたりたくさんして、形にしようとして初めて気づくことがあったのでこう思いました
ただブログとしてモヤりを言語化してもわからないことだらけなので、
今日のこの記事とかを振り返りつつまた考える時間が必要です。

今回ですが完全にまわりに影響されて無理やりにでも2日目のことを公開せねばならぬと思い公開しました!!!!!
書けてないこともあるし、またぼちぼちやっていきます。
まず2日間お疲れさまでした。

WACATE1日目はじまった!

WACATE初日はじまりました!!

WACATE2018 夏 プログラム内容 - WACATE (ソフトウェアテストワークショップ)

早起きめちゃくちゃ心配でしたが無事起きられました。えらい!!!

f:id:tonono:20180616235822j:plain
海だー!!!!!

各セッションの内容は先輩方がきれいにまとめてくれるようなので、
わたしからは思い出を公開していきます。アルバムを眺める感覚でお付き合いください。

ポジペの思い出

参加の必須条件として、「ポジションペーパー」の提出があります。
これかくのめちゃくちゃ苦労しました(物理的な意味で)。。(これ前も言ったかも)
どうやらわーどがあるとサクッといけたようなのですが、今後参加する方でわーど環境ない方はほんとにはやめの着手をおすすめいたします。時間かかります。
苦労はしたものの心は込めて書いたので、今日のセッションではたくさん話す時間をいただけたのでうれしかったです。
みなさんからもバックグラウンドがわかったり、いろんなお気持ちを知ることができたので楽しい時間でした。

ユースケース図&アクティビティ図の思い出

ユースケース図、アクティビティ図の基本的な描き方を教えてもらったあと、実際にワークを通して書いてみる+テストケースを考える、ところまでやりました。

ユースケース

  • ユースケース を入れるとき、前後関係をどう描いたらよいかよくわからず手が止まる
    →「前後関係はいったん考えなくてOK」と教えてもらいました。ユースケースどうしは並列でよさげ?
  • 「メールを受け取る」みたいな受動的な内容がうまくハマらない
    →受動だとハマらないので、主人公(アクター)を中心にして「〜〜する」みたいな能動的な形で捉えたほうがいい。(この場合は主人公を別の人/システムに移して「メールを送る」にするとハマる)

状態遷移図

  • 挙げたはいいもののしっくりハマらないイベントがある
    →別のイベントともしかしたら同じなのでは?と回答例を見て解決しました
  • 「元の状態に戻る」という仕様は要注意

なんでモデリングなのか?セッションの思い出

  • いろんなモデリング観点/記法があるよ
  • UMLはそのなかのひとつの記法だよ
  • PlantUMLっていうツールあるよ
  • この話はじめにやってくれてよかった〜〜〜〜〜〜
    →「モデリング」という単語に目が眩んでいましたが、この話を聴いて整理されて、自分の中で構えができた感じがしました。

そのほか初日の思い出

  • 起きれてよかった(なお、明日もがんばらねばならぬ)
  • JaSST全部まわるとおいしいごはんが食べられるらしい
  • 海鮮丼を食べた

    f:id:tonono:20180617003553j:plain
    おひる

  • みんなやさしい

  • ガチ勢が集まっている
  • ToDo↓

取り急ぎ現場からは以上です。
あしたもがんばる

JSTQB_FLシラバス_6章:テスト支援ツール

2018/06/07
ということでシラバス読むつづきです。

f:id:tonono:20180605112058p:plain
シラバス学習時間の割合

今回は6章「テスト支援ツール」を読みます。

6章:テスト支援ツール

  1. テストツールの種類
  2. ツールの効果的な使い方:利点とリスク
  3. 組織へのツールの導入

3つの節があり、端から読んではみたものの頭に入ってくる感じがしませんでした。おそらく出てくる単語が難しいせいだと思ったので、
"ツール"を包丁とか鍋とか、料理する場合に置き換えてイメージしつつ読んだら少しつかめた気がしました。 (業務での具体例を思い浮かべられたらよいのですが、経験も知識もないのでイメージできませんでした。。)
そのイメージでつかんだ雰囲気のまま書いていることをご了承ください。

ツールの導入

  • ツールを導入する際の基本原則がある。
     テスト対象に対して効果的なツールなのか、ツールを使う上で組織はどんな教育や訓練が要るか、費用対効果はどのくらいか、などを気にしたほうがよい。

  • パイロットプロジェクト
     選んだツールを使うのは簡単な(限定された)プロジェクトから。

  • ツールの展開を成功させるには
     利用ガイドを定める、ツールを使えるプロセスにする、ツールの利用状況や効果をモニタリングする、新規ユーザーに対してトレーニングする、徐々に展開する、などなど

ツールのよさ/リスク

よさ

  • 反復作業が減る
  • 同じことを何回も簡単にできる
  • 客観的に評価できる
  • 統計を取ったりインシデント率の算出が簡単になる

リスク

  • ツールがあるだけで神だと思いこんでしまう
  • ツール自体が使えなくなる可能性がある
  • 予想外の出来事が起こる などなど

このツールはとくに注意

  • テスト実行ツール:大量の工数や、専門知識が要りがち
  • 静的解析ツール:大量の警告メッセージが出るかもしれないので段階的に導入するといい
  • テストマネジメントツール:組織が必要とするフォーマットに合わせないといけない

ツールの種類

f:id:tonono:20180607130503p:plain
テストの活動による分類

ひとつの活動に対してしか支援しないツールもあれば、複数の活動を支援するツールもある。
テストの実際の出力に影響を及ぼすものもあり、(実行タイミングが実際と異なるとか)その結果をプロープ効果という。

テストツールってどんなもの?

  • テストに直接利用されるツール
  • テストプロセスのマネジメントを支援するツール
  • 調査や探索のためのツール
  • テストを支援するあらゆるツール(表計算ソフトウェア など)

ツールの目的は?(なんでつかうの?)

  • テストの活動の効率を改善するため:反復作業の自動化、テストレポートの支援など
  • 手動でやると大きなリソースを要する活動を自動化するため
  • 手動では実行できない活動を自動化するため
  • テストの信頼性を上げるため:大量のデータ比較や動作のシュミレーション

ひとこと

テストを支援するあらゆるツールはテストツール!
わたしが業務でいちばんつかっているのはスプレッドシートですかね〜〜
テストやテスト結果の管理とか、テストケースを考えるときにつかったりとか。 次回は2章の ソフトウェアライフサイクルを通じてのテスト になる予定です。

JSTQB_FLシラバス_3章:静的技法

2018/06/04
JSTQBのFLまだ持っていません。のでお勉強はじめました!
自分の言葉で整理しなおすと頭に入るらしいのと、未来のわたしが読んだとき、赤面したり涙を流したりするかもしれない、のが楽しみだから書きます。

3章:静的技法

「動的」テストがコードを実行してテストするのに対して、「静的」テストではコードを実行しないでテストする。
故障自体を探す動的テストと比べて、静的テスト技法は故障の原因(欠陥)を探す。
静的テスト技法はシラバスに2つ出てくる。レビュー(人力) と 静的解析(自動) である。

レビュー

レビューとはどんなことをするのか??

〈一般的な公式レビューの流れ〉

  1. 計画
  2. キックオフ
  3. 個々の準備
  4. 実施/評価/結果の記録
  5. 再作業
  6. フォローアップ

…(個々の準備?????)
レビューミーティングの準備としてドキュメントをレビューしたり、可能性のある欠陥、質問、コメントを書き出したりすることらしい。
考えたらそらそうかな、と思うのですが、「レビュー」に関しては自分以外の他の人の存在があって、ひとりで黙々とするイメージとはちょっと違っていておもしろいなと思いました。

静的解析

レビューが人力なのに対して、こちらはツールによる自動解析。
わたしの普段の業務ではやらないので馴染みがない。

静的解析はソースコードやソフトウェアのモデルの欠陥を見つけるのが得意!(目的)
なので静的解析ツールをつかうのは主に開発担当者やモデルの設計者、と書いてあったので馴染みがないのも納得。ただ、レビューのほうでもサポートするツールがあるようなので自動=静的解析(ツール)と繋げてしまわないことー

レビューの種類

静的テスト技法が2種類あるとわかったところで馴染みのあるほう「レビュー」に戻って、レビューにもいろいろ種類があるらしいので整理

  • 非公式レビュー
  • ウォークスルー
  • テクニカルレビュー
  • インスペクション

非公式レビュー

お金や時間をかけずにある程度の効果を出したい世界。

ウォークスルー

ソフトウェアの内容を学習、理解し、そして欠陥を見つけにいく世界。

テクニカルレビュー

円卓会議。
ディスカッションする、判断を下す、他の方法を評価する、欠陥を見つける、技術的な問題を解決する、仕様や計画、規定、標準に準拠していることをチェックする。
ここにだけエキスパートの存在が明記されている

インスペクション

テクニカルレビューを読んだあとなのでこの世界の存在意義がわからなくなった。(主観、あくまで主観)主な目的は欠陥の検出。 inspection という単語をググったら「検査」ってでてきた。

レビュー世界におけるキャラクターのロール

  • マネージャー:レビューの目的が適切かどうか判断する
  • モデレータ:レビューのとりまとめをする。世界を左右する超重要人物
  • 作成者:レビュー対象のドキュメントに責任をもつ
  • レビューア:レビュー対象物で気がついたことを示したり述べたりする。別名チェッカー/インスペクタ
  • 書記:記録係も世界には必要

レビュー攻略法

  • レビューをはじめる前には目的を明確にしましょう。
  • 目的を達成するために、(ソフトウェア、レビューアのタイプ、レビューアのレベルなどなどに対して)最適のレビュー技術を適用しましょう。
  • 欠陥を見つけることは歓迎すべきことですよ
  • チェックリストや役割決めは欠陥を効率よく見つけられるならつかおう
  • きちんとレビューを進めるには支援が必要です(スケジュールで時間をとってもらうとか)
  • レビューの方法を学習したり、プロセスを改善したりすることも目的ですよ

さいごに

なんで3章からなのか

各章のなかで、「レビュー」がいちばんなじみのない用語だったのでしっかり読もうと思いました。
それと、学習時間を見たとき3章がいちばん短かったので最初にやるにはちょうどいいかなと思ってそこから手をつけはじめました。
f:id:tonono:20180605112058p:plain

すると次は「テスト支援ツール」かな?? テスト設計技法はいまいちばん勉強が必要だけど、重いので最後かもしれないです。
今回はここで終わります。書きなぐりで読みづらかったと思います、読んでいただきありがとうございました。

ブログはじめました

ブログはじめました

2018/06/01

今日はついたちなのでなにかはじめたくなりました。
ということでブログはじめました!
f:id:tonono:20180601115248p:plain:w200

いままでよりもさらにゆるく気軽にテストの記事投稿したいなと思っていて、アカウントだけは用意していたのです…今日やっと投稿します!

きのうはWACATEポジションペーパーをなんとか提出し、ひとつの納期を終えた気持ちです。
なんか白いし見た目も内容も地味で、(もっとやりようがあったよな)とごねごねしつつ、「提出した!」ことで1歩進んだ気がしました。

書く内容よりも編集方法で結構つまづいて苦しかったです。まだ誰にも参加するって言ってないし土日の予定も空くしひっそりとやめちゃおっかなーとか思ったのですが、
こんな後ろ向きな理由で参加をやめたら後悔しそうかなぁと思ったのでがんばって提出することにしました。

テスト設計が遅くてもやっているので、解決のヒントにできるかもしれないなという期待があります。
あとはなにより、「WACATEはいいぞ」とよく聞くので自分でたしかめようと思います。 初参加ですが、お会いできる方はぜひ仲良くしてください。

こんな感じで とりあえずやってみる の精神でゆるくやっていきます(内容なくても書かないよりとりあえずやってみる!みた!)のでよろしくお願いします。