メトリクスを取るときに注意する5つのこと
この記事は、ソフトウェアテスト Advent Calendar 2022 の17日目の記事です。
身近なものに例えることで、概念を理解するのが最近のトレンドのなそです。
テストや育成の話をしているときに、ドラクエ3や料理、健康について例えて周りを混乱させてないかは気にしています。が、良い例えがこれ以外に見つからないんだもん。
その話は今回しません。(じゃ、なんでここでするのさって?年一回しかブログ書いてないから1年分の言いたいことがここに詰め込まれるんだもん)
普段はテストラジオでよしたけさんと色んな話してます。
本題
では、本題をしていきましょう。
ソフトウェアテストに関わりだしたときはメトリクスに対して疑念しかありませんでした。収集も考察もなにもかもに反対の立場でした。なぜって、最後にあわてて集めた各種メトリクスを信頼してなかった。そのメトリクスはシステムの批判にしか使われなかったというのが主な理由なきがします。
それから数年が経ち、考え方が変わってきているのでまとめてみました。
メトリクスをとるときに注意する5つのこと
①一回ではなく、一定周期で取得すること
②メトリクスの増減の理由が説明できること
③自分たちのルーチンに組み込めること
④欲張らないこと
⑤無理だと思ったらやめること
①一回ではなく、一定周期で取得すること
メトリクスの収集の理由を明確にしましょう。今考えてみるとゲートを通過するためだけのメトリクス収集でした。メトリクスの収集する理由は現状の把握からチームがうまく運営されていることを確認するためです。
ゲートを通過するのは結果であって、日々の活動から自分たちの状況の把握にメトリクスを活用しましょう。
②メトリクスの増減の理由が説明できること
例えば、昨日よりも食べ過ぎたときに体重が増えるのは理由が説明できます。他にも夜中にラーメン食べちゃったとか理由はありますよね。体重を一つのメトリクスとしたときに体重が増えたことは結果であって、食べ過ぎた理由や夜中にラーメンを食べた心理状況が重要なんですよね。心理状態がテヘペロであれば良いです。むしゃくしゃして食べましただとなにか対応をしないと大変なんですよね。あとリカバリを考えないといけないですよね。
③自分たちのルーチンに組み込めること
メトリクスの収集するタイミングが明確でないと収集することが止まってしまいます。あと楽に収集するのが大事なんですよね。Excelにダウンロードしてそれをピボットテーブルで加工して……ははは。
もう一つはそのメトリクスをちゃんと活用していないと収集することをやめちゃいますよね。
④欲張らないこと
メトリクスを収集すると全てを収集したくなるタイミングがあります。無理なく集めてください。最初から全部を集めようとするとメトリクスの分析自体をやらなくなっちゃうんですよね……
それはシステムの健康診断ができずに自分たちの状態もわからない結果になります。
⑤無理だと思ったらやめること
④に絡むことですが、無理だと思ったらメトリクスは減らして見てください。メトリクスはいろんな側面を持ちます。進捗、生産性、品質を見るのかをできますが、最初からすべてを収集するのはNGです。
まとめ
メトリクス分析は正直最初は何を見たいのかわからない事が多いですが、普段から意識してルーチンワークにしておくことで自分たちのシステムやプロダクトの状況を理解する情報になります。無理せずに1つ1つ収集してみてください。
最後に最近の話を12月から姪っ子と勉強みたり、遊ぶことが多くなりました。
普段コーチやコンサルティングといった仕事をしているが、小学2年生に論理が通じるわけありません。あなたの弱点は九九だと言っても「ふーん」とゲームをしたりと毎日、コーチングの敗北を経験してます。良い日々を過ごしています。
それでは、皆さん良きメトリクス収集を!
なそでした!
テストで問題になるけど、その前から兆候があるよ!3選
なそです。
この記事はソフトウェアテストの小ネタAdvent Calendar 2021 15日目の記事でございます。
テストフェーズで問題になるけど、発覚したのがテストフェーズであってその前から原因があるよねってことを前職の経験のみで語ります。
前職は基幹システムの開発をやってたSIerでしたが、トラブルが無いプロジェクトはなかったです。転職しようと思ったプロジェクトを思い出しながら、現象を3つ並べてみます。
①大丈夫です!何とかします!
②進捗60パーセントから数日経過している
③仕様検討会議が予定時間を超過して続く
①大丈夫です!何とかします!
具体的な施策があれば何とかなるかもしれませんが、これ単品だとアイディアゼロなのでなんともなりません。また、状況を定量的に見れていなく、現場や担当者が言っているからという又聞きパターンもあります。
例)Aシステムの開発が若干押していますが、大丈夫です!何とかします! では、次の議題は~
②進捗60パーセントから数日経過している
WBSのタスクは終わって次に進めていきますが、時に進捗率という謎の割合を求められることがあります。進捗率が進まなかったり、戻ったりと定量に見えるが定性データなので『一歩進んで二歩下がる』があります。
ほかにも日報や業務報告書で「昨日と同じく」という言葉や単語を見たり聞いたりしたら、タスクが分解できていない可能性があります。
③仕様検討会議が予定時間を超過して続く
一時間予定の会議が延々と夜中までは前職でもよくありました。進め方が悪いもあるとは思いますが、なにか良くないことが発生している可能性があります。
特に毎日毎日と続くと元から持っているタスクも押しますし、予定が予定じゃなくなっていきますのでうまくいかないことになります。
他にもあるかもしれません。個人の定性的なお話でした!
テストを見直すのも当然ですが、その前も確認してみましょう♪
やばい!あと1時間で大事な人が来る! から学ぶ テストの進め方
本記事は、ソフトウェアテスト Advent Calendar 2021 11日目の記事です。
こんにちは、なそです。アドベントカレンダー11日目なんですね。早い!!
テストをしていく中で「XXまでにテストを終わらせて」と言われることもありますが、こっちは「見積もった結果YYだから無理」と返すことがあります。売り言葉に買い言葉、ちょっとギスギスした感じになることも……
当然、経験や実績等での見積もりですから全てをやろうと思うと無理だと思います。
でも、もう少し歩み寄ることはできないのかなと思うときもありました。相手も困っているからテストが詳しい人に相談しているはずです。
仕事場では上のやり取りになりますので、私生活を例に考えると腹落ちしやすいかもです。相手からの強制イベントではなく内発的なイベントに変えてもう少し自分事にしてみましょう!(この記事は、ギリギリにテストを依頼してくることを許容するわけでも、手抜きを推進しているわけではないです。新たな視点が増えるといいなぁ)
テーマ:やばい!あと1時間で大事な人が来る!
自分の部屋を見渡して見てください。
どうでしょうか?
私の部屋は、ソファーにはちょっとだけ置くつもりでおいた服 や 外から帰ってきて脱ぎっぱなしの上着。
台所には出しっぱなしの調味料や後で洗おうと思った食器……
と、部屋の中は、大事な人を迎え入れられる状態にはなっていません。
人によっては諦める、時間をズラすという選択肢もありますが、今回は1時間後に大事な人を迎え入れれるようにしてみましょう。
1時間でできること VS 最低限のお部屋クオリティ
このバランスが重要になります。
1時間で自分の許せるお部屋クオリティに近づけられるかを考えていきます。手段は問わずです。全部をやろうとすると3時間かかるかもしれませんし、15分で終わるかもしれません。ただし、目の前の掃除から始めると絶対に終わらないです。
『クレヨンしんちゃん』の作中で、野原しんのすけは散らかった部屋を片付けるときにすべてを外に退避させることで部屋だけはきれいにしたという荒業で乗り切っていたりしました。そう!方法はあるのです。(その瞬間は大丈夫だけどその後は……)
この引き出しの数が勝負の鍵になります。
机やテーブルに散らかっている小物はすべて所定の場所に戻さないという手も取れますし、押入れに退避してもらうこともできます。干しっぱなしの洗濯物もきれいに畳まなくても良いかもしれません。
- すべてを100点の状態にはできない
- 掃除中に新たな課題(掃除ポイント)が生まれるかも
- どのくらいのお部屋クオリティになるかは想像ができる
この2点をもとに時間を分けて対応することで1時間後の未来を変えることができます。
人生はマルチエンドを採用しているのです。
- 全体を見回してみる
- どこに時間がかかるかの段取りをする
- 手を動かして実際に掃除を開始する
- 次の段取りを考える
- 繰り返し
タイムボックスを活用して、15分単位にすると4つのことができます。
洗い物15分になると結構な洗い物をすることができます。
1時間後に大事な人を迎え入れそうな気がしてきませんか?
この考え方を先程のやり取りに当てはめてみるとどうでしょうか?
- 全体を見回してみる
- どこに時間がかかるかの段取りをする
掃除では自分の中で完結しますが、「このくらいならできるけど」と会話はできるようになりますよね。その上で自分が本来やろうとしていた作業(取り掛かっている作業は無くならない事が多い)と比べてどちらにするかを選択することを提案できます。
それが決まればテストを開始できますし、自分の作業との優先順位をつけることができます。
Aさん「XXまでにテストを終わらせて」
な そ「見積もった結果YYだから無理」
↓
Aさん「XXまでにテストを終わらせて」
な そ「ZZとAAだから、こことBBを手伝ってくれれば、CCくらいの品質になるんじゃない?こっちの作業はとまるけど……」
Aさん「ギリギリだけど、こっちも頑張るからおねがい」
な そ「一緒にがんばろう」
とやり取りを変えることができそうです。
掃除の方法がテスト手法だったりするので、いっぱいやり方を知っていると案を提示しやすいですね。(日々勉強)
参考:The 10 Minute Test Plan
この話と似ているかなとおもったのがGoogleの10分テスト計画です。英語なので翻訳ツールを使いながら読んでみました。
おわり
余談
やばい!あと1時間で大事な人が来る!
これがもっと早くに分かっていれば、こんなに慌てることがないので事前にカレンダーを見て確認しておくことで対応できたりしますよね(突然始まるイベントもあるので事前準備ができない場合もあります)
アジャイル開発で、小さく作って小さく回すためのテストの下準備
この記事は ソフトウェアテスト Advent Calendar 2020 - Qiita 12日目の記事です。
アジャイルリーダーシップを品質面からサポートしようと日夜活動をしている なそです。アジャイル開発の短いサイクルの中で、品質をどう良くしていくのかを考えています。
では、どうしていくのが良いでしょうか?サイクルを短くしていくための下準備は大きく分けて以下の3点が必要になります。
- 自信のない部分の洗い出し
- 網羅的なテストの洗い出し
- テストのロードマップの作成
それぞれ見ていきましょう。
自信のない部分の洗い出し
短いサイクルで対応しようとすると、どうしても不安な部分がありますよね。テストが終わるのか?は興味深いテーマの一つです。何をすれば、自信がつくのでしょうか?漠然とした不安を具体的な不安に落とし込みましょう。そのためには3つの品質を考えてみましょう。
ここでの品質は、チームもそうですが、プロダクトを出すステークホルダーや使うユーザーも含まれます。
- 機能品質
- スプリント品質
- プロダクト品質
機能品質は、作るプログラムの品質です。機能要件や非機能要件も含めて考えるべきです。スプリント品質ですが、チームを含めてうまく回っているかです。
例えば、品質を見すぎて、働きすぎていませんか?無理は確実にチームやプロダクトに影響します。最後に、プロダクト品質です。提供する価値が想定通りに実装できているかどうかです。
そして、品質を考える際には定性と定量を意識しましょう。
その数字を使ってどう分析するのかが大事なので自分たちは何を得たいのかを基軸としてデータを集めつつ、自分たちがどう品質を分析するのかの両面で考えましょう。
分析は議論の土台です。そのデータを使って論じるのはプロダクトであって人ではありません。リーダーだけがこの数字を意識するのではなく、基準として意識していきたいですね。
網羅的なテストの洗い出し
システムに対してのテストの網羅をどのようにするかです。システムから見る方法もありますが、今回のポイントは別視点で考えたいと思います。以下の3つです。
スプリントは、サイクルの中でのテスト活動。リグレッションは、スプリント内での改修が他に影響していないかのテスト活動。リファクタリングは、リグレッションと似ているのですが、あえて分けています。その理由は、改善における改修が他に影響していないかに加えて、改善できているかを確認する必要があるからです。
いま自分たちが行っているテストをいかに見える形で網羅的にしていくのが重要です。今のテストで十分性を訴えるのではなく良くしていくかの議論をするべきです。
テストのロードマップの作成
それぞれに対して、どういう手段を用いるかも重要です。私達の使える時間は限りなく少なくていつも不足しているのです。
そうすると足りないものが見えてきて、ロードマップの原型が生まれます。それをどのように立てていくかが重要ではありますが、今よりもアップデートができます。個々の技法で攻めるのではなく、プロダクトをどうするかに合わせて様々な技法や考え方を適用するかを議論しましょう。
最後に
簡単に記載しているので、深堀りを行う必要がありますが、最初から全部を狙うと難しいと思います。もう少しで新年です。新たな目標を立てて、どうやって下準備をして行くのかを考えてみると良いのではないでしょうか?
簡単ではありますが、なそがお送りしました。
テストの諸々のドキュメントをテキストベースで作ってみるにはどうすれば良いかを考えてみた。
空気も冷たく、朝布団から出て行くのが億劫な季節となりましたが、みなさまいかがお過ごしでしょうか?
私、なそはアドベントカレンダー 19日目の記事を元気に書いております。
@akiyama924さんの次の日と知り、緊張で押しつぶされそうです。
と言っていても、始まらないので元気に始めましょう♪
今日の趣旨はタイトルの通りです。
アジェンダ
- テキストベースとは?
- なぜ、そんな恐ろしいことを思ったのか?
- 何を対象にドキュメントを作成するか?
1. テキストベースとは?
*.csv や *.txtといったメモ帳やサクラエディタ、秀丸とかで編集するファイル形式です。
2. なぜ、そんな恐ろしいことを思ったのか?
テストに関わるドキュメントは長い間、最強のツールExcelによって運用されています。いまでも最強のツールとして君臨しています。使いやすいですよね。
とはいえ、最強のツールは最近Googleのスプレットシートに置き換えられることもあります。結局、表計算ソフトを使っているんですよね。
そんな最強のツールではなく、テキストベースで作ってみることを検討しているのは、ドキュメントのバージョン管理をしたい。
例えば、開発ではPlantUMLを用いてテキストベースでUMLを記載することが増えてきています(なそ調査、サンプル数1)。しかし、テストのドキュメントをテキストベースでバージョン管理を目論んでいるのはそんなにいないのではないでしょうか?
大きく分けて理由は3点あります。
- なぜ、修正したのかを明確に記載したい
- 1つのドキュメントをメンテナンスし続けたい
- Gitにコミットしたい
1. なぜ、修正したのかを明確に記載したい
バージョン管理を行うとコミットログを残すことができます。Excel等々では取り消し線を引いて赤字でホゲホゲみたいなローカルルールに従う必要がないです。また、修正理由や変更点にJIRAとかのチケットのURLを書いても大丈夫です。運用設計は必要になりますが、ドキュメントは常に最新に保つことができます。
2. 1つのドキュメントをメンテナンスし続けたい
アジャイルテストを行う場合に、実際にあったのが「テスト計画_SprintXX」といったファイルがそれぞれ作られ続けていました。これってSprintXXとSprintXX+1の差分をみるとかはあると思いますが、ファイルが増え続けます。そうではなくて「テスト計画」として1つのドキュメントで常に最新にしてクリーンな状態にしておくとどのファイルを見れば良いかが明確になります。
では、SprintXXの時のテストのドキュメントを確認したくなったらどうするのかというとSprintの終わりにTagを切ってSprintXXとしておけば良いのではと思っています。
3. Gitにコミットしたい
Excel Onlineやスプレットシートはオンラインでも使えます。それならGithubとかで管理するのも別に良いのでは?というかテストコードを書き始めるとバージョン管理が必須になります。それなら先にやって慣れておいてもいいんじゃないですか?
あとコミットするとなんか終わった感するんですよね。私だけですかね?
コミットすることでバージョン管理ツールのレビュー機能が使えたりと開発と同じ土俵で考えることを進めることができます。
という感じで、ドキュメントをバージョン管理するメリットとして差分を確認できます。それを行うためにはテキストベースである必要があります。手段が先か目的が先かという話はあります。しかし、「やってみたい」は大事な気持ちです。
3. 何を対象にドキュメントを作成するか?
今回は、テスト計画 → テスト設計 → テストレポートをテキストベースのドキュメントを考えてみましょう。
ドキュメント名 | テキストベース |
---|---|
テスト計画 | マークダウン形式 |
テスト設計 | CSV形式 |
テストレポート | マークダウン形式 |
テスト計画
テキストベースなので、書き方もシンプル。罫線とかはもちろん気にする必要がありません♪
# title
## Test Base
カラオケシステム http://karaoke/system
## Risk
この辺不安
## Test 端末
iOSを中心にテストする
・・・
と言った具合に別にExcelじゃなくても書けるんですよね。
大きな表はかけないですが、表も書くことができます。
テスト設計
テスト設計で書かなくちゃいけないことってなんでしょうか?
私はシンプルに
- テストでみるべきポイント
- 操作手順
- 期待値
- 実行結果
- 実行時に気が付いたことを書く備考
このくらいでも良いのではないかなと思っています。当然、会社の方針によっては大分類、中分類、小分類と記載することもあります。
テストでみるべきポイント,操作手順,期待値,実行結果,実行時に気が付いたこと
カラオケの電源,左下の電源ボタンを押下する,電源がONになること,OK,
テストレポート
テスト結果をレポーティングすることになります。これも壮大なドキュメントを作成する必要はないと思っています。
# テストレポート
## スケジュール
2019/12/19 - 2019/12/20
## 今回の品質について
ばっちり👌
## 発見された障害
| やばいやつ | 10 |
| そこそこやばいやつ | 2 |
## 所感
やばいやつが多く、リリースするために十分なテストが実施できていない
このように、記載する内容をシンプルにして何を伝えるかを明確にすることでテキストベースでテストのドキュメントを作っても運用できそうなイメージがつきました。
今使っているテストのドキュメントをテキストベースにしてみるためにどうすれば良いかをこの年末考えてみると良いのではないでしょうか?断捨離することで本当に必要なテストのドキュメントが作れると無理せずに生産性が高まり、働き方改革に繋がるかもしれません。
重厚なドキュメントも重要ですが、今一度身軽なテストを考えみるといかがでしょうか?
さいごに
おすすめのマークダウン形式でかけるテキストエディタ
Typora はてなブログと同じように見たまま編集ができる。
それでは、本日はなそがお送りしました。
ちょっと楽になる便利ツールのご紹介 windows編
なそです!
こんばんわ、なそです。
この記事はソフトウェアテストの小ネタの11日目の記事です。
追記:CliborのサイトのURLが変更されたので、修正しました。
サイトには応用編などの使い方が記載されています!
参考になるので、ぜひとも見てみてください♪
今回の商品はこちら!
クリップボードの履歴管理ができる常駐型のアプリケーションになります。
何が便利かっていうと、
Ctrl+Cして
Ctrl+Vを押そうとして
あ、間違えた・・・
Ctrl+Cをまた押してしまった・・・
って時でも大丈夫。
Ctrl,Ctrlと2回押せば、Cliborが立ち上がり履歴が表示されます。
そこからペーストしたい履歴を選ぶとあら不思議、クリップボードに保存されてすぐにペーストできるようになります。
また定型文を登録することもできますので、忘れやすいサーバー名やファイルパス等をあらかじめ登録しておくとより便利に使えます。
Cliborにはインストーラーは存在しないので、展開して起動した場所がCliborの起動場所になります。 そのため、ダウンロードフォルダではなくドキュメント等に展開することをオススメします。間違えて消しちゃったということが無いように......
問題点は、OSの再起動した時に合わせて手動で起動しないといけないところですが、windosではスタートアップにショートカットを入れておくだけでOSの再起動時に立ち上げてくれます。
windows10の場合
C:\Users\ユーザー名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
windows7の場合
C:¥Users¥ユーザー名¥AppData¥Roaming¥Microsoft¥Windows¥Start Menu¥Programs¥Startup
どちらのOSでも、「Windows」キーを押しながら「R」キーを押すと「ファイル名を指定して実行」ウィンドウが表示されます。そこで「shell:startup」を入力すると起動するようです。(調べるまで私は毎度フォルダを延々と辿っていました)
もちろん、スタートアップにアプリケーションを入れれば入れるほど起動した時の立ち上がりが遅くなるので、入れるものは慎重に入れてください!
それでは、簡単ですがなそがお送りしました。
システムを把握する3つのコツ
こんばんわ、なそです。
この記事はソフトウェアテスト Advent Calendar 2018 - Qiitaの9日目の記事です。
指摘を受けて、その通りでしたので、修正しました。
- システムを把握する
↓
- システムの目的を把握する
みなさんは、仕様書や設計書を元にテストを実施したのに、リリース後に障害発生させて、一生懸命にテストしたのに...... という経験ありませんか?
100%防ぐことができなくても、少しでも減らしたいと思います。どうしても「仕様書」や「設計書」に記載しきれないことが多くて、『それ聞いてないよorz』ってちゃんと書いてよって思うことはしばしば。それ以外に回避するためには、テストするシステムの理解を進めるという方法が1つあります。システム全体をイメージできると機能間の矛盾や行方不明になるデータ、隠された機能を見つけやすくなります。
今回はシステム把握する時に気にしていることを3つのコツを説明します。
- システムの目的を把握する
- 業務を理解する
- データの流れを意識する
システムの目的を把握する
自分がテストするシステム全体で何をしたいのかの目的を把握し、その目的をどう実現しているのかを把握していきます。業務によって必要なシステムの構成がある程度決まります。ECサイト等は普段使用することが多いと思います。いくつかのサイトを利用しているのであれば、その経験を参考にできます。
自分が知っている知識との差分を考えることで、どこで何をしているかを把握できてシステムの把握が進んでいきます。
機能から徐々にボトムアップしていく方法と、システム全体から徐々にトップダウンで降りていく方法がありますが、初めて触るシステムの場合、ボトムアップの方が考えやすいかもしれません。複数のシステムを見たことがある人ならシステム全体の構成を意識することができるため、トップダウンで考えていく方が考えやすいです。最終的には両方を意識することになります。
誰が使うのかという視点も意識してください。ECサイトでは購入者となることが多く、そこに対する意識はできると思いますが、出店者側の視点が抜けやすくなります。いろんな人が関わるシステムですので、1つの面だけではなく複数の面を意識することが必要になります。
業務を理解する
システムを把握してくると機能と機能の繋がりが見えてきます。そうすると見落としやすいポイントが「いつ」システムを使用するのかということです。
ルーチン:「日」「週」「月」「年」etc.....
アクション:「購入ボタンクリックした時」「間違えた登録した時」etc......
テスト設計していると仕様書や設計書に目がいってしまい、1週間に1回しかやらない処理、間違えた時などの処理が記載されていなくて、リリース後に運用できないとかのトラブルが発生します。書いてない仕様を探すために、システムの矛盾や想像していない業務の流れを探していく必要がトラブルを減らすコツですね。
基幹システムの業務知識は、イメージしにくいと思います。下記の本である程度の知識を得ることができます。(基幹システムは普段触れることは少ないので本から得られる知識でも結構重要になります)
データの流れを意識する
システムで使用するデータはシステムの中で流れる血のようなものです。流れ続ける場合もあれば、どこかで止まる場合もあります。
止まるデータは、何かしらの分析に使用されることが多いです。分析には流れているデータも使用します。
システムや業務を知っていてもデータの流れは出てこないです。特に履歴や内部で監査のために保持している等のデータは上記2つのコツからは見つけられないです。その辺を意識しないといざ使おうとした時に使えないなどのトラブル時の対応でトラブルに発生することもあります。異常系のテストであることが多く、重要度が低くくされることが多いです。
不自然に止まるデータは、仕様の矛盾が発生していたり、同じような項目が多い場合は障害の温床になったりします。(A列を更新するはずなのに似たようなB列を更新してしまったためにステータスが更新されずにいつまでも修正できるとか)
システム化するときに、以前は手動でやっていたやり方をそのまま取り入れられる場合があります。不思議なところにデータがあったりして、話を聞いてみると以前の業務を聞くことができ、使う人たちをさらに意識できる場合もあります。(昔話に花が咲いて藪蛇の場合もありますがw)
まだまだコツはありますが、今日は3つ紹介させてもらいました。システムを広く知っておくと、レビューの時の矛盾点の指摘だったりと活躍の場面は多いです。少しずつ理解して知識を増やしていきましょう!
それでは、なそがお送りしました。