ソフトウェアテスト勉強会 ～PistMasterを使い倒す！～に行ってきました

2014/11/28のソフトウェアテスト勉強会のレポート。

今回の勉強会は、組み合わせテストの項目を簡単に作成するPictMasterの勉強。

インストール

ここからPistMasterをダウンロード。
PictMaster プロジェクト日本語トップページ - OSDN

ダウンロードしたファイルにユーザーズマニュアルが含まれてるので、その手順に従ってインストールする。

実践

基本

フォント4種類と、それぞれのフォントで太字、斜体、下線、影付きの有無を組み合わせるテスト項目。
パラメータ名と、それぞれのパラメータの値を','区切りで入力する。
(日本語入力でカンマを入力するのはちょっと面倒だけどそこは我慢)

実行ボタンを押すと、a.xlsというファイル名で、以下が出力される。

各項目について、2項目の組み合わせ(フォント-太文字、太文字-斜体字など)のパターン全てが出力されている。
組み合わせ項目数を変えたい場合は、環境設定->組み合わせるパラメータ数 を変更する。

実行ボタン押下すると、3項目の組み合わせ(フォント-太文字-斜体字など)全てが出力される。

なお、環境設定でシードの値を変えると、別の組み合わせパターンが出力される。 (シードの値を変えなければ抽出される項目は常に同じ。)

同値分割

複数の値がテストとして同じ意味を持つ場合、同値分割によりテスト項目数を減らす事が出来る。 同値は、各値を'|'で区切って指定する。

出力した結果。フォント4種類の値を同値としているため、テスト項目が減っている。

排他指定と結果表

Webからの入力項目の試験。 名前、メールアドレスは、入力がなければエラーとする。

名前：未入力とメールアドレス：未入力を組み合わせた試験を行うと、エラー発生時、どちらの未入力が原因でエラーになったのか分からなくなるため、各試験パターンについて、未入力とするのは、名前とメールアドレスのどちらかのみとする必要がある。 この場合、組み合わせてはいけない値は、'~'から始まるように記載する。

また、結果表を使用し、名前未入力、メールアドレス未入力の場合の結果もテスト結果として出力してみる。 結果表は「環境設定」->「結果表を使用」にチェックを入れる事により使える。

実行結果。 名前＝未入力とメールアドレス＝未入力が組み合わさったパターンは出力されない。 また、各試験パターンについて、結果も出力される。

特定条件でのみ許容するパターン

ラーメン注文のパターン試験。ただし、以下の条件あり。

• 紅しょうがは、とんこつの場合のみ可。
• すりおろしニンニクは、とんこつ以外の場合のみ可。
• とんこつの場合、麺の茹で方はバリカタ、カタのみ可。

この場合、制約表により組み合わせの条件を指定し、制約条件になる方("if(トッピング==紅しょうが) then スープ=とんこつ"のif文になる方)に色を付ける。 色は何でもよい。
制約表で「～以外」という指定を行う場合、#から始まる値を指定する。今回は「#とんこつ」で「とんこつスープ以外」を指定している。
*(ワイルドカード)も使用できる。ワイルドカードは部分一致する条件の指定に使用する。
なお、残念ながらワイルドカードのみの指定はできなかった。

実行結果。

• トッピング＝紅しょうがはスープ=とんこつとの組み合わせのみ出力されている
• トッピング＝すりおろしニンニクはスープ≠とんこつの組み合わせのみ出力されている
• スープ＝とんこつの茹で方はカタ、バリカタのみ出力されている

「ありえない組み合わせを試験パターンから除く」ための指定なので、「該当のパターンを指定されたらエラーにする」ような試験では使用しないよう注意。

応用

問題内容。
問題には記載がないが、ブラウザのパターンも組み合わせに入れる。

自分が作成したもの。

他の参加者が作成したシンプルな回答。
自分が作成したものと比べると、こっちの方がすっきりして見やすい。レビューもしやすそう。

PictMasterのマニュアルを見ると、他にも色々機能があるっぽい。

今まで組み合わせテスト作る時は、マトリクスで組み合わせを検討してたけど、こちらの方が簡単だし、パターンの抜けがないので便利。 次の組み合わせテストの項目作成で使ってみよう。

UX仙台 デザイナーが大事にしていること に行ってきました

2014/11/15のUX仙台のレポート。

チームで協業するための、共有のしかた (フジタジュンコさん)

過去

デザインチームが話を聞いた時点で開発期間はもう決まってたりする。
前工程で遅延が発生してても、〆切は変わらない。
デザイナーはその短い期間内で徹夜してでも頑張って終わらせる。

なのに、
「この通りに作ってくれればいいから」と言ってたのに、出来上がったら
「何か違うんだよねぇ。。」と言われたり、
全部作り終わって、テストに入ろうという時になって、
「偉い人がダメって言うから直して」と言われたりする。

死にたい...

なぜこうなる？

「この通りに作ってくれればいいから」の何が悪いかというと、意図を全く伝えていない。
そうなるとアウトプットもいいものが出来ない。指示が明確でないものをデザイナーは表現できない。

お客様に検証するための指標がない。
指標がないので、偉い人が「これじゃダメだよ」と言った事をそのままデザイナーに返す。

どうすれば？

全体を見ることが必要。

Webを作るといった時、製作者はWebだけ考えて良い物を作ろうとしてしまう。
ユーザは「何かをしたい」「何か欲しい」ためにWebを触る。
ユーザに価値を提供する媒体としてWebがあり、ユーザはWebではなく「Webを通して得られる体験」にお金を払う。
全体の流れの中にWebがあることを理解する必要がある。

ユーザに届ける価値が一番大事。
ユーザが「お金を払っても良い」と思える価値は何か？

チームでコンテクストを共有する。
全体でコンテキストを共有しないと最高のものを提供することはできない。

全体を見て協業するためにやってきたこと

インセプションデッキ

良かった点

• コンパクトなので、共有がすばやくできる。
• キャッチフレーズを作ると、Webサイトでそのまま使える。
• ミーティング１～２回で作れる

悪かった点

• どの程度具体的にすればよいのかが難しい。
• 大きいプロジェクトだと、内容がざっくりすぎて、何回も作る羽目になった。

大規模なプロジェクトでは難しいが、中規模、小規模のプロジェクトでは有用。
インセプションデッキを使用することで、ユーザが何を求めているか？
我々のサービスがどうアプローチ出来るかを共有する事が出来る。

ビジネスモデルキャンバス

良かった点

• チーム外の活動(営業、マーケットの動き、エバンジェリストの活動等)を洗い出す事ができた。
• 顧客にもたらす価値を共有できた。
• コミュニケーションのポリシーまで決められた。

悪かった点

• 時間がかかる。(以前のプロジェクトでは１週間くらいかかった)

デザインコンセプトを作る時には有効。
他にカスタマージャーニーマップも参考になる。

ペーパープロトタイピング

UI設計書の前にペーパーでプロトタイピングしたもの。
UIするデザイナーとのやりとりに使っていた。

社内でテスターの人を呼んでペーパーで使い勝手をテストしてもらう。

良かった点

• ペーパーで一旦テストしているので、後で「この画面使えない」という事はなかった。
• テストとデザインを別立てで走らせられる。デザイナーを待たせないで済む。

悪かった点

• 工作に時間がかかる。
• 学習コストが高い。
• 紙は動かないので、インタラクション設計を別にする必要がある。

画面遷移がそれほど多くないものであれば、紙に書いたものをデザイナーに渡すだけで、デザイナーは割とやれる。

気を付けている事

全体を見て共有する事によるメリット

プロジェクトが始まった時点ではみんな「よいもの」を作りたいと思っている。
職歴、立場等で、「よいもの」がずれてくる。
「ユーザにとって」よいものを作るために上記の手法は有用。

デザインワークをスムーズにする、共有のしかた (井上亜津奈さん)

デザインはふわっとしたモノととらわれがち。

なぜこのデザインにしたか、デザイナーは常に答えを用意しておかなければいけない。
クライアントは説明の方にお金を払っている。

デザインの目的は課題の把握と解決。
デザインで何ができるかを考えて、具体的な方法を提示する。
主観やセンスで片付けられるものではない。

デザインの現場でよくある事

でも、お客さんは悪くない。当たり前の事。

お客さんに分かりやすいものを提示して誘導するのもデザイナーの仕事。
明確なイメージを一緒に探らなければ迷路に迷い込んでしまう。

まず、ビジネスやサービスの目的を理解すること。

デザインに出来ない事も理解しておくこと。
「検索で常に上位に来る」とかはデザインでは出来ない。

トーン＆マナーを作る

トーンとは、企業やサービスがもってる「らしさ」の事。
トーン(概念)をルール化したものをトーン＆マナーという。

トーン＆マナーを作るときはターゲットが大切。

デザインの前に表現の方向性の共有を行う。これでデザインが楽になる。

ヒアリングでは世界観を表すものだったら何でも(雑誌、サイト、ブランド等)いいので聞く。

ユーザのヒアリングに有効な手法

言語マトリクス

ユーザヒアリングの中で出てきた抽象的なワードを拾って言語マトリクスを作成し、どのあたりを狙うかを考える。
競合の会社がマトリクス上どのあたりに位置するかをポイントし、そのあたりは外すという事も出来る。
お客さんも参加しやすいというメリットがある。

カラーリング

こんなキーワードで、こんなターゲットで、こんな組み合わせはどうでしょう？ と提案する。
カラーは世界を決めてしまうものなので大切。

イメージボード

世界観を表す画像を集めたスクラップブックのようなもの。
手間はかかる。
お客さんとイメージ共有を手っ取り早くするために使用する。

サンプルサイト

見えるものに引っ張られてしまうという弊害がある。
見せたサイトと全く同じものを作ると思われたり、イメージではなくガワの話に終始する危険性がある。
使えるかはお客さんに依る。

ワークショップ

２チームに分かれてのデザインワークショップ。
自分のチームは、ずんだPRのためのWebサイトリニューアル企画検討。
(課題内容書いた紙を持ち帰るの忘れた orz)

ワークショップの内容

1. 依頼内容の確認。
2. 依頼内容を元にお客様にヒアリング。(ヒアリングシート無くしたので写真なし。)
3. ヒアリングした内容から、企画検討。
4. プレゼンのボードを作成し、お客様(相手チーム)にプレゼン。

企画検討

良かったところ

• 企画検討のとき、アイデアを各自が発言しながら付箋に書いて貼っていくのは良かった。(誰か一人が記載するより早い。人の発言を聞きながら自分の手を動かせる)
• 企画検討で、対象の情報をググって、アイデアのヒントになる情報を探すのは有効。(「ずんだは仙台七夕あたりからお盆までが繁忙期」という情報から、七夕祭りとファッションショーを関連付ける案が出た。)
• いまいちだな、と思ってもとりあえず出してみる。他の人がそのアイデアを膨らませてくれるかも。
• アイデア出しのとき、「否定しない」事は大事。人のアイデアで「いまいちだな」と思っても、「このアイデアの活かせそうなところは。。」という方向で考えて、アイデアを発展させることが出来た。

悪かったところ

• お客さんへのヒアリングが難しかった。抽象的なイメージを聞くためにどんな質問したら良いか分からなかった。今ブロク見返して、言語マトリクスとか使ってみても良かったと思ったり。

自分のチームで作成したプレゼンボード。

作成した後に思ったのが、「ユーザの発言全てに応えようとはしなくて良い」事。
お客様の色々な立場の人が、それぞれの立場から意見を出してきたら、その中には相反する要望、実現出来ない要望、単なる思いつきの要望も入ってるはず。
なので、要望全てに応えようとするのではなく、要望をヒントに方向性を決めて、その方向性に沿って提案をする事が大事。
自分も含めて、プログラマーは言われたことは全て実現しないといけないという考えになりがちなので、この視点は意識しないといけない。

デザインにもアジャイルの手法が有効な事が分かったのは面白かった。

アジャイルサムライ−達人開発者への道−

IntelliJでスネークケースとキャメルケースの切替

IntelliJで、変数のsnake_case⇔CamelCaseの切替(Eclipseだとctrl+alt+kで出来る)をどうやってやればよいか調べたのでメモ。
Plugin入れないとダメらしい。

試した環境は、IntelliJ IDEA 12.1.6、Windows7 Professional。

導入手順

1. JetBrains Plugin Repository :: CamelCaseをインストールしてIntelliJ再起動。
2. 切替する単語にカーソルのせて、Shift+Alt+uで切替。押す度に切り替わる。

is_readable という単語を切り替えてみると、

• IS_READABLE
• IsReadable
• isReadable
• is_readable

というように切り替わる。

Pythonのデフォルト引数にハマった

Python初心者がハマるポイントにしっかりハマってしまったので記録残しとく。

Pythonの関数引数にはデフォルト値が指定できる。
時刻指定する関数で、引数省略時は現在時刻を取得する関数を作ろうとした。

import time

def tim(t=time.time()):
    print(t)

if __name__ == "__main__":
    tim()
    time.sleep(1.25)
    tim()
    time.sleep(1.4)
    tim()

が、このtim関数を実行すると、同じ時間しか取得されない。

C:\>python.exe time_func_test.py
1414077198.46061
1414077198.46061
1414077198.46061

このデフォルト引数の値はモジュール評価時に決まるようで、一度関数を実行すると、後は決まった値が使用され続けるらしい。
上記の関数ではやってないけど、デフォルト引数にリストなどの可変オブジェクトを渡して、処理内でリストを更新すると、次の関数コール時は更新したリストが渡されてしまう。

元々やりたかった処理は、以下のような処理で実現した。

import time

def tim(t=None):
    if t is None: t=time.time()
    print(t)

if __name__ == "__main__":
    tim()
    time.sleep(1.25)
    tim()
    time.sleep(1.4)
    tim()

実行結果。毎回値が変わるようになったのでやりたいことは出来たっぽい。

C:\>python.exe time_func_test.py
1414078025.345443
1414078026.595514
1414078027.997595

参考：
Python初心者によるPythonのいいところ、はまりどころのまとめ - Webtech Walker

ExpectedExeptionを使ってみる

JavaでExceptionが発生する事を検証するテストは以下のように書く事が出来る。

    @Test(expected = IllegalArgumentException.class)
    public void Exceptionの検証() {
        throw new IllegalArgumentException("このメッセージは検証できない");
    }

ただ、このテストケースでは、意図したExceptionが発生する事は検証できるが、そのExceptionの内容の検証を行う事が出来ない。
Exceptionの検証にExpectedExceptionクラスが使えるという情報を貰ったので使い方を確認。

使い方

1. @Ruleアノテーションを付与し、ExpectedExceptionクラスのインスタンスを取得
2. テストケースの先頭で、Exceptionについて検証する内容を設定
3. Exceptionが発生する処理を実行

サンプル

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;

import static org.hamcrest.Matchers.endsWith;

public class ExpectedExceptionTest {
    // @Ruleを付加するフィールドはpublicフィールドとする
    @Rule
    public ExpectedException expected = ExpectedException.none();

    @Test
    public void ExpectedExceptionを使ったException検証() {
        // 検証する内容を設定
        expected.expect(IllegalArgumentException.class);
        expected.expectMessage("sample");   // 部分一致検証
        expected.expectMessage(endsWith("exception"));

        // Exceptionが発生する処理を実行
        new SampleClass(null);
    }

    static class SampleClass {
        SampleClass(String str) {
            if ( str == null ) {
                throw new IllegalArgumentException("sample exception");
            }
        }
    }
}

このコードで、Exception#getMessage()の内容を検証する事が出来る。
なお、ExpectedException#expectMessage(String)メソッドは部分一致の検証である事に注意。

JUnit実践入門にも載ってた。

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

TDDBC仙台 4thに行ってきた

昨年に続きTDDBC仙台に参加してきました。
@t_wadaさん、スタッフ、および参加者の皆さん、どうもありがとうございました。

当日のtogetter
TDDBC仙台 4th - Togetterまとめ

基調講演

@t_wadaさんによる基調講演。
講演資料は後日SlideShareにアップするとの事。

TDDの目標

動作するキレイなコードがTDDの目標。
テストコードが存在することで、改善が可能になる。

ソフトウェア工学は予測性が低い。コードを書き始めることで初めて問題に気がつくことが多い。
なので、完璧な設計をしてから実装を始めるのではなく、とりあえず実装し、きれいなコードにするのはその後にする。TDDはその手助けをしてくれる。

TDDのサイクル

1. 目標を示すテストコードを書く
2. テストを成功させるプロダクションコードを書く
3. プロダクションコードをリファクタリングする

このサイクルが重要。
納期等の理由でリファクタリングされなくなる事があるけどちゃんとやりましょう。

テストコードのメンテナンスコストが高いと、「テストコード修正が大変だからプロダクションコードの改造はしない」という本末転倒な事になる。
なので、テストコードにもリファクタリングが必要。
プロダクションコードと同じく、テストコードもDRYにする。コピペしまくったりとかやってはいけない。

TDDを導入することで、実装時間は2割弱増えるが、その後の不具合検出数が減るため、トータルでの開発工数は減る。

TDDの対象範囲

テストの目的は対象によって異なる。
TDDはDeveloper Testing。開発者の開発促進が目的。

TDDの"T"はTestというよりCheckingに近い。(TDDはプロダクションコードが動作する事の確認でしかないため)
要件のテストとして、BDDという方法も出て来ているが、RSpecを使用したBDDとScenarioを使用したBDDの二派に別れているのが現状。

テストを動かすだけでは品質は上がらない。テストは品質を明確にするだけ。
品質を高めるのはリファクタリング。
体重計に乗っただけでは体重は減らないのと同じ。

なぜTDDをするか

「動いているコードは触るな」とは今は言えない。
コードを触らなくても周り(OS、フレームワーク等)が変わっていく。直さざるを得ない。
何もしなければコードは腐っていく。

テストコードがあることで、コードへのフィードバックが即座に得られ、書いたコード、これから書くコードに自信が持てる。

TDDライブデモ

@135yshrさんと@nnasakiさんによるgo言語によるライブデモ。
go言語は全く知らなかったけど、@135yshrさんのIDE(Sublime text)の使いこなしに感心したり、「テストコード書くのにコピペは使わないようにしてる」の発言になるほどと思ったりしながら見させて頂きました。

昼飯

はらこめし。うま。

ペアプロ

昨年に続きJavaで参加。
Pythonやりたかったけどペア居なかった。。

課題と自分らのチームで実装したソース

TDD Boot Camp(TDDBC) - TDDBC仙台04/課題
実装ソース

感想KPT

Keep

• IntelliJコーディング楽しい。
• 「あれどうやるんだっけ？」と詰まった時に備えて「JUnit実践入門」持っていったのは正解だった。
• GitHubでコード共有して演習進めたのは、お互いに自分のマシンが使用できて効率良かった。
• コードレビューで、設計や改造について、色々なチームの意見が聞けたのが面白かった。

Problem

• GitHubの使い方あんまり分かってなくてペアの方に世話になりっぱなしだった。
• テストコードのリファクタリングやったとき、リファクタリング後のテストが動作するかの確認が雑だった。
• 仕様追加時、作成済みテストコードの作り直しが多く発生した。実務で既存コードの修正量を抑える方法をもう少し考えた方がいいかも。

Try

• ExpectedExceptionでExceptionの検証を行うテストが書ける事を教えてもらったので、後で機能確認しておく。
• 残りの演習やってみる。

QAとか

和田さんへの質問と回答。

Q) 基調講演の中で、プロダクションコードとテストコードの比率が同じになるような例が出ていたが、テストコードはそんなに減らせるものなのか？
A) プロダクションコードとテストコードの比率が1:1になるようにリファクタリングし、プロダクションコードとテストコードの比率が1:1～1:2の範囲に収まるようにする。
この比率を超えるようならテストコードの見直しが必要。

Q) テストコードで、Mockは使うべきか、使わないべきか？
A) Mockは使う派と使わない派がいるが、@t_wadaさんはMock使わない派。
実物のコードが使えるなら、出来るだけ実物を使うようにしている。実物のコードを使うことで時間がかかるのは仕方ないと考えている。

最後に

テスト書きましょう。

pipのインストール（Python3.3 Windows7)

Windows7の環境でpipをインストールしたときのメモ。

参考：python - How to install pip on windows? - Stack Overflow

環境

• OS：Windows7
• Python：Python3.3.4

手順

get-pip.pyをダウンロード

https://raw.github.com/pypa/pip/master/contrib/get-pip.py
からget-pip.pyをダウンロードして保存する。拡張子は.pyで。

コマンドプロンプトからget-pip.pyを実行

なお、Pythonのインストール先をProgram Files配下にしている場合、コマンドプロンプトは管理者権限で起動する必要がある。

C:\>python C:\Downloads\get-pip.py
Downloading/unpacking pip
Downloading/unpacking setuptools
Installing collected packages: pip, setuptools
Successfully installed pip setuptools
Cleaning up...

これで、Pythonインストールディレクトリ下のScriptsディレクトリにpipコマンドがインストされる。
PATH環境変数にこのディレクトリを追加しておけば、コマンドプロンプトからpipコマンドが実行出来る。

(後日追記)

Proxy配下でのpipインストール

Proxy配下の環境では上記手順だとインストール出来なかった。
公式のPythonの代わりにnimicondaをインストールした環境で、以下手順でProxyの設定を行ってインストールした。

C:\>set HTTP_PROXY=http://ID:PASS@PROXY-HOST:PROXY-PORT
C:\>conda install pip
Fetching package metadata: ..
Solving package specifications: .
Package plan for installation in environment C:\Programs\Miniconda3:

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    conda-3.7.1                |           py34_0         201 KB
    pip-1.5.6                  |           py34_0         1.3 MB
    requests-2.4.3             |           py34_0         607 KB
    setuptools-5.8             |           py34_0         738 KB
    ------------------------------------------------------------
                                           Total:         2.9 MB

The following NEW packages will be INSTALLED:

    pip:        1.5.6-py34_0
    setuptools: 5.8-py34_0

The following packages will be UPDATED:

    conda:      3.7.0-py34_0 --> 3.7.1-py34_0
    requests:   2.4.1-py34_0 --> 2.4.3-py34_0

Proceed ([y]/n)? y

Fetching packages ...
conda-3.7.1-py 100% |###############################| Time: 0:00:01 160.19 kB/s
pip-1.5.6-py34 100% |###############################| Time: 0:00:04 328.15 kB/s
requests-2.4.3 100% |###############################| Time: 0:00:01 501.35 kB/s
setuptools-5.8 100% |###############################| Time: 0:00:08  84.44 kB/s
Extracting packages ...
[      COMPLETE      ] |#################################################| 100%
Unlinking packages ...
[      COMPLETE      ] |#################################################| 100%
Linking packages ...
[      COMPLETE      ] |#################################################| 100%

pip実行する時もproxy指定が必要。

C:\>pip install pycrypto --proxy=http://ID:PASS@PROXY-HOST:PROXY-PORT

参考：
Windows & プロキシ配下でPythonを開発する君へ - Qiita
Installing Python's easy_install using ez_setup.py from behind a proxy server - Stack Overflow
pythonメモ proxy下でのpip、easy_install - Qiita