テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



92. テストの目的 その④

f:id:m_training:20200802205359p:plain

 92. テストの目的 その④

 欠陥を防ぐため、要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。

JSTQBの2018V3.1.J02に書かれているのは上の通り。

 

V3の最初は「欠陥の作りこみ防止の話」と「作業成果物の評価(レビュー)の話」が別々だったけど、今はマージされていますね。

 

「欠陥の作りこみ防止」については、レビュー、つまり静的テストを行うことによって欠陥を防ぐ、というのがあります。

シフトレフトというやつですね。

あとはマンガに描いた通り、継続的な開発においてはこれまでのテストの情報、中でもバグの情報をレビューに活かすことができます。

 

続きを読む

91. テストの目的 その③

f:id:m_training:20200719164233p:plain

91. テストの目的 その③

 ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。

 JSTQBに書かれている言葉としては上の通り。

テストをしないと

「これホント大丈夫なんだっけ…。ちゃんと動くんだっけ…。不安だ。けどエイヤで出すぞ!」

といったところ。

それがテストをすることによって様々な情報が「見えてくる」わけです。

自分たちが考えている使い方だとバッチリ動作することがシナリオテストでわかったとか。

負荷テストを行って、今までの最大アクセス数までは全然余裕で動くことがわかったとか。

セキュリティテストを行って、よくあるような脆弱性の心配は解消されてるとか。

実はオプション画面で繰り返し変更かけると1/100くらいで設定失敗するとか。そこ原因わからなくて直してないとか。

こんな感じで、テストしないときは漠然と「不安だ~」と思っていたことが、テストによって

続きを読む

90. テストの目的 その②

f:id:m_training:20200712210502p:plain

90. テストの目的 その②

欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する

「バグの発見」と書いたけど、シラバスに書かれている文章は上記の通り。

 

バグを見つけて、それを修正することで市場に出たときのリスクを軽減することができます。

「おいおい、見つけまくって全部直すのかよ!?」みたいに言う人もいるけど、これはまた別の回の「ステークホルダーへの意思決定のための情報提供」の話でやろうとも考えています。

先出しすると、見つけたバグについては「こういうリスクがあるよ」ということがわかるわけです。

そのうえで、どこまでリスクを許容するのかという考え方もあります。

「これだと大きなリスクはないし、次のスプリントで修正」ってことも全然ありなワケです。

けど例えばカーナビみたいな市場に出た後直せないやつだと、次、がなかったりもします。

 

ユニットテスト、統合(結合)テスト、システムテスト段階ではなるべく多くのバグを見つけまくる、がどのみち幸せかと思います。

そして修正することで市場に出たときのリスクレベルを下げることができます。

 

続きを読む

89. テストの目的 その①

f:id:m_training:20200629062620p:plain

89. テストの目的その①

テストを行う目的

JSTQBのFLのシラバス(2018V3.1.J02)に記載されているのは以下の7つ。

 

  • 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
  • 欠陥を防ぐため、要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
  • ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
  • 明確にしたすべての要件を満たしていることを検証する。
  • テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
  • テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
  • 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。

2011年版のシラバスだと記載は以下の4つだった。

  • 欠陥の検出
  • 対象ソフトウェアの品質レベルが十分であることの確認
  • 意思決定のための情報の提示
  • 欠陥の作りこみ防止

ベースは2011年版の4つだけど、それらをより詳細に書き表したのが新しいバージョンといったところ。

テスターちゃんでは新しい方でお話を描いていくつもり。

 

ちなみに2018年版の最初は9つだったけど、まとまるところがまとまって7つになったようだ。

 

続きを読む

【新人さん向け】web系でよくあるテストケースの実行の一連の流れと注意点

こんにちは。作者です。

 

IT系では在宅業務になった会社さんが結構あるかと思います。

在宅業務は良いのですが、結構大変な目にあっているのが…新人さん!

入社早々在宅環境に投げ込まれ、先輩たちも慣れない環境のせいでサポートがあまりうけられない!なんて方々もいらっしゃるかと思います。

あと、先輩と同じ空間にいたら気軽に聞けていたことも、チャットを介してだと聞きにくくて放置している疑問もあるかもしれません。

その結果、自分がどういう風に動けばいいのかわかっているようで曖昧……

さらに、6/1から在宅があけて出社に!!

ああっ!!私はどうすれば!?

…みたいな人のために(?)、テスト系業務をすることになった新人さんが恐らく最初にやることになるであろう「テストケースの実行」のweb系でよくあるフローを書いておきたいと思います。

作者はwebやゲーム系の会社しか回っていないので、他の場所は知らないです。

けれど、ゲーム/web/appの巡った場所は大体似たようなフローだったのでそれについて書いていきます。

もちろん場所によってルールは様々。

大まかな流れ程度の把握にしましょう。

自分の会社、担当業務でのやり方はしっかりと先輩方に聞いて把握してくださいね!

 

【新人さん向け】web系でよくあるテストケースの実行の一連の流れと注意点

テストケースの実行の大まかな流れ

  1. テストリーダーからテストケース実行の担当範囲が割り振られる
  2. テストする環境とデバイス(ブラウザ)をしっかり確認
  3. テストケースをひとつずつ、手順をしっかり見て確認
  4. 問題がなければテスト結果をPassなどのステータスにする
  5. 問題があったらテストリーダーに問題があった旨を報告
  6. テストリーダーがバグか、問題なしか、既知(登録済み)の問題か判断して対応を指示
  7. バグ登録の指示があったらテスト結果にFailを入れてバグ票を書く
  8. バグ票を書いたらテストリーダーに報告する
  9. そのFailのテストケースとバグ票の番号(URL)を紐づける(記載欄に書くとかね)
  10. 自分の担当範囲が終わったらテストリーダーにちゃんと報告
  11. 登録したバグの修正が返ってきてたら、確認テスト(そのバグが直ってるか確認)を実施
  12. 直っていたら、バグ票のステータスを決められたステータスに変更(修正済みなど)
  13. そのバグ票が紐づけられているテストケースをPassにする(または修正済みステータスなど)
  14. もし直っていなかったら、テストリーダーに「直ってるっていってるけど直ってないです><」と連絡

 

大体こんなかんじ。

コレがweb系でよくあるテストケースの実行時のサイクルです。

さらに細かく見ていってみましょう。

続きを読む

Oculus Quest用Fitnessゲーム「BMSFitness」公開!【BMS】

サンデープログラマーまつです。こんにちは。

ゴールデンウィークを利用して、自作のFitness音ゲーを作りましたので公開します!

SideQuestで公開中です。

https://sidequestvr.com/app/942/bmsfitness

 

The Fitness Game "BMSFitness" for Oculus Quest is now available!

You can read English explanation the below link.

https://github.com/jam0824/unitybm98v2#Download

 

  • 【Oculus Quest】Fitness App「BMSFitness」公開【BMS
    • Download
    • 概要
    • 紹介動画
    • 使い方
    • 遊び方
    • カテゴリーの作り方(20200516バージョンで追加)
    • ランダム選曲(20200620バージョンで追加)
    • BM98のUI
    • 消費カロリーについて
    • GitHub
    • プレイ動画
      • TO MAKE THE END OF BATTLE
      • 三人称視点での撮影
      • Final Fantasy4 battle
      • Last! Least! Regrets!!
      • Welcome Mr.E-R
      • 璃子 JV-1080Mix (2nd Mix)
    • 仕様について
      • ファイル形式
      • 音声形式
      • ヘッダー
      •  アニメーションファイル形式
      • メインデータ
      • Oculus内の曲ファイルについて
      • mpgについて(20200510バージョンにて対応)
    • Avator modeについて (20200524バージョンにて対応)
    •  
    • キャッシュについて (20200620バージョンにて対応)
    • 既知の問題点
    • ソフトウェアテスト研修用のテスト対象にも考えてみたい
    • 更新について
    •  使用音声

 

【Oculus Quest】Fitness App「BMSFitness」公開【BMS

Download

以下から最新版apkがダウンロードできます。

BMSFitness - Google ドライブ

※非公式Appです。ご利用の際は自己責任でお願いします。

※横幅1.4mくらいを行き来します。ケガをしないようにご注意ください。

概要

Oculus Questの専用アプリで、音楽に合わせて飛んでくる弾を叩く、いわゆる「音ゲー」です。

また、ゲームでどれくらいのカロリーを消費したかもわかります。

音楽で楽しみながらやせられるゲームです。

この手のFitnessゲームはVRではBOXVRを筆頭に結構あります。

何が違うかというと「BMSファイル」を読み込んで使うという点です。

dic.nicovideo.jp

BMSは有志が作っている音楽を奏でるファイルです。

その昔ビートマニアのエミュレーション的なソフト「BM98」でとてもとても流行り、私もキーボードが壊れるまでプレイしたものです(しみじみ

leafの曲、Kanonの曲……思い出深いです。

話はそれましたが、有志が色々と音楽を作ってくださっています。

その曲を利用して遊ぶことができるわけです!

また歴史がある形式なので、すごーく昔の懐かしの曲なんかもあったりします。

 

紹介動画

www.youtube.com

 

続きを読む

bm98の曲データを読み込んでOculus Questの音ゲーにした話

こんにちは、作者です。

今日はテストの話も仕事の話も全然関係ありません。

趣味全開の話でも書こうかと思います。

 

 

bm98の曲データを読み込んでOculus Questの音ゲーにした話

近頃は業務前にOculus Questでボクササイズのゲームを行うことが日課です。

簡単にいうと、音楽に合わせて弾が飛んでくるので、それを打つべし打つべしするゲームです。

で、やっているとだんだん同じ曲なども増えてきて飽きてきちゃったりするのですね。

そこでふとこんなことを思いました。

 そんなわけで、さっそく木曜の夜から作ってみました。

木曜の夜~日曜日午前中くらいまでで作成です。

これができるようになったらたぶんマッハオラができます。もしくは北斗百裂拳。

まだプレイ画面しかないしOculus questなので配布ができず自己満足にしかなりませんが、githubは置いておきます。

気が向いたらリザルト画面や曲選択画面を付けようと思います。

https://github.com/jam0824/unitybm98v2

 

www.youtube.com

 f:id:m_training:20200426145106p:plain

曲データはビートまりお様の「約束-HappyHyperStarmiX-」を拝借しております。

 

bm98の曲データを利用

音楽に合わせて打つべし打つべしのボクササイズゲームを作るにも、まず必要なのは曲や譜面データ。

そこで思い浮かんだのが「bm98」でした。

その昔「ビートマニア」というゲームが流行り、そのオマージュのフリーゲームとして「bm98」がありました。(もう20年は前)

https://ja.wikipedia.org/wiki/BMS_(%E9%9F%B3%E6%A5%BD%E3%82%B2%E3%83%BC%E3%83%A0)

有志が曲データを作ってネットで配布していました。

作者もその昔めちゃくちゃハマっていて、そのことを思い出したわけです。

そんなわけで、bm98の楽譜データ(bms)を読み込んで曲データを詰めた弾を飛ばし、叩くとその弾から音が流れるようなものをVRで作ってみました。

 

開発の流れ

  1. 「bm98の譜面データ読み込んだろ」と思いつく
  2. 譜面データの構成のお勉強はじめる(http://www.charatsoft.com/develop/otogema/page/04bms/bms.htm 
  3. むしろ音符の勉強をする
  4. なんとなくわかったので譜面をフレームに変換するアルゴリズム考える
  5. そのアルゴリズムで計算通りに音が配置されるかコード上でテスト
  6. ただのオートプレイの音楽再生機を作る(プロトタイプ1)
  7. オブジェクトを飛ばしてドンピシャのとこで音を鳴らすために時間やら距離やら速度のお勉強を思い出す。(結果オブジェクト生成タイミングさえ合わせればオッケーだった)
  8. 雑に壁を作ってそこにオブジェクトをぶつけて曲がイイカンジに鳴るか検証
  9. Oculus Questの環境を作って結合。システムテスト。この時点で原型がほぼ完成(プロトタイプ2)
  10. 見栄えをリッチにするために飛ばす弾とかステージをunity assets storeでお買い物
  11. カッコイイエフェクトをつけまくって悦に浸る
  12. Oculus Questでシステムテスト。フレームレートがガタ落ちで真の戦い開始
  13. テクスチャのクオリティ下げたりオブジェクト削ったりいらないcolliderをけしたりエフェクト削ったりエフェクト時間を短くしたり音のオブジェクト消える距離を短くしたりとあらゆる削減を実施。oculus quest既定の72FPS確保する
  14. beat saberが流行ってることを思い出して急きょ仕様変更して刀のオブジェクトを買う
  15. プレイしたけどやっぱり拳で語りたくなったので刀を破棄する
  16. bm98には「BGA(BackGroundAnimation)」というのがあるので、fpsと相談しながらそれに対応する。スクリーンっぽく配置
  17. コンボ表示を追加。Oculus Questでテストプレイしながら表示位置調整
  18. 最終テストプレイ。もう腕が上がりません

 

テスト

http://www.charatsoft.com/develop/otogema/page/04bms/bms.htm

bmsデータの変換の仕様としては、これの「メインデータ」の01,02,04,10~19に対応。

この辺の変換周りは、「特定フレームで、指定した音データが含まれているか」「3/4拍子になったときに音符間の長さが想定する計算結果と一致するか」みたいなユニットテストでいけます。

 

けど、ゲームはオブジェクト(3Dモデルとか)の操作がとても多い。

例えば弾にコントローラーがぶつかったとき。

  • 弾がぶつかったらその弾は消える。
  • その弾が抱えている音は鳴り終わるまで消えちゃダメ。(このバグに引っかかりましたw)
  • 弾が消えるときにはエフェクトが生成される。

こういったところはコードでのテストでは見にくく、システムテストでOculus questを通して見た方が早い。

(けどヘッドセット被ってるとlogcat見づらい…!)

あとPCの画面上での表示とVR空間上の表示はかなり印象が異なったりするので、ヘッドセットをかぶってUIを確認して位置調整をしたり。

 

結果的に、ほとんどOculus Questをかぶってシステムテストレベルで確認となってしまい。。。

いつも「システムテストでまとめて見ちゃダメだよー」と言っている人なのにっ><

 

で。

テストプレイ後半は15分の休憩を入れないと息が……息が……!!

(最初はもっと簡単な曲でテストしてんですけれどね)

 

ゲーム系のテストは難しい……!

 

 

マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1

マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1

  • 作者:松谷 峰生
  • 発売日: 2020/03/25
  • メディア: 単行本(ソフトカバー)