テストと開発の違いをわかりやすく教えてやんよ！

タイトルは釣りです。むしろ、教えてほしいです。とは言いつつも自分で比喩が思い浮かんだので書いてみました。

テストはQAでもいいんだけど、まぁロールとか立場とか視座とかが違うとはこういうことであるというのをなんかいい比喩を考えついたので。 このエントリでは「プログラミングする」と「テストする」はどう違うのか？ということを説明します。なので、プログラマーが「うーん。テストしているんだけど、あんまり意味がないかもー」って感じるときはこの例に出てくるような「テストする」になっていないかもしれないし、ただただ品質が高いのかもしれません。

ソフトウェア開発を塗り絵として考える

ソフトウェア開発はある形の塗り絵として考えてみます。複雑なものはちょっと考えにくいので、まずは大きな長方形を赤色に塗ることとしましょう。

まず開発する（塗る）

で、例えばプログラミングするときに左から右に筆で赤く塗ったとしましょう。ちょうど下のような感じに。

次にテストする（塗れているか別のペンで調べる）

次にこれをテストします。まずはぬれていない場所を探すことにしましょう。テストには塗られていない場所に塗ると裏写りするペンを用います。このときにたいていのテストというのはもっとすっごく細い鉛筆のようなものでしか実施出来ないという制限があります。（これは大抵は型と値の違いで言われると思う。） そしてその芯が短いこともしばしばあります。

さて、このときに開発と同じように横向きに線を引っ張ってみると。。。

でも、これを縦に引っ張ると。。。

これらを裏返すと塗れていない部分全体をそれなりに予測しやすく黒がでているのは下の方だというのはなんとなく伝わるかと思います。

このように開発とは違う視座や視点を持つことで対象を調べることがテストだと僕は思いました。なので、開発をなぞらえるようにテストしていては塗れていないところの全体像はわかりにくかったり、下手したらより見つかりにくい感じになると思います。

実際には

それにさっきは塗れていないところだけでしたけど、はみ出している部分のテストしていないですよね。これはいわゆるテストの範囲を示していると見ていいでしょう。テストレベルに近いかな？1つの図形だと関数しかないみたいな感じだけど、複数の図形がつらなっていたり、風景画だったりすると、別の色で塗りつぶしていたら困りますよね。なので、図形の中だけ奇麗になっているか見ても、実際には他の図形が塗りにくいとか書きにくい感じになっていないかを調べないといけません。これは統合テストとかコンポーネントテストですかね。

それに、実際にはこれはもっと複雑な形をしています。そうすれば塗り方もかわるし、それによってよい調べ方も変わるでしょう。そうなると、技法が生まれるし、描き方の主義も出てきます。遠近法とかでてくるし、印象派とかでてくる。前者がイディオム、デザインパターン。後者がオブジェクト指向とか関数型とリアクティブとかに似ている気がしています。で、それに対応するようにそれを評価する仕組みも必要ですよね。いい感じに描けているかっていうのを効率よく調べるためにテストエンジニアは最初の例だったらテスト技法でより塗れてなさそうな線のあたりを効率よく線引くためのアルゴリズムを経験則から導きだします。つまり、「右利きでこういったツール使っている人はここで線が曲がりやすいからこういったテストケースが一番塗れていないところを検出できそう」みたいな。あとはツールをつかって人間には判定が難しそうな部分を計測したり高速化します。視座についてもその方法論にあったもので、でもその方法論をなぞるのとは違う感じでどこから始めたらいいかとか、どの方法が早くわかりそうかとか、ざっくりわかるためにはどうしたらいいのかとか考えるわけですね。

じゃあ、TDDってなによ

小さい頃に塗り絵をやったときに塗り絵の枠をまずは縁取りましょう。ってやったことあると思います。TDDはあれに近いんですね。「僕はこれからこの範囲内のものを塗るんだー」っていう感じ。だから、ある意味テストに近いんですけど、実際には開発なんですよね。だからTDDはあくまで設計のライン引きをより奇麗にしている感じなんです。

要求のテストってどうなったのよ？

例えば「印象派後期のような雰囲気で光がつよい絵がほしい。リビングに飾りたくって、これくらいのサイズで、、、」っていうのにうまくあっているかですよね。えっと、考えるの忘れていました。

電子データならソフトウェアで部屋をつくって、そこに実際に配置してみるとか言うシミュレーション？をやるなぁと思いました。で、どの程度部屋に似せるかとか、むしろあり得そうな別の状況でも対応できるかを考えます。うん、やっぱり後付け感がひどいw

まとめ

って言う感じで、絵描きをテストと開発の比喩に使ってみました。描き方を知らないと、その描き方がうまくいっているかはわからないですが、知っているだけでは、それがうまくいっているかどうかを普段から考えていないとなかなか評価もできないものです。たぶん、誰かに同じ方法でつくってもらったのをレビューするときになって気づくことが多いのではないかなぁとか思いました。

まぁ、なのでテストが無駄に感じるときは自分の方法がうまくいっているというのを、どうやったら違う方向から確認出来るかを考えてみるといいと思います。それを思いついたら、あとはテストケースを減らせないか考える段階で、テスト技法で何か出来ないや、そもそも作り方を変えたらテストしなくていい部分が増えないかを考えましょう。で、大抵はそれなりの数もあるし、つくりながら変わるのでどの順番でやるとか、どのときに気をつけるとか考えておいた方がうまくいくので、テスト戦略を考えましょう。

みたいな感じですかね！

基本から学ぶソフトウェアテスト

基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために

ソフトウェアテスト293の鉄則

単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる

なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。

これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？

要約

だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。

あと、観測結果として　同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。　というのが大きかった。

単体テスト

まず、最初に思ったのはTwitterで文句を言っている人たちは単体テストを定義できていない人がほとんだだった。つまり、カレーが何かはわからないけど、これはカレーじゃない。だってテレビで見たのとか、なんかお店で食べたのと違う。そういっている感じだった。客ならいいけど、自分の仕事に対してそれでいいとは僕は思わなかった。自分の仕事の言葉を自分なりに定義もしくは引用できないでなんなんだろうって思った。

実際に言葉というのは定義の問題であることころがおおい。実際に画面単体でのテストというのはいわゆる単機能テストといわれるテストレベルであろう。WebMVCで言えば一つのコントローラに結びつくような感じのテストだ。単機能テストのことを単体と呼んだときに、単体より小さなものを意識しにくいという言葉の印象が持つ問題というのは僕も2,3年前に感じた。言いたいことはわかる。

単体テストと呼んだ方が楽な場合もある

これは単体テスト/結合テストなんて存在しない - Togetterまとめでも言ったが、この当時の問題意識はつまり「納品物であるドキュメント駆動な開発」ということによってそれ以外のテストを考えられないというものであったが、画面単位が単体テストであるとしてしまえば、クラスやコンポーネントのテストは納品物として作成する必要はなくなる。工数の調整をどうするかは面倒だが、それはマネージャーがいい感じにガントチャート動かしておけばよくって、そうすると作業は増えて品質をあげているけど、納品物は増えないというトリックを使える。（普通は作業には納品物が必要になるが、規定されていない作業には納品物がない）。

まぁこれが正解だなんて思っていないけど、こうやってうまく使えばいい。おそらく対外的な要因でコンポーネントレベルのテストが出来ないということはあまりない。（開発者がやる分には）

組織内にどうやって単体テストを普及させるのか

まぁ隣の人がxUnitやxSpecでのテストをやってくれない。自分しかやらない。むしろ許されないとかいう状況はあるかもしれない。そのときに単体テストをやっているから、コンポーネントレベルのテストなんかいらないんだという発言にであったら、それは計測するまでわからない。とりあえず現状を計測しよう。まずその単体テストと呼ばれているものや統合テストと呼ばれているもので発見されているバグとそれを改修するのにかかっている時間の件数や傾向を調べる。また、静的解析ツールでコードの保守性を計測してみるのもいい。他にも、新しい改修のときに既存コードを読むのにかかる時間や間違いやすい単語を調べるのもいい。これらをした結果、xUnitやxSpecで単体テストをしたほうがかなりの割合でもとがとれるならそうすべきだ。

もし、そうでないなら僕はしなくていいと思う。そんなのはエゴだ。僕もプログラミングは好きでUnitTestのないコードなんて窓から投げたいとか思うときもあるし、汚いコードはrmしたいし、プロフェッショナルじゃねぇよそんなの！ってツバを吐きたくなる。でも、なにかを変えたいときはそうであってはいけない。プロジェクトの成功がなにで失敗がなにで、継続的成長の継続的とはどの範囲なのかを見極める必要がある。

なにより、やってもただ疲れるだけのテストコード導入(画面単体の手動テストでやるのとコストや保守性が変わらない状況）なら価値に「教育」とか「スキルアップ」とかがあるべきだ。

何を言ってもわからずやなバカとどうやって仕事をするかはしらない。だけど、自分がどれくらい根拠を持って説明出来るかは、実際にはエンジニアの大きなスキルだと僕は思っている。全てではないけれど。でも、大きな部分だと思っている。

ちょっと自分の話になるけれど、同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。別に言葉は曖昧でいいし、どんな答えなら満足するとかはないんだけど、まぁなんというか物事に対する姿勢としてという感じで。

スクショの件

エクセルにスクショを貼り続ける仕事についてだけれど、まぁ辛いというのはわかる。僕も結構やった覚えがある。たぶん貼った枚数はわからなくて、Excelファイルでいうとたぶん数十GBは超えているだろう。（これは前職の話だ）

ただ、僕には現状であまりいいソリューションが思い浮かばなかった。つまり画像をいい感じにモックアップのようにスライドショーできるようなツールが2005から2010年ころにWindows XPで使える環境ではなかった気がする。個人的にはツールとしては妥当だったと思う。

なんでかというと、まずスクショをとるようなテストをやっている人たちはまずテストを好きでやっていることはあまりなくて結構手抜きなこともある。そういう意味では強制力はあった。ただ、全ての画面をあれでやるのかと言われると微妙だなぁとは思う。なにかいい感じに差分だけ適当にとってくれるツールがあるとうれしいんだけど。って言う感じで、「こういったツールだったら差分も確認しやすいし、いいねー。次のプロジェクトでプロトタイプに活かせるかもねー」とかいう新しい良いものをつくる感じの話題があるといいな。

まとめ

特にまとめはないし、誰かに何かを強制するものでもないけど、テストを勉強する時間はないけど嫌々言う人がいるから自分みたいなロールも必要なんだなぁとか思った感じです。テストなくなればいいのにね。

基本から学ぶソフトウェアテスト

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト技法

WindowsでJenkinsのジョブ失敗をデスクトップ通知する

Windowsの通知ツールやシステムというのは言うほど連携感がないので、Jenkinsからの通知をどうしたものか悩んでいましたが、素晴らしいツールがあったので紹介します。あと設定について公式に実は書いていない感じのことがあったので補足です。（たぶんJenkinsに詳しい人なら察する内容だけど。）

Jenkins On Desktop

PowerShellで実装されたJenkinsのジョブ失敗通知アプリケーションです。 ototadana/JenkinsOnDesktop · GitHub

READMEにある通りだいたい次の手順で使えます。

• zipをダウンロードして好きな場所に展開する
• PowerShellプロンプトを管理者権限で開いて、 Set-ExecutionPolicy Remote-Signed を実行する
• JenkinsOnDesktop.exeを実行する
• デスクトップに現れたJenkinsを右クリックして「設定画面を開く」をクリックする
• 「お仕事」タブをクリックして「パラメータ」欄にJenkinsサーバのURLを入力する

変更できること

画像変更もできますし、特定ジョブのみ監視ということもできます。

設定で気を付けること

パラメータに設定するURLでは対象となるようなジョブが通常のリスト表示されている画面である必要があります。

どういうことかというと、僕の会社で使っているJenkinsのトップ画面は失敗しているジョブだけが表示されるようにフィルタリングされたビューを使っています。このURLを指定すると、対象ジョブの検索にスクリプトが失敗してなんかエラーを出力します。

社内のJenkinsではこれとは別にAllというすべてのジョブを表示するViewを作っているのでそのURLを指定するとうまく動きました。

つまり

http://kyon_mm_jenkins:8080/ だとカスタマイズしたビューにしているからジョブが一個もなくて失敗するけど

http://kyon_mm_jenkins:8080/view/All だと全てのジョブを表示するようなカスタマイズしたビューを見に行くのでジョブが見つかって期待通りの挙動をする

まとめ

Windowsの通知センターをリッチにしていほしいと思ったけど、あんまりいらないかもしれない。

Spockの知られざる機能

僕だけが知らなかったのかもしれません。。。

Spockではテストメソッドに@Unrollとつけると、パラメタライズがテストメソッド名に反映されます。これとっても見やすくてよいです。

こんな感じ。。。

class WhenWatchingUstream extends Specification {

    @Unroll
    def "should show #channel when click #channel window"(){
        expect:
        // click channel
        where:
        channel << ["Cooking", "Music", "Animation"]
    }

}

にしておくと

ところがです。テストメソッドが大量になってくると、テストメソッドのたびに@Unrollとつけるのが鬱陶しくなります。JUnit4の@Testから逃れたと思ったら、今度は@Unrollがおってくる＞＜

Unrollの定義をみるとだ

ところでUnrollの定義を見ると次のようになっています。

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@ExtensionAnnotation(UnrollExtension.class)
public @interface Unroll {
  String value() default "";
}

つまり、クラス宣言につけられると。つまり、クラスにつけておけばそのクラスのテストメソッドは全てUnrollしたことと一緒になります！！！！（今日初めて知った

つまりこんな感じにできます。

@Unroll
class WhenWatchingUstream extends Specification {

    def "should show #channel when click #channel window"(){
        expect:
        // click channel
        where:
        channel << ["Cooking", "Music", "Animation"]
    }

    def "should show #sns message when send #sns message"(){
        expect:
        // send sns message
        where:
        sns << ["Facebook", "Twitter"]
    }

    def "Not Parameterize Feature"(){
        when:
        new Object()
        then:
        assert true
    }
}

まとめ

@Unrollはクラス宣言につけましょう。

Spockのテストレポートが想像以上に凄い件について

タイトルはホッテントリメーカーを使いました。http://pha22.net/hotentry/tb/r?word=Spock%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88&phrase=9

全国49万のSpockユーザのみなさま。SpockのMLを見ていると思うので、ご存知かもしれませんがSpockのテストレポートをご存知でない方もいると思うので紹介します。

Spockのテスト結果はだいたいみんなGradleで見ている

Spockは言わずと知れたUnitTestingFramework界最強といわれるテスティングフレームワークですが、これのテストレポートは通常はJUnitのテストレポートXMLであり、多くのSpockユーザはGradleでビルドをしてGradleが生成するテストレポートを見ている事かと思います。

ですが、私は常々困り果てていて、つまりSpockはBDDを強く支援するテスティングフレームワークであるのに、テストレポートには活かされていないということでした。（JUnitのテストレポートXMLがクソだから仕方ない。）

Spock-Reports

そこで私はいつもオリジナルテストランナーを書いて、状態遷移図やテストレポートを生成していたのですが、実は素晴らしいOSSがあったのです。

それはSpock-Reportsです。見たほうが早いでしょう。ということで、実行結果のスクリーンショットは次の通りです。

renatoathaydes/spock-reports · GitHub

サマリー画面

テストクラス毎の詳細画面

使い方

ビルドスクリプトから使うことを前提としてます。

Gradleならこんな感じです。

repositories {
    jcenter()
}

dependencies {
    compile "org.codehaus.groovy:groovy-all:2.3.+:indy"
    testCompile "org.spockframework:spock-core:0.7-groovy-2.0"
    testCompile "com.athaydes:spock-reports:1.2" // ←これを追加する感じ
}

Spock-ReportsはGroovy2.0以上、Spock0.7以上が必須です。

今回のテストコードはだいたいこんな感じです。（クソなコードだけど、出力用なのでゆるして。）

package org.kyonmm

import spock.lang.Specification

class WhenAddingProductBacklogItem extends Specification {
    def "All ProductBacklogItem should be sorted by Priority"() {
        given: "Product Backlog has 3 PBIs"
        when: "Product Owner add 1 PBI into Product Backlog"
        then: "All PBI is sorted by Priority "
        (PB + PBI).sort().last() == "c"
        where:
        PB              | PBI
        ["a", "b", "c"] | "bb"
        ["a", "b", "c"] | "cc"
    }
    def "High Priority ProductBacklogItems should be estimated"() {
        given: "Product Backlog has 3 PBIs"
        when: "Product Owner add 1 PBI into Product Backlog"
        then: "Half of All PBIs is estimated"
        where:
        PB              | PBI
        ["a":1, "b":null, "c":null] | ["ab":5]
        ["a":1, "b":null, "c":null] | ["ab":5]
    }
}

だいたいの説明

各画面を見るとわかると思いますが、言葉としては次のようなイメージです。（つまりこれはBDDを強く意識している）

• 各テストクラス -> Specification
• 各テストメソッド -> Feature
• テストメソッド内テーブル -> examples

まとめ

BDDスタイルにSpockを使うことやレビューしやすさをあげるなら、Spock-Reportsを使わないと損です。

プログラミングGROOVY

Bdd in Action: Behavior-driven Development for the Whole Software Lifecycle

The RSpec Book (Professional Ruby Series)

JUnit 4.12の新機能紹介まとめ

全国50万のJUnit4ユーザーさん。使っている言語とテスティングフレームワークののMLとGithubやBitBucketリポジトリを監視していると思うので今さらかもしれませんが、2014/7/30にJUnit4.12 Beta-1がリリースされました。

結構楽しい機能が追加されているので、見逃している方のために情報を共有させていただければと思います。

基本的にリリースから抜粋しながら紹介ですがご容赦ください。

Release Notes

junit/ReleaseNotes4.12.md at master · junit-team/junit · GitHub

全体の感想

JUnit4がおれの足元にやっと追いついたと思った。（今までJUnitとSpockを魔改造しまくってた。）

テストランナー系

クラス階層化

JUnit魔改造コミュニティに朗報です。私たちのテストランナーでよしなにやっておけば、inner classをネストさせることができるようになりました。今まではEnclosedでstatic classしかネストできませんでしたが。つまりこんな感じのコードが書けます。pull-req当人的にはcontext-nestできるぜー！って喜んでいましたが、個人的にはもっと他の使い方もできそうでうれしい。

@RunWith(KyonmmOriginalRunner)
class Sample {
    @Test
    public void topLevelTest(){
    }
    public class Child {
        @Test
        public void childTestMethod(){

        }

        public class GrandChild{
            @Test
            public void grandChildTestMethod(){

            }
        }
    }
}

個人的にはこれで十分ですが、他にも改善があります。

アノテーションヴァリデータのフレームワーク化

JUnit魔改造コミュニティでは自分でアノテーションをつくっていきますが、特定Annotationではこれを満たしているべきとAnnotationValidatorをいい感じに呼び出すためにアノテーションが追加されました。@ValidateWithです。

// 利用するアノテーション

@Retention(RetentionPolicy.RUNTIME)
@Inherited
@ValidateWith(MyAnnotationValidator.class) // このアノテーションではこれを満たしているべき
public @interface MyAnnotation {
    Class<?>[] value();
}

// AnnotationValidatorを使ったヴァリデートの実装


public final class MyAnnotationValidator extends AnnotationValidator {

    @Override
    public List<Exception> validateAnnotatedMethod(FrameworkMethod method) {
      // なんか実装して、不正だったらエラーを返す
    }
}

テスト通知がスレッドセーフになった

テストを高速化しようとしたり、まぁ普通に並行とか分散処理していると、たまにテストの通知が変な状態になったりしているときがあったのですが、スレッドセーフになったようです。 まだ未検証ですが、期待しています。

Assert系

assertのオーバーロードが追加

Assert.assertNotEqualsにfloatを引数にとるものとboolean[]を引数にとるものが追加されました。まぁ必要なこともあるかもしれません。floatを使う場面は滅多にないかもしれませんが。

Rule系

例外補足できなかった時のメッセージを指定できるようになった

ExpectedExceptionを使って例外が投げられることのテストを記述できましたが、今回の対応で例外が投げられなかったときに表示するメッセージを指定できるようになりました。

class ExpectedExceptionMessageSample {
    @Rule
    public ExpectedException e = ExpectedException.none()
    @Test
    public void topLevelTest(){
        e.expect(IndexOutOfBoundsException)
        e.reportMissingExceptionWithMessage("見つからなかったー＞＜。")
    }

}

Timeout指定に使うクラスのコンストラクタやファクトリーメソッドが増えた

あるテストメソッドがx秒以上実行していたら失敗するということもJUnitでは可能ですが、そのTimeoutの秒数を指定する方法が増えた感じです。

// ファクトリーメソッド版

@Rule public final TestRule timeoutFromFactory = Timeout.millis(30)

// コンストラクタ版
@Rule public final TestRule timeoutFromConstructor = new Timeout(30, TimeUnit.MILLISECONDS);

Debugモード時だけ特定Ruleをオフにすることできるようになった

例えば、Debugでテストを実行しているときにタイムアウトのRuleは効いてほしくないので次のようにすることで起動しないようにできます。

@Rule public DisableOnDebug t = new DisableOnDebug(Timeout.seconds(5));

他

CategoryとかDatapointとかTheoryとか拡張されていたけど、まったく興味ない。すまぬ。というか、たぶんみんなもたいして使っていないのでは。。。Spock使えし。。。（うそです。

まとめ

ということで、みんなでJUnit4.12-Beta-1のバグだしに貢献するために既存のOSSのビルドスクリプトをとにかく4.12-Beta-1にしてみてissueを投げつけて、pull-req投げつけましょう。

というか、普通に魔改造しやすくなっているし、使いやすくなっていてよいです。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

最近のソフトウェアテストの勉強会で行った事があるやつ

ソフトウェアテストを専門に仕事をしているので、ソフトウェアテストの勉強会などによく参加させていただいています。最近関わっている勉強会について紹介します。知っているけど、参加したことないなーっていうやつは最後にまとめます。

自分が主催に関わっている系

TDDBootCamp

「テスト駆動開発(TDD)」に関するハンズオン型の勉強会です。日本各地で有志によって開催されています。何年も参加者やTAとして参加させてもらっていて、つい先日名古屋で主催してみました。自称日本でBDDに詳しい人なので、もっと何か出来たらいいなぁと思っています。

TDD Boot Camp(TDDBC) - TDDBC

Cafe.Testing

カフェでご飯たべながら「ソフトウェアテストの入門」をする勉強会です。逆かな？id:rika0618が名古屋で毎月主催していてお手伝いしています。毎回テーマは書籍だったりWeb資料だったりあるのですが、基本自由な感じでみんなの普段からの疑問とかを話せてとてもいいです。これからも続けたいです。

Cafe.Testing - connpass

JaSST

ソフトウェアテストのシンポジウムとして日本各地で開催されています。これの実行委員会に入っています。あと、地方のJaSSTに行くのも非常に楽しいです。各地域で「聴講メイン」だったり「議論メイン」だったりしますし、基調講演者がどれも異なるので、気に入ったのがあれば単発で参加しやすいのがいいと思います。

JaSSTソフトウェアテストシンポジウム

WACATE

ソフトウェアテストの泊まり込み型のハンズオン勉強会です。年に6月と12月の二回、神奈川県で開催されています。入門的なことがメインですが、クロージングセッションに著名な方がくるのでそれ目当てにっていうのもいいかもしれません。ちなみに僕がテストを勉強するキッカケになったイベントです。

若手エンジニア向けワークショップ:WACATE （ソフトウェアテストワークショップ）

STAR

ソフトウェアテストの自動化について勉強している会です。1.5ヶ月に一回くらいで東京でなにかやっています。MLベース？のクロージングな会かもしれません。去年STACという勉強会を開催しています。僕もたまに顔をださせてもらっています。

テスト自動化研究会

仙台ソフトウェアテスト勉強会

仙台でソフトウェアテストの入門的な勉強会を毎月くらいのペースで開催しているようです。一度講演でいきました。いろいろなものを取り上げていて、バランスよさそうに見えます。

仙台ソフトウェアテスト勉強会のブログ

参加した事ないけど聞いた事があるやつ

TEF道

札幌？でやっているソフトウェアテストの勉強会です。僕がよく知らないせいだと思いますが、やっている内容は結構ノリで決まっている感じがします。でも、優秀な人が多そうに見えるのできっと楽しいのだろうなぁといつも思っています。あと、なんかジョジョネタが多い。よくわからん。

TEF-DO

九州ソフトウェアテスト勉強会

福岡でやっているソフトウェアテストの勉強会です。最近？は外部から誰かを呼んで講演してもらうっていうのをやっているようです。方向性はよくわからないですが、入門向けっぽいです。TEF道と同じ理由ですけど、ノリで決まっていそうです。

Facebook

SQiP

東京で開催されている品質系のシンポジウムです。なんだかんだで行った事ないです。品質という言葉をテーマにプロセスだったり、プラクティスだったり、事例だったり、ツールだったりいろんな話があるように見えます。

SQiP：Software Quality Profession

Ques

東京で開催されているQA専門の勉強会です。開催は不定期なようです。たまに知り合いが発表しているのですが、結構バラバラと毎回異なる内容ですし、気になるときに行ってみたいって行けそうな感じがしています。今度行ってみたいです。

Ques

自動化の窓口セミナー

東京で毎月？開催されているテスト自動化の勉強会です。自動実行ツールの話に偏っていないのと、比較的入門向けな感じがします。知り合いが発表とかしているので、今度行ってみたいです。

「じどうかの窓口。」セミナー - connpass

Seleniumユーザーコミュニティ勉強会

Webブラウザの自動実行ツールであるSeleniumの勉強会です。行った事ないんですけど、WebDriverを自分で書いて死にかけたので、なんかそういうのに関して意見交換出来る人がいたらうれしいなーとか思っています。

Google Groups

WARAI

関西でほぼ毎月開催している入門向けの勉強会です。最近は書籍についてみんなで解いたり意見交換したりしているようです。なかなか予定があわなくて行けていませんが、なにかで行きたいなーと思っています。

WARAI実行委員のイベント・セミナー - こくちーず（告知's） イベント・セミナー集客を支援する無料サービス

まとめ

Nagoya.Testingやっていないことに気がついたので、今年中に小さくでもいいからやりたいです＞＜