アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その5
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその5になります。
前回は「アジャイルテストの自動化戦略」について書きました。
今回は「コーディングとテスト」のうち、バグの取り扱いについて学んだことを出力していきます！
まえおき！
従来型の開発スタイルであれば、我々QA担当者は発見した全てのバグをもりもりとバグトランキングシステム(BTS)などに登録するのが一般的なアクションかと思います。しかし、あとあと見返してみれば何年も前の課題が未だに対応されず残っている・・・。なんてことはありませんでしょうか。
未対応のまま残されている課題はそのまま管理し続けるのに値する何かがあるのでしょうか。もちろん中には残しておくことに意味があるものもあるでしょう。 しかし、それなりの数の課題が経緯もわからず残っているだけだったりしないでしょうか。
アジャイルなアプローチにおいてはBTSに登録しないという方法もあります。これは選択肢が増えた、ということを意味します。たとえば実装担当者に発見したバグを口頭で伝え、付箋でタスクを管理し、対応が完了すればそれで終了。という方法もとることができます。ときにQA担当者は発見した課題をBTSに登録するまでが仕事であると思いがちです。QAはQuality assurance = 品質保証の略であり、それが達成されることが最も重要なミッションです。
なにが対応するべきバグなのか
（P414 18.6 「バグに対処する」より）
さて、上記ミッションを達成する上で、対応すべきバグとは何でしょうか。意図しないエラーを修正するなどはもちろんですが、顧客とのやりとりから生まれた課題を取りこんでいく必要もあります。顧客が優先順位と価値を決めます。それを満たすのに必要なものは全て実行していく必要があります。（もちろん優先順位が変わればスコープからこぼれ落ちる機能もあることでしょう・・・）
また、技術的負債についてもバグの一種と考えることができます。これらが残ることによって潜在的なバグが残ってしまったり、柔軟性やチームのモラルに負の影響を及ぼすこともあるかもしれません。
バグの管理
（P417 18.7 「選択のすべて」より）
では、これは対応すべきバグだ！とした事象はどのように管理していくべきでしょうか。 これは前述のとおり多くの選択肢があります。たとえば・・・
- 発生したバグを付箋に書き、タスクボードに貼り付ける
- 機能と同様にひとつのストーリーとしてスケジューリングする
- BTSにバグとして登録していく
チームの練度が高ければ、単純にひとつのタスクとして対応していくというのも良いでしょう。はたまた遠隔地のエンジニアとリモートで共同作業している場合では、BTSに登録して共有していく必要があります。そのときそのとき、環境によって最適な対応を検討していくいきます。
しかし、もし可能であるならばバグのレポートは作成しないことを推奨されます。プログラマが正しい方向に変えられないときだけ、レポートを作成するのです。
どのバグを記録するのか決める
とはいえ、レポートの作成が必要なのか否かについてはそうそう決められません・・・。そこで著者は以下のような例を提示しています。
- 単体テストのエラー（ここではCIにて繰り返し実行されているテストを指している）
- 記録すべきではない。冗長で時間の無駄となる
- 概要レベルの反復テストのエラー
- 失敗したテストがレポートと同等のものと捉えられる
- ただし効果的な修正により多くの情報が役に立つ場合もあるため、レポートを作成する場合もある
- 現在の反復でのストーリーのバグ
- プログラマと協議し、すぐに修正できるものであれば記録しない
- 反復の後のバグ（あるいは、すぐに修正できないバグ）
- 記録する
- これはプログラマはすでに別のストーリーへと作業が移っているため
- レガシーシステムから
- 記録が前提となるが、長らく使われていた中で問題となっていないのであれば無理に記録する必要はない
- 本番で見つかるもの
- 全て記録する
いつバグを修正するかを決める
対応すべきバグが見つかった、ではいつ修正するか？については以下の3つ選択肢があります。
1. いま直す
バグは開発が進めば進むほど、修正に対するコストが増大していきます。見当がついているのであればすぐに対応することが望ましいですが、既存機能への影響などが考えられる場合は、顧客に対応への優先順位をつけてもらうこともあります。
2. あとで直す
発見したバグはチームで対応する前に顧客に優先順位をつけてもらう、対応すべきか否かを見当としてもらうというスタンスです。
3. 全く直さない
実装してはみたものの機能そのものがなくなる、または大きな変更が行われると考えられるときは対応しない選択肢もあります。 このとき、記録したレポートがあればオープンのままにしておかずクローズしてしまうことが推奨されています。
まとめ
今回はバグの取り扱いについてアウトプットしてみました。 まとめると・・・
- バグの内容や状況によって、対応は様々である
- どんなアクションをとるのが効果的か、はたまたとらないほうが良いのかの検討が必要
といったところでしょうか。
次回予告
次回も今回と同様にバグの取り扱いについてについてアウトプットしていきたいと思います。
ではまた！
最年少 DataSpider 技術者の誕生！ IoTとセンサーとAPIのごった煮ハッカソン参加レポート（後編）
それでは、前編に引き続いて「IoT とセンサーと API のごった煮ハッカソン」参加レポートをお送りします。
2日目オープニング
朝、会場に入るとこんなものが！これは徹夜したチームの皆さんの為ですね。
その後、みんなで恒例の体操の時間です。
身体がほぐれたところでハッキングタイムに移ります。
ハッキングタイム
まさかの追加要件
私は前日に続いて DataSpider を使ってもらっているチームのサポートに入ります。
「最年少 DataSpider 技術者」は飲み込みが早く、初めて触ったとも思えない速度で DataSpider の使い方を習得し、前日に「kintone へのデータ書き込み」「REST アダプタを使った雑談対話API(Noby API）への送受信」まで実装することができました。 残りは「Twitter への書き込み」「HTTP トリガーによる起動」だけだったのですが、ここにきて追加要件が発生！
「Gmail の送信」「受け取ったデータによる条件分岐」もやりたいということで、急ピッチで開発を進めます。
↑私は隣でやり方を教えるだけで、実際の開発はすべて隣の子が行っています。
残りは約5時間。間に合うのか！？
もう1つの DataSpider 活用チーム
今回はもう1チームで DataSpider を使っていただきました。
釣り竿とDataSpiderが繋がるという普段ではとても考えられない面白いものを作っています。
こちらのチームへは東京からヘルプに来てくれたメンバーがお手伝いさせて頂きました。
全体の様子
DataSpider を使っていただいているチーム以外の様子は深く知ることはできませんでしたが、ざっと見渡すと昨日より更に面白い事態にに。
鍬にはソニーさんのテニスセンサーやスマートウォッチが取り付けられています。
傘にも何か付いていますね。
どうやらこれは夫婦の食卓をシミュレーションしているようです。
発表が楽しみですね！
成果発表！
簡単に全チームの成果を紹介させて頂きます。
商店街のシャッター街を見える化する「街ing」。沼津の町おこしという目的が素晴らしいです。
「ノビィの耳はラズパイの耳」は時間が足りなくて完成までは行けなかったそうです。
家電が発生する魂の声を拾う「家電の魂」。こちらが最年少DataSpider技術者の子が作ってくれた作品です。
デモもバッチリ動きました。追加要件もすべて実装できたようです。
「味噌と奥さんとおはし」味噌汁の塩分量を検出し、部屋の明暗をコントロールします。
「自己主張○○s」デモでは傘とリモコンが自己主張していました。
「うなCOOLβ」もう1つの DataSpider 採用チームです。釣り竿の振動を検出して、DataSpider 経由で Twilio を利用して電話します。
「くわエクササイズ」見た目が一番気になっていたチームです。IoT は農業でも活躍できそうです。
どのチームもとても面白い作品で、時間があればもっと洗練されて良いものになりそうです。
審査結果発表
最優秀賞
Mashup Awards 二次予選への参加権を得られる最優秀賞は「自己主張○○s」でした。
アイデアが面白かったのに加え、すぐにでも実用化できそうな完成度も素晴らしかったです。
こちらは自己主張するリモコンの中身です。
DataSpider 賞
サポート企業からも独断で企業賞を出させていただくことができます。
今回は2チームに DataSpider 使っていただいたのですが、その中でも多くの部分で活用いただいた「家電の魂」を作った皆さんに賞をお渡しさせていただきました。
終わりに
ハッカソンは凄く楽しいと思うのですが、どうしても参加者の大半は開発者の方になってしまい、他の人にとっては敷居の高いイベントのように思います。私自身も1年前はハッカソンのサポートに行くのは自信がなく、またエンジニアの方の多い空気に馴染めずにいました。
しかし、実際にハッカソンやコミュニティイベントに参加してみるととてもオープンな雰囲気で、初めての参加であっても「楽しもう！」という気持ちさえあれば経験や技術力に関係なく楽しむことができます。また、ハッカソンで様々な人と出会い様々なサービスと触れることで、知識・人脈ともに普段の仕事にも活かせることがたくさんありました。
今は便利なサービスや API も多いので、プログラミングのできない人であっても kintone や mythings などを使うことでハッカソンに参加でき、DataSpider を使うことで重要な機能を担当することもできます。また、その時点では仕事上関わりのないと思った人であっても、業界は狭いのでそのうち仕事上でも接点ができ、お互い力になれることが必ず出てくると思います。
ハッカソンに行こうか迷っている方は、是非新しい自分を探すために一歩踏み出していただきたいと思います。
最年少 DataSpider 技術者の誕生！ IoTとセンサーとAPIのごった煮ハッカソン参加レポート（前編）
皆さん、はじめまして。東海・関西地区担当の築山と申します。営業マンのクセにでしゃばってエンジニアブログに進出してきました。
10月29,30日に Mashup Awards 名古屋ハッカソン「IoTとセンサーとAPIのごった煮ハッカソン」にサポート企業として参加してきました。客観的なレポートは事務局の方にお任せするとして、私からは主観たっぷりのレポートをお送りします。
Mashup Awards とは
Mashup Awards は賞金総額「500万円」と日本最大級のハッカソンイベントでして、アプレッソは昨年よりスポンサーをさせていただいております。
各地区の予選やWebでの審査を経て 12月17日に決勝を目指します。今回の名古屋ハッカソンはその一次予選も兼ねたハッカソンイベントとなります。
では、早速レポートに移ります。
開会～チームビルディングまで
オープニング
今回は事前申し込み24名の参加者に加えて、API、デバイス、ソフトウェアなどを提供するサポート企業が7社と大盛況。
サポート企業の机の上には様々なデバイスが並んでいるのですが・・・・
ん！？ これは・・・何故ラケット？？
ラケットのことが気になりつつも、いつもの通り伴野さん、まなみんの仕切りで始まります。
「Mashup」とは元々「複数の音楽を組み合わせる音楽の手法」で、Mashup Awards も様々な API やサービスを組み合わせることにより多くの賞を狙うことができるイベントとなっています。
様々なデータを連携することが得意な DataSpider とは非常に相性に良いイベントです。
インプットタイム
続いてインプットタイムです。各企業が参加者の方に自社のサービスを紹介します。 ここで魅力的だと感じて貰えた企業はたくさんのチームでハッカソンに採用してもらえるので、大事なアピールタイムとなります。
↑トップバッターはサイボウズの北川さん。kintone の紹介です。
↑ヤフーの清土さんからは myThings と myThings Developers
↑気になっていたラケットは SONY さんの持ち物でした。
デバイスをセットすることで、スイング速度、角度などの情報が得られます。
これを使ってどんな作品が出来上がるのか楽しみですね。
私からも DataSpider + Thunderbus の紹介をさせていただいたのですが、
エンタープライズの用途で使われていることをお話しても伝わりづらいので、
過去のハッカソンの制作事例を中心に紹介させていただきました。
↑大垣ハッカソンの最優秀賞作品 Bar Sota です。
アイデアソン＆チームビルディング
各社のサービスを頭に入れた状態でアイデアソンに移ります。
このようなアイデアシートを用いて、頭のなかにあるものを発散させていきます。
その後、アイデアを絵に変えていき、様々な人と会話してチームを作っていきます。
↑「通称：ナンパタイム」の風景
ランチタイム
アイデアソンを終え、チームができたところでお昼休憩です。
今回のハッカソン会場は名古屋工業大学をお借りしているのですが、お昼は学食にお邪魔します。
安い！
ハッキングタイム
お腹いっぱいになったところでお待ちかねのハッキングタイムです。我々サポート企業はアイデアソンの内容を聞いて、自社のサービスを使っていただけそうなチームのお手伝いに行きます。
最年少 DataSpider 技術者の誕生
ハッキングタイムが始まって早々に私に声をかけてくれたのが、なんと中学1年生の子。お父さんと一緒に参加しているのですが、「DataSpider を使ってみたい！」と言うことでお手伝いさせていただくこととなりました。
DataSpider で「スクリプト」と呼ばれる処理を作っていくのですが、どうやら API などの言葉もあまり知っていなかったようなので・・・
その場にあったホワイトボードを借りて授業が始まります。
やりたいことを聞きながら整理すると、マイクで拾った情報を元に mbed というデバイスがデータの送信元になります。DataSpider では mbed から送られてくるデータを受け取って、kintone へのレコード登録、雑談対話 API へのデータ送受信、Twitter 書き込みを DataSpider で実装する必要がありそうです。
随分とやることが盛り沢山で、この時点での私の気持ちは「完成しなくても DataSpider を使って楽しんで貰えればいいかな」という気持ちでした。
どうやら、ソフトウェアのインストールも初めてだったようなので、まずは DataSpider のインストールから一緒に進めていきます。（続く）
他チームの様子
ふと、周りに目を向けてみると・・・サポート企業に相談しながら皆様黙々と作業されています。
今回のテーマは IoT ですので、こんな作業も当然あります。
え！？えーと・・・それは「鍬（クワ）」ですよね？？これは完成が楽しみです。
長くなってしまったので、後半に続きます。
APIStudy#1が開催されました
こんにちは。そしてはじめまして、アプレッソ技術部の對馬です。
いつもはDataSpider Technical Networkでブログを書いているのですが、今回はブログ内容の関係でエンジニアブログにお邪魔することになりました。 もしかしたらこれからもたまにお邪魔して、ちょろっと書いていくこともあるかもしれません。 よろしくお願いします。
さて、エンジニアブログにお邪魔して何を書くかと言いますと！ この間、とある勉強会のお手伝いをさせていただきましたので、その勉強会の様子をご紹介しようと思います。
その勉強会とは…ずばり…「APIStudy」！！
APIStudyでは「APIのベストプラクティスを考えていく」ことを目的とし、APIを利用する人や提供する人に参加していただき、お互いにとって最適なAPI設計につながることを目指す勉強会です。
そして記念すべき第1回目が、10月13日(木)にサイボウズ株式会社 東京オフィスにて開催されました。 初回ということで「発散」のテーマのもと、まずは参加者が日ごろ感じているAPIへの熱い思いをぶつけ合って、APIのどこが好きか、どこを改善したいか、どこについて話し合いたいかなど、それぞれの思いを明確にしました。
オープニング＆インプット
まずはアプレッソ 脇野からAPIStudyの概要説明ののち、3名からAPIに関するLTがありました。
サイボウズ 後迫さんから「経験から学ぶkintone API」
kintone APIの歴史や、どのような目的で提供しているのか。kintone APIの貴重なお話でした！
ケンブリッジ・テクノロジー・パートナーズ 市川さんから、「オープンデータのAPI利用と開発について」
オープンデータを使うときにあるあるな悩みについて…、利用・開発する側のご意見を話していただきました！
Misoca 松本さんから「MISOCA API V3の開発するにあたって」
名古屋から来てくださいましたー！
MISOCA API V3になるまでの奮闘したことのご紹介や、APIについて気になる点を提示していただきました。
余談
ちなみに私はAPIについて全くと言っていいほど知識がないです。
なのでLTで一番熱くなったのは、市川さんのLT内で「ラブライブ！サンシャイン‼」という単語が出てきたときでした。
※ラブライブ！サンシャイン‼は静岡県沼津市が舞台となっているスクールアイドルの青春アニメです。※
そんな私ですが、3名のLTから APIに対する熱い思いが伝わってきて、「APIって実は相当面白いことなんじゃないか！？この勉強会は楽しくなるんじゃないか！？」とワクワクしだしました。
ブレインストーミング＆チームビルディング
LTが終わると勉強会の本題、「発散タイム」です。
まずは参加者の皆さんに「API」で思いつくキーワードを挙げてもらいます。
▲キーワードを書き出します
APIへの思いを出し切った後は、参加者全員分のキーワードをカテゴリ分けしていきます。
「エラーについて」「ドキュメントについて」の困った体験のカテゴリや、勉強についてのカテゴリ、セキュリティについて語りたい！というものなど、たくさんの人がいる分、キーワードもカテゴリも多様です。
そして自分が興味のあるカテゴリについて深堀するため、カテゴリ別にチームを作ります。
テーマの深堀＆発表
チームができたら、そのカテゴリについてチーム内で語ります。
こういう困ったことあるよね、皆さんはどうしていますか？など、今まで溜まりに溜まっていたAPIへの思いを吐き出します。
真剣にディスカッションをしながら「あるあるネタ」で笑いあうなど、皆さんがとても楽しそうで、勉強会が始まってすぐの「ワクワク」は当たっていたんだなぁと、何だか嬉しくなりました。
そして最後は、チーム内で話し合ったことを全体と共有します。
Documentチーム
作るの大変！化石化しちゃう！など様々なAPIのドキュメントについての問題の解決策を話し合っていました。
設計・Versionチーム
いけてるWebAPIとは何か！？について話し合っていました。
あるある話
kintoneについて物申したかったけど、もはやkintoneAPIだけではおさまらなかった全体的な「APIのあるある」について発表していました。
おわり
参加者の皆さんの反応が気になりすぎた初回でしたが、皆さん楽しんでいただけたようで何よりでした。 APIについて、こんなに注目した勉強会というのも、なかなかないのでは…。 そしてアウトプットをメインとした内容だったので、そういった意味でも充実感があった、という意見もいただきました。
皆さん、ご参加ありがとうございました！！！
そしてそして！！！
なんと既にAPIStudy #2が開催決定しております！！ ありがとうございます！
少しでも気になった方は、上記ページからお気軽にお申込みください！
是非一緒にAPIのベストプラクティスを考え、盛り上げていきましょう！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その4
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその4になります。
前回は「テスト自動化の阻害要因」について書きました。
今回は「アジャイルテストの自動化戦略」について学んだことをいくつかピックアップしてきます。
テスト自動化のピラミッド
(P274 14.1.2 「テスト自動化のピラミッド」より)
上記の図はテスト自動化における範囲や容易性などを示した図になります。
下に行くほど容易かつ広範囲をカバーすることができます。下から順に説明していきます。
単体テスト/コンポーネントテスト
- チームを支援する技術面のテスト（第1象限）
- 一般にxUnit系のツールを用いて、対象システムと同言語で記述される
- 高速で安価に記述できる(高ROI)
受入テスト（APIレイヤー）
- チームを支援するビジネス面のテスト（第2象限）
- 「正しいものを作ったか？」を確かめる為、機能テストやストーリテストなどが含まれる
- 単体テストに比べて大規模な機能の集合をカバーする
GUIテスト
- 頻繁に変更が入る可能性が高い
- 実行に時間がかかる
- 低いROI
手動テスト
- ビジネス面について批評するテスト（第3象限）
- 人間の手と目によって実施されるべき
- ユーザビリティテストなど
テスト自動化を検討するにあたってはこのピラミッドに当てはめて考えるとよいとしています。 テスターがまず取り掛かりそうなGUIテストの自動化は実のところ投資対効果があまり高くありません。 それは頻繁な仕様変更や実行そのものにかかる時間などからです。
また、ビジネス面について批評するテストは人間の手と目によって実施されるべきものです。自動化ではその価値が計れません。
何を自動化できるのか, 何を自動化するべきでないのか
（P277 14.2 「何を自動化できるか？」, P283 14.3 「何を自動化するべきでないか？」より）
上記の通り、開発工程の中で自動化できそうなものがあげられています。ここでは機能的な側面のテスト以外にも、定型的な繰り返し作業、たとえばテストの結果レポートをメールするといった作業についても自動化 候補として検討することが推奨されています。こういった周辺作業についても自動化を進めることによって、本来注力すべき作業の生産性もあがりそうです。
また、候補外とされているものについては、人間による批評が必要なもの、ROIが著しく低いと思われるものが含まれています。失敗する可能性がほぼないテスト（「絶対に失敗しないテスト」とありますが、「絶対」はありえません。念のため！）や1回限りのテストについて自動化することは、大きな無駄となってしまいます。
自動化の戦略を立てる---どこから始めるべきか？
（P287 14.5 「自動化の戦略を立てる---どこから始めるべきか？」より）
戦略を立てるにあたっては、冒頭の「テスト自動化のピラミッド」を参考にします。ピラミッドは下層にいくほどROIが高くなります。一方でビジネス面のテストを考えると上層にいく顧客が求める機能が実装されているか、状況が理解しやすくなります。
最下層のテストを充実させつつ、いくつかのテストケースにおいては手動で確認するようにするなど、目的に合わせて優先順位をつけていくことが重要と考えます。
テスト自動化にアジャイルの原則を適用する
（P297 14.6 「テスト自動化にアジャイルの原則を適用する」より）
テストの自動化においてもアジャイルの原則を適用して、その価値を利用していくことができます。テストの設計やスコープをシンプルに保つことが必要になります。これは様々な変化に対してテストが追従していくうえで重要な思想と考えます。また反復的なフィードバックも大きな効果をもたらします。よりよい自動化の方法やテストシナリオを検討してフィードバックしていくことが大切です。しかしここで忘れたくないのはROIを意識することです。全てをやり直すとなっては、今までかけた時間が無駄になってしまう可能性があります。顧客へ価値を届ける為に何が優先されるべきかをしっかり考えることが必要と思います。
また、チーム全体のアプローチはテスト自動化においても重要な考え方としています。テスタビリティが十分に考慮された実装となるように、プログラマやテスター、その他のチームメンバーが協力することで、複数の観点やスキルセットが得られます。チーム全体で助け合うことによって前進する勇気や自信が高まります。（いいですね！）
まとめ
今回は「アジャイルテストの自動化戦略」について学んだことをアウトプットしました。 まとめると...
- 「テスト自動化のピラミッド」を利用して、注力すべきポイントを検討する
- 開発にあたって自動化可能なもの（プロジェクト進行における定型業務含む）、自動化すべきでないもの（人間による批評が必要なもの、ROIが著しく低いもの）を考える
- 自動化に対してもアジャイルの原則を適用する
となります。またそれぞれROIをしっかり意識して検討/実施していくことが重要ですね！
次回予告
次回はすこし飛んで第18章「コーディングとテスト」についてアウトプットしていきたいと思います。
ではまた！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その3
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその3になります。
前回は「アジャイルテストの4象限」について書きました。
今回は「テスト自動化の阻害要因」についてです。 自動化というとQA/テストエンジニアとって、実現すればあらゆる苦行から救ってくれる魔法のように思えてしまいますが、果たして実際のところはどうでしょうか。 どういった効能があり、どういった阻害要因があるのかについて、学んだことをアウトプットしていきます。
では、そもそもなぜ自動化する必要があるのか？という点から始めたいと思います。
なぜ自動化するのか？
本節にでは自動化する理由が8つ挙げられています。
- 手動のテストは時間がかかりすぎる。
- 手作業は間違いを起こしやすい。
- 自動化は人々を自由にし最高の仕事を行えるようにする。
- 自動化されたリグレッションテストはセーフティネットを提供する。
- 自動化されたテストはより早く頻繁にフィードバックを与えることができる。
- コーディングをこれまで以上にできるようにするためのテストと例。
- テストが文書化を提供してくれる。
- 自動化は投資上の十分な見返りがある。
（P256 13.1 「なぜ自動化するのか？」より）
ふむふむ、自動化を試みようとするエンジニアは大半が上記のようなことが「できたらいいな！」と思うのではないでしょうか。（しかしながら、いささか多くを求めすぎでは・・という危惧も抱きます。）
気になったものについてピックアップしてみます。
- テストが文書化を提供してくれる。
静的な文書を最新の状態に保つことは難しいことです。しかし、もしシステムが変更された際に、自動化されたテストを更新しなければ、テストは失敗します。私たちは、ビルドプロセスを「グリーン」に保つために、それらを更新しなければなりません。自動化されたテスト>は常に、私たちのコードがどのように動作するかを正確に書いたものであるということを意味します。
（P262 13.1.7 「テストは偉大な文書化である」より）
これはテストケース自体が仕様書になるといっているのだと思いますが、この考えは絵に描いた餅になりがち・・・。新鮮な状態に保ち続けるのはなかなか難しいと思います。 テスト対象の規模や歴史が積みあがってくるごとに増していく自動テストケース。重複するコードを共通化してシンプルにするも、新たな機能に対応していくうちにどんどんとメンテが困難になってしまう、なんてことは自動化あるあるではないでしょうか。
さて、自動化するにあたっていろいろな心配事が湧き上がってくると思います。これらは「自動化を妨げる障害」として著者の経験が纏められています。
自動化を妨げる障害
- プログラマの姿勢
- 痛みのこぶ
- 初期投資
- 常に変化するコード
- レガシーシステム
- 恐れ
- 古い習慣
（P263 13.2.2 「私たちのリスト」より）
これらについては一つずつ見ていきたいと思います。
プログラマの姿勢
ここではプログラマの姿勢について論じられています。
従来的なチーム編成ではDEVチームQAチームといった具合に別個の組織として存在しており、DEVチームは機能テストの自動化についてまったく考えたことがないでしょうと言っています。 アジャイルな体制においてはDEV, QAといった役割を超え、一体的な体制で開発していくことが良しとされているため、そのような意識では困りますよ！ということです。
また、自動化用のコードを実装する場合にはDEVよりの経験が必要となるため、プログラマにもQAレイヤーでのテストに対して積極的な姿勢が必要です。
痛みのこぶ
（特にテスト自動化に限ったことではありませんが）初期段階においては多くの時間がかかります。 これを時間に対する作業量のグラフとしたとき、ポコッとこぶがあるような見た目になります。
この状態を乗り越えるには適切な指導やマネジメント層の支援も必要となってきます。適切な指導/支援が受けられる環境であれば、組織としてテスト自動化への積極的な取り組みが行われているように思えますね。こぶも小さなものとなりそうです。
初期投資
自動化を始めるに当たってはどのような技術を使って実現するのか、十分な検討が必要となります。
自前で作ったものをフレームワークを使用するのか、すでにあるものを使うのかどうか。 高価なソフトウェアを導入しても、実現したいことに対してはオーバースペックである可能性もあります。
十分に評価できる時間（つまりはお金ですね！）を事前に投資できるとよりよい成果をうみだせるのではないでしょうか。
常に変化するコード
GUIに対しての自動化は困難を伴うと予測されます。なぜなら頻繁な変更がおこなわれ、その都度追従していくのは多くの手間がかかってしまうからです。
このような状況を改善していくにはプログラマとテスターの協調関係をより強めることが必要といっています。頻繁に変更が行われたとしても、機能としての意図は大きく変わらないはずなので、そこに着目してテストを編成していくのがよいとしています。
たとえば何らかの計算をする機能であれば、適合するテストデータをあらかじめ用意しておき、それを流し込むテストコードを変更に強い設計にしておく、といったことなのかと思います。
レガシーシステム
過去に実装されたコードにはテスタブルな状態にないものも存在します。これらはリファクタリングするなどしてテスト可能な状態に持っていくことが重要ですが、新規開発も行いながら過去のコードも触っていくというのはなかなか困難な作業となります。
実現にあたってどのような戦略を持てばよいのか、次の章で紹介されていますので次回のエントリでアウトプットしていきたいと思います。
恐れ
この項は著者の思いがかなりでているところなので、原文を引用します
プログラミングを行わないテスターはアジャイル世界において提供するものが何もないと、しばしば言われてきました。私たちはそうではないと信じています。どのように自動化すべきかをテスター個々人が心配する必要はないのです。これはチームの問題です。
（P268 13.2.8 「恐れ」より）
それぞれの知識を持ち寄って、協調していくことにより、恐れをはねのけていきたいですね！
古い習慣
困難にさいなまれたとき、ついつい居心地のよい古い習慣に戻ってしまうことがあります。インクリメンタルな自動化を行っていくべきところで、毎回手動でのテストを実施するようになってしまう、といったことです。これでは変化への柔軟性に大きく影響が出てしまう恐れがあります。後々大きなバグが生み出され、ビジネスにも影響してしまう可能性があります。
まとめ
今回の章は「テスト自動化」についてのものでした。記述内容からどのレイヤーなのかがちょっとわかりづらいところもありましたが・・、ざっくりとまとめると・・。
- 自動化によって開発工程におけるセーフティネットが築ける
- ネガティブな阻害要因は必ずでてくるが、恐れずチーム全体で解決していく
と理解しました。
次回は・・・
テスト自動化にあたっての戦略について、アウトプットしてきたいと思います！
ではまた次回。
アプレッソ品質マネジメント部に9月（去年）からJOINしました
どうも初めまして、こんにちは。9月にJOINしました、金森と申します。 9月といっても、去年の9月、つまり一年越しの自己紹介となってしまいました。 物凄く遅くなってしまい今更感がありますが、この場を借りて簡単な自己紹介をさせていただきたいと思います。 ネット上でこうやって自己紹介することは初めてなので、結構緊張しています 笑
職歴について
アプレッソ入社前までは中小のSIerにてテストや開発を行っていました。 最初はアパレル関係のシステムのテストに一年ほど従事していました。 その後、物流会社のシステムに携わり、そこでDataSpiderに出会いました。 DataSpiderを使っていた、またテスターとしてもっと頑張りたいと思いアプレッソ品質マネジメント部にJOINしました。
DataSpiderを使ってみて
実際にDataSpiderを使って一番良かったと感じたことは、比較的経験の少ない人でも使え、使い方を覚えれば容易に開発できることであると思いました。 所属していたプロジェクトは私含め経験の浅い人が多かったのですが、開発がスムーズに進みました。 使い方もそれほど複雑ではなく、どんな人でも開発ができることは最大の長所であると感じました。
アプレッソにJOINして・・・
アプレッソに入社して約1年、テスト実施に携わっていました。 そこで感じたことですが、まずQAチームという立場からテストができることが良いことであると感じました。 前職で比較的小規模なプロジェクトに携わっていたのですが、そこでは自分で作成したプログラムを自分でテストしていました。 そのため、どうしても見落としてしまうことがありました。 なので、開発だけでは見つからない不具合を別の視点から発見できることがいいことであると思いました。 また、前職で携わっていたプロジェクトで、開発とテスターの力関係が開発 > テスターという力関係のプロジェクトがありました。 そのような風潮がないことも良いことであると感じました。
これから
現在開発全体でスクラム体制を取り入れ、アプレッソQAチームはその中でQAがどう関わっていくかを常に考えています。 私もテスト実施者としてどのように表現するかを常に考え、日々精進あるのみです。 自分の知らないことをやることは大変ではありますが、それと同時に楽しいことでもあります。 以上、簡単ではありますが、自己紹介とさせていただきます。 今後ともよろしくお願い致します。
追伸
10月からジョブローテーションで2か月ほどサポートチームに移ります。 気持ちを一新し、頑張っていきます。
趣味とか
ゲーム（ポケモンとかが好きです） 野球観戦（横浜DeNAベイスターズのファンです、久しぶりのAクラスで嬉しいです）
