「テスト計画がない」プロジェクトで、テストの全体を考えてみた
テストの全体の進め方を考えてみる。
この記事はソフトウェアテストの17日目の記事です。
「テストをお願いしたい」と言われてプロジェクトに参加したものの、 テスト計画もなく、何から考えればよいのか分からない。 そんな状況に出会ったことはないでしょうか。私は出会ってしまいました。
この記事では、テストについてほとんど何も決まっていないプロジェクトに参加したとき、 私がどのようにテストの全体像を整理し、関係者と合意していったのかを紹介します。
こんなことありました
システムのテストをしてほしいと依頼を受け、プロジェクトに参加しました。 すると、テストについてほとんど何も考えられていない状況でした。
テストを実施する上でインプットとなるテスト計画書もなく、何から考えるべきか悩んでしまった。幸いなことにテストの全体から整理する時間もあり、テストの全体を整理してプロジェクトのメンバーとステークホルダーに説明することになりました。プロジェクトのメンバーも忙しい状況でしたが、テストが何も決まっていないことに危機感を持っており、質問にも優先的に回答してくれたりなど協力的でした。
こんな状況でテストの全体を考える方法について、一緒に考えていきましょう。 ということで、私ならどう進めるかをつらつらと書いていきます。
テストの全体を考えるのは難しい
テストの全体を考えることは難しいです。複数の要素が絡み合って進むプロジェクトなので、様々な要因で品質は変わってしまいます。色々な役割に説明して、認識してもらうのも難しいことです。
一般的にプロジェクトでの品質を求めることは、QCDに代表される通り、トレードオフが発生します。品質を求めれば求めるほど、コスト(C)を高め、納期(D)を遅らせます。そのため、プロジェクトで必要になる品質はシステムの特性に合わせて考えないと過剰になります。バランスを求めながら、プロジェクトの中心メンバーとすり合わせ、ステークホルダーを巻き込む必要も出てきます。
また、テストの全体を考えていくときに、テストの詳細な実行手順等が気になってしまい、一部は十分に検討できたものの他の検討が進まない場合もあります。広い視点と深く考えるこの2つのバランスが大事になります。漏れなくダブりなく、一度でテストの全体を説明できれば理想ですが、プロジェクトは類似プロジェクトはあれど同じプロジェクトはありませんので積み上げて行く必要があります。プロジェクトは複数の要因で予想外の事が起こります。全てに対応することを考えてしまって行動が起こせなくなるのであれば、見直しを行う期間を決めて、進めるほうが状況把握もすることができます。テストの全体の精度を上げるための未来の活動も盛り込んでおく必要があります。
ここまで書いていて思いましたが、絶望しなくて大丈夫です。 やることは非常にシンプルです。
実際にテストの全体をどのように考えるのか？
テストの全体を考えるのに当たって何をベースにするのかというと点在しているテストの予定をまとめることでテストの全体を考えていきます。本当は品質特性（ISO/IEC 25010-1）などをベースにマッピングしていく必要がありますが、本来なら時間をかけてじっくりと検討する必要があります。このプロジェクトは進行しており、走りながらテストの全体を明らかにします。この段階で理想論を語っても、後出しになってしまいます。まずは整理整頓が必要になります。
- プロジェクトのメンバーに、現在のテストの考えや発生したらプロジェクトに影響しそうなことをヒアリングする
- 1で収集した内容をテストタイプごとに分類して、必要なテストを洗い出して全体を明らかにする
- 抜け漏れをチェックして、全体のバランスを調整する
- プロジェクトのメンバーに説明して、内容を調整する
- ステークホルダーに報告する
1. プロジェクトのメンバーに、現在のテストの考えや発生したらプロジェクトに影響しそうなことをヒアリングする
テストの全体を整理するときに考えるのは、現状と不安事項の把握が大事です。
現状の把握はプロジェクトのメンバーから何をテストするのが決められるのかの認識をヒアリングすることから始まります。 このときは一人にヒアリングするだけではなく、複数の同様の役割の人にヒアリングするようにしましょう。
その時に不安なことの把握も進めてください。不安なことは仕様、オペレーション、コード等の複雑度の高い箇所を特定できるため、プロジェクト固有の情報を把握することができます。
2. 1で収集した内容をテストタイプごとに分類して、必要なテストを洗い出して全体を明らかにする
「テストタイプごとに分類」と言っていますが、実際には「まず分類し、その後で名前を付ける」という順序になります。 よくある例は、 機能テストや非機能テスト、性能テストとかがあります。
これは全プロジェクト共通のテストタイプの一覧は存在していません。（私が検索したりChatGPTに聞いた限りではISOやISTQBでは存在を確認できませんでした）私の経験ではチームや企業で管理しており、社内標準に組み込まれています。プロジェクトごとにカスタマイズが必要で、見直しが必要になるので、考え方を整理するためのツールくらいと考えて、自分たちのプロジェクトのテストタイプの一覧を作っていきましょう。
テストで確認する項目や何をインプットにテストを考えるのかを一緒に考えることでテストタイプの一覧に厚みをもたせることができます。
3. 抜け漏れをチェックして、全体のバランスを調整する
さて、十分に検討しました。では、テストの全体が十分に検討できたかを確かめる方法があるのでしょうか？ テストの全体を確かめる方法があります。それはシステム構成図と業務フローを用いてテストタイプの一覧と星取表を作ることです。
システム構成図とテストタイプの星取表は、製品品質のチェックができます。 業務フローとテストタイプの星取表は、利用時品質のチェックができます。
星取表を作るときにテストタイプが製品品質と利用時品質の両方で必要になる場合は、分割することをおすすめしています。例えば、テストタイプ『シナリオテスト』が両方で必要な場合は、「シナリオテスト(製品品質)」と「シナリオテスト(利用時品質)」と分割してください。名称を分割する場合は、テストで何を確認したいのかも変わりますので、それぞれのテストタイプを検討する段階で違いを明記してください。
また、すべてのテストを行う事ができません。できないので優先順位を検討することで全体のバランスを調整します。QCDのバランスが取れていない計画は、実現性がなくて誰にも賛同を得ることができません。
4. プロジェクトのメンバーに説明して、内容を調整する
一番良い方法は、プロジェクトのメンバーといっしょに作業していると、説明するときに共通認識があるため、スムーズに行くことが多いです。しかし、プロジェクトのメンバーも自身の作業があるため、最初から最後まで一緒に作業するのは現実的ではありません。部分的に手伝ってもらったり、現状の整理をしていくことで共通認識が全くない状態は回避できます。
テストの全体はプロジェクトのメンバーの困りごとに対して、テストタイプを説明していきます。 ここで重要なのは、プロジェクトのメンバーに影響する部分や新規で追加されたことを説明することです。
細かな計画を説明するのではなく、概要やスケジュールを中心に説明するのが大事です。 プロジェクトのメンバーは一緒に働く仲間です。敵対関係にならないようにしましょう。私のときは好意的だったので大丈夫ですが、このタイミングでトラブルになった話はよく聞きます。
5. ステークホルダーに報告する
ステークホルダーに説明するときは、全何回で説明するのかを明確に伝えてください。 1回目は全体、2回目は注目するテストと時期、3回目は質問事項への回答。それぞれで何をテーマにするのかを伝えるようにしましょう。また、詳しく聞きたいと言われることがありますので、別途時間を作るほうが建設的だったりします。
ステークホルダーの中には、全部に参加できない場合があります。業務の都合をつけれるのかをあらかじめ予定を確認することをおすすめします。早くても直前にキャンセルされることもあります。
テストの全体の共有が終わったあと
全体像を文章化して全体テスト計画とするか、テストタイプごとに個別のテスト計画を立てることが、次のステップです。
最後に
テストの全体を考えるとは、網羅的な計画を一度で作ることではなく、 現状・不安・制約を整理しながら、関係者と合意できる形に育てていくプロセスを作る必要があります。
関係者に説明するまでがお仕事のワンセットになります。説明と関係者の納得が必要になりますので、事前の準備や相手の関心事をリサーチして対応することが必須になります。
全体を定義していくことは難しいので、最初にも書きましたが見直しをするタイミングを設けておくことをおすすめします。
普段はYouTubeでソフトウェアテストの話題をまったりゆったりと喋っています。 良ければチャンネル登録をお願いします。
メトリクスを取るときに注意する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)。しかし、テストのドキュメントをテキストベースでバージョン管理を目論んでいるのはそんなにいないのではないでしょうか？
大きく分けて理由は３点あります。
- なぜ、修正したのかを明確に記載したい
- 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」を入力すると起動するようです。(調べるまで私は毎度フォルダを延々と辿っていました)
もちろん、スタートアップにアプリケーションを入れれば入れるほど起動した時の立ち上がりが遅くなるので、入れるものは慎重に入れてください！
それでは、簡単ですがなそがお送りしました。
