KazuCocoa

『万人のためのデザイン』を読んだ

『万人のためのデザイン』を読みました people designが原書です。ほぼデザインの本で、色々なデザインの引用を持ってきながら、工業デザインの進化を平均な人に向けたもの、規格外の人に向けたもの、と色々区分して紹介・説明していくという内容でした。この中で、人に合わせたものを作る、という目的のために人の理解を進めようとする話もあります。デザイン、なので、主には外見に関わるところですが。人間工学への進展や、ユニバーサルデザイン、経済、オープンソースデザインなどの話も。その中で、製品とユーザの関係で、初期の使い始めの頃から、だんだんと慣れて日常になるまでの興味の持ちようをグラフとして引用してたところが面白かったです。More

[iOS]XCUITestを少し追って試しにシナリオを書いてみる

XCUITestがXcode7から利用できるようになったので、少し追ってみたので、メモ。まだ正式に導入するとか、評価したとか、そういう話ではないです。以下は、Xcode7.0で適当なXCUITestを書いたあと、コード上でメソッドを追った時の情報をもとに引用しています。Online Documentなどでは違うところがあるかも。また、 Swift をベースに追っています。 accessibility systemを使って要素を特定する /*! Protocol describing the attributes exposed on user interface elements and available during query matching. These attributes represent data exposed to the Accessibility system. */ どうやら、XCUITestはXCTestを拡張し、さらにはAccessibilityの機構を使うみたいです。ひとまず、UIAutomationのために埋め込んだaccessibilityIdentifeirなど、そのまま流用可能のようです。ということは、すでにUIAutomationを使いシナリオを記述している人は、テストシナリオを記述する粒度は変われど、同一のシナリオを記述することは可能かもしれないです。例えば、 public protocol XCUIElementAttributes にはが定義されています。これは accessibilityIdentifier の要素を指しているらしいので、accessibilityIdentiiferでつけた要素を特定する、ということは従来のUIAutomationと変わらず実施できます。この要素特定には、との2種類が使えそうです。見た感じ。(まだちゃんと使ってはない) また、accessibilityベースではなく、より実装に依存することになりますが実装対象のUIButtonといったUIKitの要素単位を取得するためのインターフェースとしてが宣言されているようです。ここら辺は、UIAutomationで取得できていた要素を、XCUITestで参照できるようにした、というもののようです。 @available(iOS 9.0, *) のある XCUI* 群…More

『さよなら、インターフェース』を読んでUXに思いを馳せる

『さよなら、インターフェース』を読みました。何かのWeb情報を見て、タイトルが気になった書籍。おそらく原書のノリそのものだと思うのですが、訳も砕けた感じの言葉で話を進めている、トントンと内容を読むことができるものでした。また、画面全体であったり、複数の画面にまたがってUIの説明などしている箇所があり、これは書籍として手に取るほうが楽しめそうなものだと思いました。(そもそも、Kindle版は無さそうですが) この書籍自体、User Interfaceが人にどのように影響を与えるか、UXをどうするか、ということを、UI/UXとを切り離して考えるきっかけをあたえてくれるわかりやすいものだと思います。これを読んだ後、私が属している組織が提供するサービスはNO UIの考えにどのくらい近づけるのか、何が提供できるか考えました。つまり、料理を作るに関係する試行において、いちいち検索とか、アプリ開くとか、そういうことをしなくても必要なものを機械がサポートしてくれる。そんな世界はどういうところだろう、と。キミたちはもうひとつ、やるべきことがある。シリコンバレーの二番煎じなんかじゃなく、さらなる高みを目指せ。シャンとするんだ！ > p.54 UIとUXに対して、比喩的に以下の通り捉えていました。いわゆる、Qualityとして目指すはUXで、その手段としてのUI。広く言われている感じですね。 UIとは、ナビゲーションやエラーメッセージ、テキスト入力や領域、アニメーションなどのsignifire UXとは、人、しあわせやうれしさなどの感情、問題解決、至福など。ほか、最近のUIとUXを類似したもの、と捉えた時の反例的な例を幾つか挙げていました。 UIをつければ良い！という、UX無視したアプリ開発ユーザ体験と広告の、利益を得るための(分かっていての)犠牲 UIを表示するディスプレイのバックライトのγ値などと、人の知覚の関係(覚醒するとか。) 「まずは画面」から、スマホはケツポケットにしまっとけ！という考え方への転換スマホを操作してxxできうようにする、ということは、スマホを取り出して、ロックを解除して、アプリを起動して…という操作をさせること。それ自体が、本来したい動作の大半に無駄を埋め込んでいる。日常の範囲内で、体験を満足させることができるようなサービス/機能それらの反例にあるスマホを出して操作するという事後対応型と、この No Interface の主張としての事前に設定しておくことで以降はわざわざスマホを取り出さなくても使える事前対応型サービス/アプリの例も、対比としてつらつらと書かれていました。余談: 広告に関して、Facebookのユーザ体験向上施策と、ユーザの滞在時間の短縮と、広告収入のために意図的に滞在時間を伸ばすように体験を低下させた話とか。(その真偽はさておき、例として。) いろいろ悩ましいところですね。。。鍵となる考え方は以下の3つ。画面なんかよりも先に、解決したい課題の「いつもの手順」を理解する利用者にこき使われるシステムを創り出すひとりひとりに合わせる物理的なものを持たない、特にWebから出発したサービスって、どういう品質がユーザにとってしあわせになるのでしょうかね。そこをちゃんと考えるには、手段としてSoftwareだけではなくHardwareも関わらないといけないのかな。More

[Elixir]defmacroに2つの要素を持つTupleを与えるとき、例外的にTupleがそのままASTとして使われる

ex_parameterizedを修正していたときに遭遇した振る舞い。以下の通り、簡単な defmacro でマクロを定義していたら、 Example.a(do: {1, 2}) のように、この場合だけ意図しない出力が得られました。これ、 Example.a(do: {1, 2}) の出力として [do: {:{}, [line: 11], [1, 2]}] が得られないといけない、と思って聞いてみたら、これは以下の通り問題ないみたいですね。 http://elixir-lang.org/docs/master/elixir/Kernel.SpecialForms.html#quote/2 Quote literals Besides the tuple described above, Elixir has a few literals that when quoted return themselves. They are: つまるところ、この defmacro の中身の Example.a(do: {1, 2}) は、 {key, value} のtupleに該当するから [do: {1, 2}]…More

AndroidTestingSupportLibrary22.2.1リリースメモ

2015年9月14日に、新しいAndroid Testing Support Libraryがリリースされていました。Android Test KitのEspressoなどのバージョンがあがってたのでざっと調べたに続いて、少し見てみようと思います。 releasenoteなんかはgithub.ioで公開されるようになったのですね。 https://google.github.io/android-testing-support-library/downloads/release-notes/index.html リポジトリはこちら https://github.com/google/android-testing-support-library/tree/gh-pages 主な内容 espresso 各種修正 rule IntentTestRule の追加 runner JaCoCo supportの修正 test shardingの修正他、API 23に向けた修正 External contributionという枠があったのですが、外部からの修正に関しても明記するようになったのですかね。貢献へのモチベーション上がりそうな感じですね 🙂 One More Things GitHubにAccessibilityの確認用ライブラリが公開されていました。Espressoの、Accessibilityの部分ぽいです。 https://github.com/google/Accessibility-Test-Framework-for-Android/blob/master/src/main/java/com/google/android/apps/common/testing/accessibility/framework/integrations/espresso/AccessibilityValidator.javaMore

『ソフトウェア・テストの技法第2版』を久しぶりに読んだ

『ソフトウェア・テストの技法第2版』を再度読んでみました。読み直す、と積読にしてたもの。入門的なものなので、結構前に読んでいたのですが、改めて軽く読んでみました。ソフトウェアテストであったり、デバッグであったり。プログラムを書く上で、エラーを見つけて治す、というところに対する原理原則をまとめている書籍です。用語の定義は置いておいて、昨今の開発者テストの文脈で開発者も多少は目を通すのも良いかなと思った内容です。ソフトウェアテストの心理学テストとは、エラーをみつけるつもりでプログラムを実装する過程である。 (この書籍における)ソフトウェア・テストの原則テスト・ケースの必須条件は、予測される出力または結果を定義しておくことであるプログラマは自分自身のプログラムをテストしてはならないプログラム開発グループは、自分達のプログラムをテストしてはならないそれぞれのテストの結果を完全に調査せよテスト・ケースは、予想できる正しい入力条件ばかりでなく、予想しないあやまった場合も考えて書かなければならないプログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることであるプログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならないエラーはみつかれないだろうという仮定のもとにテストの計画をたててはならないプログラムのある部分でエラーがまだ存在している確率は、既にその部分で見つかったエラーの数に比例するテストとは、非常に創造的であり、知的に挑戦しがいのある仕事であるそういえば、エクスロリームプログラムにおけるテストであったり、インターネットを含んだWebアプリのテストの話が載ってました。2版で追加されたものですね。前者は、JUnitなどのフレームワークも用いた、自動化されたテスト群をおもに扱っていました。後者は、ネットワーク含むシステム全体を、ネットワーク/DB/Webアプリのモデル層などのように区分して、それらに関わるテストの話を載せていました。 Webアプリのテストの話では、コンテンツ・テストとしてGUIに関する要素が、利用時の品質に大きく関わる、という文書がありました。おもに回帰テストにおけるテストの実行速度の面になるとどうしても優先度下げられたり、人海戦術任せになってるところがありますが、ここら辺は利用時の品質に大きく関わる(利用者が多ければ、尚更)箇所なので、ちゃんと言及されているのは良いことですね。システム全体の構成の話、目新しさは無かったのですがそこらへんの要素を経験/学んでいない場合は目新しさに映るのですかね？昨今ではそれぞれの箇所で専門性が高まったり、よくあるSeleniumを使ったE2E系の話しだとそれらの多くの要素が(意図的かどうかは置いておて)省略されている場合もあって、システム全体に対する構成に対する想像がされない世界になってきている気がします。隠蔽された良い面と、開発やテストを行う者としては知らなさがシステムを造る上では悪い面がありますね。More

[iOS]UIAutomation will be going away and focused on XCUITest

そこまでXCUITestを調べてなかったのですが、最近のFacebookのWebDriverAgentに少し気になるissueのコメントを見つけました。 issueはこちら。 ★ いくつかピックアップすると、 There are a number of limitations currently with XCTUI testing, but we will need to start with the groundwork, since it’s possible that UIAutomation is going away in the next major Xcode release. > https://github.com/facebook/WebDriverAgent/issues/7#issuecomment-140745640 The old UI Automation support in Instruments is deprecated. UI testing in XCTest is the replacement,…More

Stetho1.2.0でScreenchastingが実現されている

Stetho1.2.0がリリースされていたので、私向けのメモ含めて。 Changelogはこちら New Chromeへのscreencasting initalizeするのが楽になった他にも、SQLに対してEXPLAINできるようになったり。ElementタブからCTRL+Fして要素を検索できるようになったり。 initalizeが楽になった今まで、複数行を使って Stetho.initialize に与えていたものが、1行に済むように。例えば以下。 Screencasting ChromeDevToolsの機能を使って、AndroidのViewをChrome上に表示させる、という機能です。(ChromeDevTools自体、こういう機能あったのですね。この機能を知るまで、全く知らなかったです…)それがStethoに統合されました。統合するPR ただ、以下だとキーボードが表示されているのですが、Viewを取得するだけなのでシステム側のViewを持ってくることができません。なら、システムダイアログなんかは取ってこれなさそう。少しコード見てみると、確かに activity からViewを取ってきているので、そうっぽい。 https://github.com/facebook/stetho/pull/190/files#diff-ac2bcff06c8c53f332d091e75117b95cR87 たとえば、ここの機能だけをみると単純にAndroidアプリをブラウザ上から操作する場合は以下のようなサービスが存在します。 http://www.vysor.io/ http://openstf.io/ これらと比べて技術的にChromeDevToolsを使ってStethoはどうようなことを実現されているぶん、実現も容易になっていそうです。このコードの変更箇所を少し覗いてみましたが、思いの外少ない実装で実現されているのですね…STFはもっとチューニングしてそうなので、ちょっと毛並みが違いそうですが。 https://github.com/facebook/stetho/pull/190 締め Screencast自体、いろいろ楽に類似サービスみたいなやつ構築できるようになりそうですね。サービスではなく、内々で使うには十分な感じものもが。時代はChromeDevToolsかなー。More

OSSとして公開された、巨大なFacebookのiOSアプリでUIAutomationを使うために使われているツール群

iOSアプリ開発、動作確認、テストを経験されている方なら分かるとおもいます。UIを確認したいときのiOSアプリの動作確認を自動化する時、UIAutomationを使う形が多いですね。そして、その場合において、一番のボトルネックはやはり実機やSimulatorの同時起動、実施速度の制約になっていきますよね。 UIAutomationは、実機で実施するには遅延があります。また、実機ではデータをCleanにして毎回テストを回すには、それ用のdebug機能を実装しなければ不可能です。遅延に対しては、Facebookのinstruments-without-delayを経由して、遅延の少ないSimulatorで実施するこができていました。そして、特定のディレクトリを削除して毎回Cleanな状態を確保できていました。そういうことができるiOS Simulatorの価値は高いものです。(Xcode7ではツールの制約上この機能が正常に動作しませんが、このGistによると、Simulatorのplistをinjectionすれば有効にもできるそうな。) 例えば、Appiumはこのツールを組み込んでいるので、iOS実機もそうですが、シミュレータではより早く安定したGUI Testigを実施することができます。なのですが、Simulatorは1つのセッションしか、Mac上では起動することができません。これはSimulatorやXcodeのinstrumentsに課せられた制約になります。そこで、最近Facebookが以下の通りその問題を解決するようなライブラリをOSSとして公開しました。 FBSimulatorControl Objective-Cにより実装されていて、複数シミュレータを起動することができるようにしているもののようです。以下がこのOSSのAboutなのですが、このライブラリは、Private APIの DVTFoundation や CoreSimulator にリンクして、直接ごにょごにょしているらしいです。例えば、シミュレータを直接操作する simctl を操作したり。Private APIをモリモリ使っているぽいので、Xcodeの変更に対してリスクはありますが、それでもFacebook同様、巨大なアプリはこういう形のツールを使わなければ、GUI Testingでは結構な時間を持っていかれますよね… About The original use-case for FBSimulatorControl was to boot Simulators to run End-to-End tests with WebDriverAgent. As FBSimulatorControl is a Mac OS X framework, it can be linked to from inside any Mac OS Library,…More

入門ではなく、基礎として『人間中心設計の基礎』を読んだ

『人間中心設計の基礎 (HCDライブラリー (第1巻))』を読みました。新しめのユーザビリティ系の本やデザイン系の本を読むと必ずと言っても良いほど出てくる参考書籍です。基礎と書かれていますが、入門ではないので積読な状態でした 🙂 序盤はISOなどで標準化された領域の話しや、その遷移などが書かれていて、だんだんと”人”に対する設計や品質といったものが評価されるようになってきたのかを見ることができます。人間工学よりの話は出てくるだろうなと思っていましたが、Software QualityのISO 25000シリーズへの言及があったのが個人的に面白かったです。良い驚き。テストエンジニアというか、ソフトウェアテスト界隈でよく参照されるISOがこういう場でも取り上げられるって、ソフトウェアの品質という視点が広く影響を及ぼしているということですね。ISO25010から、一部、抜粋。 Product Quality Functional Suitabiiity Performance effectivicy Compatibility Usability Reliability Security Maintainability Portability Quality in Use Effectiveness Efficiency Satisfaction Freedom from Risk Context Coverage http://maisqual.squoring.com/wiki/index.php/ISO/IEC_SQuaRE 中頃では人間工学と認知心理学の話し、より技法よりな話しがかかれていました。最後は評価で締め。評価なんかは、実際に経験もしないとなんとも言えないのですが、そういうことも経験として腹に据えることができる環境にもいるので、落とし込んでいきたいです 🙂 コード書くだけかプログラマではないように、テストコード書くだけがテストエンジニアではないですよね。More