欠陥は作りこむ前につぶすことにした
アジャイルな現場やサービスだと、開発速度が早すぎて、とにもかくにもリリースが優先させることがある。
僕は個人的に仕様書を書いたり、テストをしたりな時間を十分に確保しないで新機能をバンバンつけていく状態は正直よくないとは思っている。
開発速度が大事なのもわかるけど、それにしても品質を軽視しすぎてる。
壊れてるのわかってる車をそのまま出荷したら、困るのはユーザだし、リリースした会社も評判を落とすでしょうに。
って僕は思うんだけど、どう言っても会社や職場、プロダクトの方針がそれなら仕方がない。
のでQAの僕がとった行動はとにかく欠陥（故障）は作りこむ前につぶすこと。
JSTQBだと静的レビューに分類されるんだろう。
とにかくレビューとか仕様策定とかの段階で課題をみつけては指摘する。
ただし、ブレストとかは文句言わない。
仕様書などのドキュメントがほぼなくても
「こういうのを作りたい」「作ろう」って、打ち合わせなりチャットなりが必ずある。
組織なんだからある。（いや、他社は知らない。。）
そこに加わって、その機能やサービスを作るにあたっての懸念点をその場で指摘することに注力してる（した。）
あと、口頭で仕様変更されることがあるので、そこはいろいろと注意してる（した。）
雑談しに行ったり、ご飯食べに行ったりして
「どうっすか」
な話をするとか。
偉い人を捕まえるとか。
ソフトウェアのいわゆるバグ（不具合）は、早めの工程でつぶした方が後戻りが少ない。
とにかく早めに見つけて指摘することで、そもそも不具合の発生頻度を下げることにした。
テストにかける時間も限られることが多いので、そもそも不具合を作りこむことを避けた。
けど、やりすぎると嫌われるのが厄介なところ。。。。
あれねー。
スライド数枚に50件指摘したのはやりすぎたかもしれないね。
いや、それでも絶対外せないと思われるところ以外の非機能要件は指摘を避けたんだけどさ、、、
品質はすごい大事なんだけど、そのために人間関係悪くしちゃうと、良いものも作れなくなる。
難しいところ。
ソフトウェアテストのSlackワークスペースができたよ
showです。
https://testingcommunityjp.slack.com/
この記事を書いている2018年3月11日時点で40人以上がすでに参加してくれています。
それなりに需要あったみたいです。
PostgreSQLやMySQLはSlackのワークスペースがあったけど
そういやソフトウェアテスト系は見当たらないなー
週末にでも作るか
って思ってたら
JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo
で、話題になってたタイミングでもあったみたいで
作ろうかーって話にちょうどなってた。
Twitterで「作ろうかー」「作ろうよー」ってなってたら
作ってくれた方がいらした（一応名前は伏せる）ので、僕もサクッと参加しました。
僕も管理人になってるけど、今のところ運用はフレキシブルにしていきたいと思っています。
ひとまず作ってあるチャンネル
・general → これはまぁ全員参加
・random → 雑談用
・welcome → はじめましての挨拶
・beginner → 初心者が声をあげやすい場
・automation → 自動テスト関連
・event → 勉強会とかセミナーとかの周知や告知用
・testingtools → テストに使うツールについて話す場所
あとはデザイン関連の
ux-design
ってチャンネルを作ろうかーみたいになってます。
ご興味ある人、とりあえずROM専（見てるだけ）でも構わないと僕は思っているので
とりあえずどうぞー
長期安定試験は鬼門だと思う話
showです。
今回は長期安定試験の話。
各社で呼び方はたぶん違うと思うけど、よーするに
長い時間システムが動き続けても大丈夫だよね？
を試験する。
個人的な経験だと
48時間とか72時間とかシステムに負荷をかけ続けて
メモリ、CPU、キャッシュHit率などを測定する。
メモリリークが起きないですよーとかを見るためにやることが多い気がする。
で、問題はこの試験の実施のタイミング。
システムが安定稼働するかを確認するので、当たり前だがシステムが構築されないと試験できない。
よって、かなり終盤のフェーズで試験することになる。
そんなときに72時間とかかけて試験したあげくに
「メモリリークの危険性がある」
とかになったら、さぁ大変
迫りくる納期、そしてデバッグしたとしても再度72時間とか試験しないといけない。
これは本当に鬼門だと思う。
なので、これをなるべく早めにつぶすためには、結合試験とかの段階で正常系の試験をパスしたら、その状態で24時間とか流してみて問題ないかを事前に確認しておく。
のがいいんだけど、実際はそんなことができる余裕がなかったりするので、やっぱり長期安定試験は怖いモノです。
探索的テストはベテランがやるものだと思ってた
今週、急性気管支炎で平日全部休む目にあいました showです。
各方面に本当にご迷惑をおかけしました。。。申し訳ない。。
さて、そんなときにTwitterで尊敬するブロッコリーさんと少しやりとりしてこんなことがありました。
探索的テストはベテランがやるのは誤解。
ってスライドのページを頂きました。
ちなみにWAKATEっていう「若手エンジニア向けワークショップ」ってのがあるらしい。
※行きたい
で、探索的テストはベテランがやるってのは誤解。
まじで？
JSTQB（ってかテス友）でも「探索的テストは経験とかがいるよ」みたいな話になってた記憶なんですが、どうもそうとも限らないらしい。
www.slideshare.net
このスライドをみてみると、たしかに誤解って書いてある。
で、22ページ目に
探索的テストは「テストを設計しながら実行する」「事前にテストケースは書かない」とある。
で、27ページ目になると
学習→設計→実行のサイクルを何度もまわすモノになってる。
あー・・・
言われてみればたしかにそうだなと。
探索的テストってなんとなく闇雲にやるイメージを正直もっていて
僕個人の勝手な経験だと、仕様がよくわからんシステムのサーバにXMLをwgetで送ってそのレスポンスを確認するテストをやったことがあって
その時は本当に手探りで闇雲な試験になったので、あれが探索的テストかなってイメージがあった。
けど、このスライドによると
無駄を省くためにやるもので、テスト設計しながら実行する
ってのが探索的テスト
つまり、闇雲とも限らなくて、学習→設計→実行を繰り返して精度をあげていく。
そうか。
そりゃそうか。
その通りである。
なので、事前に決められた（設計された）テストを実行するテスト方式ではないのが探索的テストというモノを指すのであれば
たしかに、ベテランがやるものというより、むしろそれこそ若手がやって学習していくのも十分アリである。
で、このスライドにでてきている本、読むことにします。
テストについて真面目に0から（1から？）学びなおすのもいいかもしれない。
何事も守破離である。
ブロッコリーさん
ありがとうございます。
JUnitでassertじゃなくてErrorCollectorを使うという選択肢
showです。
風邪気味です つらぽよ。
今回は掲題の通り、JUnitを使ってるならばErrorCollectorってのも使えるよ という話。
E2E試験（受け入れ試験）でWebページのテストをするときにSeleniumを使うことは結構あるとして
それをJavaでJUnitを使って実装しているとき、assertを使うことって結構あると思ってます。
けど、これ欠点があって
例えば、あるWebページにチェックする項目が3つあるとして
assertなんちゃらで上から3つチェックを書いた場合、
1つ目のassertで異常が見つかると、その場で動きが止まってしまう。
それはそれで正しいっちゃ正しいんだけど、これだと2つ目、3つ目の試験すべき箇所が正しいのか間違ってるのかを検証することができない。
ミッションクリティカルな試験だとこれはおそらく正しくて、止まるべきである場面もあるけど、そうでもない場合
1つ目で引っかかりましたー
デバッグしますー
直しましたー
再度試験を走らせましたー
2つ目で引っかかりましたー
デバッグしますー
直しましたー・・・・・・
って1つ1つやるのめっちゃ効率悪いと思ってます。
※そもそもバグを埋め込むのが悪いとかそういうのは別として。
そんな時にErrorCollector君が使えます。
この子をassertの代わりに使ってあげると、チェックしている箇所でfail扱いになってもJUnitは動き続けてくれます。
で、「これをチェックしたら期待値はこれだったけど、こうなってましたー」ってのがまとめて出力してくれる。
ってサンプルコードをここに記載しようと思ったら既に記事が存在した・・・ｗ
この記事では期待値が何で、結果こうなってますーってのが書いてあるんだけど
ここに書いてなくて、僕が個人的に使ってるやり方は
public class UseErrorCollector {
@Rule
public ErrorCollector errorcollector = new ErrorCollector();
//Seleniumの設定類を書く
@Test
public void errorCollector() {
//hogehoge画面のタイトルバーの文字列を確認する
if(!(driver.findElement(By.id("hogehoge:id/titlebar_text")).getText().equals("こんにちは"))){
errorcollector.addError(new Throwable("試験No.XX hogehoge画面のタイトル文字列が「こんにちは」ではありません"));
}
}
}
こんな感じです。
ErrorCollector にもやり方はいっぱいあるけれど、僕はこれでやることもあります。
なんでかっていうと、もともとassert文を使ってたけど、trueとfalseがごっちゃになる場合があって
かつ、うちのメンバーにプログラム書けないテスターさんもいるので、あんまりJUnitのassertシリーズを使い分けさせたくなかったから。
なのでif文で分けて、fail("hogehoge画面がーーー")って書いてた。
※サービスとかメンバーとかにもよる
正直、若干めんどいのも事実ではあるのですが、Seleniumを使ったコードを書いていると
自分でもたまに条件がよくわからんってなる時があったりするので、明示的にif文を書いてます。
なので最初にコメントで何を試験するのかを書いて、それに沿うようにif文を書いてる感じです。
テストコードがバグってるってのは、かなりよろしくないと思っていて、それを防止する意図も若干あります。
これをやると、「あぁこの試験やってんだな」ってのが他の人でもわかりやすい（気がする）。
はい。
こんなやり方もありますよってお話でした。
JSTQB Foundation受験記
showです。
2018年2月10日（土）にJSTQB Foundation試験を受けたので受験記を書いておく。
受験記
受 験 日 ： 2018/02/10
合 否 ： たぶん合格 ※発表まで2～３か月かかるらしい
受験科目 ： JSTQB Foundation
受験言語 ： 日本語
取 得 点 ： 非公開
合 格 点 ： 6割説と8割説がある
問 題 数 ： 40
出題形式 ： 単一選択
試験時間 ： 60分＋アンケート10分
勉強期間 ： 20時間くらい
受験目的 ： 自分のスキルアップ
勉強形態 ： 独学
実務経験 ： そこそこ
勉強前のレベル ： SIerのガチガチな品質の世界で生きてた
本試験のレベル ： 定められてる用語がわかったなくらい
何度目の挑戦か ： 1回目
セクション毎の正解率
非公開
使用教材
「ソフトウェアテスト教科書 JSTQB Foundation 第3版」
「テス友」
一押し >>> テス友
勉強方法
「ソフトウェアテスト教科書 JSTQB Foundation 第3版」を1週読んだら、
あとは通勤時間を中心に「テス友」をスマホでポチポチ
市販のなんちゃって対応テキスト・問題集や
対策問題のWebページもあるが一切やらなかった
試験の感想
問題用紙がでかい冊子でビビる。
「でっか！！」
ってなる。
時間がなくなることはおそらくない。
途中退席者も多い。
が、すべての問題をもう一度解きなおす見直し時間まではあるかないか微妙。
また、複数選択の問題が（今回は）（僕の認識では）なかったことと
・「適切な」ものを選べ
・「不適切な」ものを選べ
・「高い順」はどれか
などの問題文にアンダーラインが引いてあり、うっかりミスを救済する意図を感じた。
重箱の隅をつついてくると言われていたが、そんな印象はなかった。
そういう意味ではOracleのSQLやJavaのOCJ-Pの方がよほど意地汚い。
受験者へのアドバイス
基本的にはシラバス暗記ゲームなのだが、
テキスト一周したら、あとはひたすらテス友すればいい。
テス友そのまんまの問題はほぼない。
しかし、テス友で聞かれる問題を応用すれば十分対応できる。
テスト工程や品質知識に疎い場合は覚えることが多くなるかもしれない。
学生には厳しい可能性がある。
終わりに
受験票がこなくて半べそかいたんで、指定日に受験票がこなかったら即時運営に連絡すること。
以上
JSTQB受験がやべぇ話
showです。
JSTQBの試験が2月10日に迫っております。
土日にブログを書いているので次の記事は受験後のはず。
で、「テス友」というアプリで勉強してて今の正答率がこんな感じです。
だいだい75％を超えているくらいですね。
なんとかなるかもしれない感じです。
はじめの方はミスってばかりいましたが、今では正解率も高いので今の実力だともうちょい正答率は高くなるはず。
で、さっき
「そーいや受験票きてないな」
って思ったら。
受験票・受験のご案内は郵送にて2018年1月19日発送予定でございます。
2018年1月29日までに書類が届かない場合には、必ず下記受付までお問合せください。
って
おおおおおいいいいいい！！！！！！！
先ほどお問い合わせメールを慌ててだしました。。。
明日電話連絡もします。。。
