コードがあたり前の世界
世界を変えよう。アップルによるキッズ向けコーディングワークショップ : ギズモード・ジャパン
の記事を読んで思ったこと。
世界を変える手段はコードだけじゃないだろうけど、もはやプログラミングスキルは義務教育レベルに当たり前スキルになってくるとしたときに、自分の子供に教えてあげられる(可能であればレベルの高いものを優しく)ようになってたいし、一緒にプログラミングを楽しめるようになりたい。
例えば今、年齢高い人でPC使えない人って、どこかであきらめたんだと思います。私には無理だから。あるいは(それまでの)仕事をやる上で必要ないから。でも現実的にそゆ人は組織の生産性を下げてると思います。
これは”使う”話ですが、今後は”作る”のが当たり前な世界になるんじゃなかろうか。例えば自分に期待されるアウトプットがメールやエクセルじゃなくてコードになる。営業も経理もデザインすらコードになる、みたいな世界。
chromedriverの時に --ignore-certificate-error を消したい
- Ruby2.0.0 + SeleniumWebDriver
- chromedriver でブラウザを立ち上げると「サポートされていないコマンドライン フラグ --ignore-certificate-error を使用しています。これにより、安全性とセキュリティが損なわれます。」ていう警告文出る。
- これを消したい
- http://qiita.com/zaburo/items/5d98d51fc3ab4f44db1d にてjavaでの対応方法がわかって嬉しい。
- が、rubyに置き換えられない(スキル不足という意味で)
- これによると何かに「test-type」を設定するようだ
- http://peter.sh/experiments/chromium-command-line-switches/#test-type
- ↑ここにtest-typeの説明があるが、設定の仕方がわかんないお。
- https://sites.google.com/a/chromium.org/chromedriver/capabilities
- ↑ここにたどり着いて、ひとまずコピってやってみた。
require "selenium-webdriver" caps = Selenium::WebDriver::Remote::Capabilities.chrome("chromeOptions" => {"args" => [ "--test-type" ]}) driver = Selenium::WebDriver.for :chrome, desired_capabilities: caps driver.get("https://www.google.co.jp/")
Before
After
めでたしめでたし。(それによりどんなことが起こるのかよくわかってないけど)
ヒンシツ大学 Evening Talk #01 ”高橋寿一氏とアジャイルとテストを語ろう に参加してきた
- プログラムの話じゃないですが、表題の勉強会に参加してきました。
- 初めてSHIFT社にお邪魔しましたが、キレイなスペースで素敵空間でした。
- 写真NGとのことなので残念。
ヒンシツ大学 » 先着50名様！【無料開催】高橋寿一氏とアジャイルとテストを語ろう！
自分の感想
探索的テスト、、、楽しそうだけど「上手にやる」のは難しそうだな。
探索的テストのスキルの伝達方法
- (探索的に関わらず)なんでその人は見つけるのか。本人も説明できない。
- 出来る人を育てる、増やす、に関しては時間が掛かりそうだし、何をもって「できる」とするのかも定義は難しい。
- 重要度の高いの不具合を多く見つけた人、とかかな。
- ある期間やってみて圧倒的に差がつくようであれば多分その人はできる人。
探索的テストの前に、開発者レベルでの「最低限の品質が担保できていること」が前提
以下、勉強会時のメモ
マイクロソフトの25年位前
- MSでは開発者：開発40%、テスト40%、UIとか20%だった
- そこから、よりスピードが求められた
- 上流工程のテストに移行＋探索的テストに移行
旧来のテスト
- 網羅的＝全機能ちゃんとチェック。かつ、機能の組合せ
- →網羅度が品質基準になる、を厳密にやる
- お金がかかる＝品質に関わる投資はどんなプロジェクトでも50%を超える
- →
- 時間がかかる＝最初のリリースから数ヶ月のテストしてませんか？
- →お金がある大企業ではお金がかかるより時間がかかるのがいや
軽いソフトウェア、重いソフトウェアで同じテストでいいのか？
- よくないよね。
クラウドアジャイルの新しいテストとは？
- 早い
- 安い
- そこそこの品質
ビジネスで勝たないと意味が無い。
- 旧来のやり方でメリットがあるのかどうか。
提案する新しいテストのスタイル
- TDD＋探索的テスト
- TDD：
- 開発者による網羅的テスト
- QAではなく開発スピードを上げるための手法
- 仕様変更に耐えながら「最低限の」品質を担保する
- 探索的テスト
- 探索的テストvsテストケースベーステスト
- →探索的テストは有効、なグラフ (開発品質によるよね？)
- 探索的テストは「スキルがあるテスターが」やらないと効果は低い
探索的テストとは？
- ソフトウェアテストの「スタイル」
- 個人に自由意志を持たせるとともに責任をより明確んする
- 一個人のテスト活動
- ↑メモが追いつかなかったので
- http://sssslide.com/www.slideshare.net/goyoki/ss-34292539 のP10から引用
- Cem Kanerによる探索的テストの定義
- ソフトウェアテストのスタイル
- テスター一人一人の自由意志と責務に基づく
- 各々の価値の合わせて洗練されていく
- テスト関係の学習、テスト設計、テスト実施、テスト結果の説明を扱う
- プロジェクトを通して並行実施される補完的な活動
やってることは
- ソフトウェアを理解する
- ケース設計
- ケースの\実施
- の3つを同時実行する → つまりこれらを説明、書き出すことができない人には探索的テストをやらせても効果は低い
同時実行なので一つ一つのテストケースは書かない
- 書いても見ない(実施者が自分だから)
- 何のために書くのか？
- そんな暇があったらテストしようぜ → テストケースを書く時間は全体の半分くらい？
過去はテストケース数に対していくつ消化したか、で品質を判断していた
- １０００ケースのうち、９９９ケースやったらから出荷していいのか？
- ケースは品質を代表する指標なのか？
- それよりは、スキルのあるテスターが「品質を担保するために」ユーザーケースを考えてテストする
- 仕様に変更があるたびにケースを修正する時間があるなら、テスターがそれも含めてテストする
- ソースコード量は増えている。コピペ。
- テスト実施者の生産性はそんなに上がらない
従来のテストケースベースのテストをネガティブに言うと
- ケースは時間がかかるしめんどうだから書かない、だったらテストする時間にしよう
- だいたいどこにバグが有るかななわからない 触ってみる
- 回帰テスト：スキルのあるテスターが変更箇所を考えてテストすることでバグが見つかる
要求仕様（ドキュメント）は間違いと言うより記述されていないものがバグになる
- エスカレータの例
- 靴を履いてください
- 犬を抱いてください ←犬を買ってこないとならない
テストケースがあるとテストケースしかやらない
- テスターはそれだけやることが自分の仕事、になる。
探索的テストの本
- 探索的テストのPass/Fail基準
- アドホックでもいいかげんでもランダムでもない
- ちゃんとストラテジックに行うもの
- マネージャが部下のテストアクティビティを理解する（何をやったか、ではなく）
- どのコンポーネントに対して、どの品質特性を担保するのか、を定義する
- 機能性｜○○したら合格｜○○したら不合格｜
- 安定性｜ ｜ユーザーが目的を達せられない
- 対象ソフトウェアはWindowsOSを不安定にさせない、とか
- ↑この辺りは↓この本に詳しく載ってそう
探索的テストのプロセス
- 製品の目的を明確にする
- 重要機能リストアップ
- 機能を明確にする（役割分担
- 弱いエリアを叩く ←わかりきってることはテストしない（誰かが気づく)
- 理論的には継続開発では７％のファイルからすべてのバグが見つかる (２０１０年くらいの情報)
- テスト実行およびバグを記録する
- 上記を継続して実行する
- ↑この辺りも↓この本に詳しく載ってそう
JamesWhittakerのアイディア
- ソフトウェア
- └入力処理
- └計算
- └出力処理
- └データ保存
- ソフトウェアは上記の4つしかしない。
- ケースを考えるときにはこれを考える
タスクシートを書く
- タスクの記述：なにをやろうとしているのか（何を担保するため？
- 探索アプローチガイド：どのように進めていくか。どんな値を入力するか、どんな操作をするか、どういう考えですすめるのか
- 結果：どういう品質のものがリリース可能か
- 終了基準：どのように終わらせるか。どうなったら終わりと判断するのか。
探索的テストとは「スタイル」。メソドロジーじゃない。
- 結果がきちんと報告できる必要がある
- この値は境界値。この値はディシジョンテーブルでやりました。
- 正常ステート、異常ステートを確認しました
- 入力データは正常、異常を確認しました
- こんなバグがでて、修正され、回帰テストを行い、問題なかったので出荷OKです。とか。
スキルのあるテスター
- ねらった品質を担保するために適切な手法が使えること
探索的テストの欠点
- 素人がやるのはダメ
デベロッパーとテスター
- が並んで、デベロッパーが実装の仕方、仕様を話しながら、隣でテスターがテストする
- こういうときにエラーハンドリングするから、やってみて
- とかは効果を発揮した。
注意点
- 100％探索的テスト頼っちゃだめ
- トレーニングを十分に受けたテスターがやる
- コードを書く人のできる人できない人差は26倍。
- テストの場合は10倍くらいと思ってる
- 非機能テストについては探索的テストの効果はビミョウ
マイクロソフトの実験
- 未経験者 １０％のバグを発見
- 教育を受けた人 ６５％のバグを発見
MS時代
- ファーストビルドが動くようになるまではみんなで遊ぼうよ
- (テストが無駄になるから開発者自身で使ってみる)
ファーストビルドが動くまでは開発者が担保する
現状はドキュメントも揃ってない、仕様変更も起こる、最新が何なのかわからない、、、
- これが「あたりまえ」の時代になってきている。それでもリリースしなければならない状況。
- その状況でも耐えうるテストが必要
質疑応答
- テストエンジニアの地位
- MSではコンピュータサイエンスを学んできた人じゃないとテストエンジニアになれない
- PM、開発者の１０％～２０％低いくらいの給与
- ポジションが明確に存在するので転職しやすい
- 日本はプロジェクトマネジメントエンジニア、テストエンジニアの地位が不明確
- ちゃんとスキルをもって労働市場にでれば、企業はほしい
現場で探索的テストを活用している例
ある会社の例
- 1スプリント2週間
- 1週目に開発
- 2週目の初日に探索的テストを全員で実施
1日時間をとるだけでも、継続開発を続けていった将来から見た時に検証時間は劇的に下がる
「チャーター(ガイドライン)」が重要になる
- チャーターについては↓これのP26以降に例
- プライマリファンクション（これがないと意味が無い、という機能）
- コントリビューションファンクション（あったりいいな）
を説明して、2時間くらいで切って実施
画一的なチャーターを導入してもだめ。
自分のチームにあったものを作って、他のチームのチャーターを見ながら良くしていく
ケースを書いて消化するときにバグに悩まされる、ではなくて、
今あるソフトウェアの状況を把握し、それをもとにディスカッションしながら進める
セッションベースドテスト
- http://www.nttdata.com/jp/ja/insights/trend_keyword/2014072401.html
- 終わった後にどんなことがあったか会話する
探索的テストの効果を説明できること
- リスクは存在する
- 成果が出なかったチームは無い
優秀なテスターの指標
- コミュニケーションスキル
- 開発者と仲がいい方がバグを見つける
- バグを見つけるスキル
- (高橋さんが)長年人間観察しているが答えが出ていない
- できる人にやったあとに聞くと、
- 前回の製品よりはいいですよ、とかコメントして、実際に市場評価もそんな感じになっている
意味のある探索的テストにするためには
- 前提知識をみにつける
- ドメイン知識
- テスト対象の理解(システムの目的や使われ方、ユーザー層など)
- ドキュメントレビューへの参加
- 過去の類似プロジェクトの不具合状況
- 知見を共有する
- 類似プロジェクトのバグの傾向、リスク
- 手順に書かれていないテストの必要性
- 書かれたことを消化するだけでやった気になってしまう
- 開発プロセス全体の中の1つのプロセスとして探索的テストを位置づける
品質で儲かるエリアの製品、スピードで儲かるエリアの製品がある
- エビデンスは残らないので、医療のような厳しい品質を求めるものには向かない
要素が存在するかの確認
あるページで、条件によってそのHTML要素が表示される場合とされない場合があるとします。(例えば記事を書いた本人には「編集ボタン」が出るけど、他の人には出ない。それ以外の要素は同じ、とか)
その際に何も考えず
driver.find_element(:id, 要素)
をしてしまうと、要素が存在しない時には
Selenium::WebDriver::Error::NoSuchElementError
を返されます。「そんな要素無いよ」ってことでnilでも返してくれればいいのに？と思いました。
調べてたら
http://mirahalab.blogspot.jp/2013/02/selenium-2xhtml.html http://stackoverflow.com/questions/13677263/check-whether-element-is-present
が見つかって、なるほど find_elements (エレメン「ツ」)で要素数を取得して判別すると。
if @driver.find_elements(:id, "要素").size != 0 return @driver.find_element(:id, "要素") else # 設定されていない時は空文字を返す、、、とか? return "" end
2014/6/27 追記 でもこの場合、elementsが見つからないとtimeoutまで待っちゃうのは困るんだよねぇ。。。 みなさんどうやってるのだろうか。
RSpec で expect した時のログ
rspecでexpectするときに、「文字列が詰まった配列」を期待していたのですが、
- 期待と違う文字列が入ってた ("aaa"を期待してたのに"bbb"が入ってた)
- 期待してない文字列が入ってた (配列の要素数が増えてた)
ってことがあって、ログに出力されるdiff見方がよくわからなかったので整理してみました。
# test_spec.rb require 'rspec' expected_data = { match: "title", mismatch: "description" } got_data = { match: "title", mismatch: "description!!", added: "22" } describe 'てすと' do context '配列比較' do it 'できるかな' do expect(got_data).to eq(expected_data) end end end
で、結果が下記。
てすと
配列比較
できるかな (FAILED - 1)
Failures:
1) てすと 配列比較 できるかな
Failure/Error: expect(got_data).to eq(expected_data)
expected: {:match=>"title", :mismatch=>"description"}
got: {:match=>"title", :mismatch=>"description!!", :added=>"22"}
(compared using ==)
Diff:
@@ -1,3 +1,4 @@
+:added => "22",
:match => "title",
-:mismatch => "description"
+:mismatch => "description!!"
# C:/spec/test_spec.rb:34:in `block (3 levels) in <top (required)>'
Finished in 0.00554 seconds
1 example, 1 failure
- [無印] は取得値と期待値が一致してるもの。
- [+] は取得値
- [-] は期待値
- 取得値と期待値が異なるものは + が付いたものと - が付いたものが表示される
- [@@ -1,3 +1,4 @@] ってどういう意味なんだろう
きっとgitなどのソースコード管理ツールに慣れてる人はなんてこと無いんだろうなと思った。
[追記]
- RSpecじゃなくてdiffの基本的な見方の話じゃね？って教えてもらったので勉強になりました。m( )m
- http://d.hatena.ne.jp/kakurasan/20070610/p2
「@@」の付いている行は、テキストの違いが存在する領域(Hunk/テキストブロック)の始まりを示し、数字は修正前後のファイル内の該当する範囲を示す。
tableのレコード数(tr数)をカウントする
RSpec+SeleniumWebDriver で、画面に表示されたtableのレコード数をカウントしたい。
これそのものが http://jigsaw.hatenablog.jp/entry/2013/08/12/225148 にありました。
- JAVAコードだったのでrubyに置き換えましたってだけなのですがｗ
tr_elems = @driver.find_element(:css, "tdobyまでのpath > table > tbody" ).find_elements(:tag_name, "tr") p tr_elems.size
- 少しずつですが RSpec+SeleniumWebDriver が書けるようになってきました。
CasperJSじゃなくてSeleniumWebDriverをRSpecであれこれできるようになる方が先だな！
元旦に「やるぞ」と言ったものの、ここ2ヶ月くらい何もできていないので、いいかげんヤバイなと思ってたところに背中を押されたので勉強再開したいと思います。
この間、身の回りでSeleniumがぐいぐい来てて、というかCasperJSだとブラウザごとの違いがわからないじゃないか、っていう「何をいまさら」っていうことに気づいてしまったので、SeleniumWebDriverがいいじゃないか！とね。
ちょうどお仕事でRSpecでSeleniumWebDriverであれこれやったら楽しそうだった(メンバーにやってもらうことにしたｗ)ので、便乗して自分も勉強しちゃおうかなと。
ということで気持ちだけは盛り上がってるところ。あと、他の人が書いたコードが自分の環境で動かないのを何とかしてるところ。
