TestonoBlog

Softwaretest,QA

iPhoneで通信環境をわざと悪くしたいときのこと

発掘記事です。
わざと接続環境を悪くしたいとき、iPhoneの「デベロッパ」の機能をつかうとその環境をつくりだせます。
わざわざ電波の悪い場所を探さなくてもOK!
Developer>NETWORKING_Network Link Conditioner>EnableをONにする


2016/11/07

iPhoneの通信速度を変更する iPhoneで通信速度をあえて遅くしたいとき!

方法

この記事がわかりやすいです https://www.lancork.net/2014/04/ios-dev-how-to-change-network-condition/

デベロッパ」が設定にないときは?

最新のXcodeにつないでもらう
https://www.htmlhifive.com/conts/web/view/study-room/devtool-network-ios-web-inspector#HiOS7AEF672B306E300C8A2D5B9A300D306E980576EE306B300C30C730D930ED30C330D1300D30928868793A3059308B

まとめ

設定 →デベロッパ →NETWORK LINK CONDITIONER  →Status  →EnableをON(緑)  →速さを選ぶ

注意

検証し終わったら必ずもとに戻すこと!!!

テストマスターへの道 第3回 狩野モデル

過去記事の再投稿です。


2016/10/06
テストマスターへの道 第3回 狩野モデル
テストマスターになりたいとののが勉強した記録です。
9/15のチーム会で発表した内容になります。

今回のテーマ:狩野モデル

ソフトウェアテストの教科書』のPART1 ソフトウェアテストの基礎 のところを読んでいて、
前回の第2回 ビューティフルなテストに通じる考え方だなと思いチーム会で発表共有しました。

狩野モデル

  • テストに限らず、商品企画などものの品質を考えるときに使われる考え方
  • 狩野さんが考えた
  • ユーザーの要求に応じて品質を分類するという考え方:大きく3つ→当たり前品質、一元的品質魅力的品質

■例えば:携帯電話

  • 当たり前品質→電話ができる(できて当たり前)
  • 一元的品質→バッテリーの持ち(長ければうれしい、短いと不満)
  • 魅力的品質→音声がめっちゃきれい(あるとうれしい)

このように分類して考えてみることで、検証の力の入れどころや、検証の質としてもどうだったのかを捉えられて
→ビューティフルなテストになる!とわたしは解釈しました。

チーム会より

  • テストにも当てはまる:大事なところがわかるので、「木を見て森を見ず」のようなことが防げる
  • 経済の勉強とかでも出てくる
  • ラーメンつけ麺狩野さんはイケメン?(親しみやすさ)

出典

あまりうまく伝えられなかったのですが、個人的には「狩野モデル」しっくりきています。
テストマスターへの道のりはつづく。。。

テストマスターへの道 第2回 「ビューティフルなテスト」

過去記事の再投稿です。


テストマスターへの道 第2回 「ビューティフルなテスト」
テストマスターになりたいとののが勉強した記録です。
2016年7月5日

今回のテーマ:ビューティフルなテスト

図書館でタイトルに惹かれ『ビューティフルテスティング ーソフトウェアテストの美しい実践』という本を読みました。

  • 本の概要
  • 2章「ビューティフルテスティングは、ステークホルダーを満足させる」
  • まとめ
  • 出典

本の概要

この本は、テストのプロフェッショナルたちが編み出したテストの極意、「美しいテスト」について語るものです。

豊富な経験やユニークな見解をもつ人物に焦点を当てた「テスター」、試行錯誤の末に到達した「プロセス」、すばやく効率的に行うための「ツール」という3部構成で、書き手自らが確率したテストの極意を実例を上げてわかりやすく解説します。


と裏表紙に書いてありました。
眺めるとわかるのですが、2部と3部は特にエンジニア向けという感じで、私は正直ほぼ意味がわかりませんでした。(諦めた)
その中でも意味が理解できて、なるほど〜と思った、
第1部2章「ビューティフルテスティングは、ステークホルダーを満足させる」
についてまとめます。

2章「ビューティフルテスティングは、ステークホルダーを満足させる」

この章では、「ビューティフル」を「満足」だとして、それはどのようなテストであればよいか、的なことが書いてありました。

「誰が」満足するかを明らかにする。誰=テストステークホルダー

ビューティフルなテストをするためにまずは、誰に対するテストなのかを明らかにしましょう。
筆者は満足させる人々を、テストステークホルダーと呼んでいます。
テストステークホルダーとは、テスティングと、その最終的な成果物の質に対して、利害、関心、影響力などを持つすべての人々のこと。
例えば、テスター本人、開発メンバー、プロジェクトマネージャー、ユーザ、スポンサー、など。

「何が」満足させるのかを知る

それぞれのステークホルダーは、テスティングをする目的と、期待するものを持っています。
誰が満足するかがわかったら、その人のテストの目的と期待を明確化しましょう。
これが不明確だと、ビューティフルなテストになるかは運任せになり、ごくわずかなステークホルダーしか満足させることができません。
ステークホルダーと合意形成ができていれば、「有効で、効率がよく、エレガントなテストとは何か」がわかり、美しいテストが実施できるのです。
有効に:各ステークホルダーの目的と期待を満足させること。
効率よく:投資したリソースから最大限の価値を生み出す方法を通じて、目的と期待を達成すること。
エレガントに:有効さと効率を、手際よく実行すること。

外面的な美しさ

誰が何に満足するかを明確にしたら、具体的にどのくらいやれば満足なのか、を考えます。

 - 存在しているバグのうち、実際に検出したバグの割合は? - バグ全体における重要なバグの割合は? - バグ1件あたりの検出・修正に要するコストは本番環境で障害が1件発生する場合と比べてどの程度か?


例えば上記のような質問に答えるために、指標をつくります。
(((計算式が書かれていましたが、よくわかりませんでした)))
また、コストを測定する方法として、CoQ(Cost of Quality:品質コスト)があります。
これにより、テストや品質に関する以下の3つの主要コストを明らかにできます。

  • 検出コスト  - バグの検出がゼロだとしても発生するテスト費用。
  • 内的障害コスト  - バグ検出のみに起因して発生する、テストおよび開発コスト。バグ報告の作成、バグ修正、修正の確認テストなど
  • 外的障害コスト  - 提供した製品にバグが存在することに起因するコスト。テクニカルサポート、保守、維持のための費用


こうした指標によって、ステークホルダーの満足を達成する方法と、達成度を測定する方法をしめすことができます。

内面的な美しさ

ビューティフルテスティングについてもうひとつ検討するべき要素が、内面的な美しさです。
例えば、テスト工数のかなりの割合を手動での回帰テストに費やすと決めたとします。

 ○自動化した回帰テストの割合は?  ○回帰関連の品質リストのうち、網羅できた割合は?  ○自動化によって、手動よりどの程度早く回帰テストを実行できるのか?


(((これを指標にする計算はやっぱり意味わかりませんでした)))


ここでは、テスティングの目的と期待を内部の観点から設定することで、仕事をよりよく、速く安く賢く行うためにテスティングを測る方法を示します。

まとめ

ステークホルダーが満足するビューティフルなテストをするにはどうすればよいか!

  1. ステークホルダーを知ります。
  2. ステークホルダーにとっての、テスティングの目的と期待を知ります。
  3. ステークホルダーの目的と期待を達成するための、メトリクスと目標を設定します。(外面的な美しさ)
  4. テスティングの目的と期待を達成するための、メトリクスと目標を設定します。(内面的な美しさ)

いままで考えたことはありませんでしたが、
この検証は成功だった!と言えるとすれば、たしかにこんなふうに誰にとってどのくらい達成した、と言えれば確実に成功なのかなと思いました。

出典(読んだ本)

『ビューティフルテスティング ーソフトウェアテストの美しい実践』
Tim Riley,Adam Goucher
大西健児(監訳),児島修(訳者)
オライリー・ジャパン,オーム社
2010年10月25日

テストマスターへの道 第1回:テスターの適性

社内Qiitaに投稿したりした記事をあつめてきています。
ちょっと直しながら再投稿しています。


2016/05/13
テストマスターへの道 第1回:テスターの適性
テストマスターになりたいとののが勉強した記録です。

今回のテーマ:テスターの適性について

  • まずは
  • くわしく
  • まとめ
  • 出典、参考

まずは

診断チャートをつくってみたので、やってみてください!

くわしく

ソフトウェアテスト実践ガイド』によると、

テスターの素質については、

その1:体力に自信があること

テストは長丁場になることが多く、時間がかかり、単純な作業も多いため。

その2:忍耐強いこと

同じ理由で、メンタルの体力(忍耐)も必要

その3:素直だが、ひねくれてもいること

事実は事実として客観的に素直に受け入れた上で、その事実が真実なのかどうかをきっちり見極める目をもつこと。
不具合がみつかったとき、その背景を含めどういった現象なのかを観察し、特性を把握しなければならない。
その上でそれが表出している現象だけなのか、ほかに影響がないかなど、いろんな角度から検証できるかどうか。「鼻が利くかどうか」これには経験が必要。

その4:好奇心旺盛なこと

不具合の臭いに敏感な鼻をもつために、経験を積むためにも必要。
「どうなっているの?」「こうすれば、どうなるのだろう?」「分からないといらいらする。くやしい!」ただしほどほどに。熱中し過ぎると効率がよくない。


だそうです。

次に適性については、

  • 細かいところまで目配りができる
  • ダメなものはダメとはっきり言える
  • 時として大胆
  • 複数の角度で物事をとらえられる
  • 横同士のコミュニケーションが上手

といったことが挙げられるようです。
テストエンジニアの国内の男女構成比は男性が多く、IT産業全体とかわらず、ほぼ3:1。
国外の、テストエンジニアという職種が確率している米国ではほぼイーブン、もしくは女性が多いそうですよ!

『基本から学ぶソフトウェアテスト』による優秀なテスト要員のもつ素質や能力

  • 誠実さ、そして品質に対する責任感
  • 理論よりも経験をもとに根拠を見つける能力
  • 教育(高いほどよいそうです)
  • プログラミングの経験
  • コンピュータやソフトウェアの豊富な利用経験
  • 組合せ論についての知識
  • 優れたコミュニケーション能力や高い文章能力

『基本から学ぶテストプロセス管理』による良いテスト技術者の条件

  • プロフェッショナルな悲観主義
  • バランスの取れた好奇心
  • 熱中型の人はダメ
  • 見当違いの野心を持っている人はダメ
  • 怠け者はダメ:ある程度怠け者でないと効率のよいテスト実装、実行をしようとしないのでほどほどに
  • 臆病者はダメ:ある程度臆病でないと入念なテスト設計や実行にはつながらない

まとめ

テスターの適性を知ることで、テスターとして必要なことがわかってきました。 わたしは熱中しすぎてしまうことがあるので、ほどほどに、客観的に、というところも身につけていきたいなと思います。 知識もあればあるほどよいようなので、まずはこの本を読破するところからはじめていきます!

出典・参考

『ステップアップのためのソフトウェアテスト実践ガイド』 p.135〜 第3章 テストマスターになろう 大西健児/日経BP

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章の ソフトウェアライフサイクルを通じてのテスト になる予定です。