うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

週刊ソフトウェアテスト 2014-創刊号 #swtest_jp

Testing SWTestWeekly

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@にご連絡くださるとうれしいです。創刊号なので、若干時期が広めになってるのと、選択基準がまだハッキリしていない部分もございます。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

Summary

  • CIaaS(CI as a Service)のCircle CIに無料のプランが追加されました。個人的には、CloudBeesの無料枠からの移行組をとろうとしているのかなぁ？と感じました。
  • HTTPSの無償利用が実現に向けて動き出しました。実現すれば、HTTPSのテストをしづらかったたくさんの開発チームが救われそうですし、HTTPSを利用するようなアプリケーションを作りやすくなりそうですね。
  • Webアプリケーションのセキュリティのためのテストに使える無償ツール「Firing Range」をGoogle が公開しました。他のツールよりも実際にありえそうなテストケースを実行するツールのようです。GitHubで公開されているので、コードを読んでみようかと思います。
  • モバイルフレンドリーなWebアプリケーションであるかのガイドと確認するためのツールである「Webmaster's Mobile Guide」をGoogleが公開しています。URLを入力するだけでレポートしてくれるので、勉強しながら開発するのに良さそうです。
  • モダンなビルドツールであるGradleの日本語書籍である「Gradle徹底入門」が発売されました。自動化の強い味方になるので、ぜひご参考にしてください。
  • 週末にはTDDのイベントであるTDD Boot Camp in Tokyoが開催されます。xUnit Test Patternsというユニットテストのバイブルを著者であるGerardが基調講演をします。
  • 先週は、JaSST 四国 2014が開催されました。レポートが待ち遠しいところです。
  • 来週末にはJaSST 九州 2014が沖縄で開催されます。参加費は無料で、申し込み受付中のようです。
  • JavaScriptの静的検査ツールとしても、altJSとしても使える「Flow」というツール、プログラミング言語をFacebookが公開しました。OCamlで開発されているようで、先日公開していたHackといい、Facebookは前衛的ですごいですね。
続きを読む

Gradleの最新版を簡単に使う方法

Groovy Gradle

Gradleの最新を使いたい

Gradleは素晴しいビルドツールで、インストールも簡単です。でも、成長がはやいので、いったい何がGradleのトレンドなのかわからなくなることも最もです。また、Gradleのバグが直っている可能性を考えると最新版を使いたくなります。

つまり、僕が一番使っているGradleのバージョンはmasterブランチなんですよ。実は簡単に使えるので、紹介します。

最新版を利用する準備

次のツールがインストールされている前提です。

  • gvm / posh-gvm
  • JDK8
  • git

gvm install gradleでgradleをインストールできます。基本的にgradle.orgでリリースされているものが使えます。でも、それでは満足できないです。ということで、次のコマンドを実行しましょう。

git clone https://github.com/gradle/gradle.git
cd gradle
sh ./gradlew install /path/to/gradle-master
# もしくは
gradlew.bat install /path/to/gradle-master

gvm install gradle master-version /path/to/gradle-master
gvm default gradle master-version
gradle -v

これで、あなたの環境ではgvmで最新版のGradleとリリース済のGradleを利用することができます！！

一行ずつ解説しましょう。

  • git clone https://github.com/gradle/gradle.git
    • Githubからgradleをクローン
  • cd gradle
    • ディレクトリを移動
  • sh ./gradlew install /path/to/gradle-master, gradlew.bat install /path/to/gradle-master
    • gradleをビルド gradleはgradlewrapperという機能によって、gradleがインストールされていなくてもgradleを実行することができます。(実行時に必要なgradleをダウンロードしてきて利用する)
  • gvm install gradle master-version /path/to/gradle-master
    • gvm install fooBarとすると、普段はgvmが管理しているバージョンのみがインストールできますが、gvm install toolName customVersion toolpathとすることで、任意のバージョン名でローカルにあるツールをgvmの管理配下に追加できます。
  • gvm default gradle master-version
    • デフォルトで利用するgradleのバージョンを先に指定したmaster-versionにします。
  • gradle -v
    • gradleのバージョンが2.3.xxxx などと出ることを確認します。

まとめ

Gradle masterブランチを利用するためにビルドツールをインストールする必要もないし、gvmでリリース済のものと簡単に切り換えられます。前衛的にGradleを使い倒しましょう。

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

Gradleの最新動向を紹介しました #jggug

Gradle Groovy

Gradle本がでます。

日本人著者による日本語のGradle本がでます。僕が知っている中では最も深く突っ込んだ内容でいて、幅も広い書籍です。ぜひお手にとることをオススメします。やたらとレビューしました。

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

発売記念を兼ねたGradle勉強会でLTしました。

JGGUGでGradleのハンズオンを行なってくれました。内容的にはGradleの概要、Gradleのタスクを作ってみる、Gradleのプラグインをつくってみるというもので、とてもわかりやすかったです。

僕はつい先日リリースされた2.2-RC-1のリリースノートおよび、次期バージョンである2.3のリリースノートを要約した感じのLTをしました。

Gradle2.2によって、利用するライブラリを一括してなんらかの制限や選択ルールを追加できるので、巨大プロジェクトでも利用しやすくなってきています。これはおそらく、Gradlewareの実業務とかからんでいそうです。

2.3ではANTLR3, 4対応が今のところメインですが、まだまだ開発中ですので、みなさんで新しい機能をpull reqしてみればいいと思います！！！

ちなみにスライドはemacs + org-mode + ox-reveal(reveal.js for org-mode)で書いています。

HerokuでGrailsを使うとクエリパラメータが文字化けするのでbuildpack直しました。

Grails Heroku Groovy

TL;DR

HerokuではGrailsを簡単に（普通のGrailsプロジェクトをgit pushするだけで）デプロイすることができます。ですが、（少なくともHerokuがデフォルトで使う）Tomcat7ではクエリパラメータが文字化けします。Grailsで使うTomcat7のクエリパラメータをUTF-8でエンコードするようにするビルドパックをつくりました。（フォークして一行変えただけだけど）

問題

ローカルでGrailsを使って開発しているときには気づかなかったのですが、Herokuにデプロイするとクエリパラメータに日本語を使うとめっちゃ化けてしまいました。もうTomcatのことなんてすっかりわすれていたので、原因調査にめっちゃ時間かかりました。。。

それに付随していろいろわかったのでまとめておきます。

調査方針

次の方針で調査しました。結果としては最後の他の何かで、それはTomcatの設定だったんですけど、これをHerokuの場合にはどうするか？というのがHeroku初心者ながらにがんばった。

  • Viewの文字コードがUTF-8になっていないのではないか
  • サーバーサイドでクエリパラメータをとってくるときにUTF-8になっていないのではないか
  • 他のなにか

Viewの文字コード

Grails2.3.11でプロジェクトを新規作成すると、すでにConfig.groovyにUTF-8指定されています！

grails {
    views {
        gsp {
            encoding = 'UTF-8'
            htmlcodec = 'xml' // use xml escaping instead of HTML4 escaping
            codecs {
                expression = 'html' // escapes values inside ${}
                scriptlet = 'html' // escapes output from scriptlets in GSPs
                taglib = 'none' // escapes output from taglibs
                staticparts = 'none' // escapes output from static template parts
            }
        }
        // escapes all not-encoded output at final stage of outputting
        filteringCodecForContentType {
            //'text/html' = 'html'
        }
    }
}

また、念のためgspのmetaタグにUTF-8を入れてみたけど変わりませんでした。

サーバーサイドでクエリパラメータをとってくるときにUTF-8になっていないのではないか

これもGrails2.3.11でプロジェクトを新規作成すると、既にConfig.groovyにUTF-8指定されています。

 grails.converters.encoding = "UTF-8"

他のなにか

GrailsではクエリパラメータはContoller内でparamsというプロパティに格納されています。そこで次のような取得をすると文字化けのタイミングがわかりました。

  • params → 文字化けしている
  • request.getQueryString() → 文字化けしていない（requestから直接クエリーパラメータ部分の文字列を取得する）

paramsはGrailsParameterMapというクラスなのですが、コンストラクタでHttpServletRequestクラスのgetParameterMapメソッドから値を取得しています。具象クラスはこの場合は実際に利用しているサーバになってくるので、この場合はTomcatです。

ということで、Tomcatのクエリパラメータのエンコードをいじればよさそうです。

ここで、Tomcatの設定を変更する方法なのですが、組み込みTomcatの場合には次の方法がありました。

  • org.grails.plugins.tomcat.ForkedTomcatCustomizerというクラスをつくる。 つくる場所はsrc/main/groovy配下になります。イメージとしてはこんな感じで、void customize(Tomcat tomcat) というメソッドを実装して設定を変更します。
package org.grails.plugins.tomcat

import org.apache.catalina.connector.Connector
import org.apache.catalina.startup.Tomcat

class ForkedTomcatCustomizer{
    void customize(Tomcat tomcat) {
        def c = new Connector(protocol: "HTTP/1.1", port: 8080, URIEncoding: "utf-8", redirectPort: 8443)
        tomcat.service.findConnectors().each {println "${it.protocol} ${it.URIEncoding}"}
        tomcat.service.addConnector(c)
    }

}

前まではEvents.groovyで出来た気がしたのですが、どうもEvents.groovyに以前のようなTomcat用のイベントがこなくなったらしく、上記のような方法になったようです。

でも、私がやりたいのはHerokuのTomcatでした。

最初、この方法で組み込みTomcat以外の設定もオーバーライドされるのかと思ったのですが、そんな感じではなかったようです。で、ローカルにあるTomcatならserver.xmlを変更すればいいのですが、HerokuにあるTomcatを変更するとなると。。。って思い、buildpackを変更することにしました。

HerokuのGrailsビルドパックはJettyもしくはTomcatを利用するようになっていて、Tomcatの場合には別の場所からwebapp-runnerという別のリポジトリで管理されているtomcatをまるっとくるめたjarをダウンロードしてきて使っています。tomcatの設定を変更するにはこのwebapp-runnerをいじればよさそうです。

最新版である7.0.40.1をダウンロードしてきてヘルプを見てみます。

curl http://repo2.maven.org/maven2/com/github/jsimone/webapp-runner/7.0.40.1/webapp-runner-7.0.40.1.jar > webapp-runner.jar 

java -jar webapp-runner.jar  --help

するとなんと--uri-encodigっていうオプションで指定できるよ！とか書いてあるじゃないですか！！ やったね！

ということで、Grailsのbuildpackで指定しているRUNNER_OPTSという環境変数に--uri-encoding utf-8って指定をすればいいのですが、buildpack見てみると、ダウンロードしているwebapp-runner.jarが7.0.40.0で古くて、--uri-encodingに対応していない。。。

ということで、これをフォークして7.0.40.1のjarをダウンロードするようにしました。あとはフォークしたbuildpackを使えば問題ない感じです。

forkしたプロジェクトはこちら。（Pull Reqしたほうがいい気はしているが、フォークもとのブランチ戦略がよくわかっていなくっていま出していいのかよくわからん。

まとめ

2014/10/13現在で、Grails + Tomcatで出来るだけ簡単にHerokuにデプロイしてクエリパラメータを文字化けさせないためには次をする。

環境変数を追加する（コマンドで追加する場合）

heroku config:add BUILDPACK_URL=https://github.com/kyonmm/heroku-buildpack-grails
heroku config:add RUNNER_OPTS=--uri-encoding utf-8

Githubのherokuボタンを利用しているなら、app.jsonにも同じように追加しましょう。

{
    "env": {
        "BUILDPACK_URL": "https://github.com/kyonmm/heroku-buildpack-grails",
        "RUNNER_OPTS": "--uri-encoding utf-8",
    }
}

補足

Jettyを使えばこんな問題とはおさらば出来ます！！ですが、Grailsのビルドパックで利用しているjetty-runnerの実装がイケていなくって、起動時にタイムアウトが頻発してしまいます（Herokuではアプリケーション起動に60秒以上かかってはいけない）。これは、環境変数PORTがjetty-runnerなかなか割り当てられないためのようです。これを解決するrunnerを書いている人もいるのですが、いまいち最新に追いついているのかわからなかったので今回は利用を見送りました。

そのうちJettyを使うならこうやるよ！っていうのを試してみたいです。

超補足

Heroku本買いました。わかりやすくて助かります。

プロフェッショナルのための 実践Heroku入門 プラットフォーム・クラウドを活用したアプリケーション開発と運用 (書籍)

プロフェッショナルのための 実践Heroku入門 プラットフォーム・クラウドを活用したアプリケーション開発と運用 (書籍)

Grails in Action

Grails in Action

Programming Grails

Programming Grails

技術書を買ったけどなかなか読了できない理由

読みたいと思った技術書を買ったけれど、半年たっても読了できていないとか、最初の10ページだけ読んであとは読んでいない。読み終わったけど最初の方は忘れていて書籍の内容が自分の中で体系化できていない。そしてそれを後悔しているという人がいると度々聞きます。

自分もそういうことがあるのでなんでそうなってしまうのか振り返ってみました。みんなどうせこうだろ？とかではなくって、僕はこうだったわーっていう感じ。

基本的には次の3つかなぁと思います。

  • 先送りにしてしまう
  • 前回読んでから今回読むまでの期間が長過ぎる
  • 書いてあることを復唱するだけになっている

つまり

  • 先送りにしない
  • 出来るだけ短い期間で読み切る
  • 要約と応用事例を考える

を徹底すればだいたい読めます。これを出来ないときは買わない方がいい。と僕は割り切って書籍を買ったり借りたりするようになりました。（課される場合は別です。）

先送りにしてしまう

皆さんの私生活がどれくらい暇なのかもしくは忙しいのかは知りませんが、例えば平日のうち3日くらいは1時間ずつ勉強する機会を自分で設けられるとしましょう。土日は1日くらいを3時間とか。

でも、それらのうち何回くらい「あぁー、今日はパスー」とか「Twitterで時間つぶしたー」とか「眠いー」とか「艦コレで時間がー」とか「懇親会だしー」とか「踊って疲れたー」って思うかです。

あくまで僕の経験ですが、そういうときって「月曜日にさぼるかわりに今週は火水金でやろう」とか思うんですけど、たいていやりません。もうダメの典型ですね。習慣的に火曜日にモチベーションないのに、火曜日にモチベーション高めるの難しいんですよ。

技術書を使うような勉強って締め切りと評価がないので、いくらでも先送り出来るのがこういったさぼりグセをさらに歯止めきかなくするところです。

勉強したいと思ったら、まずは素直に自分が一ヶ月でどれくらいの周期でどれくらい勉強に時間をあてているのかを計測しましょう。

「勉強可能な時間」はたいていは「勉強している時間」より長く申告してしまいます。自分が勉強するということに対して習慣づいていないと「勉強可能な時間」には「残業できる時間」も合わせているからです。そして残業時間でやったものはろくな成果に結びつかない。

前回読んでから今回読むまでの期間が長過ぎる

一ヶ月に10時間ほど時間を取れると仮定して、でそれが2週間おきに5時間ずつだとしましょう。2週間前に初めて目を通した文書についてそれほどハッキリ覚えられているのでしょうか？僕はあまり覚えられません。覚えているときは、その内容を使った作業か発展させたものをその2週間ずっと使っているときくらいです。でも、それだったらその書籍をむしろ職場かどっかに持っていって日常的に読み直していてもいいくらいです。なので、そういうのは除いて、現状ではあまり使う機会のないものについて2週間ごとに読み進めているときですね。

自分が得意な分野だったらスラスラと覚えられるので、もしかしたら大丈夫かもしれません。で、それ以外の分野だったらたぶんダメです。覚えられないし、そもそも5時間で進む量がとても少ない可能性の方が高いです。

書いてあることを復唱するだけになっている

分野にもよりますが、書いてあることを復唱するだけのような読み方をしているとあまり身になりません。大抵のものは応用がききます。そしてそれを適用出来る場所を発見したり、組み合わせたりして効果的に今よりよくしていくものかなぁと思います。

学び始めはなかなか適用する場面を発見したり、組み合わせ方を思いつかないかもしれませんが、それは天から降ってくるものではなくて、基本的には自分で発見するものです。（もちろん形式知にしていくことは大切ですけど、知識を得る側にとっては限界があります。必要な知識全てが形式知化されているとして、自分にとって最適な知識を自分で探し出せるほど、まだ方法論やシステムは発達していません。）

復唱すること、真似ることは上達への近道です。それは間違いないのですが、真似ることは基本的に「真似ながら自分なりの何かを探す」という最初の手段であって、真似ることがゴールではないはずです。

まとめ

どう変えたらいいのかという僕なりの結論は上に書いたように次の3つです。

  • 先送りにしない
  • 出来るだけ短い期間で読み切る
  • 要約と応用事例を考える

で、僕はこれが出来ないと思えるときには対象の勉強をしないようにしています。技術書だって時間だって無料じゃないですからね。非効率な勉強のために使った10時間があればもうちょっと健康になれるかもしれないし、得意分野ならちょっと上達できるかもしれませんし、語学の勉強をできるかもしれません。でも、必要だったら他の何かを調整して計画段階で変えるべきです。「○○強化プロジェクト」とかにして、日常生活や職場での過ごし方を変更します。

なんにせよ、ROIが低すぎる勉強はやめたほうがいいってことでしょうか。まぁあんまりこういうこと言うと「勉強できる時間が少ないからやらない！」って人が増えてしまうのかなぁとか思うのですが、自分の幸せとか楽しさとかが重要ですし、勉強しないことが原因で仕事なくなったり信用減ったとしたらそれは君の判断が間違っていたというだけではーっていう気がします。ある分野でのスキルアップや投資は手段であって、幸せになるという目的のために使えばいいのでは。。。で、スキルアップや投資自体が幸せなのが趣味になるものではー。とか思います。

※ゴール指向っぽいのは僕の癖です。

IMPACT MAPPING インパクトのあるソフトウェアを作る

IMPACT MAPPING インパクトのあるソフトウェアを作る

ソフトウェア・プロセス改善のROI―プロジェクト・マネジャーとソフトウェア・エンジニアのためのメトリックス

ソフトウェア・プロセス改善のROI―プロジェクト・マネジャーとソフトウェア・エンジニアのためのメトリックス

テスト戦略のたった3つのチェックリスト

Testing

本稿はSoftware Testing ManiaX vol.9に寄稿したものになります。ご興味ある方はJaSST、WACATE、コミックマーケットに参加して買ってみてください。

さーくるWACATE

ちなみにkyon_mmの心情的にはだいぶ押さえて書いています。本音を言えば「なんですかそのテスト計画？昼寝しながらでももっといいの書けますよ」「訓練をしないで戦地に向かうことに恐怖を覚えないなら、いますぐこのマサカリを首にかけてやる」って気持ちを必死におさえて書きました。偉いです。自分をほめたいです。 そういう雰囲気で書いているのであまり整理されていない内容ですが、皆様の何かのご参考になればと思います。突っ込み歓迎ですが、こういった文章ですのでface2faceだとコンテキスト共有しやすいと思われます！

はじめに

ソフトウェアを開発していくなかで、品質を考えるということは非常に重要なことです。品質のすべてをテストが担う訳ではないですがテストは多くの品質に対して比較的わかりやすくアプローチできる手段であると言えます。

例えばソフトウェアに対して求められる品質というのは例えば「カレンダー連携アプリケーションはだいたいこういうのが普通だ」とか「○○社が出しているソフトウェアってこういう感じ」とかもありますし、「○○ってソフトウェアはバグが発見されたら次の日には修正版がリリースされる」とか、「見やすさ重視している」とか「たくさんカスタマイズできる」とかいろいろあります。

それぞれを体系的にそれは○○品質で特性がなにで、、、のようなお話はたくさん出来ますし、有意義なわけですけど、まぁとりあえずは置いておきます。

今回はこのようにソフトウェア（もしくはそれを運用している組織）に求められる品質があり、それを鑑みてテスト戦略をたてていくとはこういう例がありそうですよ。というお話になります。

テスト戦略の目的

テスト戦略の目的というとかなり広範囲になりますし、結構立場によって違うと思います。より一般的に使えそうな目的というのはIEEE829やISO29119のような規格を読んでいただくとして、この文章では「ソフトウェア開発におけるソフトウェアテスト全体のROIやCBAを最大化するために合意するもの」としておきます。

テスト戦略のたった3つのチェックリスト。

さて、皆さんはどのようなテスト戦略（テスト計画）を立てていますか？テストフェーズ毎にスケジュールをたてて終わりとかいう残念な話は置いとくとして、IEEE829やISO29119をはじめとするなんらかのフォーマットに従って策定することもあるかもしれません。まぁそういったものがどのようなフォーマットになっているかは皆さん知っていると思いますので、すっ飛ばしまして、今回は私が何を考えてテスト戦略を策定しているか？という感じですすめます。

テスト戦略でとても重要視しているのは次の点です。

  • そのテスト戦略は今達成したい品質を達成できるか
  • 仮に不足してしまった品質があればそれについて成長的にリカバーできるものであるか
  • プロジェクトが進むに従ってその戦略の範囲内で変更可能なことと、変更不可能なことが明示されているか

私がこれらを守るように書けばまぁなんとなくうまくいっている気はします。つまりテスト戦略のフォーマットとか挙げている項目というのはある目的に対して達成しやすそうな手段の1つでしかないので、正直そこは好きなようにしたほうがいいと思っています。「標準やフレームワークをうまく使える人間というのは、それなしでもうまく進められる人間だけなのである」というとても普遍的なことがやはり、テスト戦略のフォーマットにも当てはまる訳です。多分これを読んでいる人はそういう人ではないと思うというところもあってですね。つまりは、テスト戦略のようなある程度大きくアクティビティを決めるレベルの文書で手段を目的化するのは非常に辛さしか生まないです。（勉強しようと始める場合を除いてですね。）

では、各目的について軽く説明をします。

そのテスト戦略は今達成したい品質を達成できるか

いま対象としているソフトウェア、そしてそれを提供する組織に求められている品質があるはずです。先ほど述べたような感じですね。それらの依存関係を示した上で、テストによってどの部分を達成できそうであるかを示していることが大切です。 テストをすることは手段であって目的ではありません。例えばある品質を達成するための手段です。ここで言っている品質は必ずしも「物が出来上がってから何件のバグが出ているか？」などを測るものだけではないことは前述の通りです。 そのテストで何を達成しようとしていて、何が達成できないのかがわからないとどんでん返しをくらいます。例えば「○○っぽさっていうのって確認できるのか？できないのか？」みたいなところを誰も達成しようとしていなくって、リリース直前になってそれが発覚して急にやり直しとか。つらいですね。このソフトウェアをリリースするときに達成していなければいけないものが何であるかを明示化するのは、テストだけでは非常に洗い出すのが難しいので、出来るだけチームで洗い出しましょう。その上でテスト戦略策定時にテストではここまで出来そうであるとしていきます。

仮に不足してしまった品質があればそれについて成長的にリカバーできるものであるか

プロジェクトが進むにつれて、テスト戦略を変更することはよくあることです。その中でどうしても今回は達成できなかった品質というのもあるかもしれません。例えばある組み合わせについてはおそらくはほとんど発生しないのでテストケースを削ったり、ユーザビリティ評価をせずにリリースせざるを得ない状況になったりすることです。そういった判断をする場面はありますが、ここでそのテスト戦略をただ単に一部削除してしまってはかなり意味が薄くなってしまいます。 達成できなかった品質を、リリース後にどうやって本来あるべき姿に持っていけるかというシナリオまで描けてそのテスト戦略は意味を成します。リリース後にもテストを続けるのか、マーケットでいち早く対象の品質を計測できるようなテストを考えるのか、テスト以外の方法で達成できるように別の戦略を考えるのか。 テスト戦略とは一回つくって終わりというものではありませんし、惰性でつくって終わりというものでもありません。それがどんなに軽くても重くてもです。

プロジェクトが進むに従ってその戦略の範囲内で変更可能なことと、変更不可能なことが明示されているか

計画したものというのは基本的に様々な前提条件を伴っています。プロジェクト全体の前提条件とは別に、個々のアクティビティやソリューションにも前提条件があります。例えばとあるデータベースを使っていたけれども、急に特定パターンでのみのデータ追加が膨大になるということが判明したら、テーブル設計で解消しやすいのか、データベースの選定からやり直したほうが解消しやすいのか、データベース以外の部分を変更することで解消しやすいのかはそのときの前提条件によります。それはデータベース自体の制約かもしれませんし、チームのスキルなどによる制約かもしれませんし、運用環境の制約かもしれません。何にせよ前提条件は存在します。 このようにテスト戦略にもこの戦略で対応しやすいこと、テスト戦略自体の変更で対応しやすいこと、テスト戦略以外の変更で対応しやすいことが存在します。 具体的なスキルセットやロールが指定されている人、そしてその人が関わってくれる時間、使える環境、プロダクト、要求、テスト期間などは実際のテスト戦略で決定するものでもありますが、それらがどのような条件で変動できるのかなど、変更な可能な部分と変更不可能な部分に関して明示的にされていないとプロジェクト全体でのリカバリーが難しくなるばかりです。

テスト戦略策定

テスト戦略策定手順書みたいな、つまり手順書というのは正直どうでもいい（陳腐化しやすい）です。便利なんですけどね。なので、最近自分は技術的なものは出来るだけゴールとチェックリストを明確にしたらあとはどうやってそれに近づけるかの様々な手段を勉強なりサポートなりする方がいいと思っています。という前提においてテスト戦略の策定についていくつかの手段を書きます。

状況を把握する

対象のプロジェクト自体がどのような状況であるかを把握したほうが、テストの見せ方を工夫したりテスト自体の合意する状況作りに役に立ちます。少なくともソフトウェアテストにおいては、「それはテストだから関係ない。気にしないでとにかくテストケースを考えてテストを実施するんだ」ということはありません。 状況と曖昧な言葉になっているのは、それは範囲が広いことを示しています。実際にはかなりBig IAと似通ったことをすることになります。自分がやるときは利害関係者を洗い出して、コンテクスチュアルデザインをなんらかで描くようにしたりなどしています。 また、この他にも決まっているマイルストーンやチームメンバーのスキル、守るべきルール（法律だったり社内規則だったり）や予算もあります。他にも既存で使えるものに関しても把握しておく必要があります。 また実際に言われている要求についても整理する必要がありそうです。

言及すればまだまだキリがないのですが、重要なのは状況を把握しているということで何をどこまでやれば把握していると言えるかはプロジェクト次第になります。自分がやってきたプロジェクトでは上記のようなことは最低限やっておきたいことになりますが、それもまた別の組織では別の回答になりそうな気はしています。 これは私だけなのかもしれないのですが、自分がユーザーだったとしても実際に自分が使う場面を絵やシナリオ的に書き出したあとにソフトウェアを設計してみると最初の想定とはずいぶんと違い、それによってまたテストもかわってきたりというのがよくありました。

全体の品質を達成する方法を複数用意する

目的と手段は相互に影響し合うので、達成する品質が決定してから方法を考えるのも、方法を考えてから品質が決定するのも行ったり来たりであるので、どちらであるかはあまり気にしないでいただきたいという前提で。 ある品質をどのようなテストをすることで達成するかは実に多種多様です。ある面においてはそれはテスト技法の選択方法（ドメイン分析に時間をかけるのか、リスク分析に時間をかけるのか、AllPairに時間をかけるのか、など）によるかもしれませんし、ある面においてはどのような手段でテストをする（例えば○○環境によってこの範囲で動的テストをするのか、WorkInProgressなプルリクエスト形式のコードレビューをするのか、毎日テスト担当者を変えるのか、など）かもしれません。 自分の場合なのですが、テスト自体は開発と違う視座で考えられることが多いのですが、テスト自体が狭い視野になっていることがあり、考えたテストが唯一の方法であるかのように振る舞ってしまうときがあります。 ちょっと飛躍した比喩ですが、「○○駅に行く」という目的を達成するためには「GoogleMapを見ながら歩いていく」「自転車で行く」「自家用車で行く」「タクシーで行く」「電車で行く」「誰かに迎えにきてもらってつれてってもらう」という方法はありますよね。テストもある品質を達成するためにはいろいろな方法があると思います。それにあまりにも毎日行かなければ行けないのであれば「近くに引っ越すために長期的に取り組む」という方法も出てきます。これはソフトウェア開発で言うとよく保守性とかブランディングと言われているような時間をかけて取り組む品質と似ていますね。なんにせよ、様々な方法を備えておけばおくほど変更に強くなります。自転車で行くのが慣れている人でも、雨が降った日には電車で行きたくなりますよね。でも、電車の乗り方を知らないと困りますよね。で、それで電車がない田舎だと車がないと困る訳で、免許がないと雨の日は遠いと出かけにくくなってしまいますね。ということで、あらかじめ備えておく必要が出てきます。みたいな。

テストのROIを計算する

テストのROIは正確に出せるなら出した方がおそらく予測がよりたてやすくなるのですが、まずは相対的な値でいいので自分たちがやろうとしているテスト、今回はあきらめるテスト、今後継続していく活動などのROIを出しておくと、戦略で変更可能なものと変更不可能なものがわかりやすくなってきます。 どんな項目を使えばいいのかは対象によってかなり変化するので難しいですし、詳細はRisk Reduction ROIやCBAにお任せします。相対的でもいいのでROIやCBAを作ることになれていると、開発やテストにおける設計の小さめな意思決定にも簡単に使えるようになってなにもないよりは比較的客観的で説明しやすい理由付けをできます。 テスト戦略自体は多くの人と共有する必要が出てきやすいものですし、比較がわかりにくいままの状態での意思決定はあまりに職人芸になりがちです。職人芸を否定する気は全くありませんが、私個人のスキルではどうにもならない部分もありましてこうしているという感じです。

まとめ

ちょっと手薄な感じもしますが、あまり語られないテスト戦略についてどうあるべきかについてkyon_mm個人の経験を少しまとめてみました。 テスト戦略だけではありませんが、あまりフォーマットや手順にこだわらず、ですが今後少なくとも自分が成長するために残していくのはとても有意義だと思いますし、そのチェックリストおよびサポート的な手段を紹介しました。あくまでkyon_mm個人の経験とかスキルに依存した話でしたが。 今後もテスト戦略についていろいろ議論していきたいと思っています。

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

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

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

ソフトウェアテスト12の必勝プロセス-テストの計画・準備・実行・改善を究めるために

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

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

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

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

基礎勉強会について

各地で基礎と名のつく勉強会がたくさんあると思いますが、@が行っている基礎勉強会はどういったものかというのをお話しましょう。

あ、基礎と入門は違います。

こんなことを目的にやっています

勉強会が開催されるキッカケはあるわけですが、基礎勉強会の目的は基本的に「中級者をいかに底上げするか」と「上級者が好き勝手に話せる場を設けたい」をマッチさせることにあります。 これがうまくいくという見通しがたてば開催するという感じです。

今までにやったやつ

それこそ大半の基礎勉強会開催のキッカケ自体はかなりノリです。でも、やるときにはやっぱり上の目的が達成されるようになんとかしたいなーと思ってやっているつもりです。 雰囲気を感じてもらうためには過去のハイライトを見てみます。

Java基礎勉強会

全ての基礎勉強会はここから始まったJava基礎勉強会

といった感じで始まりました。いや、バイトコード生成の話もありましたし、メモリモデルの話もありましたし、JavaEEの話もありました。

型理論の話の他にもこういう誰が話せるんだこんなのみたいな話もありました。

2012/08/26 Java基礎勉強会 at 名古屋 資料

→return も throw も break も continue もただの継続の起動

はい。これJava基礎勉強会です。おわかりでしょうか？（わからない

Scala基礎勉強会

日本のScalaでこわい人がやたらと集まりました。 それでもやっぱり

という感じの発表もあります。 この日は論文の読み方から、Haskellとの比較が多いとか、モナドがどうとかいろいろ話がでました。

わかめのモナド浸し

@さんをモナドで浸すために会を開いたのですが、いろいろと会が大きくなって、基礎勉強会とチュートリアルと併催でやることになりました。 これは分けられたのである意味よかった。全員が基礎勉強会に行っていたら死んでた。

でも、チュートリアルのほうは本当に好評でよかったです。チュートリアルに使ったid:bleis-tiftさんのスライドもすごいview数になっています。

とりあえず基礎勉強会のほうでは最初の数十分まるでモナドって単語がでてこなかったのが。。。可換図を描いていました。

Groovy基礎勉強会

今のところ唯一名古屋以外でやった基礎勉強会です。 + Groovy基礎勉強会 - connpass + 2013/03/09(#GroovyBase)Groovy基礎勉強会 - Togetterまとめ

この日はほぼ全ての発表者が「それで、ASTはですね」という話をしていました。そうだね。Groovyの基礎を勉強するのにMOPとASTは外せないね。

並列並行基礎勉強会

並列プログラミング、並行プログラミングの基礎についての勉強会です。知らないことがたくさんでてきてすごかったです。

π計算あたりのBisimulationとかわからなかったし、最後の僕の発表であるJavaのLockFreeでは最後は延々とJVMのコードリーディング勉強会になって最終的にアセンブラまでおりていきました。

.NET 基礎勉強会

名古屋では珍しい.NETの勉強会が開催！と思ったらこれですよー。的な。でも、ものすごい人がきていました。

ILの話とかλの話とかでしたね。

※ちなみに直前はid:bleis-tiftによるチャーチ数とか型無しλ計算の話でした。（F# 関連ということで）

基礎勉強会忘年会

java-jaの人がくる！ということで、勉強会しよう！ってなりまして。これは基礎的な話をしていただきたいということで開催しました。

当時、@さんと@さんは知識すごいなーと久しぶりに感じさせられて、さすが東京のソフトウェアエンジニアが道をあけるjava-jaだけあるぜ！とか思いました。（うそです

ここから下は妄想的な感じ

基礎勉強会が僕にもたらしているもの

まぁ人脈がひろがった！とかはあるのか、ないのか的な感じなんですけど、注目はされやすいのかもしれません。

やってみていて、思ったのはやっぱりこういう勉強会は僕にとってすごい有用なのでいいなぁと思っています。なんというか、こういう基礎に踏み込んだ内容ってなかなか日本語で情報がなくって迷子になるし、英語で勉強するのってやっぱり2倍とか3倍とか時間がかかるので、こういったガイドライン的な資料があると後から勉強するときにものすごい役に立っています。

あと、こういうことやりたいんだけど、あんまり聞かないなぁ。。。っていうのに挑戦することが多いので自分にとってはこういった普段はまったく聞かないような研究に近いような話もとても勉強になります。

なので、僕のスタンスとしては基礎勉強会ではその場でわかることはまったく意図していないです。発表をきくような勉強会でそもそも得られるものってあんまりないと僕は思っているので、それを思いっきり振り切って「簡単には得られないようなエントリポイントとガイドをたくさん用意する勉強会」というのが基礎勉強会として僕には意味があります。そういう意味もあって基礎勉強会では「あぁ、なるほど、わからん」くらいのほうがちょうどいいと思っています。

その一方で出来るだけ理解してほしい部分とかはハンズオンでしかも数人に一人のTAがつくようなスタイルでやったほうがいいと思っているので、BootCamp系とかの別の勉強会をやっています。

名古屋とそれ以外という話

これはあくまで僕の感覚なんですけど、名古屋は比較的理論的な勉強を好きなソフトウェアエンジニアさんが名古屋内の比率としてたくさんいて、東京はその比率が少ないかもしれません。 でも、ソフトウェアサイエンスの学校は名古屋よりあるし、○○研究所的なところもあるし、名古屋よりは絶対数は多そうなんですけどあまり僕が知っているようなコミュニティでは見かけません。

そういった事情もあって、基礎勉強会で発表できる人間というのが名古屋に偏っているというのがあり、基礎勉強会を開催するのが、東京では難しいというかんじになりつつあります。 多分、Scalaとかなら東京でいけそうですが。

他の地域はよく知りませんが、更に少ないのでは！！と思っています。

まとめ

2014年は難しいかもしれませんが、基礎勉強会シリーズは私のソフトウェア開発の勉強に非常に役立っているので、今後も「基礎と入門は違う。基礎っていうのは根幹なんだよ。」っていう感じでどんどんすすめていきたいです。また、.NETやScalaもやりたいですし、ずっとやりたいと言っているOO基礎をやりたいです。