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 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデル