In 2014, I talked about GUI testing architecture. 20141018 selenium appium_cookpad from Kazuaki Matsuo Recently, someone asks me about the architecture.So, I post the blog about it. The following flow means the architecture. I think this architecture is common if anyone uses libraries such as Cucmber. Scenario layer Describe scenarios. This layer depends on “User…More
Category Archives: software test
「消極性デザイン宣言」を読んで、approchiabilityという言葉を知った
「消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。」を読みました。 シャイハック。 私自身、ここに書かれていたように消極的な人間で、V字タイプな人。少人数や大人数だとある程度大丈夫だけれど、微妙な人数になると「・・・」となるような。 そんな人たちのコミュニケーションの話から入り、だんだんとモチベーション、インタラクションの話へと内容が移ってきます。個人的に面白かったのは、approchiabilityという考え方と、モチベーションの話。ここのモチベーションはやる気を出していく話ではなく、やる気がわかないことを前提とした(意識の低い)モチベーションの話なので、疲れず良かったです。 人間は基本的には消極的 これが基本的な立ち位置でした。消極的なので、自然にできるようにどうデザインするかとか、そういう話になってきます。 機能があることではなく、”機能する”こと、その機能を使おうとしやすいことなど。 Usability と Approachability Usabilityは使いやすさとしてよく言われます。品質の話になるときや、人間工学の話、デザインの話といったように様々なところで出てきます。一方、Approachabilityという言葉は私が把握している限りでは初耳でした。 Usabilityとの対比としては、Usabilityが製品/サービスそのものの使いやすさを評価の対象とするのに対して、Approachiablityは対象となる製品/サービスがどれだけ”使おうとしやすいか”を評価しようとしている、という感じ。なので、製品/サービスのその周辺から連続した出来事を評価の対象に加えるという感じでしょうか。モバイル端末などの使いやすさとしてはこういった連続性に言及しているものもちらほら見ますが、そこに焦点を当てたものがこの”Approachiablity”という感覚を受けました。 使おうとしやすさ、行為の切り替え・接続、やめやすさ、いかに無理せず自然とできるか。 特別ではなく日常に溶け込む系のサービスとか製品ではこういう考え方って大事なデザインの話になりそうですね。 そういえば、インタラクションデザインにも言及していて、その中であったモチベーションの設計は色々なところで関係しそうな感じがしました。 締め こういう書籍は時折読みますが、Approchiabilityという言葉の定義はなかなか良い発見でした。More
[ReactNative][Appium]testIDの振られ方
ReactNativeだと、 testID としてiOSだとaccessibilityID、Androidだとview tagを使ってIDを埋め込むのですね。なので、ReactNativeのアプリに対してidで要素を検索したい場合はAndroidだと特に従来のAppiumやEspressoとは少し異なる。 Appiumだと、以下でview tagの取得をサポートするらしい。 https://github.com/appium/appium/issues/6025 これつくと、resource idが同じ要素も細かくidを振って操作することもできるようになるので、安定性向上に寄与しそうですね。 Does EarlGrey support finding react-native elements? https://github.com/google/EarlGrey/blob/master/docs/faq.md react native https://facebook.github.io/react-native/docs/accessibility.htmlMore
[UX]HEART Framework
GoogleのUXの話で、HEARTというフレームワークを見つけました。 http://www.appcues.com/blog/google-improves-user-experience-with-heart-framework/ この記事には、HEARTの中身である以下と、それぞれに対して実例を交えながらどういうものがそれぞれの要素に該当するのか、を説明しています。 name description how to measure Happiness: satisfaction, likelihood of recommendation / via user surveys User surveys Engagement: how much an average user is using your product (by time, sessions, etc) Analytics Adoption: the percent of users that adopt your product after signing up (user onboarding), and/or the percent of users that adopt…More
Read Advanced-Test-Automation-Engineer-Syllabus
ソフトウェアテスト/品質界隈だとISTQBやJSTQBは耳にする機会が比較的多いのではないでしょうか。 その中で、以下のようにadvances test automation engineerのシラバスが公開されていたので読んでみました。ジックリとではないのですが、流してどのようなことが書かれているのかをざっと。 http://www.istqb.org/downloads/category/48-advanced-level-test-automation-engineer-documents.html 内容はテスト自動化の話をテストケースの話から実装時の設計の話、実行、レポートの話までと順に書いていました。実装時の設計のところらへんで、データ駆動とかキーワード駆動、プロセス駆動などの話があったりしました。 ざっと見た感じ、開発者からテスト側によっている人の方が読みやすい(想像しやすい)のかなーと思いました。More
[iOS]Run multi simulators with FBSimulatorControl
複数のシミュレータを1つの端末/OS上で起動可能な FBSimulatorControl はご存知の方も多いかもしれません。 それを使った時のメモ。最後の方に、XCTestを実行する時のものも。 installはリポジトリを参考に。 (以下は 0.2.0 のバージョン) listを表示 2つの端末を同時起動 help 以下のPR/議論で、結果の出力フォーマットとしてJUnitなんかを選択できるようになったようです。 formatterのサポート https://github.com/facebook/FBSimulatorControl/issues/281 https://github.com/facebook/FBSimulatorControl/pull/290 また、以下の通り .xctest を対象にすると、XCTestを実行可能なようです。 という形でテストを実行できる模様。 .xctest はAWS Device Farmとかでも使えるコレですね。 http://docs.aws.amazon.com/devicefarm/latest/developerguide/test-types-ios-xctest.htmlMore
[Android]Reactive系のテストではIdlingResourceやっぱり大事
Rx系において、Android向けの物にはRxJavaの他にAgeraがあります。 codelabsにAgeraがきていたので、簡単な学びがてらやってみました。 Rx系のテスト(Espresso使ったUI含む)までも書かれていたので、Rx系学ぶ人には良い材料になると思います。やっぱりRx系のテストコード書こうとしたら、 Espresso.registerIdlingResources と IdlingResource の実装を使った非同期要素を待つ、ということがかけないといけないよなーということを思いました。 対象 codelabs https://codelabs.developers.google.com/codelabs/android-agera/ my repository https://github.com/KazuCocoa/agera-example-android Repositoryに対する処理 AgeraはRepositoryが1つの大事な要素だと書いていました。その中で、複雑なrepositoryを扱う場合は、以下のようになるそう。 https://codelabs.developers.google.com/codelabs/android-agera/#7 この中で、例えば値の変化を観測してそのないように変化があればそれをsetTextに反映する、というところは以下のようになる。 https://github.com/KazuCocoa/agera-example-android/commit/ba11829000bf820a2c34861cfb3e5c9b071a0e78 なるほど。 テストの書きやすさや保守も考えて… このようなAgeraの特徴の他、Rx系はcallback地獄のように入れ子にコードを書けやすいが、その反面そうするとテストしにくかったり保守が困難なコードが出来上がる。そこで、Ageraの例ではそこを対応する方法を紹介している。 https://codelabs.developers.google.com/codelabs/android-agera/#9 他、処理の分散としてメインスレッド外へ処理を逃がすために、 .goTo(mExecutor) を使った処理方法も。 Espressoも使う 最後、UI含んだテストとして、 IdlingResource の実装を使った Espresso.registerIdlingResources を利用した非同期型のこのようなRx系に対するテストコードも書いています。 https://codelabs.developers.google.com/codelabs/android-agera/#11 アニメーションOFFは毎度のご愛嬌ですね 🙂 最後に Reactive Programmingには幾つか世代があり、Ageraはまだまだ、RxJavaは2.0で世代3~4付近だと言われていました。 https://github.com/google/agera/issues/20#issuecomment-212007539 そうはいっても、Ageraを使ったこの題材は、Androidに対してReactive Programmingを入れてテスト書くまでをざっと学ぶことができるので、やることには良い意味があるものだなーと感じました。More
Appium1.6.0 released !!
https://github.com/appium/appium/releases/tag/v1.6.0 support XCUITest(WebDriverAgent) to test against Xcode8 x above iOS9.3 BTW, this feature has some unstable/known issues support UI Automator 2 for Android I already tried previous its beta version in my company, and then I issued some problems to Appium and it already fixed. I’ll switch to this new version from previous 1.5 in…More
read “The Way of the Web Tester”
The Way of the Web Tester を読んでみました。 私が読んだ時は、まだBeta3でした。最近、Beta4が出て、JSによるテストコードの話が追加されている状態でした。 この書籍は、自動化されたテストを書くための、テストエンジニア向けの入門書という感じです。内容はいかが大まかなところです。 Unit/Integration/UIのテストピラミッドの話 Unit/Integration/UIのテストコードの書き方(Rubyを例に) コラムとして、例えばrecord/playbackの使えないところ、など 全般的にWebだけの言及なので、モバイルに関しては対象外でした。Selenium系の書籍のようにツールに特筆してはいないので、そういう意味では確かに全般的な入門書という感じです。 ただ、コードの書き方などの話になるとリーダブルコードの内容や実装に近いところの話が含まれてきていたので、そこらへんの実装よりを詳しく学びたいとなったら何かWebフレームワークを使った実装とそのテストコードを書く、というところを開発者向けのなんらかの書籍など見て行う方が良いかもしれないです。 ある程度、書籍などで学んでいたり実装を経験した人からすると確かに入門的なものなのでザーッと読み飛ばしながらコラム中心に読んで終わり、となりそうです。More
reading “Advanced Software Testing – Vol. 3”
ISTQBのTTA(Technical Test Analyst)がどのようなことを学んでいるのか、を知るために読んでみました。 Advanced Software Testing – Vol. 3, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst ざっというと、様々なソフトウェアに関するメトリスクやその計測方法、カバレッジの話、さらにはテスト自動化に関する話までありました。 内容として、これはゆるSoftware Engineer in Testと呼ばれるような位置の人は頭に入れておくべき事柄、という感じでしょうか。 data driven や keyword driven なテストコードの話とか、静的/動的テストの分け方やその詳細への落とし込み、様々なコードカバレッジの定義やその役割など。 中でも、コードカバレッジをはじめとした様々なカバレッジ(それこそ、変更量とか含む)の厚みはすごくページを割いていて、その計算(アルゴリズム)の理解までこの書籍でできる感じです。 ただ、これだけできても十分ではなく、ここと実際の経験(開発など)が合わさって相乗効果を発揮する、という感じでしょうか。 効率性のテストの中で、以下のように数多くの xx testingという呼び名があったことは今回初めて気付きました… Load Testing Stress Testing Scalability Testing Resource utilization Testing Endurance or soak Testing Spike Testing Reliability…More