とある組み込みエンジニアひとりごと

朝活を通じて得たものを紹介していきます

ソフトウェアのテストセミナー

セミナーに参加してきました。

わたし自身昔はテストで品質を抑えればいいじゃんと思っていました。

テストでどうやって抑えるのかは関心ごとです。

本日聞いてよかったなと思ったことをまとめておきます。

基本は仕様書がないという制約の中どう想像してテストケースを作るかに集約されていました。

  • 何をテストするのかを考える

  • 品質の定義

V字モデルを前提とした場合

品質は要求を満たすことである

  •  要求をどう分析するか

狩野モデルというのを知ってますか?たまたま上司が狩野モデルを知っていたので展開されたことがあります。MSではよく使われているようですね。日本ではほとんど使われていないといわれていました。

*1

https://www.juse.or.jp/departmental/point02/08.html

では狩野モデルを使ってチームで何をするとよいかというと

  1.  ある機能について5分でワークをやる
  2. 5分経ったら洗い出したものをチームで共有する
  3. 偏った観点がわかる

という流れです。チームビルディングの基本ですよね

お互いの考え方が違うということを認識する

以下の本で読んだ内容です 

『個』を生かすチームビルディング チームスポーツの組織力を100倍高める勝利のメソッド

『個』を生かすチームビルディング チームスポーツの組織力を100倍高める勝利のメソッド

 

 セミナーではスマートフォンのあたりまえ品質を洗い出しました。

自分は

・電話できる

・電源が入る

・OSが起動する

魅力的品質

・アンドロイド、IOS両方が使用可能

とか入れました。

ここでの自分の気づき

 ・5分という限られた時間内では自分が特に困ったことや当たり前と思っていることを出すので精一杯の時間しかない

ということです。なので、最近OSが消えたとか、IOSないので英語アプリが入れれないとか困ったことがどうしても出てきてしまいますよね。ということ。

これをやったと

 ・絶対ないといけない機能(never)

 ・必要な機能(must

 ・あったらいいなという機能(want)

の3軸で考えるとより抜け漏れがなくなるという観点です。

スマホで言うと

 ・電源が入って爆発しないこと

 ・充電が終わっても燃えない

PL問題につながるようなことはないよね?を考えるとmust機能って

でるよねって考え方です。

  • どうテストするのかを考える

これは各機能がどんな目的のために作られたのかを明確にしたうえで

テスト内容を決めるというやり方です。

  • テストの全体像を考える

各機能テストした観点をマップにして見える化するという方法です。

問題が出るとなぜテストしてなかったんだ!と言われるがそもそもQCD達成のためにそぎ落としたなかでそんなこと言われてもしらんがねってこと。

PDCAを回すためにもどの機能がどんな観点でテストを行いどうなったかは

重要だよねって流れです。

 

狩野モデルは日々やってもいいなと感じたことと

頭を使う部分と訓練する方法はいろんなものの基礎だよねってことを学びました。

年休とって行った価値はあったかな。

 

 

*1:狩野モデルは以下を参照

div #breadcrumb div{ display: inline;font-size:13px;}