yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

2018/02/04 TDD体験的なワークショップに参加してきました!

ふとしたご縁で(ただただ押し掛けただけなんですが…w)
テスターちゃん作者Mさん、のご友人のYama Kenさん主催のワークショップに参加してきました。
(大分遅くなったけど…)以下、内容と感想です。

※主催者の方のこのワークショップのエントリ
欠陥プログラマーの整備手帳 — ワークショップ@博多

■開催概要

日時: 2018/02/04
参加人数: 3人

ワークの内容

ワークの流れ

  1. ワーク1
    1. お題のプログラムについて、テストを考えずに実装する
    2. ↑を参加者が持ち回りで探索的テストする
    3. それぞれがテストした結果を共有する
  2. ワーク2
    1. 1.2や1.3をもとにテストケース&テストデータを作成する
    2. 2.1のテストコードを作成した後、お題のプログラムを作成する

お題【マイヤーズの三角形】

  1. ユーザーが3つの整数を入力する。この3つの整数は三角形の一辺の長さを表す
  2. 3つの整数から、「不等辺三角形」「二等辺三角形」「正三角形」を判定してメッセージ出力プログラムを作成する
  3. それぞれの三角形のメッセージは英語表記とする
  4. 不等辺三角形(Scalene triangle)
  5. 二等辺三角形(Isosceles triangle)
  6. 正三角形(Equilateral triangle)
  7. クラス「Triangle」を定義し、実装すること
    ※使用するプログラミング言語は自由

■ワーク1について

お題のマイヤーズの三角形は、そもそも知ってたのと、 "テストを考えないで"っていうのがなかなか、難しいなぁ…と思いました。
なので、初めてマイヤーズの三角形に出会った時の感覚と、学部生時代のころを思い出して プログラムすることにしました。出来上がったコードが以下です。
※私が選択したのはJavaScriptです。

<html>
<head>
<title>マイヤーズの三角形byモンキー!</title>
<script type="text/javascript">
function Triangle( line1, line2, line3 ){
  if( line1 == line2 & line2 == line3 ){ 
    return "Equilateral triangle" ;
  }
  else if ( line1 == line2 | line2 == line3 | line3 == line1 ){ 
    return "Isosceles triangle" ;
  }
  else { //Scalene triangle
    return "Scalene triangle" ;
  }
}
function disp(){
  line1 = window.prompt( "三角形の1辺を入力してください①", "" );
  line2 = window.prompt( "三角形の1辺を入力してください②", "" );
  line3 = window.prompt( "三角形の1辺を入力してください③", "" );
  alert( Triangle( line1, line2, line3 ));
}
</script>
</head>
<body>
<p><input type="button" value="三角形識別!" onClick="disp()"></p>
</body>
</html>

ワーク1 感想

一応補足すると、もちろん、三角形が成り立たないことがあるとか、入力されるデータのチェックが必要とか… そういうのはわかっておりますw(念のため)

プログラミング学びだしたころぐらいまで感覚を戻しまくって、 ただお題だけを読んで「よっしゃこんなん簡単やで!」っていう思考で、 特に調べることなどせず、辺が全部一緒なら正三角形、 2つ一緒なら二等辺三角形、全部違うなら不等辺三角形! という考えを疑うことなくプログラムをした。
という感じでした。
その結果なんですが、とりあえずIF文で辺を比較したらそれでいいだろう、という思考になりました。
コードができた後に、「0が入力されたら」とか、「マイナスがにゅうりょくされたら」とかそういうのを考えました(時間がなかったので実装はしてないです)

そしてお二方に動かしてもらったんですが…まぁバグいっぱい出してくださいましたw
正常系以外バグしか出ないですしね…。これ。
だいぶ楽しんでくれてて、ある意味いいもの作った感でしたw

■ワーク2について

事前に作成したテストケースは以下です。

・テストケース(32ケース)
正三角形の確認(1パターン)
二等辺三角形の確認(3パターン)
不等辺三角形の確認(3パターン)
三角形が成り立たない(6パターン)
全角文字が入った時にエラーとなること(3パターン)
半角英字が入った時にエラーとなること(3パターン)
0以下が入ったときにエラーとなること(3パターン)
小数が入ったときにエラーとなること(3パターン)
入力が最大値を超えた時にエラーとなること(3パターン)
先頭に0がついた時、エラーになること(3パターン)
空白の時、エラーになること(3パターン)

ワーク2感想

プログラム書く前の、テストコードを手で書いていくのが大分辛かったですw
3人とも頑張ってテストコードをただただ手打って…苦行でした。。

だけど、テストコードを書き終えた後は、待ちに待ったプログラムができる! ってかんじで、みんな楽しみながらプログラムしていて、良い感じでした。
一応ルールとして、テストケースが全部Passになったら完成、というのがあったのと、 あとどの機能を実装したら完成か?というのが目に見えて分かりやすかったので、 精神的な負担が少なかったです。

■全体の感想

ワーク1とワーク2で、状況や感じたことをざっと比較すると、以下になります。

  • ワーク1
    • 先に基本機能を実装する→あとから継ぎ足し継ぎ足ししていく
    • 終わりがわからない不安感がある
  • ワーク2
    • 先にテストする項目を考える→仕様が細かく決まっている
    • いつでも動作確認ができるので、精神的に楽。
    • テストケースを終わらせていく感覚が、ゲームで実績解除していく感覚に近くて、楽しめた

最近はほとんどコード書かないですし(そもそも社会人になって開発したことないですし) プログラムを書く!っていうワークが新鮮でしたw

ワーク1であんなコード書いてますが、長崎QDGで池田さんが言われていた、 設計時に思考が狭まっていく(仕様を定めていく)っていう感覚は一応あったんですよね。
なので、ワーク1でプログラム書き終わった後、探索的テストになったんですが、 テストの思考に切り替えるのがだいぶつらかったですね。
テストする視点を広げていく、というのがなんとも難しかった。

昨年出版されたTDD本の 「テスト駆動開発」を読んではいたんですが、実際に経験してこそわかることがありますね。
また読み返そうと思いました!
本の中に、開発が予測可能となる、プログラムを書いていて気持ちがいい、
ということが書かれていましたが、まさにその通りで、 ワーク2では、先にテスト考えれてて、いつでもテストが楽に行える、っていう安心感と、
ゴールが明確化されているという、すっきりとした感じが開発中にずっとありました。

そして、普段ブラックボックステスト(+グレーボックスっぽいこと)しかしていないので、 ホワイトボックステストを経験できたのも有益でした。
こういう実装しているから、このテストはいらない、とテスト項目を削るのが新鮮でした。

そして、事前にテストを考える=仕様を明確化しているんだなぁと実感できました。
普段の業務でも少しはあるんですが…テストと開発を一緒にやることになると、更に深まった感じでした。
やっぱり静的にテストするって大事ですね

突如押し掛けてしまったんですが…普段できない貴重な経験ができたワークでした!
Yama Kenさん、まつさん、ありがとうございました!
またやってみたいですし、自分の周りの人にも経験させてあげたいなぁ…と思えるワークでした(^^)


Reference

その他

続きを読む

2018/02/02 第3回長崎QDGに参加してきました!

NaITEさん主催の、第3回長崎QDGに参加してきました。
(大分遅くなったけど…)以下内容と感想です。

■開催概要

日時: 2018/02/02(金) 12:00 ~ 17:20 場所: メルカつきまち nagasaki-it-engineers.connpass.com

togetter.com

■各講演の感想

池田暁さん:「単なる仕様チェックから卒業するために 〜最初に抑えたいキホンのキ〜」

www.slideshare.net

講演内容は、昨年の盛岡勉強会での内容をギュッとまとめて、という感じでした。
(具体的にはスライド32~94の内容でした。)
個人的に、↑の資料を見て、講演内容を聞いてみたい!と思っていたのですごいありがたかった。。。

スライドにもあるんですが、以下のように設計の思考とテストの思考は違うんだよ。

  • 設計のための思考 > 問題領域を狭めていく
  • テストのための思考 >問題領域を広げていく

っていうのが、納得感が高かったです。
(さらにこの2日後に実体験することになって、理解は深まりました。)

テストをする前に如何に気づくことができるか?
っていうところを重要視されていて、同じ感覚だなぁと思いました。
(ただ、気づくまでのアプローチも、気づいてからのアプローチも、自分は全然足りないなぁとグサリ…。)
あと、ブラックボックステストホワイトボックステストは、
技法というよりはどちらかというとスタイル、っていうのはなるほど〜となりました。

原 佑貴子さん:「速効性重視のレビュー技術:高速2パーソンインスペクションのススメ」

なんとリモートでの講演でした。
原さんの登壇が決まったのは、開催日の週ということだったんですが、 講演が決まってからツイッターが盛り上がっていたのでワクワクしながら聞きました。
(原さんが、細川さんの話によく出てこられる赤ペンの方だったというのは、講演が終わってから知りましたw)

セッションの内容は 参加者が実際にインスペクション レビューを体験するというもので、 2人組になり、唐突に渡されたFlight Planning and Management Systemのドキュメントについて 役割分担してレビューするというかんじでした。

以下は原さんの講演資料と口頭で教えてくださったにレビュー実施のコツです。

  • お菓子を用意する!
  • 自分が1ページが何分で読めるか?っていう力を持っておくべき
  • 指摘に対して「いいね!」と口にする

  • 指摘や言い換えに自信がなくてもとりあえず言ってみる
  • 事実を指摘する
(書いていないことを指摘しない)
  • 欠陥の検出に注力する(原因や解決策を議論しない)

  • 1ページ目からレビューしない(1ページ目は、書いた人が1番自身があるから)

ガツッと”レビュー”という名目なレビューを体験したことがなかったので、 ただただ戸惑うばかりでした。
ただ、2人組になった相手がなそさんだったので、指摘の仕方とかも知れて助かりました。
感謝。。

一般にはインスペクションは重たい空気になりやすいとのお話だったんですが、 今回体験したのは楽しかったなぁ〜と。

そして後半、細川さんと原さんによる生インスペクションを披露してくださいました。
ドキュメントの曖昧さに対して「これはバグですか?」という指摘が衝撃でした。
ドキュメントをレビューする段階で、「バグ」っていう言葉を使うんだなぁと。

レビューはもちろんながら、静的テストという概念を、もうちょっとチームに広めていきたいなぁと思いました。

日下部先生:「いろいろ使える(システム理論に基づく)セーフウェアのためのモデルSTAMPとその分析法」

STAMPとは「ものごとがうまくいかないことを説明するモデル」!
とのことだったのですが…
そもそもSTAMPというものを知らなかったので…個人的には難しい内容でした。。^^;

以下を読んでそもそもどういうものか勉強しようと思います。
「はじめてのSTAMP/STPA ~システム思考に基づく新しい安全性解析手法~」の公開:IPA 独立行政法人 情報処理推進機構

STAMPを活用できそうな状況として、
例えば大学教授と学生の関係において。
* 大学教授の思惑>この内容の講義をやれば学生は積極的に参加するはずだ! * 実際の学生>とりあえず参加する、そもそもやる気がない…など。

というような状況をSTAMPで説明できそうとのことでした。
このあたりを聞いて、問題分析ということで TOCクラウドやブランチにも近いのかなぁ…って思ったりもしました。

くまちきさん: 「PSP活用SIG活動報告」

というのは覚えました!w
たぶんここが一番重要(違う

PSPは、CMM(Capability Maturity Model, 能力成熟度)を開発した ハンフリー博士が提案した個人レベルでの継続的プロセス改善のしくみ!
とのことなんですが、 PSPもまた知らなかった内容なので…こちらも個人的には少しむずかしい内容でした。。。
(そもそもCMMもよくわかっていないので…勉強不足すぎる。。。

以下を読んでみようと思います!
第1章 PSPを導入する理由(わけ) ~自立したエンジニアのためのライフハック:ゼロからはじめるPSP ─Personal Software Process | エンジニアマインド … 技術評論社

金子 昌永さん:「チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング」

www.slideshare.net

金子さん、とりあえず冗談が冗談に聞こえず、普通に信じてしまいました。
「天は人の上に人を作らず…」これは忘れられないw
たぶん、僕は金子さんをお見かけするたびに、思い出すんだろうなぁと思いました。

内容について、 ソフトウェアビジネスのイメージが、わかりやすくて納得でした。
またチームの方向性や、求められる知識など、考えさせられることが多く、 現状の分析をツールも含めてやってみると、足りていないものやできていることなど分析できそうだなぁと思いました。

LT セッション

tositeさん:「いっぽんのサービスのむこうに」

www.slideshare.net

LTらしいテンポ感なLTだったなぁーとw
システムを1から全部1人で導入してていてすごいなぁ…と。
自分も研究室時代にClientからServerまで全部やって大変だった記憶があるけど、 会社で製品としてそれをするのはただただすごいなぁと思いました。
寿司とビールが同じ問題とかあるんですねぇ。
第18回 MySQLの寿司ビール問題,Pgpool-II3.6.1リリース:OSSデータベース取り取り時報|gihyo.jp … 技術評論社

caori_tさん: 「一人じゃ探せない答えを探してみたら…」

caori_tさんの発表は、ひとまず癒やされますよねw
チームメンバーとの問題解決をするのにファシリテートって大事だなぁ…とひしひしと感じでおります。
さじ加減が難しいのと、これでいいのか?がよくわからないのが最近の悩みですが…。
ゆるファシをされたい。

さとうひろゆきさん: 「テストを料理で例えてみよう」

テストの伝道師、さとうさんの、テストプロセス(開発工程も含む?)を料理で例えてみた。
というお話。
常々、さとうさんは例えるのがうまいなぁ…と思います。
テストプロセスとか自分なりに説明しようとしてもなかなかわかってもらえないんですよね。
( そもそも自分がそんなに理解できてないというのが問題ないんですが…
経験してない相手に如何にわかりやすく伝えるか?というのは重要ですよね。
自分も精進しようと思います。

細川 宣啓さん:「ソフトウェア品質レビューの全て:生い立ちから先進技術まで」

昨年、私が一番拝聴した講演者は、間違いなく細川さんなのです!が…
まさか2018年、1回目のテストイベントで細川さんの講演を聴くことができるとは…という なかなか衝撃でしたw

「いいレビュー・すごいレビューってどんなレビュー?」という、問いかけから始まったのですが 、 これは自分が「いいテスターってどんなテスター?」って悩んでいた疑問に似ているなぁと思いました。
人や状況によってだいぶ違うだろうし、難しい問いだなぁ…と。
細川さんが提示された、うまくレビューする(いいレビューをする)という1つの解としては、以下とのことで、あぁ、たしかに直してもらわないと意味ないし、どうせ直してもらうなら気持ちよくのほうがいいよなぁ…と思いました。

  • 開発者に気持ちよく直してもらうこと。
  • うまくフィードバックして、すっと直してもらえる。そして、開発者の行動が良い感じに変わること。

また、バグ分析のために、毎日バグのカルテを書いていた、というのは刺激的でした。
バグのカルテを書いて、そのカルテを自分の血や肉として、今に活かせている、と。
自分の環境的には、バグの原因まで知ることが今の状況だと難しいですが カルテをつけていってみようと思いました。

■全体の感想

参加者と講演者が近くて、良い感じの会だなぁと。
懇親会も翌日のツアーも面白かったですし!
福岡から陸路で行ける数少ない勉強会なので、来年もまた参加したいなぁと思いました。

そして、長崎、とても美味しかったです(´▽`
f:id:yoshitake_1201:20180304000722j:plainf:id:yoshitake_1201:20180304000733j:plainf:id:yoshitake_1201:20180304000742j:plainf:id:yoshitake_1201:20180304000749j:plain

Xocde : AutoLayout > TabView & NavigationBar付きTableViewで背景にImageViewを使ったら、Layoutが崩れまくったので、その時した対処(メモ)

ひょんなことから、知人のお店アプリを以下の仕様で作成することになった。

  • 環境
  • Xcode8 & Swift3.0
  • 仕様(超ざっくり)
  • TabViewでページを切り替え
  • TableViewで店舗一覧表示
  • 店舗一覧で店舗をTapすると、詳細ページに行く

でもXcode 触るのもSwift書くのも1年以上ぶりで(そもそも当時もそんなにかけるほど触ってない)どうしようかと悩んで本屋に赴いたところ、すごく参考になる本が!

TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応

TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応

自分がやりたい機能がほぼほぼ書かれていて、実戦向き&それでいてわかりやすい。 (自分は使わなかったけど、書籍内ではAPIを使用して TableViewに店舗一覧を表示することを実現していました。) Xcodeの使い方、Swiftの説明、AutoLayoutを使ったアプリ開発Apple申請の仕方までこの一冊は本当にすごく重宝しました。


しかし問題が…。 Navigation BarつきのTable ViewとTableの詳細ページの背景に画像を使用しようとAuto Layoutを使用してImage Viewをおいたところ、まぁずれる。ずれる。 ↑の本のおかげで、昔から苦手だったAutoLayoutと仲良く慣れたと思ったのに。 ※ちなみに↑の本には、Image ViewをAutoLayoutを使用して背景にする使い方は書かれていませんでした。 自分の力不足としか言いようがない。

んで結果とりあえずどうしたかというと、

qiita.com

chocoffee.cafeblog.jp

onga-tec.hatenadiary.jp

上記のサイトを参考に背景のImage Viewだけ viewDidLoadで呼び出すということで解決。・゚・(ノД`)・゚・。 きっといつかAutoLayoutで実現してやる!

ちなみに参考サイトではSwift2.0以前っぽくて、CGRectMake が使われているんだけど、Swift3.0では使えなくなったみたいで…。 でもソッチのほうがすぐ解決できました。

    // TableViewがあるViewControllerのviewDidLoad()
    override func viewDidLoad() {
        super.viewDidLoad()
        let bgImageView = UIImageView(frame: CGRect(x: 0, y: 0, width: self.tableView.frame.width, height:self.tableView.frame.height))
        let image = UIImage(named: "background_image.jpg")
        bgImageView.image = image
        bgImageView.alpha = 1
        self.tableView.backgroundView = bgImageView
    }
    override func viewDidLoad() {
       // TableView からshowdetailで遷移したViewControllerのviewDidLoad() に 以下を追加
        UIGraphicsBeginImageContext(self.view.frame.size)
        UIImage(named: "background_image.jpg")?.draw(in: CGRect(x: 0, y: 0, width: self.view.frame.width, height:self.view.frame.height))
        let bgImage: UIImage! = UIGraphicsGetImageFromCurrentImageContext()
        
        UIGraphicsEndImageContext()
        self.view.backgroundColor = UIColor(patternImage: bgImage)
    }

ブログ始めた

今年はいろいろチャレンジしよう!
ということでブログを始めてみました。

 

福岡でソフトウェアテスターやってます。
基本的には、自分のやってることまとめたり、疑問に思ったこと書いたり、
業務で役立ちそうなまとめとか…書いていく方針です。
かけそうならイベントの参加感想とか、そういうのを書いていければと思ってます。

2週に1回とか更新目標でがんばってみよう。