mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

VAIOのWindows10で無線LAN接続が出来なくなった話

久しぶりにWindows10起動したらWifi接続出来なくなってしばらくハマったのでメモ残しとく。

環境

発生した問題

Windows10を起動したら無線LAN接続が出来ない状態になってた。(以前は接続できてた)
ネットワークとインターネットの設定で、Wi-FiをONにしてもOFFに戻る。

f:id:mokky14:20171029183250p:plain

ここの手順を参考に対応してみたけど状況変わらず。
他に、Windows Updateデバイスドライバの更新やってみたけど状況変わらず。
なお、有線LANは問題なく使えた。

問題原因

VAIOにプレインストールされていたVAIO Smart Networkが原因。
こいつの無線LAN設定がなぜかOFFになってた。

f:id:mokky14:20171029183628j:plain

VAIOコントロールパネルを起動して、VAIO Smart Network→詳細設定を開くと

f:id:mokky14:20171029183639p:plain

無線LANがOffになってた。
ここをOnにして、ネットワークとインターネットの設定のWi-FiをONにしたら無線LAN接続できた。
Offになった理由は分からないけど、どこかのWindows Updateで設定が変更されたのかな?

使ってないツールなのでアンインストールしようとしたら、エラーになってアンインストール出来ず。

f:id:mokky14:20171029184015p:plain

事象が再現する事があるかもしれないので、備忘録として残しておく。

システム設計の原則読書会(2017/8/25)のレポート

2017/8/25のシステム設計の原則 読書会のレポート。 今回は読書会ではなく、著者の増田さんからの執筆裏話+QA。

増田さんの執筆話

www.slideshare.net

個人的に気になったところ。

  • RDRAって初めて聞いたので後で調べる
  • ドメインオブジェクトのパターンは整理しておくと、毎回ゼロベースから考えなくてよいので良さそう
    • 「場所」という感心事に関するLocationパターン
    • 「分類」という感心事に関するCategoryパターン
    • 「権限」「認可」という感心事に関するRoleパターン
  • 現場への取り入れ方が刺さった
    • 現場で結果を形で見せられないと、賛同者も出ない
    • とりあえず自分で手を動かしてみる事を実践してみる
    • 失敗したらそれはそれで財産
  • Kent Beckの言葉
    • どんな状況でも改善はできる
    • どんなときでもあなたから改善を始められる
    • どんなときでも今日から改善を始められる

QA

6章の「データベースの設計とドメインオブジェクト」の内容が気になっていたので質問してみた。

  • 質問
    • ドメインの設計とDBの設計はどのように進めていくのがよいか?
  • 回答

    • まずは、ドメインオブジェクトは業務に着目して設計、DBは事実の記録を行う事だけを考えて進める
    • ドメインオブジェクトを設計していく中で、DBにデータが欲しくなったら、そのときにDBのテーブル等を追加する
      • ドメインオブジェクトの検討の結果として、DBのテーブルが出来る形
      • DBの設計を後に回しても、致命傷になる事は少ない
  • 質問

    • 既にあるDBを使用しなければいけない場合も同じ考え方でよいか?
  • 回答
    • まず「DBを変えてもよいか」を確認する
    • 既存のDBは意識せずに、あるべき理想型のDBを検討する
    • すきあらばDBを変えてしまう

正直なところ、6章の内容は自分でもまだ腹落ちしていない事が多々ある。
実際やったらどうなのか、手を動かして試してみる。

JaSST2017東北のレポート

2017/5/26(金)のJaSST2017東北のレポート。
今回のテーマはテスト技術者育成。

f:id:mokky14:20170603102505j:plain

講演メモ

基調講演

  • テストは品質に関わる情報を提供するための活動
  • テストの価値は情報提供の価値
    • 早い(情報提供は早いほど価値が高い)
    • 安い(情報提供コストが低いほど価値が高い)
    • 旨い(必要な情報が正確でわかり易く提供されているほど価値が高い)
  • テスターに必要なスキル

    • テストスキル
    • ITスキル
    • テスト対象ドメイン知識
    • ソフトスキル(コミュニケーションスキルなど)
  • テスターは「開発を加速させるための協力者」というマインドが大事
    (開発者と対立する関係ではない)

テスト初心者が最初の一歩を踏み出すために重要なこと
  • テストの全体感を知る
    • テストタイプ
      • 機能テスト
      • 非機能テスト
      • 構造テスト(条件テスト、ステートメントテスト、パステストなど)
      • 変更部分のテスト(確認テスト、回帰テストなど)
    • テストレベル
      いわゆるV字モデルの話
    • テストプロセス
      計画→分析→設計→実装→実行→評価→終了
    • テスト設計技法を学んでも実務で使えないのは、テストベースに対していきなりテスト技法を適用しているから。
      • 最新のテスト開発プロセス
        • テスト要求分析→テストアーキテクチャ設計→テスト詳細設計→テスト実装→テスト実行
        • テスト設計技法は、テスト詳細設計の一方法
        • テストアーキテクチャ設計は「どこまでテストするか」を説明・合意するのに有用
  • ロールモデルを見つける
    • 自分の志向の方向性(技術・マネジメント)を意識する
    • 具体的にイメージできるあこがれの人を持つ
      • あこがれの人のレベルに到達するためのマイルストーンを考える(「〜年後に〜ができるようになってる」など)
    • 自分自身成長への壁を作って成長を限ってはいけない
  • 成長へのモチベーションを持ち続ける
    • 成長が目に見える形で測れて実感出来るようにする
      • 既存のツール活用(Test.SSFなど)
      • 資格試験
    • 社外に出てみる
      • 運営側に回るとよりレベルアップ

事例発表1

  • 適正なキャリアパスを設定し、教えあい、互いを高め合う組織を作る。「自ら成長するエンジニア」を目指す
  • 研修

    • 「教わる」ではなく「考える」研修(受け身にならないように)
    • 基礎
      • 仕様整理
        • システムをMVCで捉える
        • FunctionとFeatureの違いを理解する
          • Functionは「システム」の機能 システム目線
          • Featureは「ユーザが利用する」機能 利用者目線
    • 応用
      • テスト観点の洗い出し
  • 開発経験者からテストエンジニアへ

    • 木を見て、森も見るエンジニア
    • 実装ベースによるテスト → テスト知識を持った上でのテスト
      • 仕様不備の早期発見
      • 品質の高い製品づくり
    • テストスキルの向上により、設計スキルも向上した

事例発表2

  • 学習を手助けするのが「育成」
  • 育成の始まりは興味を持ってもらうこと
  • 興味を惹かせるため、RPG風スキルマップを使ってスキルを判断
    • 個人の力を知る
    • チームの力を見える化する
  • スキルマップは自分たちで作ってみる。押し付けのスキルマップには意味がない。

  • 成長を実感させる「褒め方」

    • タイプによって褒め方を変える
      1. 達成者:達成することに喜びを見出すタイプ
        定量的、数値を軸に褒める
      2. 探検家:新しい事に挑戦するのが好きなタイプ
        →次のステージを用意。 次は〜でやってみようか
      3. 社交家:コミュニケーションに重きを置くタイプ
        →感謝を伝える
      4. 殺人者:勝ち負けなど競争に重きを置く
        →人と比較して褒める

事例発表3

  • 学んだ技術・技法をすぐに自身の現場のテスト設計に生かすのは難しい。

    • 学んだ知識→[何かギャップ]→現場での実践
    • このギャップを埋めるのが研修の目的
  • 技法と実践の組み合わせ研修

    • 基礎→応用まで
    • 本格的な題材での演習
    • 実践はレベル1,2,3と段階的に
  • WACATE

    • テスト分析をグループで演習できる場を提供
    • 夏と冬に1回ずつ開催
    • 中・上級者向けに他の成功事例、失敗事例をINPUTに
    • 自分たちが扱っているドメインに近い題材を元にする

事例発表4

  • 組織によってカルチャーや特性に違いがある
    • 重厚長大軽薄短小
    • 自社開発⇔受託案件
    • 外部開発⇔内部開発
    • 安心・安全⇔スピード
    • 安定⇔変化
  • 組織により評価ポイントが違う

    • 加点式⇔減点式
    • 安定⇔変化
  • テスト技術は普遍

    • テスト技術
    • 不具合・障害分析
    • ソフトウェア概論・工学
  • 多くの組織でテスターの評価が効果的に行われていない

  • 評価をするには、可視化&合意が必要

    • 説明責任
      • バグを見つける技術があっても、その方法を説明出来ないのでは評価されない
      • 評価されないと広まらない
      • 良い技術・手法が広まらないのは業界の損失
    • 評価する人は評価方法を考える
    • 評価される人は説明責任を果たす
  • 評価の先には、日本のソフトウェア産業の未来がある

お悩み相談

炎上しそうなプロジェクトである事をどうやったら客観的に証明できるか?
  • まずは,プロジェクトの計画(予定)通りに進んでいるか,予実を確認する

  • 前工程の設計をサボっていて,予定通り進んでるようで,実質的には遅れているプロジェクトは?

    • バグの発見工程と抽出工程を確認する
      • 抽出するべき工程が前工程のバグが多いプロジェクトは危険
      • クリティカルパスの作業を行っている人と話をする
        • 問題との因果関係を示せたら証明になる
    • メトリクスを確認する
      • 必要な情報は予め決めておく
      • 取得情報を後から追加する事は現場から受け入れられない事が多い
    • 悪い情報を持ってきた人に「ありがとう」と言える事が大事
    • 成果物の完了条件を予め決めておく
      • いわゆる「90%問題」にならないように
      • 進捗は「完了」か「完了でない」かだけを判断
  • 炎上パターンを自分で明確化できると武器になる

テスターを下に見ている開発者にはどうアプローチすればよいか?
  • 実績で見せるのが一番良い。テストしか出来ないテスターは弱い

  • 開発者とテスターの仲が悪いのは不毛。

    • テスターがOutputを作って開発者に検証させるのがよい
    • 開発者とテスターの分担として,開発→部分,テスター→全体 という分担が良いかも
テストを行うときに,仕様書が存在しないようなプロジェクトはどのように対応するか?
  • 仕様書がない場合はヒアリングする
    • 誰のためのシステムか
    • 何のためのシステムか
その他
  • 結合テストは人と人の結合を確認した方がよい
    • 同じ人が作った機能であれば,機能間結合を行っても不具合はあまり出ない

思ったことなど

今回のテーマは「テスト技術者の育成」だったわけだけど、 正直なところ、自分の周りでは、テストは「動けばいいんでしょ」くらいの面倒くさい作業くらいにしか思われておらず、 テスト技術を高める必要性を感じてない人が大半なのが実情。 (自分も昔はそうだった)

その上で、自分の経験上、テストの手法を覚えることは、品質の向上につながると考えている。 プロダクトの品質はテストの結果で証明するのが普通。なので、テスト知識がある事は品質を証明するための手段を多く持っている事になる。 また、設計段階からどういうテストが必要かを考えながら設計を進めることができるので、設計品質も上がる。
そういうところから、テストの必要性を啓蒙していくのが必要かなと考えてる。

ちなみに、JaSSTの最後「職場に戻ったら何をするか」というまとめがあり、自分は 「品質モデル(ISO/IEC 25010に定義されてる)を元に、プロダクトとしてどのような品質を確保するか考えて、その品質のためにどんなテストが必要かを検討する」 という事を考えた。

その後、職場に戻ってやってみたが、品質モデルは考える上でのネタにはなったが、テストだけでプロダクト品質を確保する訳でもないので、考える上ではあまり効率が良くなかった。
必要なテスト観点を考えた上で、観点の抜けがないかを品質モデルから検証するというやり方に変えた。 (にテスト観点は、JaSST2016東北で覚えたVSTePで検討)
これでプロダクト品質が上がるか検証してみる。プロダクト品質が上がるようならフレームワーク化していきたい。

リンク

公式レポート(講演資料へのリンク含む)

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku レポート

Togetter

JaSST Tohoku 2017 つぶやき まとめ - Togetterまとめ

RPG風スキルマップの元ネタの記事

若手ITエンジニアに贈る 今必要な経験・スキル・考え方 - あなたのスキルは職人気質型?バランス型?コミュ型?:ITpro

テストスキル標準

JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル

仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜 のレポート

f:id:mokky14:20170129072503p:plain

GaiaxでWebシステムのQA(Quality Assurance)をやってる@sakaimoさんによるQAレクチャーのレポート。

講演内容(抜粋)

「あたりまえ品質」を担保するためにやること。

テストでやること

  1. 仕様を理解しながらどんなテストが必要かイメージする
  2. テストケースの作成
  3. テストを実施
  4. バグトラッキング

開発者の視点として

  • 作るものを正しくQAに伝えることは大切
  • ドキュメント化が基本だが、全ては表現できない
    • 密なコミュニケーションが必要
    • 意図や熱意の共有
  • 開発者からの情報が全て、の場合も多い
    • 整理して説明してもらわないとテスト漏れする
    • あなたの当たり前は私の当たり前じゃない、の精神

実際の業務では
「仕様(書)の不明点や抜け漏れをどれだけ 実装前に 指摘できるか」が大事。
後工程で見つかったバグほど、修正コストは高くなる。 リリース後の不具合修正コストは、リリース前とは比較にならない。

CRUD(Create/Read/Update/Delete)のD

仕様を考える人も、コードを書く人もDが抜けることが多い。(経験上)
言われなくても、作るときに発想して下さい。

  • SNSでアカウント削除したら、投稿、他人へのコメント、友だち関係はどうするの?
  • 投稿がシェアされてたら? イベントの主催者だったら?
  • 削除後、同じアカウントで再登録できるの?

ソフトウェアテスト7原則

  • 原則1:欠陥があることしか示せない
    欠陥がないことは証明できない
    「バグのないシステムを作って下さい」と言われても、「バグがない」事は証明できない
  • 原則2:全数テストは不可能
    組み合わせは膨大。テストの焦点を絞る
  • 原則3:初期にテストすべし
    開発サイクルのなるべく早いうちにテストすべし
  • 原則4:欠陥の偏在
    バグの大部分は特定の少数モジュールに集中する
  • 原則5:殺虫剤のパラドックス
    同じテストを繰り返していると、そのテストではバグが出なくなる
    バグが出なくなったから品質が良くなったとは限らない
  • 原則6:テストは条件次第
    ECサイトとゲームではテスト方法が異なる
  • 原則7:バグゼロの落とし穴
    バグを修正してもシステムが「使えない(使い物にからない)」のでは役に立たない

品質観点からのテスト分類

  • 機能要件
    • 機能テスト
  • 非機能要件

機能ばかりに目が行って、非機能観点の要件は忘れがちなので注意。

実行方法によるテスト分類

  • 動的テスト
    • テスト対象を動作させてみて結果を確認する
  • 静的テスト
    • ドキュメント、ソースコードを「見る」「読む」ことで確認する(レビューも含む)
      • コーディング規約
      • 静的解析ツール
      • ソースコードインスペクション

テスト手法による分類

  • ホワイトボックステスト
    • 制御・パステスト
      • 理経路をどれだけ網羅したか(カバレッジ)
        • 命令網羅(C0) 全ての命令文(statement)が少なくとも1度は実行されるように設計
        • 判定条件網羅(C1) 全ての判定条件において、真と偽が少なくとも1回は通るように設計
          このあたりが現実的に出来るところ
        • 条件網羅(C2) 全ての条件について結果(真・偽双方)が少なくとも1回を確認するように設計
  • ブラックボックステスト
    • 同値分割
      • 同じ結果になる値を同値グループとして扱い、試験パターンを減らす
    • 境界値分析
      • 同値グループの端の値について試験を行う
    • ディシジョンテーブル
      • 複数の条件の真・偽の組み合わせを表にする
      • それぞれの場合に対応する結果(行動)を示す

QAチームでやってるのはほぼブラックボックステスト

「なぜそのテストで充分なのか」説明できるか?

品質特性(ISO9126)として以下のものがある。

  • 機能性(正確さ、セキュリティ等)
  • 信頼性
  • 使用性(使いやすさ)
  • 効率(性能)
  • 保守性
  • 可用性

このうち、どこの品質特性を満たすか、的を絞る。
品質特性は、モノを作り始める前に使い、「このプロダクトで求める品質は何か?」を検討する。

どの品質を確認したいのかで内容は変わる。 使用性を担保するためのテストと、信頼性を担保するためのテストは中身が違う。
プロダクトとしての確保が必要な品質特性に応じ、テストを実施する。

往々にして「動けばOK=機能テスト」に目が行きがち。でも動くのは「当たり前」。

Q&A

  • 「使用性」のテストは属人化する事が多いが、何か良いやり方はあるか?
    • 「使いづらい」については、とりあえず意見を出してもらって、みんなで判断する
    • 周りのWebサービスを触ってみて「世の中の当たり前」を確認、自分の作ったサービスと比較してどうかを判断する
  • アジャイル開発を行ったとき、仕様書の作成に力を入れなか結果として、テスト担当から「仕様書がないので何をテストすればよいのか分からなかった」と言われた事があった。開発チームに求める仕様書とか作成基準はあったら教えて欲しい
    • 仕様書について、条件は特にない
    • アジャイル開発では、チケットに完了条件を書いて、この「完了条件」を満たせばチケットクローズになる
    • 完了条件を書くのはチケット担当になった 人。他の人が完了条件を追記することは可能

感想とか

人への指導や説明に使える枠組み(公的なもの)の情報が欲しかったので、今回の「なぜそのテストで充分なのか」の話が聞けたのは良かった。
最近関わった開発で「どこまでテストすればいいか」について各自の意識がバラバラだった事があり、どうやって意識合わせすれば良かったのかと思っていたが、そもそもプロダクトに求められる品質を明確化していなかったので、意識合わせをする元がなかった事が原因だった事に思い至った。

仕様書でバグを見つける事は同意。仕様書を見れば検討不足とかは良く分かる。非機能要件は特に漏れがち。
ひどいPJだと仕様書見ただけで炎上する事が分かったりする。テスト目的に限らず仕様書の確認は重要。
JaSST'2015東北でレビューの話聞いてたので、後で見返しておく。

メモ

7つの習慣ボードゲーム公式ゲーム会に参加してきた 

2016/6/19(日)の「7つの習慣ボードゲーム 公式ゲーム会」のレポート。

7つの習慣ボードゲームとは

f:id:mokky14:20160619130520j:plain

スティーブン・R・コヴィーの名著「7つの習慣」(自分は読んだことない)で書かれている成功のエッセンスを体験できるゲーム。
クラウドファンディングで、ボードゲームのプロジェクトの中で史上初の1000万円を達成したゲームらしいです。

ゲームの概要(公式サイトより引用)

7つの習慣ボードゲームは、
「第1ステージ:私的成功」
「第2ステージ:公的成功」
「第3ステージ:成功の習慣化」
上記3つのステージが存在し、サイコロを振りながら駒を進めていきます。
 

プレイヤーは人材を雇用しながら「影響力」を高め、 プロジェクトを成功させながら「お金」と「信頼チップ」を集めます。
 

プロジェクトのキモは「交渉」!!
「交渉」では普段の決断力や判断力が実に問われてきます。
特に「7つの習慣を理解している」ことがカギとなる部分です。
 

このゲームは、決められたターン数の間に、
・第3ステージに到達する
・「肉体」「精神」「知性」「社会・情緒」4種類の刃を研ぐカードを揃える
・「ミッション・ステートメントカード」の条件を達成する
以上、3つの条件をクリアすることで、ゴールとなります。

やってみた

結果は、クリア条件のうち、「刃を研ぐカード」を揃えられなくてゴールできず。

7つの習慣ボードゲームということで,「7つの習慣」に照らしあわせた自己評価。

7つの習慣 評価
主体的である ○ 自分の頭で考えてゲーム進めてた。
終わりを思い描くことから始める × ゴールから逆算した進め方をしてなかった。目先で困っている事(資金不足、人材不足)を優先してしまった。
最優先事項を優先する △ 自分の中では優先事項を考えてプレーしてたが、そもそもの優先事項の選択が誤っていた。
Win-Winを考える ○ 交渉の時、相手の利益も考えて交渉した。
まず理解に徹し、そして理解される △ 全く気にしないでやっていた。(特に意識せずとも友好的にゲーム勧めてたと思う)
シナジーを創り出す △ 参加メンバー同士での協同効果は作れていたと思う。(自分以外のメンバーはクリア、自分もクリア条件満たしかける所まではいった)
刃を研ぐ △ ゲームの中では「刃を研ぐカード」集められなかったので×だけど,ゲームの中ではあまり意識するものでもなかった。

経営者モード

時間があったので、経営者モードでのゲームも実施。 経営者モードは以下のルールが変更になる。

  • スタート時の資金が10倍。
  • 雇用している人材の雇用費を毎ターン支払う

結果、二回連続で破産(資金がショート)。
↓全員、手元にお金が残ってない。 f:id:mokky14:20160619162627j:plain

その後,3回目の挑戦で全員クリア達成。

f:id:mokky14:20160619172245j:plain

経営者モードの感想。

  • 経営者って大変。
    • 収入の有無に関わらず固定費が毎ターン出て行くのは怖い。
    • 想定外のトラブル(イベント)が発生したら、その都度立て直しが要る。
      トラブルは発生することを前提に対応計画を考えておかないといけない。
  • 人を雇用する事は難しい。
    • ゲーム上、雇用した人材は解雇できない。
      雇用した人材に対して毎ターン支払いが発生するので、人を抱える事が負担になる。
    • 経営者目線で見ると、成長しない人材(レベル低の人材カード)はイライラする。
      うちの会社に、人材は人財にも人罪にもなるというのがあるけど、自分は人財になるようにしないといけない。
  • 一人ではどうにもならない。
    • 全員で協力するのは前提で、その上で入念に計画立てた上でやっとクリア。

改めて、7つの習慣とは?

f:id:mokky14:20160619145054j:plain

  • 私的成功
    • 第一の習慣・主体的である(Habit 1 Be Proactive)
    • 第二の習慣・終わりを思い描くことから始める(Habit 2 Begin with the End in Mind)
    • 第三の習慣・最優先事項を優先する (Habit 3 Put First Things First)
  • 公的成功
    • 第四の習慣・Win-Winを考える (Habit 4 Think Win/Win)
    • 第五の習慣・まず理解に徹し、そして理解される(Habit 5 Seek First to Understand, Then to Be Understood)
    • 第六の習慣・シナジーを創り出す(Habit 6 Synergize)
  • 第七の習慣・刃を研ぐ (Habit 7 Sharpen the Saw)

ここの内容が分かりやすかった。
前はハードカバーの分厚さで尻込みしてたけど、今はマンガも出てるし、一度読んでみるかな。

参考

7つの習慣 - Wikipedia

世界的ベストセラー『7つの習慣』ってどんな習慣なのか知ってる? | 美女読書

7つの習慣ボードゲーム 成功の鍵 公式サイト

書籍

JaSST東北2016に行ってきた

2016/5/20(金)のJaSST東北2016のレポート。

f:id:mokky14:20160521104503j:plain

今年のJaSST東北2016はVSTeP(ブイステップ)祭りだった。

基調講演 VSTePによるソフトウェアテストの開発 ー 西 康晴 ー

VSTePとは?

テスト設計の技法の一つ。
(他のテスト設計技法は、HAYST法、ゆもつよメソッドがある)

VSTePの流れ

  • テストケースをざっくり考えてから具体化する
    • いきなり細かく考えると抜け漏れが発生しやすくなる
    • まずは「負荷」とかざっくりした観点で考えて、具体化していく
  • 全体像を把握するための図を描く
    • Excelの表だと全体像の把握は難しい
    • 図の形式やツールにはこだわらない。全体像を把握するのが目的

テスト要求分析

テスト観点図を作成する。

  1. テスト観点を思い浮かべて、線でつなげる
  2. 観点を詳細化していく(親観点から子観点を引く)
  3. 関連する観点を線でつなぐ

テスト観点図の作成方法は、トップダウン型とボトムアップ型の2種類がある。

  • トップダウン型 ざっくり観点を挙げて徐々に詳細化していく
  • ボトムアップ型 試験内容を思いつくところから挙げて、挙がった試験項目から観点を導出していく

地図見るのが得意な人はトップダウン、苦手な人はボトムアップてやるのが良い(らしい)。
実際にはトップダウンボトムアップを循環させながら進める。

テスト観点を導き出した理由・意図を明確化することが大事。
意図が分かっていれば、意図が間違っていたのか、意図通りに行かなかったのかが後から分かる。

テストコンテナ設計

テスト観点をグルーピングする。
コンテナはテストのカテゴリを示す(機能テスト、負荷テスト、セキュリティテストなど)。コンテナは単数または複数のテスト観点をグルーピングしたものとなる。

  1. コンテナを設計し、テスト観点と対応させる
  2. テストコンテナ図を作成し、各コンテナの実施順序(テストの順序)を検討する

テストの順序はテストの戦略になる。

テストフレーム設計

テストケースのひな形(骨組み)を作る。

テストケースを実施するために、どの観点を組み合わせて試験を行うかを設計する。具体的な値は詳細設計で考えることとし、ここでは観点の組み合わせのみを考える。

テスト詳細設計、テスト実装

普通のやり方でよい

  • テストケースのひな形に具体的な値を入れる
  • 値を入れたひな形を手順に具体化する

導入にあたって

  • いきなり全部導入するのではなく、自分が困っているところに入れてみるのがよい。
    とりあえず導入してみて、ダメなら止めればよい。
  • 最初から完璧を目指してはいけない。
    大事なのは困ること。困ったことを自覚して、図にして、直して、納得すること。
  • 観点の抜け漏れはしょうがない。それが自分達の現在の技術レベル。 
  • 観点網羅を目的にしない。観点が「もう出ない」ことをチームで合意する事が大事。
  • 観点として必要だと思わないものも観点として明示した上で「不要」であることを合意する。
  • 「これさえあれば、何も考えなくても作業できる」とかはない。単純作業したい、自分の頭で考えない、言われたからやる、というような人や組織では導入しない方が良い。

演習

Lhaca+の解凍機能を題材にしたワークショップ。
以前のソフトウェアテスト勉強会でもやった題材。

テスト観点図

自分らのチームで作成したテスト観点。
ファイルのパターンを重点的に抽出。それ以外は、パラパラと出ていたテストケースに対して、ボトムアップで観点を付けた感じ。

f:id:mokky14:20160520145026j:plain f:id:mokky14:20160520145020j:plain

何だか網羅性がなくて気持ち悪いと思っていたら、その不安が後で的中する形に。

テストコンテナ

写真撮り忘れた。
うちのチームでまず作ったのはこんなコンテナ。

  • 解凍テスト
    • コンテナに含めた観点
      • (インプットとして)圧縮ファイルバリエーション
      • (実施手順として)人による操作
      • (アウトプットとして)出力先

実際にテストするときは、ファイルパターン×解凍機能の呼び出しパターン×出力先のバリエーションでの組み合わせテストになると考えて作ってみたけど、こんなんで良いのかとモヤモヤして、西先生に助言を頂くことに。
西先生からは「何をテストしたいのか?」「コンテナに入れる観点は、テストしたいもの。実施手順は観点ではない」というコメントを頂きました。
このコメントを受けて作りなおしたテストコンテナ。

  • 解凍テスト
    • コンテナに含めた観点
      • 圧縮ファイルバリエーション

「解凍ソフトとして、色々なバリエーションの圧縮ファイルの解凍ができる事」を確認するテストとして、コンテナ作成した。 演習はここで時間切れ。

振り返り

  •  ファイルの観点を先に深堀りしたのは失敗だった(と思う)。 ファイル観点を深堀りしただけで満足してしまい、それ以外の観点をあまり考えないままテスト観点の作成を終えてしまった。
    • テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
      • そもそも、ファイルの種類が重要な観点だとは考えてもいなかった
    • テスト観点の全体像を作成して、重要と思う観点をチーム合意して、その観点を深堀りするよう進めた方が良かったかも。
  • チームの意識が、観点の抽出よりも、細かいテストパターンを出す方に意識が行っていたと思う。
    テスト観点の抽出に意識を向けるよう、ファシリテートする技術が必要。
  • 「プロダクトとして大切なのは何か」をチーム内で合意出来てなかった。 それぞれが、考えがバラバラなまま進めてた。
  • VSTePを使うには慣れが必要。
  • 自分のチームではテスト戦略まで考えられなかったが、他のチームが言っていたテスト戦略は興味深かった。テストの順番がテストの戦略という事がよく分かった。
    • 性能テストは早い段階で実施する。理由は、性能に問題があった場合、改修が大変なので。
    • 製品の品質を上げる事が先なので、製品の魅力テストは「当たり前品質」を確認した後に実施する。

感想など

去年のソフトウェアテスト勉強会でやったゆもつよメソッドと比べると、ゆもつよメソッドは仕様書をインプットにして観点上げるのに対して、VSTePは仕様書をインプットとせずブレストで観点上げる形なので、現場導入のハードルは高いように思う。
一方、他のチームで出ていた「魅力テスト」というコンテナとかは、仕様書からは絶対に出てこないテスト。これは「仕様書を見ずに観点を上げる」事による効果だと思う。

とは言え、プロジェクトにも寄ると思うが、仕様書見ないでテスト項目上げるのは、実業務ではハードル高い。
むしろ、設計入る前とかのブレストの方が使えるかも知れない。 あと、設計が実装に寄りすぎて「そもそもこのプロダクト何したいんだっけ?」な開発では有効かも知れない。(そもそもそんなプロジェクトは炎上案件だけど)

あと、現場導入時はファシリテート出来る人がいないと崩壊するのが目に見える。
幸い、ソフトウェアテスト勉強会でまた実施するそうなので、引き続き実践してみる。

リンクなど

VSTeP

VSTeP – Qualab

当日のToggtter

JaSST'16 Tohoku ソフトウェアテストシンポジウム 2016 東北「テスト開発しちゃいなよ!~テスト設計との違い~」 #jassttohoku - Togetterまとめ

VSTePとゆもつよメソッド(とHAYST法)の違い

http://jasst.jp/symposium/jasst13tokyo/pdf/A2-1.pdf

仙台ソフトウェアテスト勉強会のレポート(2015/09)

2015/09のテスト勉強会レポート。
先月の勉強会 に引き続き、ゆもつよメソッドの勉強。

マトリクスのチェック

前回作成したマトリクスに対して、仕様書等を参照しながら、作成したマトリクスに、試験が必要と思う所に○を付けていく。 (今回は時間の都合で圧縮の所まで○付け)

f:id:mokky14:20150924124030j:plain

重み付け等で差を付けたい場合は適宜記号を工夫する事。

試験項目作成

作成したマトリクスを元に、試験項目を作成する。

f:id:mokky14:20150914195026j:plain

表に記述する内容は以下の通り。

項目 記載する内容
機能名 中項目-小項目(内容が分かれば小項目のみでも)
テストタイプ テストカテゴリの種類(ex.機能性、負荷テスト、パフォーマンステスト)
テストカテゴリ テストカテゴリの各項目
仕様項目 テストでの確認観点
期待結果/確認内容 期待する結果、確認する内容等
パラメータ テストで指定するパラメータ(上図では省略)

機能名~テストカテゴリはマトリクスに○を付けたものを抜き出して記載する。 この各項目に対し、確認対象、確認する内容を記載していく。
試験項目と、マトリクス、仕様書を相互確認しながら作成する。マトリクスに不足があったりしたら、そちらも適宜修正する。

マトリクスの用途

ゆもつよメソッドのマトリクスは、システムテストのチェックに使用するために考えられたもの。

以下、自分の解釈。

単純に機能のIN/OUTだけに着目した試験だと、機能的に確認しておくべき試験が漏れてしまう事が懸念される。
そのため、ユーザシナリオでユーザにとって重要な機能を確認した上で、内部構造にも着目して試験観点を抽出する。
マトリクスの内容は、結合試験の内容と多少オーバラップしたものになるが、機能や処理パターンを網羅する事が目的ではない。 「ユーザシナリオを提供する」ために必要な機能を試験観点として抽出する事が目的になる。

非機能観点の試験は、「ユーザシナリオを提供する」ために必要な機能を抽出した上で、 その機能を多方面(性能、連続運転、ユーザビリティ、セキュリティ、等)の観点から検証するために実施する。

非機能観点は対象のプロダクトが変わっても流用できるものが多くなる。 チームやプロダクトで育てていくと良い。

最後に

ねもとさん、ありがとうございました。