JaSST2017東北のレポート
2017/5/26(金)のJaSST2017東北のレポート。
今回のテーマはテスト技術者育成。
講演メモ
基調講演
- テストは品質に関わる情報を提供するための活動
- テストの価値は情報提供の価値
- 早い(情報提供は早いほど価値が高い)
- 安い(情報提供コストが低いほど価値が高い)
- 旨い(必要な情報が正確でわかり易く提供されているほど価値が高い)
テスターに必要なスキル
- テストスキル
- ITスキル
- テスト対象ドメイン知識
- ソフトスキル(コミュニケーションスキルなど)
テスターは「開発を加速させるための協力者」というマインドが大事
(開発者と対立する関係ではない)
テスト初心者が最初の一歩を踏み出すために重要なこと
- テストの全体感を知る
- ロールモデルを見つける
- 自分の志向の方向性(技術・マネジメント)を意識する
- 具体的にイメージできるあこがれの人を持つ
- あこがれの人のレベルに到達するためのマイルストーンを考える(「〜年後に〜ができるようになってる」など)
- 自分自身成長への壁を作って成長を限ってはいけない
- 成長へのモチベーションを持ち続ける
- 成長が目に見える形で測れて実感出来るようにする
- 既存のツール活用(Test.SSFなど)
- 資格試験
- 社外に出てみる
- 運営側に回るとよりレベルアップ
- 成長が目に見える形で測れて実感出来るようにする
事例発表1
- 適正なキャリアパスを設定し、教えあい、互いを高め合う組織を作る。「自ら成長するエンジニア」を目指す
研修
- 「教わる」ではなく「考える」研修(受け身にならないように)
- 基礎
- 仕様整理
- システムをMVCで捉える
- FunctionとFeatureの違いを理解する
- Functionは「システム」の機能 システム目線
- Featureは「ユーザが利用する」機能 利用者目線
- 仕様整理
- 応用
- テスト観点の洗い出し
開発経験者からテストエンジニアへ
- 木を見て、森も見るエンジニア
- 実装ベースによるテスト → テスト知識を持った上でのテスト
- 仕様不備の早期発見
- 品質の高い製品づくり
- テストスキルの向上により、設計スキルも向上した
事例発表2
- 学習を手助けするのが「育成」
- 育成の始まりは興味を持ってもらうこと
- 興味を惹かせるため、RPG風スキルマップを使ってスキルを判断
- 個人の力を知る
- チームの力を見える化する
スキルマップは自分たちで作ってみる。押し付けのスキルマップには意味がない。
成長を実感させる「褒め方」
- タイプによって褒め方を変える
- 達成者:達成することに喜びを見出すタイプ
→定量的、数値を軸に褒める - 探検家:新しい事に挑戦するのが好きなタイプ
→次のステージを用意。 次は〜でやってみようか - 社交家:コミュニケーションに重きを置くタイプ
→感謝を伝える - 殺人者:勝ち負けなど競争に重きを置く
→人と比較して褒める
- 達成者:達成することに喜びを見出すタイプ
- タイプによって褒め方を変える
事例発表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 システム及びソフトウェア製品の品質要求及び評価（ＳＱｕａＲＥ）−システム及びソフトウェア品質モデル
仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜 のレポート
GaiaxでWebシステムのQA(Quality Assurance)をやってる@sakaimoさんによるQAレクチャーのレポート。
講演内容(抜粋)
「あたりまえ品質」を担保するためにやること。
テストでやること
- 仕様を理解しながらどんなテストが必要かイメージする
- テストケースの作成
- テストを実施
- バグトラッキング
開発者の視点として
- 作るものを正しくQAに伝えることは大切
- ドキュメント化が基本だが、全ては表現できない
- 密なコミュニケーションが必要
- 意図や熱意の共有
- 開発者からの情報が全て、の場合も多い
- 整理して説明してもらわないとテスト漏れする
- あなたの当たり前は私の当たり前じゃない、の精神
実際の業務では
「仕様(書)の不明点や抜け漏れをどれだけ 実装前に 指摘できるか」が大事。
後工程で見つかったバグほど、修正コストは高くなる。
リリース後の不具合修正コストは、リリース前とは比較にならない。
CRUD(Create/Read/Update/Delete)のD
仕様を考える人も、コードを書く人もDが抜けることが多い。(経験上)
言われなくても、作るときに発想して下さい。
例
- SNSでアカウント削除したら、投稿、他人へのコメント、友だち関係はどうするの?
- 投稿がシェアされてたら? イベントの主催者だったら?
- 削除後、同じアカウントで再登録できるの?
ソフトウェアテスト7原則
- 原則1:欠陥があることしか示せない
欠陥がないことは証明できない
「バグのないシステムを作って下さい」と言われても、「バグがない」事は証明できない - 原則2:全数テストは不可能
組み合わせは膨大。テストの焦点を絞る - 原則3:初期にテストすべし
開発サイクルのなるべく早いうちにテストすべし - 原則4:欠陥の偏在
バグの大部分は特定の少数モジュールに集中する - 原則5:殺虫剤のパラドックス
同じテストを繰り返していると、そのテストではバグが出なくなる
バグが出なくなったから品質が良くなったとは限らない - 原則6:テストは条件次第
ECサイトとゲームではテスト方法が異なる - 原則7:バグゼロの落とし穴
バグを修正してもシステムが「使えない(使い物にからない)」のでは役に立たない
品質観点からのテスト分類
- 機能要件
- 機能テスト
- 非機能要件
- 性能
- 負荷
- ユーザビリティ
- セキュリティ
- 保守性
- 信頼性
- 移植性テスト
機能ばかりに目が行って、非機能観点の要件は忘れがちなので注意。
実行方法によるテスト分類
- 動的テスト
- テスト対象を動作させてみて結果を確認する
- 静的テスト
テスト手法による分類
- ホワイトボックステスト
- ブラックボックステスト
- 同値分割
- 同じ結果になる値を同値グループとして扱い、試験パターンを減らす
- 境界値分析
- 同値グループの端の値について試験を行う
- ディシジョンテーブル
- 複数の条件の真・偽の組み合わせを表にする
- それぞれの場合に対応する結果(行動)を示す
- 同値分割
QAチームでやってるのはほぼブラックボックステスト。
「なぜそのテストで充分なのか」説明できるか？
品質特性(ISO9126)として以下のものがある。
- 機能性(正確さ、セキュリティ等)
- 信頼性
- 使用性(使いやすさ)
- 効率(性能)
- 保守性
- 可用性
このうち、どこの品質特性を満たすか、的を絞る。
品質特性は、モノを作り始める前に使い、「このプロダクトで求める品質は何か?」を検討する。
どの品質を確認したいのかで内容は変わる。
使用性を担保するためのテストと、信頼性を担保するためのテストは中身が違う。
プロダクトとしての確保が必要な品質特性に応じ、テストを実施する。
往々にして「動けばOK＝機能テスト」に目が行きがち。でも動くのは「当たり前」。
Q&A
- 「使用性」のテストは属人化する事が多いが、何か良いやり方はあるか?
- 「使いづらい」については、とりあえず意見を出してもらって、みんなで判断する
- 周りのWebサービスを触ってみて「世の中の当たり前」を確認、自分の作ったサービスと比較してどうかを判断する
- アジャイル開発を行ったとき、仕様書の作成に力を入れなか結果として、テスト担当から「仕様書がないので何をテストすればよいのか分からなかった」と言われた事があった。開発チームに求める仕様書とか作成基準はあったら教えて欲しい
- 仕様書について、条件は特にない
- アジャイル開発では、チケットに完了条件を書いて、この「完了条件」を満たせばチケットクローズになる
- 完了条件を書くのはチケット担当になった 人。他の人が完了条件を追記することは可能
感想とか
人への指導や説明に使える枠組み(公的なもの)の情報が欲しかったので、今回の「なぜそのテストで充分なのか」の話が聞けたのは良かった。
最近関わった開発で「どこまでテストすればいいか」について各自の意識がバラバラだった事があり、どうやって意識合わせすれば良かったのかと思っていたが、そもそもプロダクトに求められる品質を明確化していなかったので、意識合わせをする元がなかった事が原因だった事に思い至った。
仕様書でバグを見つける事は同意。仕様書を見れば検討不足とかは良く分かる。非機能要件は特に漏れがち。
ひどいPJだと仕様書見ただけで炎上する事が分かったりする。テスト目的に限らず仕様書の確認は重要。
JaSST'2015東北でレビューの話聞いてたので、後で見返しておく。
メモ
７つの習慣ボードゲーム公式ゲーム会に参加してきた
2016/6/19(日)の「7つの習慣ボードゲーム 公式ゲーム会」のレポート。
7つの習慣ボードゲームとは
スティーブン・R・コヴィーの名著「7つの習慣」(自分は読んだことない)で書かれている成功のエッセンスを体験できるゲーム。
クラウドファンディングで、ボードゲームのプロジェクトの中で史上初の1000万円を達成したゲームらしいです。
ゲームの概要(公式サイトより引用)
7つの習慣ボードゲームは、
「第1ステージ：私的成功」
「第2ステージ：公的成功」
「第3ステージ：成功の習慣化」
上記3つのステージが存在し、サイコロを振りながら駒を進めていきます。
プレイヤーは人材を雇用しながら「影響力」を高め、 プロジェクトを成功させながら「お金」と「信頼チップ」を集めます。
プロジェクトのキモは「交渉」！！
「交渉」では普段の決断力や判断力が実に問われてきます。
特に「7つの習慣を理解している」ことがカギとなる部分です。
このゲームは、決められたターン数の間に、
・第3ステージに到達する
・「肉体」「精神」「知性」「社会・情緒」４種類の刃を研ぐカードを揃える
・「ミッション・ステートメントカード」の条件を達成する
以上、3つの条件をクリアすることで、ゴールとなります。
やってみた
結果は、クリア条件のうち、「刃を研ぐカード」を揃えられなくてゴールできず。
7つの習慣ボードゲームということで，「7つの習慣」に照らしあわせた自己評価。
| 7つの習慣 | 評価 |
|---|---|
| 主体的である | ○ 自分の頭で考えてゲーム進めてた。 |
| 終わりを思い描くことから始める | × ゴールから逆算した進め方をしてなかった。目先で困っている事(資金不足、人材不足)を優先してしまった。 |
| 最優先事項を優先する | △ 自分の中では優先事項を考えてプレーしてたが、そもそもの優先事項の選択が誤っていた。 |
| Win-Winを考える | ○ 交渉の時、相手の利益も考えて交渉した。 |
| まず理解に徹し、そして理解される | △ 全く気にしないでやっていた。(特に意識せずとも友好的にゲーム勧めてたと思う) |
| シナジーを創り出す | △ 参加メンバー同士での協同効果は作れていたと思う。(自分以外のメンバーはクリア、自分もクリア条件満たしかける所まではいった) |
| 刃を研ぐ | △ ゲームの中では「刃を研ぐカード」集められなかったので×だけど，ゲームの中ではあまり意識するものでもなかった。 |
経営者モード
時間があったので、経営者モードでのゲームも実施。 経営者モードは以下のルールが変更になる。
- スタート時の資金が10倍。
- 雇用している人材の雇用費を毎ターン支払う
結果、二回連続で破産(資金がショート)。
↓全員、手元にお金が残ってない。
その後，3回目の挑戦で全員クリア達成。
経営者モードの感想。
- 経営者って大変。
- 収入の有無に関わらず固定費が毎ターン出て行くのは怖い。
- 想定外のトラブル(イベント)が発生したら、その都度立て直しが要る。
トラブルは発生することを前提に対応計画を考えておかないといけない。
- 人を雇用する事は難しい。
- ゲーム上、雇用した人材は解雇できない。
雇用した人材に対して毎ターン支払いが発生するので、人を抱える事が負担になる。 - 経営者目線で見ると、成長しない人材(レベル低の人材カード)はイライラする。
うちの会社に、人材は人財にも人罪にもなるというのがあるけど、自分は人財になるようにしないといけない。
- ゲーム上、雇用した人材は解雇できない。
- 一人ではどうにもならない。
- 全員で協力するのは前提で、その上で入念に計画立てた上でやっとクリア。
改めて、7つの習慣とは?
- 私的成功
- 第一の習慣・主体的である(Habit 1 Be Proactive)
- 第二の習慣・終わりを思い描くことから始める(Habit 2 Begin with the End in Mind)
- 第三の習慣・最優先事項を優先する (Habit 3 Put First Things First)
- 公的成功
- 第七の習慣・刃を研ぐ (Habit 7 Sharpen the Saw)
ここの内容が分かりやすかった。
前はハードカバーの分厚さで尻込みしてたけど、今はマンガも出てるし、一度読んでみるかな。
参考
世界的ベストセラー『7つの習慣』ってどんな習慣なのか知ってる？ | 美女読書
書籍
![完訳7つの習慣 [ スティーヴン・R．コヴィー ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/0246/9784863940246.jpg?_ex=128x128 "完訳7つの習慣 [ スティーヴン・R．コヴィー ]")
- ジャンル: 本・雑誌・コミック > 人文・地歴・哲学・社会 > 宗教・倫理 > 倫理学
- ショップ: 楽天ブックス
- 価格: 2,376円
![まんがでわかる7つの習慣 [ 小山鹿梨子 ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/5314/9784800215314.jpg?_ex=128x128 "まんがでわかる7つの習慣 [ 小山鹿梨子 ]")
- ジャンル: 本・雑誌・コミック > 人文・地歴・哲学・社会 > 心理学 > 生き方・人生論
- ショップ: 楽天ブックス
- 価格: 1,080円
![まんがでわかる7つの習慣（2） [ 小山鹿梨子 ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/3999/9784800223999.jpg?_ex=128x128 "まんがでわかる7つの習慣（2） [ 小山鹿梨子 ]")
- ジャンル: 本・雑誌・コミック > 人文・地歴・哲学・社会 > 宗教・倫理 > 倫理学
- ショップ: 楽天ブックス
- 価格: 1,080円
![まんがでわかる7つの習慣（3） [ 小山鹿梨子 ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/7164/9784800227164.jpg?_ex=128x128 "まんがでわかる7つの習慣（3） [ 小山鹿梨子 ]")
- ジャンル: 本・雑誌・コミック > 人文・地歴・哲学・社会 > 宗教・倫理 > 倫理学
- ショップ: 楽天ブックス
- 価格: 1,080円
![まんがでわかる7つの習慣（4） [ 小山鹿梨子 ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/0157/9784800230157.jpg?_ex=128x128 "まんがでわかる7つの習慣（4） [ 小山鹿梨子 ]")
- ジャンル: 本・雑誌・コミック > 人文・地歴・哲学・社会 > 宗教・倫理 > 倫理学
- ショップ: 楽天ブックス
- 価格: 1,080円
JaSST東北2016に行ってきた
2016/5/20(金)のJaSST東北2016のレポート。
今年のJaSST東北2016はVSTeP(ブイステップ)祭りだった。
基調講演 VSTePによるソフトウェアテストの開発 ー 西 康晴 ー
VSTePとは?
テスト設計の技法の一つ。
(他のテスト設計技法は、HAYST法、ゆもつよメソッドがある)
VSTePの流れ
- テストケースをざっくり考えてから具体化する
- いきなり細かく考えると抜け漏れが発生しやすくなる
- まずは「負荷」とかざっくりした観点で考えて、具体化していく
- 全体像を把握するための図を描く
- Excelの表だと全体像の把握は難しい
- 図の形式やツールにはこだわらない。全体像を把握するのが目的
テスト要求分析
テスト観点図を作成する。
- テスト観点を思い浮かべて、線でつなげる
- 観点を詳細化していく(親観点から子観点を引く)
- 関連する観点を線でつなぐ
テスト観点図の作成方法は、トップダウン型とボトムアップ型の2種類がある。
地図見るのが得意な人はトップダウン、苦手な人はボトムアップてやるのが良い(らしい)。
実際にはトップダウンとボトムアップを循環させながら進める。
テスト観点を導き出した理由・意図を明確化することが大事。
意図が分かっていれば、意図が間違っていたのか、意図通りに行かなかったのかが後から分かる。
テストコンテナ設計
テスト観点をグルーピングする。
コンテナはテストのカテゴリを示す(機能テスト、負荷テスト、セキュリティテストなど)。コンテナは単数または複数のテスト観点をグルーピングしたものとなる。
- コンテナを設計し、テスト観点と対応させる
- テストコンテナ図を作成し、各コンテナの実施順序(テストの順序)を検討する
テストの順序はテストの戦略になる。
テストフレーム設計
テストケースのひな形(骨組み)を作る。
テストケースを実施するために、どの観点を組み合わせて試験を行うかを設計する。具体的な値は詳細設計で考えることとし、ここでは観点の組み合わせのみを考える。
テスト詳細設計、テスト実装
普通のやり方でよい
- テストケースのひな形に具体的な値を入れる
- 値を入れたひな形を手順に具体化する
導入にあたって
- いきなり全部導入するのではなく、自分が困っているところに入れてみるのがよい。
とりあえず導入してみて、ダメなら止めればよい。 - 最初から完璧を目指してはいけない。
大事なのは困ること。困ったことを自覚して、図にして、直して、納得すること。 - 観点の抜け漏れはしょうがない。それが自分達の現在の技術レベル。
- 観点網羅を目的にしない。観点が「もう出ない」ことをチームで合意する事が大事。
- 観点として必要だと思わないものも観点として明示した上で「不要」であることを合意する。
- 「これさえあれば、何も考えなくても作業できる」とかはない。単純作業したい、自分の頭で考えない、言われたからやる、というような人や組織では導入しない方が良い。
演習
Lhaca+の解凍機能を題材にしたワークショップ。
以前のソフトウェアテスト勉強会でもやった題材。
テスト観点図
自分らのチームで作成したテスト観点。
ファイルのパターンを重点的に抽出。それ以外は、パラパラと出ていたテストケースに対して、ボトムアップで観点を付けた感じ。
何だか網羅性がなくて気持ち悪いと思っていたら、その不安が後で的中する形に。
テストコンテナ
写真撮り忘れた。
うちのチームでまず作ったのはこんなコンテナ。
- 解凍テスト
- コンテナに含めた観点
- (インプットとして)圧縮ファイルバリエーション
- (実施手順として)人による操作
- (アウトプットとして)出力先
- コンテナに含めた観点
実際にテストするときは、ファイルパターン×解凍機能の呼び出しパターン×出力先のバリエーションでの組み合わせテストになると考えて作ってみたけど、こんなんで良いのかとモヤモヤして、西先生に助言を頂くことに。
西先生からは「何をテストしたいのか?」「コンテナに入れる観点は、テストしたいもの。実施手順は観点ではない」というコメントを頂きました。
このコメントを受けて作りなおしたテストコンテナ。
- 解凍テスト
- コンテナに含めた観点
- 圧縮ファイルバリエーション
- コンテナに含めた観点
「解凍ソフトとして、色々なバリエーションの圧縮ファイルの解凍ができる事」を確認するテストとして、コンテナ作成した。 演習はここで時間切れ。
振り返り
- ファイルの観点を先に深堀りしたのは失敗だった(と思う)。
ファイル観点を深堀りしただけで満足してしまい、それ以外の観点をあまり考えないままテスト観点の作成を終えてしまった。
- テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
- そもそも、ファイルの種類が重要な観点だとは考えてもいなかった
- テスト観点の全体像を作成して、重要と思う観点をチーム合意して、その観点を深堀りするよう進めた方が良かったかも。
- テストコンテナの作成では、深堀りしたはずのファイル観点は入れる事すら出来なかった。
- チームの意識が、観点の抽出よりも、細かいテストパターンを出す方に意識が行っていたと思う。
テスト観点の抽出に意識を向けるよう、ファシリテートする技術が必要。 - 「プロダクトとして大切なのは何か」をチーム内で合意出来てなかった。 それぞれが、考えがバラバラなまま進めてた。
- VSTePを使うには慣れが必要。
- 自分のチームではテスト戦略まで考えられなかったが、他のチームが言っていたテスト戦略は興味深かった。テストの順番がテストの戦略という事がよく分かった。
- 性能テストは早い段階で実施する。理由は、性能に問題があった場合、改修が大変なので。
- 製品の品質を上げる事が先なので、製品の魅力テストは「当たり前品質」を確認した後に実施する。
感想など
去年のソフトウェアテスト勉強会でやったゆもつよメソッドと比べると、ゆもつよメソッドは仕様書をインプットにして観点上げるのに対して、VSTePは仕様書をインプットとせずブレストで観点上げる形なので、現場導入のハードルは高いように思う。
一方、他のチームで出ていた「魅力テスト」というコンテナとかは、仕様書からは絶対に出てこないテスト。これは「仕様書を見ずに観点を上げる」事による効果だと思う。
とは言え、プロジェクトにも寄ると思うが、仕様書見ないでテスト項目上げるのは、実業務ではハードル高い。
むしろ、設計入る前とかのブレストの方が使えるかも知れない。
あと、設計が実装に寄りすぎて「そもそもこのプロダクト何したいんだっけ？」な開発では有効かも知れない。(そもそもそんなプロジェクトは炎上案件だけど)
あと、現場導入時はファシリテート出来る人がいないと崩壊するのが目に見える。
幸い、ソフトウェアテスト勉強会でまた実施するそうなので、引き続き実践してみる。
リンクなど
VSTeP
当日のToggtter
JaSST'16 Tohoku ソフトウェアテストシンポジウム 2016 東北「テスト開発しちゃいなよ！～テスト設計との違い～」 #jassttohoku - Togetterまとめ
VSTePとゆもつよメソッド(とHAYST法)の違い
仙台ソフトウェアテスト勉強会のレポート(2015/09)
2015/09のテスト勉強会レポート。
先月の勉強会
に引き続き、ゆもつよメソッドの勉強。
マトリクスのチェック
前回作成したマトリクスに対して、仕様書等を参照しながら、作成したマトリクスに、試験が必要と思う所に○を付けていく。 (今回は時間の都合で圧縮の所まで○付け)
重み付け等で差を付けたい場合は適宜記号を工夫する事。
試験項目作成
作成したマトリクスを元に、試験項目を作成する。
表に記述する内容は以下の通り。
| 項目 | 記載する内容 |
|---|---|
| 機能名 | 中項目-小項目(内容が分かれば小項目のみでも) |
| テストタイプ | テストカテゴリの種類(ex.機能性、負荷テスト、パフォーマンステスト) |
| テストカテゴリ | テストカテゴリの各項目 |
| 仕様項目 | テストでの確認観点 |
| 期待結果／確認内容 | 期待する結果、確認する内容等 |
| パラメータ | テストで指定するパラメータ(上図では省略) |
機能名～テストカテゴリはマトリクスに○を付けたものを抜き出して記載する。
この各項目に対し、確認対象、確認する内容を記載していく。
試験項目と、マトリクス、仕様書を相互確認しながら作成する。マトリクスに不足があったりしたら、そちらも適宜修正する。
マトリクスの用途
ゆもつよメソッドのマトリクスは、システムテストのチェックに使用するために考えられたもの。
以下、自分の解釈。
単純に機能のIN/OUTだけに着目した試験だと、機能的に確認しておくべき試験が漏れてしまう事が懸念される。
そのため、ユーザシナリオでユーザにとって重要な機能を確認した上で、内部構造にも着目して試験観点を抽出する。
マトリクスの内容は、結合試験の内容と多少オーバラップしたものになるが、機能や処理パターンを網羅する事が目的ではない。
「ユーザシナリオを提供する」ために必要な機能を試験観点として抽出する事が目的になる。
非機能観点の試験は、「ユーザシナリオを提供する」ために必要な機能を抽出した上で、 その機能を多方面(性能、連続運転、ユーザビリティ、セキュリティ、等)の観点から検証するために実施する。
非機能観点は対象のプロダクトが変わっても流用できるものが多くなる。 チームやプロダクトで育てていくと良い。
最後に
ねもとさん、ありがとうございました。
仙台ソフトウェアテスト勉強会のレポート(2015/08)
2015/8/20のソフトウェアテスト勉強会のレポート。
今回はゆもつよメソッドのテスト分析マトリクスを使ったテスト分析のワークショップ。
なお、今回の内容は、勉強会主催者の理解に基いたコンテンツを、更に自分の理解した内容で書いているため、オリジナルのゆもつよメソッドと違う事を書いてたりする可能性があります。しかも自分が内容を理解し切れていません。 予めご了承下さい。
テスト設計三大巨頭
テスト分析マトリクスとは？
こんなやつ。
このマトリクスに対して、テストが必要なところに○を付けていく。
このマトリクスで、テスト全体を俯瞰して漏れがないようにする。
また、関係者でテスト観点についての合意を取るためのネタにする。
なお、このマトリクスは、 +Lhaca に対して作ったもの。
マトリクス要素の抽出
分割した3つの要素をそれぞれ作成していく。
機能一覧の作成
中項目の導出
- ユーザストーリーを考える
ストーリーはメイン(ユーザの主利用方法)のシナリオ、サブシナリオを考える。 - 作成したストーリーからキーワードを導出する。
- システム管理、設定の項目を追加する。
これらの項目はどのシステムでも汎用的に使える。
なお、設定は中項目に入れるパターンと小項目に入れるパターンある。
小項目の導出
抽出した各中項目に対して、小項目を抽出する。
機能テストの導出
完全なブラックボックスではなく、少し構造に踏み込んで検討する。
非機能テストの導出
非機能の観点は世の中に出回ってるのでこれをベースに考える。
中項目、小項目で上げた機能に対して、機能を揺さぶる観点から、必要な非機能観点を抜き出す。
マトリクス化
中項目、小項目と、機能性項目、非機能カテゴリを掛け合わせたマトリクスを作成する。
感想、疑問など
- 何で大項目がないんだろう？
- 非機能カテゴリ、「機能を揺さぶる観点から」考えると、頭の中で中小項目と非機能のカテゴリを掛け合わせて、必要なものを考える事になるように思う。 突き合わせ結果はエビデンスとして明に残しておいた方が良さそう。
- 中項目、小項目と機能性項目の掛け合わせ、フルのマトリクスでやる必要ある？ 中項目/小項目単位で機能性項目考えてもよいのでは？ 無駄に対象を大きくしてるようにも見える。
- ユーザシナリオをベースに項目を考えること、ユーザのメインシナリオ中心で項目抽出するのは、大事な所からテストするという点で有用そう。
今回は消化不良気味。
次回続きを行うそうなので、その時にはもう少し理解出来るかな。
JaSST'15 東北 に行ってきました
今更公開するのも何だけど2015/5/29のJaSST東北のレポート。 今年のテーマは「レビュー」。
togetter: JaSST'15東北まとめ - Togetterまとめ
現在のレビューに必要な次の一手を把握するレビュー実践ウォークスルー
www.slideshare.net
ドキュメントレビューについて
100の問題があるプロダクトを与えたときの問題検出率は、
- レビュー：80％
- テスト：50％
レビューの方が問題が見つかりやすい。 バグは混入してから直すまでの時間が短いほど効率的に修正出来る。
レビューによるコミュニケーション効果
- レビュー後に、チーム内の認識を一致させることができる
- チーム作りができる
- レビューを通して、プロダクトへの理解を深められる
レビューの開始基準
もし、突然レビューを頼まれたら？
- まともな欠陥は見つからない
- 何となくレビューすると、書いてあることだけのレビューになる
- 思いつきでレビューが出来るほどのスキルを持っている人はほとんどいない
構造化されたドキュメントは、短い時間で多くの指摘が出来る。
人にレビューお願いする前にセルフチェックは実施しておいてもらう。
そのスキルもない人だった場合は事前方針を決めてからレビュー。
レビュー対象だけではなく、その対象物のInput情報も一緒に見る。
安達さんがレビュイに求めるレビュー条件
- レビュー観点が言えるか
- どう作ったかを言えるか
- 単純な指摘(誤字、脱字等)ばかりが出てこないか(レビューに耐えうるものか)
- 設計相談にならないか
レビュー観点
立ち位置(役割)によって観点は変わる。
- 開発者：「作れるか？」
- テスター：「テストしやすいか？」
- 企画者：「使いやすいか？」
- マネージャ：「売れるか？」
レビュー観点にも粒度がある。
レビュー観点の粒度の例：
- 使いやすいものになってるか？
- 文字は見やすいか？
- フォントサイズが適切か？
- フォントカラーは適切か？
- ボタンは適切なものになっているか？
- 押しやすいサイズになっているか？
- 誤解を招く名前になっていないか？
レビュアのスキルによって、観点の粒度(どこまで具体化するか)も調整がいる。
何をどこまで書くか？ IEEE830 1998 に情報がある
よくある欠陥
- 開始・終了条件のアンマッチ
- 非機能用件の抜け
観点の体系化は目的の整理になる
レビュー実施方法
ラウンドロビン：章毎に別担当にレビューを割り当てる インスペクション：効果は最大だがコストも最大
状況によりレビュー方法も使い分ける必要がある
この本がお勧め。
- 作者: 森崎修司,日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2013/09/19
- メディア: 単行本
- この商品を含むブログ (2件) を見る
確認方法のシナリオ化
表現形式
図・表を自分の解釈で書き直してみる
テスト因子の洗い出し ラルフチャートを使うとよい
意地悪漢字
裏のワードも書かれているか？
全てやっていると時間が足りなくなるので、どこまでやるかはPJ毎に考える必要あり。
メトリクス
何に使うか？
ソースレビューは、150～200行/時間 くらいが効率が良い。
レビューは個別->全体 の順に。いきなり全体レビューは効率が悪い。
レビューコメントの書き方
レビュー指摘の仕方は一歩間違うと雰囲気が悪くなる。
主語を「あなた」ではなく「私」でコメントする。
× 「あなた」のこの書き方はおかしい
○ 「私」はこの書き方は修正した方がよいと思う
レビューの振り返りはレビューの後すぐやる。短い時間でやる。
改善をより効果的に回すためのレビューへの取り組み (CookPad 松尾さん)
www.slideshare.net
見るものをGitHubに集約
振り返りで人的な負荷が毎回課題に上っていた。
個人の意識だけでは継続が出来ない。
見るものを分散すると、人の負荷になる。
一カ所に集約することで、忘れることもなくなる。
レビュー観点
- ソフト全体 価値あるソフトになっているか？
- 計画、ドメイン、設計
- コード誤り
- 成果物
- ドキュメント
チェックリスト
PullReqを出す前にセルフチェックする
静的解析(Dokumi)
変更差分に対してのみ静的解析を行い、コメントする仕組みを用意。 自動的に行う。
まとめ
- 計算機が出来ることは計算機にやらせる
- 分散させない
効率的なレビューの運用について (村上さん)
PMPは書類が多い
打ち合わせが多い
実作業＜管理作業になる
バグトラッキングシステムで指摘を管理するように
- 指摘と修正もチケットで管理
- コミットログで修正履歴を管理
議事録も全てチケットで管理。 全文検索が出来るので便利。
達人の指摘から学ぶレビューのポイント (根本さん)
不具合の印象は強く残っているが、レビュー指摘の印象はあまり残っていない。 喉元すぎると忘れてしまう。
知識がないのにレビューをしなければいけない立場になった。
→達人のレビュー指摘から学ぶことにした
達人のレビュー指摘から観点とキーワードを導出。 自分が同じ指摘出来るようなレビュー観点を作成する 注意するキーワードを見つける
分からない事はすぐに確認。後に回さない。
業務改善コンサルからソフトウェアテスト効率化へ ～ 株式会社SHIFTサービス紹介 ～
テスト支援ツール chibinekoの紹介 https://chibineko.jp/
ライブコードレビューで学ぶ！「納品のない受託開発」を支えるコードレビューの取り組み
倉貫さんパート
レビュー＝成果物に対する指摘
マニュアル通りに書けるプログラムはない
人を育てるには、作らせて、指摘するしかない。 教育効果も狙える
相手の事を考えられる人を増やすには？
全てを担当する。
毎週、「成果」を提供する。「時間」を提供するのではない。
仕様変更はビジネス価値最大化のための選択。
ビジネスモデルとビジョンを共有する。
作る物をミーティングで合意して、翌週届ける。
動くソフトウェアが設計書。
設計内容はボード等で説明。後に残す必要はない。
ソフトウェアに求められる特性
- 常に仕様を追加・変更できること
- 常にリリース可能であること
- スピード感を持ち開発できること
- 不具合はすぐ修正可能であること
完全にはなくせないが、検知できること。放置しないこと - 上記の特性により、持続して変化できること
ソフトウェアは塩漬けにはできない。 外的環境が許さない。何もしなくてもOSやミドルウェアのバージョンアップが発生し、追随しなければならない。
西見さんパート
www.slideshare.net
ソースコードで全てを回す
以前はペアプロでコードを共有していた。効果はあるが時間がかかる。 レベルの高い人同士であれば、コードレビューで理解し合えると気づいた。
出来ない人がコードレビューするのは時間の無駄。
一人前の人は「良いコードは何か？」の共通認識を持っている。
ランチタイムのディスカッションで共通認識の醸成をやっている。
レビュータイミング
- ローンチ前の全体レビュー
- 本番リリース前レビュー
- リリース前レビューは毎回実施
レビュー観点
- 意図を読み取れるソースコードか
- テストコードは書かれているか
- リリース時に問題が起こらないか
- 障害時のリカバリは考えているか、問題時にすぐ対処できるか
- 環境周りの変更はないか
読みにくいソースコードは「読みにくい」と素直に言う。
価値観
コードレビュー ７つの秘訣
- レビューの観点を明確にすること
- 我が身に返る事を恐れずに指摘すること
- 何故悪いコードなのかを論理的に説明すること
- 良いコードについての共通認識を持つこと
- 小さい単位でレビューを繰り返すこと
- 指摘は素直な気持ちで受け入れること
- 指摘は人格否定でないことを理解すること
ディスカッション みんなにとって分かりやすいものにする
個人の趣味で指摘をしないこと
まとめ
- 自分たちの開発プロセスに適したレビュー観点を設定する
- レビュー観点に基づく、良いコードの共通認識をチームで持つ
- レビューは小口化して継続的に実施する
人の目を入れてコードを腐らせない
レビューに関するQA
自分の質問と、パネラーから頂いた回答。
質問) 効率的にレビューを実施するにはどうすればよいか？
十分な時間がない中でレビューを実施する事があり、短い時間の中でもレビューを有益なものにするにはどうすればよいか？
- 小さく作ってレビューする。
いきなり全部作ってではなく、5～10％くらい作った時点でレビュー。
大きい固まりが一度に「ドン！」と来たら既に負け戦。 - 「気になるところ」をチームでレビューする。
どういうところが大事かを事前に決め、そこを見る。
時間割を決めてやる
- 大事な所からやる
リスク部分、難しい所、重要な所など - ゴールを決める 何が出来るようになればOKか？
- 人間特性、手薄い所、異常系の記述量が薄い所を見る。
他のQAでなるほど、と思ったコメントなど。
「レビューをやって良かった！」と思わないと継続できない。 レビューの効果を測定し、見える化する。
レビューの時間は予め予定に組み込んでおく。
大きいプロダクトのレビュー終了条件は「時間」。 レビューが遅れたら後行程の作業はその分遅れる。
期間を予め決めて、その期間の中でプロダクト品質を高めるにはどうすればよいかを考えた方がよい。
改めて思った事など
ドキュメントは読み手のレベルに合わせる必要がある。 万人に対して大丈夫なドキュメントなど存在しない。
ソースがドキュメントになるには、プログラマのスキルは必須だが、言語も選ぶと思う。
Rubyはともかく、手続きのコードが多くなりがちなC言語のソースを「ドキュメント」というのは辛いように思う。
ソニックガーデンさんがRubyを選択してるのはRuby on Rails使える以外に、ソースがドキュメントになり得るという所もあるのかな、と思ったりした。
前のプロジェクトで、こっちが作った設計書に「あれ書いてない」「これ書いてない」「フレームワークが分からない」と散々ダメ出しされた事があって、チームの雰囲気が最悪になった事を思いだした。
気にするポイントはその設計書を見る人の数だけあるので、事前にサンプル出して相手と意識合わせする事が重要。
