ソフトウェアテストに関するアドベントカレンダー2019を読んでみて
ソフトウェアテスト版アドベントカレンダー
ソフトウェアテストに関するアドベントカレンダーのHOTな話題に増えていきます。
知識も人もみんなだいじ~隣人愛~
メンティーから見た尊敬できる先輩像が記載されている。
答えではなく過程を特に教える
これの最終ゴールはメンティーに教えたことが再現可能になるということを意識して伝えています。
各テスターのスキルに差があると見落としがあって、利用者にとってより良いものを提供するためには、個々人が自立的に考え方(フレームワーク)を適用する必要があります。
再現可能になるために悩みどころはいくつか課題があって、
1.興味を持ってもらう 方法論的な所は特に知らないとどうしようもないし、知ってもできないことって半年とか経って実感がともなったり興味付けにつながったり時間のかかるものですよね
2.体系化する。参照可能にする 個別の内容については2・3個のルールの組み合わせや原則・例外の説明で済むのですが、 伝える情報がその文脈に限定されたものなので、教えられる側からすると背反するように見えるルールや、情報が多くなってきて情報が紐づかなかったり整理できなかったりする
整理して伝える必要があって、適宜非公式なメモ書きとして整理したり楽に判断できるようには進めている。
- やっているところを見せる いわゆる社会的規範とか呼ばれているやつですが、やらなかったことや、やっていることが見えないと、ルールとしてやらなくても良いかもという誤解を与えたり定着しないので、お手本になる行動は心がける必要があります。
クラシフィケーションツリー法の自由さを活用する
海外ではメジャーな一方で、日本ではあまり認知されていない手法。たぶん日本で一番わかりやすいサイト。
テストケースを分析する方法で、特定の因子の組み合わせを厚くしたり、よく使われている機能に対してケースを手厚くしたり恣意的な(戦略的な)テスト設計のできる方法です。
例えば、一つ一つのテストシナリオに時間がかかり、テストパターンを増やせない場合などは重要な因子間の網羅にしぼることでビジネス上のリスクを減らす戦略にしたり、One管理などで3因子・4因子間のバグがもし多い機能があれば、AllPair・直行表ではカバーしきれないため、こちらの手法を限定的に使うなど。
変更に強いテストケースの書き方
デザインパターンの考え方を応用してテストケースの管理をカッチリやろうというお話。
書かれていることは限定的なのですが、テスト戦略や自動化に向けて一貫性のあるテスト、また継続的に管理するという話は勉強会などでは得られずどうしようかなと頭を悩ませているところ。 Jasst2019とか聞こうかなと。