JaSST '18 Tokyo【C4】「探索的テストにおけるストーリーベースのアプローチ」聴講メモ

内容まとめ

  • 探索的テストに、ストーリー仕立てのガイドを設定することで、不具合検出率を上げられないか試してみた
  • 結果として有為な差異はなかったが、事前準備やサンプル数に不足を感じており、今後に繋げていきたい

感想

  • 人ごとに探索スキルに差異があることを前提として考えると、一律に誰にでも適用できそうなメソッドではないと感じた
  • ただ、単純に内容としてはものすごく面白い
  • 個人的にはまずチャーターの概念を習得することが先だが、チャーターの発展系をイメージするうえで、今回のセッションはとても刺激を受けた

聴講メモ

人間に着目した探索的テストの提案

  • 即効性はないよ
  • これの発展系をだれかが発表してくれることを期待
  • そもそも探索的テストって？
  • 探索的テストのモデル
  • 事前や最初に思いついたテストケースを流すだけではアドホックだと思う
  • テスト実行後のふるまいをよく観察して、そこからさらなるテストにつなげる

問題定義

  • いかに、テスト実行者の直感・感情・知識・経験を引き出すか
  • 指針
  • テストチャーターを工夫する
  • ツアーのメタファー
    • ガイドブックツアー
    • ランドマークツアー
    • など＞行動の指針
    • が、イメージしづらい
  • ツアー形式をやってみてのインタビュー
    • チャーター作成者の思い
    • テスターの考えや実施範囲
  • 探索しているうちに機能を飛び越えてしまうことがある
    • チャーター適合率を報告してもらっている
    • やったことを指摘するような言い方はダメ
    • チャーターに従う必要はない、としておく
  • テスト管理者の負荷がすごい

課題感

  • テストの意図が伝わりづらい
  • スコープを逸脱する
  • テスト実行者のノウハウを引き出せていない

対策

  • 三幕構成でプロット＝チャーターを書く
    • 設定
    • 伏線
    • 解決
  • 伏線の例
    • XX画面には、最近仕様変更が発生していた
    • 前日に特殊な運用をしていた

やってみてどうだったか

  • 有意な差はなかった (>_<)
  • マインドマップの差
    • ツアーのほうが、幅広く思考できていたようだ
    • 提案手法のほうが、深く思考できていたようだ
  • アンケートの結果としては、ツアーよりは提案手法のほうがわかりやすいという意見が多かった
    • 反省：実験前にテスト実行者の属性を調べていなかった
    • アプローチとしては面白いと感じた

今後試してみたいこと

おわりに

  • もっと人間に着目してみるとよいのかも

質問

  • なにを抽出するための探索的テストなのか
    • テストチャーター作成者による
  • 思考を縛りすぎなのかも
    • いい塩梅はこれから探りたい
  • 質はどうだったのか
    • ほぼツアーと差がない
  • モブテストペアテストをやってみて片方黙っている

JaSST '18 Tokyo【A3】「テスト会社のテストリード達はどのようにテストを成功に導いているのか？」聴講メモ

聴講メモ

「テストってどんなところが面白い？」

  • 狙ったところで不具合を見つけたとき
  • 不具合を見つけたときはうれしい
  • 出る前につぶせたときはうれしい
    • どこにアンテナをたてている？
    • ユーザがどう使うか、開発者ならどう作るか　を気をつける
    • 開発者が作るような分析成果物と同じものを作っても効率はよくない
  • 考えて発想して工夫するところ

「みなさんにとって良いテストとはどんなテストですか？」

  • テスト目的がはっきりしているテスト
    • 形骸化はダメ
  • 再現性が保たれているテスト　目的がはっきりしている
  • 期待値がはっきりしている
  • テスト戦略とのトレースができている
    • 説明できるテスト　他人がみてわかるテスト
  • 編集者
  • 第一条件として「楽しそうにやっている」
  • 開発のこともわかっている
  • 状況を客観的に見ることができる
  • 不具合が残っていたとしても、ユーザーの問合せ対応が迅速であれば、顧客満足はあがるはず そういう価値もあるはず

「自分はこう成長してきた！チームメンバーをどう育てるか？」

  • 独学でがんばって、社内にできますよアピールした
  • それを他の人に強いるのは難しい
  • 10人に1人でも引っかかれば。
  • マネジメント的にいうと、ひとりひとりに得手不得手がある
  • 新しいことが始まるときによくアサインされる
    • 課題が多かった
    • テスト設計コンテストに出た
    • テスト観点って何なんだろう、といったことを考えた
  • 育成は難しいと感じる

「20年後 (先輩がいない、自分が第一人者のとき)テストの世界にいる自分は？」

  • 自分なりの答えを出せるエンジニアになりたい
  • 製品価値を高めることができるようになりたい
  • もともとのオーダーが100として、それが現実としてマイナスになって、それをどう100に戻すことを目指し、さらに付加価値を高めていきたい
  • ユーザーの立場で　UXも大事
  • テストはなくならない　テストはしないといけない
  • テストの手段にあった組織作りが大事
  • テストエンジニアがフリーになるかも
  • アジアのエンジニアで一緒にやろうぜみたいなことも今後起こってくる

感想

  • 欲を言えば場外乱闘的な何かを見たかったです

JaSST '18 Tokyo【E2】「やってみよう！探索的テスト ～ハイクオリティな妄想の高速ループ～」聴講メモ

内容のまとめ

  • 実際にアプリケーションを操作して探索的テストを体験できるセッション
  • 状況によって、スクリプトテストの実装よりも短時間で高い効果が得られる
  • 「アプリケーションの挙動」という学びをインプットに、「ユーザーが現実的にどう行動するか」を想像して、次のアクション(≒テスト設計)を考えると良い
  • 時間を区切らないと費用対効果が悪くなってくるので、タイムボックスで切るのがおすすめ

感想

  • バグ出しを始めると一種の「ハイ」になってしまい、「ユーザーが現実的にどう行動するか」の想像が後回しになってしまった(なので、チャーターなどを使った舵取りが必要ということに納得)
  • 今回のセッションでは体験しきれなかったが、テストキックオフ〜テスト振り返りのサイクル＋チャーターというフォーマットを実際に回してみたい

聴講メモ

  • 燻製をつくる人と食べる人のペアで探索的テスト
  • 似た言葉 探索、散策、冒険、探検、徘徊
  • ただ何となく徘徊するのは薄い ハードウェア壊すような冒険はやりすぎ
  • 探索的テストとは問診に近いイメージ
  • 今回のセッションは、自由度が真ん中から下寄りの探索的テスト
  • チャーターは手順ではなく指針
  • 探索的テストは、テスト設計はするけどテスト手順のドキュメント化はしない
  • 探索的テストとスクリプトテストをどう組み合わせるか
  • チビファ○ヤー○リオ
  • 探索的テストは「おもしろい！」
  • 手がかり＞ユーザーが実際にどう使うか想像する＞動かす
  • 「テスト実施」だけの状態(アドホック的)＞「テストキックオフ」＆「テスト実施」＆「テスト振り返り」のサイクル
  • 今回のセッションでは、探索的テストは「トレーニングを十分受けたテスト担当者」によってなされる、と定義している。ドメイン知識やテスト技法があると効果的

JaSST '18 Tokyo 「Advances in Continuous Integration Testing at Google」聴講メモ

内容のまとめ

  • Googleではすべてのテストを自動化している(UXに関するテストは例外)
  • CIのスケジューリングに対する取り組み&(効果は維持したまま)コストを削減するための取り組み
    • 変更の影響を受けない機能はテストしない
    • 過去のテスト結果を蓄積する
    • テスト結果を「状態」として時系列で記録し、変化がないものはテストしない
    • マイルストーンの設置頻度を減らす
  • 「Flakyなテスト」への対処
    • コード自体の変更が行われていないのに、テスト結果が変化したものを抽出→開発者にフィードバック

上記を支えるための文化

  • テストは書いて当たり前
  • テストを書きやすい設計を考えるのは当たり前
  • 再利用性のないテストだろうが自動テストを書くのは当たり前

感想

  • Googleは、良いプラクティスと言われていることをただ愚直に現実世界に持ち込んでいるだけ、という印象を受けた
  • 取り組みを評価するための数値化を、真摯に行っているという印象
  • ただそれだけのことがどうしてこんなにも難しいと感じるのか

聴講メモ

  • 1件あたり35回のテスト
  • 分散化してテスト
  • マニュアルQAは一切ない
  • 非常に高速
  • 非常に頻繁にプロダクトをリリース
  • テストの99％は合格
  • かなりお金をかけている
  • テストの文化を根付かせる
  • トイレに貼っている　ヒント　結構有効
  • テスティングブログ
  • 新規採用　一日目からテストを書いてもらう
  • QAを別部門としていない
  • 1チーム8人に1人か2人がテスト担当
  • テストのフレームワークを作る
  • 新しいシステムテストというものを追加するためにテストを整える
  • ST　という役割の人間が土台づくりをしている
  • 手作りの自動テストが主流
  • どうやってテストを選ぶのか　450万のテストをすべてするのか
  • 依存性関係を示したグラフ　図　を使って選定している
  • 影響を受けるテスト
  • バックエンドで同時並行
  • 変更リスト　IDをつけて2年間保管　パターンなどが見えてくる
  • キャパシティがあいたら　マイルストーンを区切って　その時点までの変更がテスト対象になる
  • 結果が出る
  • どの変更で緑から赤に変わったのか
  • パスからフェイルに移行した変更を見つける
  • 回帰テスト
  • 少数の変更ですべてに影響してしまう　すべてがそれに依存しているから
  • 実行しないテスト　ほとんどの問題は0.2%の箇所で起きる
  • リソースを節約するために、分析をする
  • 変更の半分は38のテストに影響する
  • 100％で400万のテスト
  • このテストが安心か否かをどう見極めるか
  • 赤い　フレーキー
  • 黒い　ビルド失敗
  • 現在のシステムは非常にコンサバです
  • マイルストーンの間の時間がある
  • いちマイルストーンは40分くらい
  • グリーンライクなサービス
  • インコンクルーシブ
  • 100％グリーンでなくても確信レベルに近ければリリースする
  • 新しいスケジューリングのアルゴリズム
  • 不合格を見落とすリスクはある
  • 少ないリソースでトランジションを見つける
  • テストをやめればよい
  • スキップするのが安全であるとはどういう意味か
  • パスという状態とフェイルという状態の遷移
  • フェイル＞フェイルもスキップして「よい」対象
  • パス＞フェイルは「安全でない」
  • パス＞スキップ＞フェイルの場合は「チェンジ2かチェンジ3が問題」
  • マイルストーンを少なくする
  • スマートスケジューラが悪い状態遷移を検知する
  • テスト戦略　テストコストを低くしたい
  • 遷移を見逃すリスクをおさえる
  • 遷移がなければテストは安全
  • どれだけの遷移を見逃すのか
  • 新しい戦略の評価
  • 2年間のデータ
  • インターンの方が作成した図
  • 3本の線
  • 横軸はスキップレート
  • 100％スキップしても0にならない
  • 90％以上の場合、テストをしなくても遷移は見つからない
  • オプティミスティック
  • 遷移がわかっているものはスキップする
  • 0.2％のみ実行する
  • 失敗するのがわかっていてもスキップしない
  • 中央の線は無作為
  • 直線にならない
  • 確率分布によるもの
  • フレーキーなテスト
  • 同じコードなのに、テストのパス/フェイルが両方出る
  • フレークの不合格は、リリースの支障となる
  • デベロッパーはフレーキーを無視する
  • 1ヶ月分のデータ
  • パスからフェイルの遷移の84％がフレーク
  • コードの変更が問題ではない
  • ブレークが起こっているのは非常に少ない
  • ペアプロのエビデンスが出た
  • 1人よりも2人のほうがいい
  • ジョーがボブよりもフレーキーを起こす可能性が高い
  • 言語によってはブレークが起こりやすい　C++とJava　Goはもっといい
  • 是非結果を記録してください
  • こんなものがフレーク
  • WEBドライバーのテスト
  • マルチスレッドのテスト
  • 環境の差異
  • 継続的に1.5％がフレーク
  • デベロッパーにプレッシャーはかけているものの
  • ある程度のフレークさは許容しなければならない
  • ほとんどのデベロッパーは、うまくいくまでサブミットし続ける
  • どれだけ頻繁に失敗するか
  • このテスト自身が、最近フレーキーだったかどうかのフラグを持っている
  • フレーキーデータベース
  • 明日のチュートリアル

  • データセット

  • 質問

  • マニュアルテストは一切やってない
  • ハードウェア含めた自動化のアイディアはあるか
    • どれだけデジタル化が進んでいるかによる
    • 信号機の制御アルゴリズムだけをテストすれば足りるはず
  • カバレッジをどの程度達成しているのか
    • 測定はしているが、チームの成熟度によって差がある
  • テストの設計の話を知りたい
    • コードレビュー　ほとんどピアによってコントロールされる
  • 小さな変更を非常に大事にしている
    • フレーキーという言葉の由来
    • 語原はミッコさんも知らない　どちらかというと見下げたことば
    • 一貫性に欠ける人　不安定　などというニュアンスがある
  • グリーンをトップダウンで導入したのかボトムアップで導入したのか
    • ボトムから、費用対効果のトレードオフをトップに説明した
    • お金がかかるというのが課題感だった
  • 3名以上　相関関係が見えてきた
    • 3人以上になると規模が大きくなるので、3人がすべてのエキスパートになるのは難しい
    • 1人よりは2人のほうがいい　他の人の目があるほうがいい　気づき
  • 新規サービスのマニュアルテストもないのか
    • 自動化できている　自動化できるということは、イレテーションが短いということ
    • 多少問題があってもクリティカルな問題にはならないサービスだから
  • UXテストも自動化できるのか
    • ユーザビリティテストは人がラボでやっている　エスクペリエンスの確認
    • 実験も含めている　それはある程度自動化といっていいのではないか　ライブのテスト　実験的なテスト
    • UIテストは自動化している
  • テストの記録には個人名が入っているのか　個人に注目してどこまでやっていいのか
    • よい質問です　アメリカでは、従業員の情報は取ることができる　すべて匿名化されている　マシンラーニングのほうでそれは対処してくれる
  • 開発者へのフィードバックについて
    • 依存関係は精度が高い　テストのグラフ　ご関心があればベーゼルをご検討ください
  • 開発者以外にフレーキー以外にフィードバックすること
    • 様々な分析結果　
  • (不具合を)見逃してリリースしてしまったことはないか
    • 何かを見逃すリスクは低い　見逃さないと思っている　トレードオフをみている
  • 組み込みのCIに興味がある　想定されるリスクなどあるか
    • 少し考えさせていただきたい　興味深い分野だと思います
  • グリーンにする社内共通基準のようなものがあるか　チームごとに違うのか
    • チームごとにテストの内用は決めている　でも、ある程度チーム間で合意は取れているとは思う
  • 再利用性が低いテストを自動化しているのは何故か
    • マニュアルテストしているのは翻訳のみ　迅速にリリースするため　36時間以内にライブに出すというルールがある　レアなテストでも、テストを書くということにコミットしている　文化的に組み込まれている
  • 自動化にはまらないコードはどうしているのか
    • もはやそういった問題はない　2006年に文化を変え始めた　2006年以降のコードは96％程度
    • どんなベストプラクティスでもコードに組み込んでいく
  • カオスエンジニアリングのような新しいテスト手法をやっているか
    • インテグレーションは根づいている
    • 実験的　ファジング　ランダムテスト　つかっているが　いまは根幹にはなっていない
  • 全体としてのテスト計画を誰が考えるのか
    • 各プロジェクトチームが、全体的なテストプランを考えている　Googleでは、少数のユーザに使ってもらって、フィードバックを得ている　各チーム自律的に動いている　チームが個々に決断できる
  • テスト変更の適切さをどう担保しているか
    • レビューをしている
  • テストの変更で失敗することはないか
    • コミットする前に動かして確認している
  • AIの活用
    • AIは使うもの　テストの選定　スケジューリング　機会学習のテストは難しい　テスターとしてそこは心配している　数学をわかる必要がある　もし壊れても気付けないおそれがある　業界全体が直面する問題
  • 人数について
    • 強い相関関係がある　複数に人が同じファイルを扱うとテストに影響する　3人以上は影響が起きやすい　3人より2人　2名が最適という判断　なぜなのかはまだわからない　ルールまでは設けていない
  • 特別なレビューはあるのか　レビュアーに必要なスキルセット
    • リーダビリティ　言語の可読性　コーディングスタイルをよく知っている　その言語をよく知っている　チームではテックリードの役割　直接同じプロジェクトに関わっていなくても、ピアプレッシャーによってうまくいっている
  • トライビュー？というフレームワーク　静的な分析　コードレビューの自動化　使えないボタン　すべてに対して修正をかけるより効率的

探索的テストとそうでないテストのJSTQB的まとめ

JSTQB 方言

きっかけ

Feedlyを設定している途中、showさんのエントリを拝見しました。

surumegohan.hatenablog.com

「探索的テストはベテランがやるものだと思ってた」というのは私もよく耳にする言葉で、「そのソフトウェアについてのドメイン知識をそれなりに有している人が、テストケースとは無関係に動くソフトウェアを使用し、ソフトウェアに対するフィードバック(主として欠陥=defectの検出)を行うこと」という行為を指して「探索的テスト」という言葉が使われることが多い印象を持っています。さらに、まったく同じ文脈で「アドホックテスト」「モンキーテスト」「ランダムテスト」という言葉が使われていることも多いと感じています。

(テスト方言あるある)

「探索的テストっぽいグループのテスト」が持つ要素

要素を箇条書きにすると、以下の2点が特徴になるかと思います。

  • 有識者だけが実施可能である
  • テストケースは書かない

ちょっと整理してみたかった

上記の捉え方には個人的にいろいろ疑問を感じているので、それを整理してみたいと思いました。 物差しとしては、JSTQBの用語を使います。

JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-

探索的テスト

まず、「探索的テスト」は以下のように定義されています。

用語 定義
探索的テスト（exploratory testing） 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。

探索的テストはあくまで「設計技法の一つ」として定義されており、「テストを設計しない」という考え方はされていません。「テストを実施する過程で、テスト担当者がテスト実施情報を活用」することがポイントで、ソフトウェアが動いた後に、動くソフトウェアを見ながらテスト設計を行うという段取りになっています。テスト実施情報は、ドメイン知識に基づく情報以外にも、一般的なソフトウェアの設計知識や、ソフトウェアが動作する環境に対する知識からも導くことができると思います。実際の現場ではドメイン知識を持っている人が圧倒的に強い(効率的に欠陥を検出できる)と思われますので、そこがフォーカスされるのは仕方ないと思います。

探索的テストと似ているが、別の言葉で定義されているテスト

次に、「探索的テスト」と同じような文脈で使われることが多いけれども、用語として分かれているものを以下に挙げます。

※他にもありましたら教えてください！

用語 定義
モンキーテスト（monkey testing） 製品の使用法については全く考慮せず、広範囲の入力からランダムに選択し、ボタンをランダムに押すことでテストを行なう方法。
アドホックテスト（ad hoc testing） 非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。
ランダムテスト（random testing） ブラックボックステスト設計技法の一つ。擬似ランダム生成アルゴリズム等を使い、運用プロファイルに合致するテストケースを設計する。信頼性、性能等、非機能属性のテストに利用できる。

モンキーテストは、「製品の使用法については全く考慮せず、広範囲の入力からランダムに選択」するところがポイントだと思っています。テスト設計もしませんし、テスト実施情報も見ません。場合によっては、「ふつうログインするときにはパスワード入れるでしょ。。。」みたいな固定概念が無い、ド素人の方が強かったりします。

アドホックテストは、「非公式に実施する」というところがポイントだと思います。公式に取り決めたプロセス以外で実施するテストですが、「実績のあるテスト設計技法を用いず、テスト結果も予測せず」というだけで、全くテスト設計をしないとは言っていません。頭の中にしかテスト設計がなかったとしても、現状に対してゼロベースで適切なテストを考えて実行する方法、というくらいのイメージです。

ランダムテストは、「設計技法の一つ」と書かれているとおり、テスト設計を行うというところがポイントです。ただ、そのアプローチとして「擬似ランダム生成アルゴリズム等」を使っているだけです。

表にまとめてみると

以下のようになりました。

用語 有識者が必要か テスト設計を行うか
探索的テスト NO(有識者がいるとベター) YES
モンキーテスト NO NO
アドホックテスト NO(有識者がいるとベター) NO寄りのYES
ランダムテスト NO YES

私が携わったプロジェクトでは、上記のうち「アドホックテスト」に該当するテストを、それ以外の呼称で呼んでいることが多かったかなと思います。

IFTTTを使って、Twitterに流れてくるテスト関連の話題をSlackに流し込んでみました

f:id:trickmr:20180304153429j:plain

きっかけ

先日、Google Homeから「もくもくなう」とつぶやけるアプレットを作ってみました。 no-plan.hatenablog.jp そのときに利用したのが「IFTTT」というサービスで、これがとても面白かったので、別のアプレットを作ってみました。

ユーザーストーリー

  • 個人の趣味として
  • Twitterに流れてくる「ソフトウェアテスト」に関する話題を見逃さないために(見逃してもあとで気付けるようにするために)
  • テスト関連の話題を拾って記録しておいてくれるようにしたい

IFTTTとは

「IF This Then That」の略で、要するに「This」に設定したアプリケーションのふるまいを入力として、「That」に設定したアプリケーションのふるまいとして出力してくれるサービスのことです。

IFTTT - Wikipedia

『Google Homeから「もくもくなう」とつぶやけるアプレット』を例に取ると、

  • 「This」のふるまい：「Googleアシスタント(Google Homeの中の人)」が「『もくもくなう』という文字列を受け取ること」
  • 「That」のふるまい：「Twitter」が「『もくもくなう』とつぶやくこと」

となります。

実装

IFTTTのUIに従って、以下の要領でアプレットを作ります。

  • 「This」に「Twitter」を指定し、トリガーとして「New tweet from search」を選択。
  • キーワードに「テスト戦略」など、好きな用語を指定。
  • 個人のSlackアカウントに、書き込み先に使う専用チャンネルを作成。
  • 「That」に「Slack」を指定し、先ほど作成したチャンネルを指定。

IFTTTのここがすごい

ノンコーディングで、下記のカスタマイズを除けば、3分程度で実装完了してしまいました。 お昼休みにちょこっと調べてさくっと実装。これはやばい。

困ったこと

実際に動かしてみると、部分一致でキーワードを拾ってきてしまいました。 たとえば、「テストタイプ」キーワードの場合、「心理テストです！あなたの性格タイプは～」みたいなものが拾われてしまいました。 そこで、伊藤由貴(@yoshikiito)さんに頂いたアドバイスなどを参考にしながら、以下の要領で「This」の検索条件をカスタマイズしました。 ついでに、複数のキーワードをひとつのアプレットにまとめてみました。

  • キーワードを「"」でくくる
  • 各キーワードをOR条件でつなぐ

要するにSQLのWHERE句を書くイメージですね。

以下の要領で書いていけば、キーワードをどんどん増やせます。

  • 「"テスト戦略" OR "テスト計画" OR "テスト設計" OR "テスト観点" OR "テストタイプ" OR "テストレベル" OR "テスト手順"」

※あまり増やすと怒られそうなので自重しています

結果

こんな感じで、指定したチャンネルに情報が流れてきます。 f:id:trickmr:20180304145905j:plain

まとめ

お手軽簡単便利にアプレットが実装できるというのがとにかくすごいですね。 多くのサービスに対応していて、パズル的に色々な組み合わせを試してみたくなる仕掛けになっているところも面白いです。 「アプリケーションをつくる」作業を辛くない、むしろ楽しいと感じさせてくれるサービスだなと感じました。 今後も色々とレシピを試してみて、自分が動かなくても済むように頑張っていきたいです。

Google Homeから「もくもくなう」とTwitterに投稿できるようにしました

きっかけはこちらの記事。

smarthacks.jp

とりあえずTwitter連携が面白そうだなー、ということで、記事を参考に作ってみました。

手順

  1. スマホにIFTTTをインストールする
  2. My Appletsを選択、「+」でアプレットを追加
  3. +this にGoogleアシスタントを指定
  4. 「Say a simple phrase」でトリガーとなる言葉を設定(例：チャーハンなう)
  5. +that にTwitterを指定
  6. つぶやきたい言葉を設定(例：チャーハンなう)
  7. 手順に沿って保存して完了(デフォルトでActiveになります)

動作確認

  • Google Homeに向かって「おっけーぐーぐる、ちゃーはんなう」と喋る。これだけ。
  • 成功すると、「わかりました。ちゃーはんなうとつぶやきます。」と返ってきます。
  • その後、Twitterに「チャーハンなう」と投稿されます。

使い道

チャーハンなうだと利用頻度が限られるので、「もくもくなう」にしてみました。 もくもく会に参加するときに便利！たぶん！

うまく動作させるコツ(？)

  • はっきりとはわかりませんが、イントネーションが重要みたいです。
  • 「もくもくなう」の場合、いわゆる「もくもく会」のイントネーションで「もくもく」と言ってしまうと、「すみません、わかりません」と返ってきてしまいました。「雲がもくもく」のイントネーションで発音するとうまくいきました。

さいごに

Google Homeで遊びたくてインストールしたIFTTTですが、むしろIFTTTの方が楽しいんじゃないかと思い始めてきました。 こちらもいろいろ遊んでみようと思います。