JSTQB TMのシラバスを読んでいる

はじめに

ソフトウェアテストの勉強をしているので、JSTQBのTMの勉強をしている。

自分がよくわかってないところを重点的に勉強しているので、ここに自分の理解を書いておく。自分の理解なので、間違っている可能性もある。

テストの見積もり

見積もりの技法

  • 直感、推測、過去の経験

  • WBS

  • チーム見積もりセッション(ワイドバンドデルファイなど)

  • 企業の標準および基準
  • プロジェクトの総工数、スタッフ構成の割合
  • 組織のデータ蓄積、メトリクス
  • FP、コードの行数、開発者工数などのパラメータから業界標準や予測モデル チーム見積もりセッション以外は、これまでやったことがある気がする。

見積もりに影響を与える要因

  • 品質レベル
  • システムのサイズ
  • 過去プロジェクトのデータ
  • プロセス成熟度、プロジェクト見積もりの正確さ
  • 物理的要因。ツール、環境、データ、再利用可能なテストドキュメント
  • 人的要因。
  • プロセス、組織、技術などの複雑さ、ステークホルダーの数。サブチームの構成と場所
  • 人数増加に伴うトレーニングと導入
  • 新しいツール、プロセスなどの適用や開発
  • テスト仕様の詳細度合い
  • コンポーネントの受け入れ時期
  • 使える範囲の限られたテストデータ
  • テスト対象のソフトウェア品質

挙げられているものは粒度がまちまちだが、そういわれれば考慮しないといけないものばかり。特に、「テスト仕様の詳細度合い」「コンポーネントの受け入れ時期」「使える範囲の限られたテストデータ」は日頃あまり意識してなかった。大体の要素が見積もりが増える要素。

テストメトリクスの定義及び使用

テストメトリクスの4つのカテゴリ

ALでは、以下のうち、プロジェクトメトリクスに重点を置く。

プロジェクトメトリクス * プロジェクト終了基準に対する進捗を測定 * 実行済み、合格、不合格のテストケースの割合など * プロダクトメトリクス * プロセスの属性について測定 * テスト範囲、欠陥密度など * プロセスメトリクス * テストプロセスや開発プロセスの能力を測定 * テストで検出された欠陥の割合   プロセス自体が機能しているかどうか * テストで欠陥を見つけられているか * 早期に大量の欠陥を見つけられているか * 人的メトリクス * 個人、またはグループの能力を測定

テスト進捗モニタリング

  • プロダクトリスク
    • テストに合格することにより対応されたリスクの割合
    • テストに不合格になったリスクの割合
    • テストが完了できていないリスクの割合
    • 最初のリスク分析後に識別したリスクの割合
    • リスクカテゴリで分類されたリスクのうち、対応されたリスクの割合

最後の要素の意味がわからなかった。一番最初のテストに合格することにより対応されたリスクの割合とは違うのか。テスト以外の手段で対応されたものということ?

  • 欠陥

    • レポート済みの総数と解決済みの総数の比

      • 未解決のものがどのくらいあるのか。終了基準にもなっていることがあるから、監視が必要。
    • 平均故障間隔または故障率

      • 内容は理解したが、何に使うのかがイメージできない。今後のテスト実行フェーズの停止頻度の予測に使うのかな。
    • 任意の分類ごとの欠陥の割合
    • 欠陥のレポートから解決に至るまでのタイムラグの傾向
      • 欠陥の検出から解決までのボトルネックを見つけるのに役立ちそう。あと、長く修正がかかってるものは修正にてこずっていることもあるから新たな欠陥を埋め込みやすい とテストのあたりをつけたりできる。
  • 拒否されたレポート、重複レポート

     * バグレポートのうち、評価対象外となるものといえるか。また、レポート内容の品質を測定するものにもなる。
    
  • テスト

    • テストの総数
    • 回帰テスト、確認テストのステータス
    • 計画している1日当たりのテスト時間と実績のテスト時間の比
      • 進捗ではなくて、コストを見るもの
    • テスト環境の可用性
      • テスト時間のうち、テスト実行ができた時間を導き出すためのもの  
  • カバレッジ

  • 確信度合い

      * カバレッジを代替とすることもある。主観的な評価となることが多い。
    

    テストコントロール

  • 品質リスク分析、テストの優先度、テスト計画見直し
  • リソース追加、プロジェクト活動・テスト活動の追加(タスクの追加)
  • リリース日の延期
  • 終了基準の緩和、または厳格化
  • プロジェクトの対象範囲の変更

どの選択肢をとるかは、PJの事情や役割・立場によって違うだろう。

今読んでいる本

 衝動買いしてしまったので、順番に読んでいく。時間を見つけてこつこつと。

最高の体調 ~進化医学のアプローチで、過去最高のコンディションを実現する方法~ (ACTIVE HEALTH 001)

最高の体調 ~進化医学のアプローチで、過去最高のコンディションを実現する方法~ (ACTIVE HEALTH 001)

 
超ストレス解消法 イライラが一瞬で消える100の科学的メソッド

超ストレス解消法 イライラが一瞬で消える100の科学的メソッド

 

 

 

残酷すぎる成功法則 9割まちがえる「その常識」を科学する

残酷すぎる成功法則 9割まちがえる「その常識」を科学する

 

 

 

PRE-SUASION :影響力と説得のための革命的瞬間

PRE-SUASION :影響力と説得のための革命的瞬間

 

 

FEARLESS CHANGEを読んだ

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 「FEARLESS CHANGE アジャイルに効く アイデアを組織に広めるための48パターン」を読み終わった。カイゼン・ジャーニーに続いて、こちらも面白かった。

本の中でも書かれているように、本書には、事例や経験談から抽出したパターンを書かれているということなので、既に経験的にやっていることが出てきたものもあれば、こういう手もあるのか、という気づきもあった。

心に残ったこと

組織というか、人に変化してもらうための気づきをあげる。 そんな劇的に人は変わらないもの。仕事で改善活動や新しいものの導入を担うと、主にマネジメントから、成果を早く出すようにプレッシャーがかかる。その中で、焦って進めて、一応、形式的にはできていることになっているけど、実態は形骸化してしまったということがあった。 高い立場の人から指示を出して、マイルストンを作ればいいと、そんな単純にはいかないので、丁寧・修正しながら進めないといけない。ただ、パターンにもあるように、影響力を持つ人とのかかわりを持ち続けていく、いうことも必要なので、そこのバランスが大事なのかもしれない。

変化を引き起こすことについての誤解

この2つ。特に、一つ目は、陥ったことがある。ついてきてくれない周りにストレスをためてしまっていた。

  • 良いアイデアであればみんなに受け入れられる
  • 新しいアイデアを紹介すれば、あとは何もしなくてよい

トップダウンの変化の特徴

変化を早く起こそうと思うと、トップダウンで進めがち。こちらも覚えがある。形骸化しやすい。

  • 急速な変化
  • 必要に迫られた問題だけを扱う

人々は変化させられることに抵抗する

抵抗する人々は、変化が嫌いな人たちではない。肝に銘じよう。

変化することに抵抗するのではなく、変化させられることに抵抗する。

取り入れようと思ったパターン

お互いに気軽にできて、いい気分になることが結構あることがわかったので、取り入れたいと思った。 人を相手にするんだから、ロジカルじゃなくて、人の感情に着目しないとね。 いやな気持になるんだったら、やらないよね。

  • 何か食べながら 仕事だからまじめにしないと、と思っていたけど、とりあえず、お菓子を差し出すことはしよう

  • 感謝を伝える あえて感謝するの気恥しいなと思っていたけど、周りの人にありがとうと言われて、いやな気はしない。

  • ブラウンバックミーティング あまり構えずに、話ができそう。機会見つけて試そう。

まとめ

これまでの自分の工夫をパターンに発見して、うれしくなったり、新しいパターンを試してみようと思ったり、 これを読んでいるときは、有意義な時間だった。 事例紹介がついているのも、わかりやすくていいなと思った。やはり、ストーリーに載せて、語られると頭に入ってくるし、やってみようと思う気持ちが上がる。この語り方もやってみようと思う。言いたいことをストーリーに乗せるやり方。

読み終えたらすぐにPCに向かってブログに書き始めたので、あまり間を置かずにブログを書けた。書きっぷりが固い気がするけど、徐々に慣れるようにしたい。

カイゼン・ジャーニーを読み終えた

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

 1か月と少しかかったが、カイゼン・ジャーニーを読み終えた。週末しか読書の時間は取れなかったので、時間はかかってしまったが、ストーリー自体が面白かったので、週末、実家にまでもっていって、読むくらい、没頭して読んでいた。

私が一番良いと思ったのは、現場で改善したいことがあるけど、様々な事情でうまくできてない、社外の勉強会に行くとみんなキラキラしてるように見えるのにー、なんでうちの現場は、、、とモヤモヤする、という身に覚えがある人が多そうなことが取り上げられていることだ。

私も、同じような境遇だったこともあるので、共感するところがあった。

心に残ったと思ったこと

  • 自分から始める

今の自分の周りに変えたいところがあって、でも、思ったようにうまくできていないとき、私はよく、社外の勉強会やSNSでほかの人の事例を聞くことで、ヒントを得ようとする。その時はテンションが高くなり、やる気も高まるが、現実との落差にうーんとなる。まさに、この本に書いてある通り。

イベントや勉強会に行って、良い話を聞いて意識を高めて、そして現場に戻って、現実と向き合い、またモヤモヤし始める。

でも、結局、自分で何かしないと、永遠に周りは変わらない。しみじみ考えると、その時は分かった気になるけど、日々の諸々に追われると、この原則を忘れそうになる。

頭に植え付けるために、ここにも上げておく。

  • 二人ならもっと変えられる

実はこの言葉が一番心に残っている。一人で何か新しいことをしているときは孤独で、自分がやっていることに対して、だれもかれもが無関心なように錯覚してしまう。そのせいで、無駄なストレスやいらだちを感じてしまう。

一人だけでもいいから、興味を持ってくれる人を探すのが大事。

だから私は、誰かが一人でとりあえず何かやろうとしているときには、とりあえず、なんかの反応はするように心がけている。

一人より二人の力は強い。

 

  • 遅すぎるということはない

自分の中でのいまさらやっても、、、という弱音や、他者からの批判やネガティブな反応に対して、自分を鼓舞するために、心に刻んで思い出すようにしたい。

 

取り入れようと思ったこと

知っているものもあれば、初めて知ったプラクティスがあった。

取り入れようと思った、プラクティスを記録しておく。

  • 現場のDiffをとる

 勉強会などで、事例を知るとすぐに自分の現場にあてはめたいと思ってしまうのだが、置かれている状況が異なるから当然、そのまま適用できない、という話。

 思えば、開発成果物や提案資料の作り方を知りたいというときに、何を何のために書くのか、という情報よりも、サンプルや事例を欲しがる人が多い気がする。サンプルや事例を基にしたときに、結局、それらが作られた時の意図を把握しないと、今回自分が書きたいことを書くのが難しいから、経緯や状況も含めて事例を参考にしないといけない。でも、そういうことをわかってるよーといいながら、わかってない人が多い。。。

 

  • 期待マネジメント

チームで仕事をすると、メンバー同士のちょっとしたいざこざは、良く起きる。「こんなこと当たり前でしょ」「xxさんはxxxをやってくれるとおもってたのに」みたいな話である。その仲裁をするのが苦手で、大きなストレスになってしまう。

この考え方を使って、個人個人の価値観や周りへの期待をざっくばらんに話せるようになると、今よりはよくなるかもなと思った。

 

  • モブプログラミング(モブ〇〇〇)

プログラミングに限らず、ほかの活動についても、適用できると思った。悩む時間を減らすという発想はすごく良いなと思った。教育という目的で、経験の浅い人に一人で考えてもらう、ということしかやってなかったのだが、別に一人で悩んでもらわなくても、教育はできるんじゃないかな、と思うようになってきた。むしろ、作業を共有することで状況の可視化、一人のひとが作業の責任を負うことのストレスをなくす、悩む時間の削減、誰かが休んだ時のフォローしやすさ、といったメリットのが多い気がする。

ただ、私の現場だと、マネジメントに認めてもらうのは時間がかかりそうだ。1人でできることを複数人でやってるように見えちゃうから。勝手にやれる範囲で勝手にやろう。

まとめ

周りの人たちがみんな読んでいたという理由だけで、読み始めたのだが、今後の自分の行動に活かせそうな考え方が書かれていた。心が萎えそうなときには再読しよう。

 

以上、初めての読書記録を書いてみた。ここに書くことで、次のアクションに行かしたいことが整理できたのでよかった。

 

ちなみに、今は、「Fearless Change」を読みはじめている。もっと早くからやればよいのだが、メモを取りながら読んでいる。こちらも、そのうち、読書記録を書く。

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

カイゼン・ジャーニーを読み始めた

ふと思い立って、巷で話題に上がっている「カイゼン・ジャーニー」を購入した。

仕事だけではなく、社外活動をいくつかやっているので、自分の進め方ややり方の参考になればと思っている。

 

少し読み始めている。読みやすい。もう少し読んだら、記録を書こうと思う。

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

 

はじめに

このブログは、私の日々の学びや気づきを記録するブログです。本や勉強会などからの学んだことや、必要にせまられて調べたことの記録につかいます。これまであまり勉強する習慣がついてこなったので、アウトプットを意識して、インプットさせるような仕組みにすることで、今よりはマシになるのではないか、と思っています。

あくまで自分の理解を書いていくので、他の人との見解が違うことがあると思います。1つの意見と捉えてもらえればありがたいです。

ソフトウェア開発に関する話や読んだ本や日々の生活の話が中心になると思います。

ブログ経験あまりなく、書くのも遅いですが、継続できるように頑張ります。