テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

JaSST'18 Tokyoに行ってきた!

JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo

このブログを何度かご覧のみなさまならご存じかと思いますが、 日本最大のソフトウェアテストのシンポジウム JaSST'18 Tokyoに行ってきました。

なぜ行ったのか

やはり日本最大のシンポジウムだけあって、各プログラムがとてもおもしろそう。
海外の講演者をお招きしているので、世界のテスト事情を聴講できるチャンスです。

さらに今回は、私が所属しているJaSST Kyushuのプログラムやテーマのヒントを探るというのも ミッションにありました。

何があったのか

ここでは、私が聴講したもののいくつかをピックアップして、感想を書きます。

きっと各セッション内容は 色んなブログのエントリーがあると思うので 探してみてくださいね:)

基調講演とチュートリアル

基調講演:Advances in Continuous Integration Testing at Google. John Micco(Google

まとめての感想になりますが、こちらではJohn Micco氏による基調講演とチュートリアルを受けました。

私は普段、受託開発と自社サービスのテストを選任でやっています。 探索的テストが得意なテスターなのですが、ものの見事に打ち崩された感じです。

Googleではすべてテストを自動化しています。
そのため、手動でテスト実行しているテスターもいなければ、 Issueを書く必要もないかもしれません
(いや、でもバグの結果をエンジニアにフィードバックしているて言ってたので フィードバック書く文章力や表現力は必要なのかも。

ではMicco氏は何をしているかというと、それらの自動テストの結果をデータとして持っていて おかしな動きをしていないか見ているそうです。

自動テストというと、OK/NGやGreen/Red、Pass/Failなどを思いだされると思うのですが、
それだけでなくFlakyな状態をみています。

フレーキーとはテスト実行をすると、PassしたりFailしたりするようなものを指すそうです。

チュートリアルでは、Micco氏がチュートリアルのために用意したデータと前もって作成してくれたSQLファイルを使って
データの集め方を教えていただきました。

基調講演で聴いた内容だけでは、Googleだから。という感じもどことなくしていたのですが
チュートリアルを受けてみると、今あるプログラムコードや、テスト実行結果をとっていれば
それをもとに、意外と似たようなことができちゃうかもしれないな。と思いました。

ちなみにMiccoさんと二日目の夜に一緒にお酒を飲む機会があったのですが 英語が超苦手な私とも話してくださいました(周りに沢山ヘルプだしたけど)
全然講演の話しなかった私のバカバカ。

Web.JaSST~ウェブ系QAがみんなのお悩みに全力で提案を返す会~

JaSST Tokyoでは数年前からWeb.JaSSTというプログラムがあります。
私もWebのシステムのテストをしているので(ここではWeb ServiceのQAという意味だったので、たまに私のスコープと外れる) 毎回参加しています。

今回は事前に参加者からいただいたお悩みを、チームで回答するというものでした。

こちらにTweetのまとめもあります

togetter.com

今回の内容に関しては、Webだから~ という内容は少なかったのではないかなーと思います:)
いつも思っていることなのですが、WebやWebサービスにだけ特化した情報はもちろんないわけではないのですが
それよりも、どの世界(組み込みやエンプラ、受託システム)でも、似たような話はたくさんあります。

きっと選り好みせず、色んな話を聞いて、自分の世界に落とし込める、変換できると
より多くの知見が得られるなぁと思います。

今回のパネルメンバーはWeb.QAという勉強会もやっているそうなので
いつも指くわえてみています。 うらやましい。

計画立案とふりかえりでリスクを捉えよう!~SaPIDTOC:未来予想型チーム運営WS(テスト編)~安達 賢二(株式会社HBA)水野 昇幸(TOC/TOCfE北海道)

このタッグのワークショップやBootCampが最近注目しているわけですが、
JaSSTでチュートリアルが受けられる!ということで受けました。

とはいっても、SaPIDの触りであったり、TOCの触りであったりは、他の勉強会で振れたことはありました。

今回は150分という時間。
まま長そうに見えるかもしれませんが、私にとってはまだまだ時間が足りませんでした。

SaPIDは問題解決手法の1つですが、問題に向き合うことが難しいです。
適当に何処かで聞いたことのある問題を言うと『それで具体的にどんな嫌なことがありましたか?』と掘り下げられます
日本語がまだまだ不自由。

当たり前ではありますが、チュートリアルを一回受けただけで習得できるようなものは そんなに多くないと思うので、今回の経験を機に、日々ちょっとずつやってみるといいよね。って思っています。

二人の話し方とかもすごい好きだったりします。

また、今回3人チームになって挑んだのですが、ふだんメトリクスとか進捗スケジュールを見ることがなくて
すごい勉強になったり楽しかったりしました。
自分の読みがあってる みたいなこともできるんだなーってちょっと好きになりました。(本来の目的と違うだろうけど)

JaSST Tokyoのココがすごい

セッションの内容の片鱗がおわかりいただけたかなーと思いますが、
他にもいろいろすごいことや楽しいことがたくさんありました。

どこもかしこも有名人だらけ

この日は日本中のテスト好きが集まってきます。

そうすると、右をみても左をみても有名人がいたりいなかったりします。

本会終了後に、関係者入口付近に居たのですが、出てくる人々が
「〇〇で有名な~さん」とか「〇〇で基調講演された~さん」みたいな状況になって面白かったですw

福岡からもたくさんの参加者がきたぞ!

私が初めてJaSST東京に参加したときは、おそらく一人で参加したんじゃないかなーと思います
(九州で括ると、理事の方々がいらっしゃったりしますが)

しかし、年々参加者が増え、今年は実行委員から5人(東京兼任のぞく)や、他の参加でも総勢10名程度参加しました(私が知る範囲で)

一人でも本会ではたくさんの友人たちに会えるので、寂しい思いはしませんが
仲間とくると、これからに活かすためにどうしようか。とこれからの話がしやすくなるなぁと思いました。

たくさんの人に出会える

有名人(の定義も書いていませんが)でも、そうでなくても、たくさんの人を紹介したり挨拶したりできました。
いち参加者でこんなに名刺交換をする機会はここでしかないかもしれません。

今となっては、テストの話だけでなく、生活や社外活動、自分に関する色んなことを相談したり
近況報告できる人たちと集まれる貴重な機会です。(一日目も二日目も飲みに行った)

講演者とまじで話せるぞ

偶然ということもありますが、基調講演のMiccoさんとも、招待講演の柴田さんとも話すことができました。 普通にその辺(失礼)を歩いていますし、情報交換会では独占も可能では・・・というくらいお話しできます。
日本人遠慮しすぎ。というのがよくわかりました。
みんなもっと話したらいいと思うし、講演者の方々も話すの好きな方多いと思っています。

自分の活動の棚卸しができるかも

シンポジウムに行くと、未来のことも、自分の現場に近いことも、さまざまなことを知ることができます。
自分の今の行動や活動があっているのか、必要ないものになるかもしれない
もっと工夫できそうだな とか ただ楽しいだけでなく、今日からどうしようかな。と思う機会に恵まれます。

私の場合、最近はテスト自動化だ、AIだと言われてきていますが、それでも人じゃないと手が届かないことを していると思いあがっていましたが、そんなことすら必要なくなるかも
私なんていなくてよくない?て思いました(少なくともGoogleでは必要ないだろう)

ときどき「自分のようなテストのやり方やテスターは必要なくなるし、必要ないようにすることが自分のミッションかもしれない」 と思っていた時期がありましたが、またもややってまいりました。

色々やっていきたいなぁ

さいごに

登壇者や実行委員をはじめ、各みなさまのおかげで、とても貴重な時間を過ごすことができました。
これらを指くわえてタイムライン眺めるだけにならなくてよかったです。

また、ほぼ参加だけの回も久しぶり(コミュニティブースとか出したりしてたので・・・今回もちょっとだけお手伝いしましたが) だったので、思う存分楽しめました。

実行委員長挨拶で「これからもJaSSTに期待して欲しい。ぼくらはその期待を超えるようにがんばります。だから期待してください」 というような話がありました。
私も地域運営として、同じ気持ちでやらなきゃなぁ

あー、いってよかった:)

チームでポモドーロテクニックDAYをやってみたよ

ということで、所属チーム(プロダクトチームではなく、組織上のチーム)で
「丸一日、ポモドーロをやってみよう!」
をやってみちゃいました。

ポモドーロとは

詳しくは↓とかを参考にしてください。 https://next.rikunabi.com/journal/entry/20161026_M1

ざっくり言うと

  • 「25分の作業+5分の休憩」を4セットし、長めの休憩をいれます。
  • 25分の間におこなうタスクを決めます(25分で終わるものにする必要はありませんが、ある程度細かい方がいいかもしれません)
  • 受験勉強の集中テクニックにも用いられています
  • 集中力を鍛えることで、ゾーン状態やフロー状態に入りやすくなるとも言われています

なぜやったのか

わたしたちのチームは2月に結成されました。
先日チームがどうなりたいか、などを話していて、その中に
"生産性向上" というキーワードがあって、ポモドーロテクニックでそれが達成できるのではないか?ということで
まずはやってみようよ!とリーダーがさくっと決めてくれました。

フットワーク軽っ

時間割

今回チームで試してみる(でもそもそもポモドーロやったことない)ので、
時間割を作成しました。

10:00~10:25 1回目 集中時間
10:25~10:30 1回目 休憩
10:30~10:55 2回目 集中時間
10:55~11:00 2回目 休憩
11:00~11:25 3回目 集中時間
11:25~11:30 3回目 休憩
11:30~11:55 4回目 集中時間
11:55~12:00 4回目 休憩
12:00~13:00 休憩
13:00~13:25 5回目 集中時間
13:25~13:30 5回目 休憩
13:30~13:55 6回目 集中時間
13:55~14:00 6回目 休憩
14:00~14:25 7回目 集中時間
14:25~14:30 7回目 休憩
14:30~14:55 8回目 集中時間
14:55~15:00 8回目 休憩
15:00~15:30 休憩
15:30~15:55 9回目 集中時間
15:55~16:00 9回目 休憩
16:00~16:25 10回目 集中時間
16:25~16:30 10回目 休憩
16:30~16:55 11回目 集中時間
16:55~17:00 11回目 休憩
17:00~17:25 12回目 集中時間
17:25~17:30 12回目 休憩

見るからにつらそう(´Д⊂グスン

ポイント

  • 準備や後片付けも考慮し、10時~17:30までで組み立てました。(基本的な業務時間は09:00~18:00)
  • 12回の集中時間があります。
  • 12時と15時に1時間と30分の長い休憩をとることができるように組み立てました。 (15時は休憩以外にも、メールチェックや他の人とのやりとりなど、今回のタスク以外のことがまとめてできる時間と想定しました)

デメリット

  • 社内外のSNSやメール、電話をシャットオフするため、返答が遅れる
  • 電話があった場合は、基本「折り返し」てもらうなど、周りのサポートが必須
  • 誰かチームメンバーに聞きたいときに連絡がとれない
  • 自分自身が誰かに聞きたいときにも聞けなくなっちゃう

メリット

  • 集中できる!
  • 強制的に休憩を入れるので、リズムよくできる
  • 意外とあっという間に感じる
  • ものすごく疲れるので定時で帰ろうってなっちゃう
  • タスクが進む!

個人的な気づき

  • いつものテストスタイルができない
    私はかなりフリースタイルなテストをやっているので、タスクと時間を決められてしまうと
    寄り道をしたテストがすごくしづらいと感じました。
    また、普段は適切なシステムメッセージを考えたりするのですが、時間に追われるとないがしろにしそうになったので、 別の時間でフォローするか、別にタスクとして設けないといけないなぁと思いました。

また、俯瞰してみようとしなくなりがちになりました。
この辺はタスクの洗い出しと整理ができてないとよろしくないかも。。

  • タスクの洗い出し、事前整理大事
    やっぱりタスクの粒度がそれなりに小さい方が迷いが少なくていいのだろうなと思いました。
    私もいつもより集中できましたが、
    マネージャー業をはじめ、色々忙しいエンジニアがめちゃくちゃタスク消化した!って言ってたので(タスク20個くらい消化したらしい) 事前準備とか大事ね。と思ったのでした。

  • 良い椅子大事!
    今回チームメンバーでおこなうために、会議室でやっていたのですが、
    いつもの椅子(バロンチェアを使っています)じゃないと、すぐお尻が痛くなるというのがメンバー共通の意見でしたw
    次回やるときはバロンチェアまで持ち込むかも

  • 1時間スプリントも不可能ではないかも
    kyon-mm.hatenablog.com

先日

hackertackle.github.io

で、1時間スプリントの話を聞いて、すごいなって思ったわけですが、
少しだけ片鱗というか、あぁこんな感覚をベースにやっているのかな。 という雰囲気だけ感じたつもりになっています。

今回は全く別のお仕事を各々でやっていたのですが、
同じプロジェクトチームでタスクを共有しながらやってみるとかも面白いかもしれないなぁと思いました。
(私も参加するならモブテストとかがいいなぁ)

生産性あがるぞ!

もともと @NoriyukiMizuno がやっているのを知っていて、チームメンバーに展開してみたのだけど
他のメンバーも良い感触だったみたいです。

ポモドーロは一人でもできるし(会社でやるときは、周りの協力が必要なので宣言は必要)
丸一日でなくてもよいので、休日でも気軽に初めてみるとよいかもしれません:)

モブテスト(mob testing)をやってみたよ。その2

underscore42rina.hatenablog.com

2週連続ですが、今週のテストランチでもモブテストをやってみました。
(モブテストってなぁに?て方は、前回のエントリーを見てくださいね)

今回の参加者

前回より増えて12名くらい? 今回はテスト対象を作っているエンジニアや
ディレクターも参加してくださいました:)やったね!

テスト対象

先週とは別の自社で作っているサービスの1画面をテスト対象としました

やってみたふりかえり

成果

Issueが7件(うち、バグが2件とか?)でした。やっぱり効果はあるようです

よかったこと

1回目のふりかえりで「2回目はさらにテスト対象を絞ろう。画面ではなく1項目についてテストしよう」という案が出て採用しました。
テストスコープを狭くすることで、4分をぐっとバグを出すことに注力できたんじゃないかと思います。

また、最近自社に入ってきた非エンジニア(でもエンジニア出身かな)の方も参加くださったのですが
終わったあとに前職の心配をしてしまう程度にテストに対する意識を肌で感じていただけたっぽいです。よかった♡

うまくいかなかったこと / カイゼンしたいところ

  • テスト対象が基本的なことだったこともあり、新しい知見が前回ほどなかったかもしれない

 人にはよるけど、既知の内容が前回より多かったような気がしました。
それでも、非エンジニアのメンバーには復習になってよかったかもしれません。

  • ナビゲーターが多すぎた

さすがに11人は多すぎました。最低でも2グループにわけた方がよさそうです。

  • テスト対象、やりたいテストの内容によってはもっと少なくてよいのでは?

参加くださったディレクターからの提案?ですが、今回のテストの内容であれば3人くらいで十分では?という話になりました。
たしかに4分という時間で効率よくであれば、そのくらいでよいかもしれません。
ただし、もっとドメイン知識がいりそうなテスト対象であったり、シナリオテストのような内容であれば人数が多くてもいいかもね
という話になりました。

  • やっぱりふりかえり6分は短い

2回目のテストまでに改善する内容を6分でするのは無理があるかなぁと思いました。
それでも上で書いたような案がでて採用できたのはすばらしいと思います!

テストランチという短い時間なので、6分ですることをカイゼンではなく、次のテスト対象(スコープが狭い場合)を決めることに注力したり、
テスト中の説明とかにしてしまうとかの方が消化不良にならなくていいのかも?

次回のテストランチは

モブテストについては、一旦テストランチでのチャレンジは終わりです(すぐやるかもしれないけど)
各プロダクトの開発で入れてみてもいいかもなぁと思います。

次回はこのモブテストが終わってIssueを実際起こすまでに私が考えていることを 共有できるといいなと思っています(それ社内共有ツールに書けばいいじゃん。とも思う)

モブテストをやってみたよ

最近わたしの流行りのテストランチ
毎週思いついたまま、思いつかないときはだらだらと続けています。

今回はモブテスト( mob testing )

モブっていいですよね

モブテストってなんですか?

モブプログラミングのテスト版です。
といってもよくわかっていないので、海外のスライドを何となく読んだり読んでなかったりしながら
「みんな知らないからとりあえずやってみよう。体験してみよう」と思ってチャレンジしました

今回の目的

  • モブテストというのを参加者全員で体験する
  • 参加者のナレッジを共有する
  • わたしのテスト脳を共有してもらう

参加者

9名いました。
エンジニア2名、マーケティングチーム3名、CS兼テスト1名、サポート兼テスト1名とわたし(テスト)です。

やりかた

  • みんなで同じPC、モニター(プロジェクター)、場所でおこないます。
  • テスト実行⇔ふりかえり をおこないます。
  • 実際に操作するドライバーは1名です。
  • どういうテストをするかを指示するナビゲーターはドライバー以外の人です。

今回は時間に対して人数が多いこともあり、1人を書記(やりとりやIssueに書く内容などをメモる人)というロール(役割)を作りました。

特別ルール 書記

モブテストに書記というロールは特に出てこないと思うのですが、
以前ペアテストについての事例発表で書記というロール使ってるて言ってたなぁと思って入れてみました。 http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3b.pdf
http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3.pdf

これは、のちほどIssue起こすときにとっても助かりました!

ドライバー

今回1回目も2回目もわたしがおこないました。

タイムスケジュール

公開されているSlideShareを参考にしつつ、そもそも1時間しかないお昼休みにやりたかったので 無理矢理スケジュールを作成しました。

また、テストはふりかえりを活かすために複数回することを必須としました。

12:00 - 12:30 ご飯&モブテストについての説明&今日のテストアイテムについての説明
12:30 - 12:34 モブテスト1回目
12:34 - 12:40 ふりかえり1回目
12:40 - 12:44 モブテスト2回目
12:44 - 12:50 ふりかえり2回目
12:50 - 片づけ

複数回するっていうのは、昔 kyon_mm さんに 福岡でやってもらった勉強会で教えてもらって、取り入れました。

atnd.org

テスト対象

エンジニア、マーケティングチーム、CSまで色んな方が参加してくれたこともあったので、 わたしたちの会社で作っているサービスの1画面を対象としました。
わたしたちも使っているシステムなので、サービスについての説明はしなくてもOKでした。

やってみたふりかえり

成果

バグが1件、Issueに書いた内容が7件ほどありました。
8分+αの時間でこれだけ出せるのは効果が高いと思いました。

ドライバーをしてみて

「私のテスト脳を共有する」を掲げていたので、手と口をなるべく動かしつつテストしました。 * 今から何を入力するか

はあまり言えないときもありましたが、自分が思っていたよりかなりのことを伝えられたと思います。

一例ですが、スラッシュ区切りのデートピッカーがあった場合
「テキストでスラッシュ以外やスラッシュなしで日付が入れられるか」というナビゲートがありました。
ここで私が話した話

「まず区切り文字なしで入力します。20180131とかですね。(ここではこれは日付として認識できないだろうからそのまま登録できることはないと予測)
 デートピッカーのテキストエリアにコピペではりつけます。
 あ、自動補完でスラッシュが入りました。この場合はそのまま登録できるのでテストOKとします」←区切り文字なしのテストおわり

「次にスラッシュではないものを入れます。これは例えばPostgreSQLなどで使われているハイフン区切りを入れてみます。2018-0-31とかですね。
 デートピッカーのテキストに貼ってみます。あ、これだとハイフンのままですね。
 そのまま登録してみます。登録できちゃいました。(一覧画面が表示される)
 では、もう一度このデータの編集を見てみます。先ほどの値がスラッシュ区切りで表示されているので、私はこれはOKとします」←スラッシュ区切り以外のテストおわり

「どういうことかというと、ハイフンでも日付として認識できて登録できれば登録としてはOKと私は判断します。
 でも、他のデータと表示が違ってしまうと他に影響があるかもしれないので、編集画面をみてみて、表示にも影響がない(他と同じスラッシュ区切りになっていること)を確認しました」

*1

  • テストの実施
  • 入れる理由を話す
  • OKと判断する根拠、そうではない根拠を話す
  • なぜIssueに書くか、書かない理由を話す

などを話しました。いつもテストでやっていることなんですけど、これ話しながらやってみると、自分てここまで考えながらやってんのね。とちょっとびっくりします。

よかったこと

  • 1つの指示で芋づる式にテストがでてくる

モブテストのだいご味の1つだと思いますが、1つテストすると、それに関連して「あれは?」「これは?」というものがでてきました。

  • みんなで楽しんでテストができる
  • 当初の目的は達成できたかも
  • 短時間の実行なのにIssueに書くようなことがでてきた

うまくいかなかったこと / カイゼンしたいところ

  • ふりかえり時間中もテストの話になっちゃう

ドライバーのテストはしていませんが、ふりかえり中もテストの話(あれやったらどうする?みたいな)が続いてしまったので
もっとメリハリつけた方がよかったのかもしれません。

というか、ふりかえりで話すものをもっと限定してしまってもいいかもしれない(ふんわり、次のテストに向けてカイゼンした方がいいことって言ってしまったので) ここは、他の資料も読みつつカイゼンしたいところ

  • Issueの書き方も別に共有したい  後ろに書いていますが、わたしがIssueを書くときに気をつけていることが色々とあるんですが、この流れでそこまでお伝えできたら
     共有という意味では理解しやすかっただろうなぁと思います(モブテストとは離れちゃうけど)
     2回目テストを入れずにふりかえりでそれをやってみてもいいかもしれません。いいのかな

想定外の発見

  • 社内共有ツールと併用できる

普段ちっこい気づきはできるだけ社内共有システム(Tamel)に書くようにしているのですが、今回の時間で
「あ、これ詳しくはTamelに書いてるから」ということが3~4個ありました。社内共有ツール大事。書いててよかった。社内共有ツール。

ただ、書いていても使いどころや、そもそもそんな記事があるって当事者にならないとわからないので、それが短時間に4つも既知の情報を共有できてよかった♡

  • Issueに書く内容や時間も省略できるかもしれない

このあと出てきた内容をサービスプロダクトのIssueに書いたんですが、Issue書くだけで1時間以上かかっちゃったんですね。
Issueは出来事だけを書くわけじゃなく、エビデンスや、どうすべきかを知ってるかぎりのコンテキストも考えつつ
最適解を自分なりに考えて書いています。
今回はサービス担当のエンジニアが参加していなかったのですが、担当エンジニアが参加していたら、考える部分もモブテスト中に解決できるかもしれないので
Issueを書く時間が短縮できるかもしれません。

  • 時間に対してのインプットとアウトプットの量が半端ない! これ↑20分のできごとだからね!ほんとすごい。
    ただ、めちゃくちゃ疲れる!

これを実業務に入れようとすると、適切な頻度や範囲みたいのはあるかなーと思います。 マリオでいうスターとった時間みたいな感じ。

さて次回

すっごい疲れましたが、来週ももうテスト対象のサービスがリクエストきたのでやってみます。
次回はサービス担当エンジニアが参加してくれるので、また違った発見がありそう!Issue問題も解決するといいな:)

Twitterでは「#テストランチ」で水曜日くらいに呟いています。

これこうした方がいいよ。うちはこうしてるよ。とかあったらぜひ教えてください。時間配分とか。

参考にした資料など

教えてくださったみなさま、ありがとうございます♡

Slideshare https://www.slideshare.net/llewellynfalco/mob-testing-72610210

https://www.slideshare.net/maaretp/mob-testing

www.stickyminds.com

devtest.hatenablog.com

本・雑誌

WEB+DB PRESS vol.102「はじめてのペアプロモブプロ」

*1:・・・そういえば区切り文字でNGパターンやってないなぁ

私が出てこないカタカナ集

何度も出てくるのに何故か出てこない用語集です。

完全に私都合です。

という内容で社内ツールに書き溜めていますが、ほんっとーに何度も見てしまいます。
脳が記憶しないようにしてるとしか思えない。

こういうの作っとくと便利ですよ。これはもう覚えないんだと思う。

エスケープとエンコードの違い

むかーし「HTMLエンコードされすぎてる」ってチケット切ってました。

「それエンコードじゃねぇだろ」とご指摘をいただき、 いまさらながらエスケープとエンコードの違いを調べました。

参考サイト:http://write-remember.com/archives/2728/

プレースホルダ

f:id:underscore42rina:20180123193427p:plain

何故か出ないプレースホルダ

[関連記事] プレースホルダーをラベル代わりにしちゃいけない http://u-site.jp/alertbox/form-design-placeholders

デートピッカー

f:id:underscore42rina:20180123193453p:plain

カレンダー機能

ローディング(インディケーター)

くるくるのやつ。f:id:underscore42rina:20180123193519p:plain

でも正しいのはスロバーみたい。

favicon(ファビコン)

f:id:underscore42rina:20180123193730p:plain よくfavicon設定してないよね。で書きます。

Subscribed

GithubのIssueを書くのに、これがないとassignやlabelがつけられない。

github コラボレーター追加してください

とお願いすること( ..)φメモメモ

ローカルストレージ

記事入力途中でうっかり消しちゃったときに 再表示してくれるあいつ。

入力途中の保存について、実装方法はLocalStorageだけとは限らないので、キャッシュはキャッシュで良いかもしれません

ということなので「ローカルストレージ的なキャッシュ保存」と言えばエンジニアに伝わる予定

CEGTest脳になろう!あらためてCEGTestを使ってみる

呟き発進で、お題をいただきました。

最近CEGTest使ってデシジョンテーブル書けるようになりたいなと思うことがあり、
あらためてお勉強中です。

ちなみに、

underscore42rina.hatenablog.com

で書いたテストランチでCEGTestの紹介をしたら、速攻CSの同僚が使いだして びびりました(エンジニア経験ありの方なので早い)

このエントリーよりもTogetterの方が勉強になるかも↓ togetter.com

このエントリーでは私の脳内回答と
課題を出してくださったあきやまさんの模範解答をご紹介します。

目次

CEGTestとは

原因結果グラフをデシジョンテーブルに変換するソフトウェアです。 JavaScriptで書かれているので、 ↓にアクセスするとすぐ使えます。

http://softest.jp/tools/CEGTest/

使い方はCEGTestを作った加瀬さんのブログなどでご覧ください。 原因結果グラフによるテスト設計支援ツール – CEGTest | ソフトウェアテスト・テスト技法に関する情報サイト

本日の課題

《以下の条件のパスワードを受け付ける》

  • 8文字以上15文字以下
  • 英数/記号

ただし、 * 英字は大文字/小文字混在すること * 数字を含むこと * 記号を含むこと * 過去3回のパスワードと同じものでないこと

わたしの解答

テストランチで紹介しながら「何か変ね」と言いつつ完成したのがこちらです。

作成までの思考回路

さて、この図ができるまでの思考回路を紹介します

1.まずは結果のノードを書くよ!

結果は「パスワードをうけつけるかどうか」 f:id:underscore42rina:20180118232102p:plain

「パスワードを受け付けない」を入れた方が良いか悩み。あとで消すかも。そして消した。

2.「8文字以上15文字以下」かつ「英数/記号」のときにログイン成功を作る

  • 「8文字以下、または15文字より大きいときにログイン失敗」も作った
  • 英数/記号じゃないときにログイン失敗も作った

f:id:underscore42rina:20180118232305p:plain デシジョンテーブルもあってそう

3.英字を含むこと、数字を含むこと、記号であることを追加してみる

・・・なんか怪しくなってきた
f:id:underscore42rina:20180118232457p:plain

4.大文字小文字、過去3回のパスワード入力でないことを追加してみる

あれ?わりと素直にできてしまった

完成した図

f:id:underscore42rina:20180118231605p:plain

実際の動きを見たい方は、CEGTestのインポート機能を使って↓をインポートすると結果が動作で見ることができます。

インポートデータ

10,0,
パスワードを受け付ける
8文字以上
15文字以下
英数/記号
英字である
数字である
記号である
大文字入力
小文字入力
過去3回のパスワードと同じものでない
159,411,165,20,obs,AND,0,1,1,1,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,,-1,
133,133,72,20,obs,,,-1,
177,130,80,20,obs,,,-1,
410,214,87,20,obs,AND,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
374,75,87,20,obs,AND,0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,,-1,
415,78,77,20,obs,,,-1,
454,79,77,20,obs,,,-1,
318,96,77,20,obs,,,-1,
323,4,77,20,obs,,,-1,
500,94,241,20,obs,,,-1,
--
[Cause Node]
8文字以上=
15文字以下=
数字である=
記号である=
大文字入力=
小文字入力=
過去3回のパスワードと同じものでない=

[Middle Node]
英数/記号=(英字である AND 数字である AND 記号である),
英字である=(大文字入力 AND 小文字入力),

[Result Node]
パスワードを受け付ける=(8文字以上 AND 15文字以下 AND 英数/記号 AND 過去3回のパスワードと同じものでない),

[Constraint]

ポイント

  • 結果ノードを先に決める
  • 適切なノードの粒度を決定するのが難しい
  • もっと複雑な条件(前提条件ありとか)のときにもスムーズに書ける自信はない
  • これで書くのに慣れると、テストパターンの洗い出しが超早くなれる予定

秋山さんの解答

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 の著者である秋山さんに添削していただいたので、内容と解答を添付します。

この本にデシジョンテーブルについての説明や、CEGTestの使い方も掲載されています。

追記:Twitterで最新解答を貼ってくださいました

Togetterもみてね☆

18,1,
パスワードを受け付ける
正しい文字列
使いまわしでない
文字列長が正しい
文字種は正しい
8文字以上15文字以下
7文字
8文字
12文字
15文字
16文字
短すぎ、長すぎ
英大文字を含む
英小文字を含む
数字を含む
記号を含む
英数/記号以外を含む
過去3回のパスワードのどれかと同じ
279,778,165,19,obs,AND,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
231,629,100,19,obs,AND,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
358,602,126,19,obs,AND,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,,-1,
177,445,126,19,obs,AND,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,,-1,
324.8000030517578,457,113,19,obs,AND,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,,-1,
126,248,150,19,obs,OR,0,0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
220,146,46,19,obs,,,-1,
121,143,46,19,obs,,,-1,
154,139,54,19,obs,,,-1,
187,141,54,19,obs,,,-1,
267,147,54,19,obs,,,-1,
232,260,114,19,obs,OR,0,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
281.8000030517578,268,103,19,obs,,,-1,
311.8000030517578,268,103,19,obs,,,-1,
344.8000030517578,295,77,19,obs,,,-1,
376.8000183105469,295,77,19,obs,,,-1,
406.8000183105469,238,135,19,obs,,,-1,
447.8000183105469,149,228,19,obs,,,-1,
ONE,176,28,27,19,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
--
[Cause Node]
7文字=
8文字=
12文字=
15文字=
16文字=
英大文字を含む=
英小文字を含む=
数字を含む=
記号を含む=
英数/記号以外を含む=
過去3回のパスワードのどれかと同じ=

[Middle Node]
正しい文字列=(文字列長が正しい AND 文字種は正しい),
使いまわしでない=(NOT 過去3回のパスワードのどれかと同じ),
文字列長が正しい=(8文字以上15文字以下 AND NOT 短すぎ、長すぎ),
文字種は正しい=(英大文字を含む AND 英小文字を含む AND 数字を含む AND 記号を含む AND NOT 英数/記号以外を含む),
8文字以上15文字以下=(8文字 OR 12文字 OR 15文字),
短すぎ、長すぎ=(7文字 OR 16文字),

[Result Node]
パスワードを受け付ける=(正しい文字列 AND 使いまわしでない),

[Constraint]
ONE(7文字 8文字 12文字 15文字 16文字),

1. 結果ノードについて

結果ノードが[パスワードを受け付ける]と[パスワードを受け付けない]のふたつありますが、こちらは、片方が真ならもう片方は必ず偽になりますので、[パスワードを受け付ける]一つだけのほうが良いです。
(結果ノードについては、しばらくは、一つにして、複数になるときには原因結果グラフを分けて描いた方がよいです)

2. 中間ノードについて

問題文から中間ノードを抜き出した感じですが、そうではなく、結果ノードを一段ずつ分解するイメージで中間ノードを作成するほうが良いです。
(私の解答例を見ていただけるとコツがわかるかな? と思いますが、何枚も描いてコツをつかむしかありません)

3. 原因ノードについて

原因ノードについては、どこまで具体化したらよいか迷うと思います。
決まりはありませんが、「ロジックレベルまでは原因結果グラフに描いて、具体値はデシジョンテーブルにしてから列を増やす」のが原則です。
上記原則で言うと、私の原因結果グラフの文字数は具体化しすぎです。私はテスト設計者として、テスト実装者へ必ず実装してほしい同値分割レベルを描いています)

4. 制約について

制約については、まずは【ONE】だけ使いこなせるようになってください。他の制約は当面不要です。

5. デシジョンテーブルを見て

全体的に[T]がほとんどなので、むむむという感じです。[ログイン失敗]の結果確認がしたいのであればよいのですが……。

CEGTest脳になろう

冒頭でご紹介したTogetterには、他にも同じ問題で解答してくださっています(なんとCEGTestを作った加瀬さんまで!)
実際に書いてみると実感できると思うのですが、デシジョンテーブルをいきなり作るのと
同じお題でCEGTestを使おうとすると、作り方が違うんですよね(もしかしたら一緒の人もいるかもしれないし、途中で一緒になるかもしれないけど)
複雑な項目になると、こういったツールを使えるか使えないかで差がでてくるなぁと感じているので
ぜひみなさんも使ってみてくださいね!

テストランチを社内ではじめた話

2018年もよろしくおねがいします。

ブログではとくにふりかえり(100エントリーのふりかえりはしたけど)も
今年の決意表明もしていませんが
自分らしくやります。はい。

テストランチをはじめてみた

昨年から社内でテストランチというものをお試しではじめました。

テストランチとは

『ゆるく、長く』 をモットーに、 テストについて考える、勉強する、知る、共有する ことを ランチを食べながら設ける時間です。

  • 名前:『テストランチ』
  • 時間と場所:1~2週に1度程度。12:00~12:50 会議室
  • 対象者:何となくテストの話がしたい人(エンジニア、カスタマーサポート、マーケ、バックオフィス、役員問いません!)
  • テーマ:設けるときと、フリーのときを作ろうと思います
  • やること:必ずわたしがいます。テーマがあるときは、それに則った何か(発表者だけ、または全員)を持ち寄るでも、フリートークでもよいと思っています。
  • モットー: ゆるく長く! (事前勉強や宿題はできるだけ設けず、ゆるくやりたいです。ゆるく続けることで意義があればいいなぁ)

誰もいないときは、私が一人でもくもくする予定です(´~`)モグモグ
今のところ誰かしら参加いただいているので、雑談とともにお話しています。

テストランチを開こうと思ったわけ

色々とあるのですが、以下のことを思い、もっと自分が動かないとダメじゃん。 でも重いのは続かないし、カジュアルにはじめたい!と思いました。

  • テスターが複数人になると「お隣のテスターがどんなテスト(やりかた、気持ち、悩みなど)をしているかわからない」
  • エンジニアのテストってなんだっけ?
  • プロダクト(のIssue)以外でテストの話する機会がないよね
  • エンジニア同士、エンジニア、テスター、ディレクター・・・テストの話する機会ないよね
  • コンスタントにテストの話題、課題、やりたいこと、知っていることを話す機会を増やしたい
  • 勉強会を定期開催するのは重いなぁ
  • 一方的にブログや社内共有ツールやSlackに発信しても情報交換がなかなか進んでいない

もちろん↑にペアテストやればいいじゃん。とかすでに出そうな解決策もあると思うのですが
そういうのも含めて話す機会を増やしたいなぁと思っています。

この先のこと

コンスタントに開催が継続できそうであったら、話題に上がった中から

  • 勉強会をする
  • 読書会をする
  • 情報を発信する(ブログなどなど)
  • テストの戦略を考える
  • テストのやり方をかえてみる

とか始められるといいなぁと思います。