Galapagos Engineering Blog

株式会社ガラパゴス エンジニアチームによるブログです。

Gitブランチモデルのおはなし

ご機嫌よう、ガラパゴスのおとめです。

突然ですが皆さまGitをお使いですね? どんなブランチモデルを採用されているのかしらん? 特に意識されていない? Git Flow? GitHub Flow? GitLab Flow? MyGreat Flow? どれにも一長一短あって、何かしら工夫されているかと思います。

そこで今日は、ガラパゴスのサーバーサイド開発の一例を紹介をしてみましょう(全社的にそうしているわけではありません)。

この記事はガラパゴスアドベントカレンダーの15日目の記事です

ブランチモデルって必要?

まず、どうしてブランチモデルが必要なのか例え話をしましょう。何も考えずにブランチを分けていったとします。そしてあるブランチの変更が別のブランチで必要になったとして……

f:id:glpgsinc:20171213164411p:plain

そうやってできたブランチ同士でcherry-pickとかしていたらどうなるでしょう? いかにも衝突しそうですね?

f:id:glpgsinc:20171213172121p:plain

あるいは、それぞれで別個に同じマイグレーションをしていたら? デプロイするときに発覚しそうですね?

f:id:glpgsinc:20171213172925p:plain

こうしてオフィスに呪いが撒き散らされました。

〜完〜

……。

GitLab Flowのおはなし

もちろん実際にオフィスに呪いが撒き散らされるようなことは避けたいです。というわけで、ここしばらく、GitLab Flowをもとにしたブランチモデルを使っていて、ガラパゴスのおとめは「やりやすい」と思っていました。GitLab Flowそのものは次のような紹介記事を読めば良いかしらん?

読んでいただいた前提でお話を進めますね。

GitLab Flowのつらいところ

中には、変更はmasterや本番ブランチにcherry-pickするような説明があったかと思います。でも、変更をいちいちcherry-pickするのは面倒じゃなくてですか? 複数のコミットに別れていたりして、一部だけ反映するのを忘れたりするような事故がいかにも起こりそうに思えます。

それに、ガラパゴスではアプリ開発をしていますが、アプリは開発時にサーバーサイドのどのブランチを参照すれば良いのでしょう。

ガラパゴスでは、以下のようなブランチ構成になっています。

  • feature:開発・ホットフィックス(実際のブランチ名は内容を表すものにします)。
  • master:幹。開発中の最新版。unstable。
  • integration:開発中のアプリ向け。masterよりはstableに近い。
  • staging:QA用(pre-productionと同義)。integrationよりはstableに近い。
  • production:本番。stable。

Galapagos Flow

基本的な運用はこうなりました。

まず、新しい機能ブランチは、masterから分岐して作ります。また、それぞれのトピックブランチに何かをマージする時には、親ブランチからしかマージしないことにします。

f:id:glpgsinc:20171213213844p:plain

そして、親ブランチにマージするときも、cherry-pickではなくマージします。このとき(特に理由がなければ)トピックブランチは削除します(図は単純化しています)。

f:id:glpgsinc:20171213175242p:plain

最終的に変更はmasterまでマージされましたね?

ガラパゴスのGitブランチモデルでは、基本的にmasterブランチはunstableです。ところでmasterブランチがunstableなら、どうやって品質を確認するのかしらん? ガラパゴスではGitLabを使っていますので、ちょっとした設定でGitLab CIも使うことができます。はい、ご想像の通り、CIが通らなければマージできないし、テストがなければマージしません。

そして、integrationではアプリの王子様からのフィードバックがあり、stagingでは検証の姫君からのフィードバックがあります。これらのフィードバックは、masterから分岐したブランチで修正します。

そこで、masterブランチがstableに近い瞬間が生まれると想像してください。チケットを消化した状態。そう、この瞬間です。これがGitLab FlowでいうPre releaseブランチにcherry-pickする瞬間です。でも、先にもお話したように、ここで行われるのは、merge masterです。

f:id:glpgsinc:20171213185909p:plain

一方で本番環境でHotFixを当てることもあります。こちらはproductionブランチから分岐します。

f:id:glpgsinc:20171213190938p:plain

さいごに

プロジェクトの大きさなどによっても適したブランチモデルは変わると思います。今回お話したモデルは、あんまり大規模な開発には向いていないかもしれません。でも、安全で適切なやり方ができるといいですね。

さて、次回はガラパゴスの女神様によるProtoPie第2回の予定です。ぜひご覧ください。

ところで

MacBook Pro Late 2016のTouchBarモデルを使っていて、TouchBarが消えてしまうことがありませんか? 復活方法を調べても、掲載されている方法で復活したことがありません。特に困るのはvimで何かしらのモードに入っている時で、escキーが押せないのでモードから抜けられません……。

そんな時、実はescにはショートカットがあります。^[ でescキーと同じ効果が得られますのでお試しあれ。


ガラパゴスでは、安全な運用を考えたり、Macを再起動せずにTouchBarを復活できるエンジニアを募集しています。皆様のご応募お待ちしています。

では、ご機嫌よう。

この記事は業務の一環として業務時間中に書きました

我が家事情

ガラパゴスのコードヒーヨアン(twitter: @luinily)です。

今回は会社の業務と関係のある話ではなくて、私が個人活動で作った家の自動化システムの紹介をしようと思います。

始まり

始まりは日本の家とエアコンの設定にあります。 日本の家は冬で寒くて、朝に暖房入れないと部屋が寒くて布団から出にくくなっています。 そのためにエアコンが朝に自動的に着くように設定していますが、毎日設定する必要もあって、1時間単位で設定しかできないので設定する時間も考えないといけません。朝起きて、寝ぼけたまま家を出た場合、エアコンを消すの忘れて、つけっぱなしにしてしまうこともあります。

hOme(2016年)

この状況を改善したい思っていて、自動化できないか調べ始めました。

そこで見つけたのはIRKitというデバイス

IRKitWi-Fiでつなげられる赤外線お受信、送信できるデバイスです。iOSSDKがありますが、curlリクエストでも操作できます。

curlで使うと、IRKitが赤外線を受信して、その信号を取得したい時はこういうリクエストを送ります。

% curl -i "http://10.0.1.2/messages" -H "X-Requested-With: curl"

こういうレスポンスが来ます:

HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/1.1.1.11.aaa11a11
Content-Type: text/plain

{"format":"raw","freq":38,"data":[18031,8755,1190,1190,1190,3341,1190,3341,1190,3341,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,1190,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,65535,0,9379,18031,4400,1190]}

赤外線の信号はformat, freq, dataのフィルドにあるデータ、同じ情報をIRKitに送信すれば、IRKitがその赤外線信号を発信します。

リクエスト:

% curl -i "http://10.0.1.2/messages" -H "X-Requested-With: curl" -d '{"format":"raw","freq":38,"data":[18031,8755,1190,1190,1190,3341,1190,3341,1190,3341,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,1190,1190,3341,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,1190,3341,1190,3341,1190,3341,1190,3341,1190,3341,1190,65535,0,9379,18031,4400,1190]}'

レスポンス:

HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Server: IRKit/1.1.1.11.aaa11a11
Content-Type: text/plain

IRKitと連携して、マックにサーバーソフトを作って、決めた時間などでエアコンの制御信号を送れるようにすれば、自動化できるのではないかと思いました。

ちょうどその時期Swiftの勉強をしたかったので、Swiftでマックのアプリを書き始めました。実装した機能は:

  • IRKitからの赤外線信号を取得
  • 登録したデバイスにコマンドの追加
  • コマンド送信
  • スケジューリング機能、曜日と時間を指定して自動的に送信される
  • iCloudで設定の保存

アプリがそろそろ使えそうな状態になっていたので、サーバーのためのMac miniを買おうとしましたが、そこでiPad Air 2の方が1万円ほど安いと気づいて、UIをiOSように作り直し、iPadのアプリにしました。

iOSではバックグラウンドに制限がかかっていて、アプリのをバックグラウンドで起動させながら自動化させるのは難しいと思いって、専用のiPadでアプリが常に起動してるような形にしました。

そのアプリは1年ぐらい使いました。冬のエアコンやベッドの電気布団の電源現入切の自動化などに使っていましたが、UIがなかなか完成せず、設定を変えたいときはiCloudでデーターを直接編集する必要があったため、使いにくかった。 それに、PhilipsのHue電球などのサービスと連係したいときは追加開発が必要になりますので、将来的に運用が重くなると思いました。

もっといい方法がないかと悩んでいた時に、homebridgeに出会いました。

homebridge + HomeKit (2017)

HomeKitについて

f:id:glpgsinc:20171205192705j:plain
ホームアプリ

HomeKitはAppleiOS 8から提供してるスマートホームのためのAPIiOS 10からHomeKit用のアプリHomeが追加されました。

HomeKitに対応するデバイスはHomeKitを対応するアプリとSiriから操作できるようになる。HomeKitは家の中でのスマートデバイスをまとめて管理・操作するためのフレームワークです。

ホームアプリはHomeKitのGUIになります。デバイスの追加、シーンの作成などが標準アプリでできるようになりました。アプリを提供始めたと同時に、Apple TVやiPadをHomeKitサーバーとして使えるようになり、オートーメーションルールやiCloudアカウント経由での遠隔操作ができるようになりました。

PhilippsのHue電球はHomeKit対応していて、このまま追加してホームアプリから明度、色相などの設定ができます。ただし、エアコンなどは赤外線でしか操作できなくHomeKitの対応していません。そこでhomebridgeの出番です。

homebridgeについて

homebridgeはHomeKitのAPIエミューレートするをNodeJSのサーバーです。homebridgeの中で設定されているデバイスがHomeKitに追加できるようになり、iPhoneのホームアプリ、Siri、HomeKitのオートーメーションなどで操作できるようになる。homebridgeはRaspberry Piで設定することができます。

homebridge単体でほとんど何もできませんが、プラグインをサポートしていて、npmにある無数のプラグインでいろんなデバイスの対応ができます。homebridge-irkitというプラグインがあって、そのプラグインを使えば、IRKitをHomeKitから操作できるようになります。操作感としてはOn/Offボタンになります。

設定してみると

設定はhomebridgeの設定ファイルの中に書きます:

{
   //homebridgeの情報
   "bridge": {
       "name": "Homebridge",
       "username": "DD:23:2F:E2:DF:20",
       "port": 51826,
       "pin": "000-00-00",
       "manufacturer": "@nfarina",
       "model": "Homebridge",
       "serialNumber": "0.4.20"
   },
  
   "description": "Hombridge",

   "accessories": [
       // homebridge-irkit のデバイスの設定
       {
           // homebridge-irkitのデバイスであること
           "accessory": "IRKit",
           //追加時ホームアプリに表示される名称
           "name": "irkit control device",
           //そのデバイスの操作に使うIRKitデバイス 
           "irkit_host": "irkitxxxxx.local", 
           //オンにするための赤外線信号情報
           "on_form": {"format":"raw","freq":38,"data":[]},
           //オフにするための赤外線信号情報 
           "off_form": {"format":"raw","freq":38,"data":[]} 
       }
   ],



   "platforms": []
}

僕が使っている設定にするとこうなります:

  • 暖房30度 On/Off
  • 冷房27度 On/Off

ホームアプリから暖房と冷房がつけられるようになりました。

うちにApple TVがありまして、HomeKitのサーバーとして設定してありますので、オートーメーションの設定ができます。冬だけ有効にする平日の朝、設定した時間に暖房をつけて、消すオートーメーション(週末は寝る時間、起きる時間が不規則なので、手動で設定しています)夏は平日の夜に冷房入れて、朝に消すオートーメーションも設定しました。

homebridgeでエアコンとHomeKitの連携ができ、簡単にオートーメーションができるようになりました。 自分で作っていたアプリに比べると保守コストがほとんどなく、homebridgeやHomekitの対応デバイスが増えれば簡単に家の自動化が進められるようになりました。スマホやSiriからの操作と遠隔操作、自作のアプリになかった機能も使えるようになりました。

さらに改善していく

今までの流れをまとめると:

2016年、自作アプリで自動化。

  • エアコンの自動化ができる
  • アプリ未完成のため、設定しにくい
  • 自作のため、保守や拡張コストが高い

ハード:

  • IRKit(一つの部屋に1台)
  • 専用iPad

2017でHomeKitとhomebridgeを導入

  • エアコンの自動化ができる
  • 設定しやすい
  • スマホで操作可能
  • Siriで操作可能
  • 遠隔操作可能

ハード: * IRKit(一つの部屋に1台) * Raspberry Pi

ただしその時点からまた改善できる点があります。

まずはオートーメーションについて、ルールは手動で有効か無効にする必要があります。家に誰いなくてもオートーメーションが有効であれば設定通りに実行されます。できれば人がいない時は実行されないようにしたいのと、寒い時は暖房のオートーメーション、暑い時は冷房のオートーメーションが実行れれば何も触らなくても一年中に使えるようになります。

もう一つはhomebridge-IRKitの方です。エアコンは一つなのに、複数の設定(暖房、冷房など)をすると連携されていないボタンとして認識されます。

例えば下記の流れの操作でボタンの状態がどうなるかみてみよう:

  • 最初はエアコンがオフ状態、暖房と冷房のボタンも両方オフになっています
  • 暖房のボタンで暖房オンにします。暖房の赤外線信号が送信され、エアコンが暖房になります。ボタンの方は暖房がオン、冷房がオフ
  • 冷房のボタンで冷房をオンにします。冷房の赤外線信号が送信され、エアコンが冷房になります。ボタンは冷房がオンになりますが、暖房は冷房の操作で影響受けずにオンのままになります。

この時点でホームアプリからみると冷房と暖房両方オンになっている。ただしエアコン一つだけなので、最後に送られた信号の状態になっています(この例では冷房)

さらに操作を続く * 暖房のボタンで暖房をオフにします。エアコンオフの赤外線信号が送信され、エアコンがオフになります。ボタンは暖房がオフ、冷房がオンのままです。

問題は赤外線でエアコンなどのデバイスを操作する時は、デバイスの実際の状態がわからないので、最後に送った信号の状態になっているという想定をするしかありません。On/Offという状態しかない時は問題ありませんが、エアコンみたいに複数の状態があるときに(ここは暖房、冷房、オフ)連携されてないボタンでしか表現できないため、ボタンの状態とデバイスの状態がズレやすい、ボタン間の状態もずれてしまいます。

まとめると気になるところが3点あります:

  • 人がいなくてもオートーメーションが実行される
  • 空調のオートーメーションは気温を見て手動で無効・有効にする必要がある
  • 赤外線デバイスが複数のボタンを使うとき、ボタンがお互い連携していない

オートーメーションは人がいなければ実行されないようにする

今年9月にリリースされたiOS 11ではホームアプリに新しい機能として、家に人がいるかいないかのをオートーメーションの条件として使えるようになりました。最初の人が帰る、最後の人が家を出るというイベントもトリガーとしてつけるようになりました。

これによって、人がいないときに実行したくないオートーメーションは実行されないように設定できました。

気温をオートーメーションの条件にする

元ともNetatmoというウェザーステーションを使っていたのですが、残念ながらHomeKitとの連携はありませんでした。 homebridgeを設定した時は、連携してくれるプラグインはないか念のために調べて見ましたが、ありましたので、設定してホームアプリで気温などが取れるようになりました。ただしホームアプリでは、気温をオートーメーションの条件にする機能はなく、諦めていた。

数ヶ月後、HomeKit対応アプリを調べていたら、アップルのホームアプリは HomeKitの全ての機能を実装しているわけではないことがわかりました。 Home - Smart Home Automationというアプリは、値段がちょっと高めものの、HomeKitの変化に沿って全ての機能に対応しているようでしたので、買って見ました。 UIはアップルのホームアプリより使いにくかったが、できることがホームアプリより遥かに多いです。このアプリでは気温をオートーメーションの条件にすることが可能ですので、暖房は部屋の気温が15度以下の時に制限し、冷房は27度以上の時のみ実行されるように設定できました。

赤外線デバイスのボタン間の連携をつける

homebridge-irkitでボタンの連携ができない問題については、解決するプラグインがあるかどうかのを調べて見ました。IRKitを対応するプラグインは他に見つかりませんでしたが、複数のボタンの連携をするプラグインはありました:homebridge-switcheroo。

その二つのプラグインの機能を合わせられれば、問題の解決ができると思いましたので、homebridge-irkitをフォークして、homebridge-irkitextendedというhomebridge-switcherooの機能を追加するように実装しました。Javascriptのブラッシュアップをしながら、必要な場所を変更して実装しました。

実装した結果、連携されている複数のボタンが設定できるようになりました。設定はhomebridgeの設定ファイルの「accessories」のところに追加します。

{
              //irkit-extendedのアクセサリであること
              "accessory": "IRKitExt",
              "name": "irkit control device multistate",
              "irkit_host": "irkitxxxxx.local",
              //複数の状態をもつデバイスである
              "type": "multiple",
              "multiple": [
                {
                    //オフ状態ある時はこういうふうに書きます
                    "name" : "OFF",
                    "form":  {"format":"raw","freq":38,"data":[]}
                },
                {
                    //暖房の設定
                    "name" : "暖房",
                    "form":  {"format":"raw","freq":38,"data":[]}
                },
                {
                    //冷房の設定
                    "name" : "冷房",
                    "form": {"format":"raw","freq":38,"data":[]}
                }
              ]
          }

動作としてはラジオボタンみたいになっています。一つのボタンを有効にすると連携されているボタンが他のボタンがオフ状態になります。追加で、「name」が「OFF」とされている項目があれば、オンになっているボタンをタップしてオフにする場合、オフのボタンが有効になるようにしました。レポジトリーへのリンクは記事の下にまとめますので、気になるかたはぜひ見てください。

最後に

プラグインを作成して、iOS 11とHome - Smart Home Automationというアプリを使うことで、現時点で気になるところを全て対応できました。

今回は例として最初の動機であったエアコンを使いましたが、現在自動化しているのはエアコンだけだはないので、現在僕の家で何が自動化されている、どういうふうに設定されているか簡単に紹介したいと思います。

図にまとめてみました。 f:id:glpgsinc:20171206162640p:plain

設定の中心になっているのはこの記事で説明したHomeKitとhomebridgeになっています。ハードとしては自分のiPhone、AppleTV(HomeKitサーバー)、Raspberry Pi(homebridgeサーバー)、IRKit(台所1台、寝室1台)になっています。

照明

照明は基本的に2種類使っています:Philipps Hue(リビング)と、自動化始める前に買ったシーリングライト(台所と寝室)。下記のように設定しています。シーリングライトはリモコンで操作できるものでしたので、IRKitで赤外線操作げできて、HomeKitで使えるようにできました。

  • 朝起きやすくするため、平日の起きる時間よりちょっと前に家に人がいれば全力にするようにしています。
  • 家に人がいなくなれば、照明が消えるように設定しています。家を出る時に気にせずに付けっ放しできるようになった。
  • 日の入り1時間前、人がいればオンになります。
  • 日の入り1時間前〜朝の間に誰もいない状態から誰か帰ると照明がつく。ドアを開ける時にすでに照明がついている。
  • 平日例時から照明がついていたら暗めの照明になる。(Nightshift的な発想で)
  • おやすみシーンをオンにすると寝室以外全ての照明がオフになります。

空調

主にエアコンですが、冬はベッドシーツの下に電気毛布をつけています。電気毛布の電源に赤外線でオン・オフができるプラグをつけて、HomeKitで操作できるようにしました。

  • 平日23時に、家に人がいて、気温が15度以下だと電気毛布が付きます
  • 平日朝起きる前に家に人がいて、気温が14度以下だと暖房がつく
  • 同時についてたら電気毛布が消える
  • 平日23時に、家に人がいて、気温が27度以上だと冷房がつく
  • 朝に冷房がついていたら消える
  • 家に誰もいなくなるとエアコン、電気毛布が消える

加湿器も対応させたかったが、赤外線の対応をしていないのと、電源の方で切ってもう一回入れるとオフ状態になっていてボタンを押す必要があるため、現在自動化していません。

ボタン

照明と空調かなり自動化しましたが、手動で操作したい時も結構あります。赤外線のデバイスは本来のリモコンとかで操作するとデバイスの状態とHomeKitの中の状態がずれてしまい、必ずHomeKitを使って操作する必要があります。

ホームアプリで操作できますが、いちいちスマホ出して操作するのもリモコンや壁のスイッチ比べて面倒に感じます。その代わりになるものはないかと調べていたが、ほとんどのボタンは電池か電源が必要で、家を借りているともちろん壁につけられません。電池を使うボタンを使ってみましたが、意外と電池を変更する頻度が高くて、使いにくいと思いました。

そうなやっていたところで、Philippsのhue tapボタンにHomeKit対応を追加しました。hue tapは電池要らず、ボタンを押す力で発電して動くボタンです。電源をつける必要もなく、電池交換も不要なボタンで、HomeKitに対応しているということは、家の照明などをそのボタンから操作できるようになります。hue tap一つにして、4つのボタンがあります。

一個購入して設定して見たところ、アップルのホームアプリで設定するとボタンを押す時に一つのアクションしか設定できない。例えばボタンに照明をオンにするアクションを設定すると、照明をオフにするために別のボタンを使う必要があります。 そのボタンの仕様の想定は一つのボタンで照明をオフにする、残りの三つで照明の違う設定三つが使えます。 一つの部屋の照明全体に使いたいときはいいのですが、寝室では部屋の照明オンオフ、エアコン、電気毛布、部屋以外家の照明を消すというアクションを設定したかったので、それだけではhue tapが二つか三つ必要になります・・

Home - Smart Home Automationの方で設定してみるとボタンを押した時に行うアクションについて条件がつけられますので、一つのボタンでできることが増えます。

たとえば、寝室のボタンはこういうふうに設定されています: * ボタン1:部屋の照明がオフであれば、オンにする、オンであればオフにする * ボタン2:エアコンがオンであれば、オフにする、オフであれば、気温が25度以上の時は冷房入れる、16度以下の場合は暖房入れる * ボタン3:電気毛布がオフであればオンにする、オンであればオフにする * ボタン4:部屋以外の照明を消す

ボタン2の方はエアコンをオンオフという操作ができますが、気温によって勝手に暖房か冷房をつけてくれますので、結構使いやすいです。

まとめ

この記事では趣味でやっている家の自動化の経緯と現状を紹介しました。最初は勉強を重ねてアプリの自作を行なっていたが、途中で方針変換して、アップルのHomeKitと連携をすることで、できることを増やしました。HomeKitを対応していない従来のデバイス(エアコン、シーリングライト、電気毛布)も使っているため、Raspberry Piとhomebridgeサーバーの設定、Javascriptでhomebridgeのプラグインの作成までしました。 家が便利になって、いろんな触ったことのなかったことの勉強ができてよかったと思います。興味ある人はぜひ挑戦して見てください。赤外線とHomeKitを連携したい方は、ぜひIRKitとhomebridge-irkitextendedを使って見てください。プラグインについての意見などがあればこの記事やgithubのページでコメントしていただければかと思います。

リンク

新人テストエンジニアの勉強会参加レポート

はじめまして。テストチームのあべです。
社会人もテストエンジニア歴も8ヶ月の新人です。
まだまだ未熟な私が少しでも知識を蓄えるべく、今回始めて勉強会に参加してきました!

イベント内容

開催日時:12/6 19:00~
開催場所:株式会社アカツキ
講義者:B氏
「いまさら聞けないテスト・品質の基礎」【初心者向け】【ソフトウェアテスト・品質勉強会】

connpass.com

Agenda

・はじめに
・テストの立ち位置とは
・何をテストすべきか
・どうやってテストケースを作るのか
・どうやってテストを実施すべきか
・おわりに

普段上流工程のお仕事をしている方や開発エンジニアの方、
ベテランテストエンジニアから私のような新人まで、
幅広い職種の方が参加されていました。

講義の資料は穴埋め形式になっており、講義の合間に参加者の方と考えを共有する時間があり、
体験的に、自ら考え学べるような仕組みになっていました。

はじめに

1.品質とは?
2.テストの目的とは?

  1. 品質とは?
    品質が高いと言えるソフトウェアは「バグが出ない」こと
    また、「ユーザーのニーズに以下に答えるか」も品質になる
    →バグが出ないことはもちろん、ユーザーが使いたくなるようなソフトウェアでなければ、品質が高いとは言えない

  2. テストの目的とは?
    ・欠陥を検出
    ・ソフトウェアの品質が十分であることの確認
    ・意思決定のための情報の提示
    ・欠陥の作り込みの防止
    →開発からのテストで確認する、ではなく、
     開発前に主体的にテストを行えば欠陥の作り込みの防止が可能になる!

テストの立ち位置とは?

代表的な開発サイクル、VモデルとWモデルの中でのテストの立ち位置は「早期に不具合を見つけること」
ソフトウェア開発 201の鉄則によると、要求仕様時点での不良修正のコストを1すると、
設計段階 5 → コーディング 10 → テスト 20 → 納入時点 200
のように、開発が進むにつれて不良修正コストは大きくなっていく
→コスト削減のためにも、不具合を早期に検出することが、テストの役割であり立ち位置である

何をテストすべきか?

本記事をお読みの皆さんも、お時間があれば以下の例題を少し考えてみてください


以下の仕様に対してどんなテストをすれば良いか。  

・パスワードは4文字以上12文字以下の英数字のみを許容する
・パスワードを3分以内に4回以上間違って入力すると、アカウントを5分間ロックする


ちなみにこの例題には完璧な回答も間違いもなく、
重要なのは、仕様を見てさまざまなテスト観点を見つけていくこと!
→1人で考えるより、複数人で一緒に考えていくと様々なことが見つかる(建設的相互作用)

テスト観点を見つけるのに必要な視座:視点・視野
視座:ユーザーの立場になる
視点:様々なドキュメントや過去の経験
視野:品質特性

どうやってテストケースをつくるのか?

テストケース作成の心得
どうしてこのテストを実施するのか(理由)を述べられるかどうか!

効果的なテストケースを作成するために、テスト設計技法(境界値分析・ 状態遷移テストなど)を活用する。
→闇雲に行うと膨大な数のテストケースになってしまう。

テスト作成時に気がついた動作の不明点は、気がついた時点で開発者に確認すべき
仕様に書いていないことは抜け漏れの可能性が高く、バグになる可能性も高い
→テスト作成の時点でバグの作り込みを防止できる(開発前に行うテスト)

どうやってテストを実施すべきか

テストは実施して終わりではなく、
発見した欠陥に関してのレポートは、だれが見てもわかりやすい内容にする
→ほかの人や、1年後の自分が見てもすぐに理解できるかどうかが重要

おわりに

まとめ

・テストの目的は欠陥の検出と未然防止がある
・開発前に行うテストもある
・早期のテストやレビューでコストを削減できる
・テストケースは仕様書や過去の経験、品質特性から作成することができる
・テストケースを少なくかつ効果的に行うためにテスト技法を活用する
・テスト実施のときは他の人がわかるように結果を残す

おまけ

各チームがするべきテスト

開発チーム:Checking
→ 正しいと信じている事柄を確認すること、妥当性確認
QAチーム:Testing
→ 新しい情報を見つける、探索、発見、究明
自動テスト:単純テスト
→ 自動テストをどれだけ行っても、テストエンジニアの工数が0になることはない

あべの全体の感想とまとめ

個人的に講義の中でとても感動したのは、「開発前に行うテスト」と「建設的相互作用」についてでした。

特に建設的相互作用については、
例題の自分の答えを参加者の方と共有する時間があったのですが、
話している間にも新しいテストケースがどんどん浮かんできて、誰かと仕様について話すことがいかに重要であるかを体験できました。
業務の中でも、仕様についてもっと話してみようと思います。

本で学んだり実際にテストするなかで気づくことを今回の勉強会で再確認しつつ、新しいことを学ぶことが出来ました。
また、勉強会に参加します!