Tag Archives: softwaretest

デブサミ2016でモバイルアプリ開発に関してお話しさせていただきました

以下の通り、お誘いいただいたこともあって、デブサミ2016でお話しさせていただきました。 http://event.shoeisha.jp/devsumi/20160218/session/1055/ Googleのとある書籍に習って、テストに関わる職種から見た開発、というものを書いてみました。ただ、ハードウェアは関係ないので”ソフトウェア”をつけています。 がっつりソフトウェアテストの技法だとか、どう活用しているという話は JaSST や SQiP でされる方がよくて、デブサミでは 自身の体験をもとにしたその周り 、という形の方がイベントの趣旨としても良さそうだったので今の物語の流れにしました。聴講者、デブサミは開発よりな人だったり開発上がりのマネージャな方なイメージだったので、時間帯も考えるとがっつりテストの話は眠くなりそうと感じたので。なのでQualityを真ん中に置いてその改善という流れにしてみました。 テストという局所的な話よりも、開発全体の中でQualityを高めるためにどうしたか、その中でテストエンジニアというものがサービス開発にどう関わっているのか、貢献しているのかが一連の流れで分かると良いなと思いました。 テストというQualityに対する一部を取り出してそこだけに深く関わるのではなくて、こういう感じで広く関わって、品質を向上させるところに 知を使う のがテストエンジニアとか、QAエンジニアと言われる方々。ソフトウェアテストの開発の上流工程から〜と言われるところの仕様というところをさらに広げた、多分もっと根本的にあったであろう活動全般になるのでないかな。(と信じてはしますが…)。日本でいう、1990年代にあったとされる品質活動と同じようなことをしている感じ。（実際にはその頃の話は聞いただけなので、想像ですが…） 品質に対してアリストテレスの話を出したのですが、そこらへんも反応がなかったので “がっつりソフトウェアテストの技法だとか、どう活用しているという話は JaSST や SQiP でされる方がよくて” という判断は正しかったぽい。(多分、そこ専門に学んでいると多少なりとも知るのでないかなと思ったので)。でも、そのあとのとある会話でSQiPやJaSSTでもそんなでもないかも、と言われたので、そんなでもないのかも。 あ、 toteka の宣伝の箇所が一番ウケがよくて、良い緩和剤になってくれました。 運営に携わっていました方々、ありがとうございました。More

[Android]duplicateFileException when import espresso-web

個人アプリのいろいろなライブラリの更新をしていると、以下のようにespresso関係でエラーが出るようになってました。 Webでざっと調べると、以下を見つけることができました。 http://openstackwiki.org/wiki/Espresso-Web_importieren_verursacht_duplicateFileException http://stackoverflow.com/questions/33800924/espresso-web-import-causes-duplicatefileexception 公式では、以下のcontribにはcoreが入っていると書かれているのでその場合はcoreは不要、とは書かれてれているのですが、これはよくわからなかったです。 ちなみに、以下のGradleサンプルでは大概のespressoに必要なものは入ってました。 https://google.github.io/android-testing-support-library/downloads/index.html ひとまず、stackoverflowにあるように以下を packageOption に追加することでエラーを回避することができました。んーむ。More

『ヒューマンエラー 完訳版』を読んだ ~ これが否応のない人生の現実である ~

単に、どんなにうまく運営されている組織でも、影響の大きな意思決定のうち相当の数が、後になって間違っていたと判明することになるという事実を認めることである。 これが否応のない人生の現実である 。 『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだであったような欠陥分析をする上で、人は一定確率で失敗するという大事な前提があります。一方で、それはどれほどなのか、経験的なものではなくちゃんと研究としてどこまでされているのか気になっていました。 そんな中、『ヒューマンエラー 完訳版』を見つけたので読みました。そのメモなどをつらつら。 ソフトウェアは人工物です。そのため、ソフトウェア開発は人の組織や認知と如何に関わるかというところが大事な要素を占めてきます。(ソフトウェアテストを学んでいると多くの人は行き着くことな気もしますね) この本では、主に原子力発電という安全性が最重要とされる情報をもとに、ヒューマンエラーに関して研究をまとめています。ここら辺は、安全性が重要な要素である航空関係、医療関係でも使われていることでしょう。たとえば スライスチーズモデル なんかで。一方で、 スライスチーズモデル の考え方なんかは、実は程度はどうであれそこ以外の分野においても有益な情報が多分にあります。 学術的な箇所は端折ってメモ。 GEMS(Generic Error-Modeling System)に沿った定義でエラーを主に扱っている 実行上の失敗: スリップ(しくじり)、ラプス(手抜かり) 計画が不適切: ミステイク(mistake) この中で、計画が不適切であるエラーの方がより見つけにくい。(ソフトウェア開発だと、仕様がそもそも誤っているというところですね。) 人の活動は、 SB: skill base RB: rule base KB: knowledge base の3つで構成されるとしている。それぞれの特徴は省略(本書のP.82付近)。この中でSBで発生するエラーは、主には 監視の失敗 によっている。RB、KBは問題解決能力が大きく関係してくるエラーに対する活動。 人は、 頻度の高いものほど認知/推論しやすくなる 。逆を言うと、そうでないものはエラーを認知することが難しくなる。5章ではそんな人の認知のロジックをモデルに落とし込み、模倣した研究が添えられている。つまり、人の正しいが、時折間違えるという状態がモデルとして扱われ、それを計算機により表現している。 第6章の数値は面白かった。データベースアクセス、更新などのある作業が エラーなくできたか、エラーが発生した時に正しく対処できたか を、SB/RB/KBで対策した時の差を計測結果として残している。 これによると、 SB ほどエラーが発生しやすいが、同様にSBの人ほどエラーが発生した時に正しく対処できる可能性があることを示している。 つまり、プロセスなどを整備することによるリスク低減と、人のスキルが成熟している状態を作ることができれば、低いリスクで万が一にも備えることができる状態を作り上げることができる。 ただ、いずれの活動に置いても、 手順の飛ばし、抜け、漏れは検出することができなかった。つまり、 手順の抜け漏れを探すようなことは、人は苦手。 エラーを検出するためには、 自己監視過程 なんらかの環境の手がかりに気づく 誰か他の人が発見する が大事。特に、ほかの人による発見は複雑でストレスの高いものほど効果が高い。つまり、 気をつける 、…More

SauceLabsのMobile App Testing Checklistがまとまってて良かった

SauceLabsのメルマガで、良いチェックリストがあったのでメモ Mobile App Testing Checklist from https://saucelabs.com/resources/white-papers/dzone_2015_spotlight_guide_to_mobile_development-sauce_labs.pdf Device Checks ☐ Can the app be downloaded? ☐ Can the app be uninstalled? ☐ Can the app be updated? ☐ Can the app be updated when multiple updates exist? ☐ Can the app be downloaded on multiple operating systems? ☐ Can the app be redownloaded? ☐ Does…More

[Elixir]tear down in ExUnit as on_exit

teardownを探していたのですが、 ExUnit では、現在はteardownは on_exit のcallbackで実装されています。過去、この形に変更されたのですね。 http://elixir-lang.org/docs/v1.1/ex_unit/ExUnit.Callbacks.html#on_exit/2 使い方は以下。 setup の中で on_exit を定義します。これで、この setup_all や setup と同じサイクルで処理が実施されます。 ちなみに、 shouldi を使った時は上手く動作しなかった… 過去、私も書いていた… MIX AND OTP vol 1More

『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだ

ソフトウェアの欠陥予防 テストより確実な品質改善法 を読みました。 ある市営図書館でたまたま見つけて、ふと手に取ってた書籍です。 この書籍は日本語訳する時に一部がっつり省かれた章があるらしいです。日本語で読んでかなり資産としてよかったので、つい英語版をポチってしまった。届いたら再読しようと思います。ご興味のある方はどうぞ => The Practical Guide to Defect Prevention (Developer Best Practices) 読んでみて、この書籍はテストエンジニアや品質にかかわる人は読んだほうが良さそうです。が、それ以上にソフトウェアで製品を開発し、それによってユーザに価値をより効率的に提供したい開発者やディレクターの人ほど読むべきだと感じました。特に、第1、2章くらいを。経済的な話など含めて、欠陥予防への取り組みの価値を知ることができるので。(ちなみに、これを書かれた方はWindows Vistの開発に関わった方々です。) 例えば、欠陥予防の取り組みが、破壊的なイノベーションへの投資へ資源を回すことができる余力を作ることに如何に貢献するかなどが書いています。欠陥予防を中心に取り組んだ組織と事後対応中心に取り組んだ組織とでは、彼らの計測結果の中で新機能やサービス改善への生産性に対して約2倍の差があったそうです。つまり、欠陥予防へ取り組んだ組織は、そうでない組織に対して新機能/新しい価値を生み出すための挑戦が多く実施可能だそうです。 この背景は想像の世界ではなく、開発時にかけるコスト、その保守対応時のコスト、機会費用などを持ってきて、費用という側面からの議論のコンテキストの上で行っていることがこの書籍の素晴らしいと感じたところです。 例えば、機能を開発している時に発見された不具合を事後対応に回すほどに、リリース前に対応していた時に比べて修正するまでに費用がかかります。それは、リリース後にユーザサポートにかかるコストや、その修正を行ったあとに行われるテスト作業など含めて考えると直感にも反しないでしょう。これは事後対応中心の組織における開発では考えられないことも多く、例えば自身の変更がmasterにマージされるまでは考慮するが、それ以外のことは考慮しない、というような 限られたソフトウェアのライフサイクルしか考慮できていない ことも関係あるそうです。 ここでいう欠陥/不具合とは、それを利用した人が欠陥/不具合と判断したものです。そのため、Specの通りに実装できていないものだけを欠陥と言っているのではないです。誤って行った設計など、より上の工程に埋め込まれた欠陥、などへも言及しています。 Microsoftの人の言葉はなかなか強いですね。論文などもちゃんとしているぶん。 幾つか頭に残った項目を以下につらつら。 メトリクス P133ページごろに書かれていたメトリクスの話。 例えばカバレッジなどのメトリクスに関して書いていました。よくあるソフトウェアテスト／品質関連の書籍同様、目指す計測可能な値の1つだと書かれてはいますが、それが銀の弾丸などではないとも書いています。コード変更量とかカバレッジの話で気構えるの、私の観測する範囲ではなんかテスト界隈の人よりも開発者が過剰に反応している環境の方が多いように見えるのですが、これは過去に何かあったのかな…その計測値が顧客への成果物になってたりする場所で働いて、それが絶対的だったりしたのかな。参考値としては多彩な情報を提供してくれますが、それだけをプロセス管理などの管理のために使うといった、誤った使い方は妥当ではないですね。 Microsoftのビジネス及び従業員のゴールは、SMARTを求められるそうな。 具体的 specific 計測可能 measurable 達成可能 achievable 結果重視 result oriented 期限付き time bound そのための要素としてGQMが言われていて、 Goal Question Metric を使うそうな。優先付けの数値は、一般に粒度があまり密でないほうが良いらしい。なので、hight 9/medium 3/low 1くらいの点数付けでメトリクスやタスクを優先付けするそうです。その重み付けには、開始の容易さ・メンテナンスの容易さ・有用性、現在収集されているか、信頼レベルなどらしいです。それを元にヒートマップを作るみたい。ヒートマップを作るの良いな。(P.140くらい) リスク分析 第8章ではリスク分析の話が書かれてました。リスク分析では、特性(characteristics)、量(amount)、インパクト(impact)、理由(reason)、オーナーシップ(ownership)でリスクレベルを判断するそう。コードの変更内容、変更量、変更による影響、変更理由、誰が変更しているか、だそうです。真っ当な感じですね。過去、現在から予測する。そこにフィードバックも入れる。 欠陥分類 第10章では欠陥分類法について言及してました。そこでは、以下の内容を前提に、欠陥を分類していく幾つかの実例を載せています。 変化には決まった種類がある: 人/文化/プロセスなど…More

『システムの科学』を読んだ

システムの科学 第3版 を読みました。 FB上で誰かがコメントしていたことをきっかけに読んでみることにしましたが、これは大学院の頃にも読んでおきたかったと思ったものでした。(ただ、その頃に読んでも今ほど楽しめなかっただろうですが) 原書は “The Sciences of Artificial, Third Edition”です。人工物に対して、科学的な見解をまとめている本です。そこには数多の論文が引用されています。第3版では、複雑性に関する内容を取り入れて、システムへの考察もその時点での経験的な側面含めて述べています。 ここでいうシステム、とは複雑系を指しています。なので、人の生活や文化、組織の話だったり、コンピュータを使った分散システムの話であったりが対象です。認知心理学やデザインの科学のほか、複雑性に対するカオスや遺伝的アルゴリズムなどの話を交えつつ、それら”システム”に対していろいろ述べています。 人は、どんなにしたいと思っても、できないことをやろうとはしないであろう。… それ以外に選択の余地がないがゆえに、「十分良好な」代替案を受け容れる、そういう人間すなわち満足化を追求する人なのである。 面白かったところは、人が満足するとはどういう状態か、というような所まで踏み込んでいたことです。科学的な視点から、例えば創造したシステムが人を満足させる、満足したとはどうなっていることなのかまで書いています。ここら辺も踏まえて、ソフトウェアテストや品質という点で、私が進んでいるような先にあるテストエンジニアを目指す人には必要な論理的な基礎として学んでおきたい所ですね。 人工物の科学を考えるのでれば、デザインの評価(評価理論、計算方法、形式理論)、代替案の探索(発見的探索、資源配分、組織化の理論、問題の表現)を学ぶ必要があると途中で書いてました。ここら辺まで踏み込んでまとめられているものが、すでに1990年代にあったとは… 政治学には「代替案なしに批判だけすることはできない」という諺がある。 複雑性の話は、私自身が複雑系を対象に研究をしていた時期があったこともあり、とても面白かったです。複雑なシステムは、少なくとも 単純な仕組みが幾重にも階層的に連なり構成されるシステム であることを、いろいろな例を基に書いています。そこにはまだ経験的な話ベースの例が多いですが、この書籍を書いた以降の幾つかの経済系論文を追ったことがある身としては、ちゃんとした数式で証明された理論もあるので経験を理論で固めていく、という科学の話を追えたこともまた面白かったです。 最後に、経済学は、心理科学であると述べていることが面白かったです。富を追う、という所よりも、人の心理に注目しているところが品質ぽかった。 いろいろ頭を使いながら読む必要がありそうな本なのですが、これはまた読み返したい。 余談ですが、複雑系では私は The Wisdom of Crowds が面白かった憶えがあります。Kindle版もでていたのですね。More

[Android]Espresso for AdapterView

Espressoは通常、 onView(mathers) によってビューの取得を行います。一方で、 Adapterview 系のレイアウトでは、レイアウトの要素は実行時に動的に作られます。その場合、 onView では、その動的に作られた要素をちゃんと取得することができないようです。 その場合は、 onData が提供されているので、それを使うことで代替します。 参考: https://developer.android.com/intl/ja/tools/testing-support-library/index.html ちなみに、 android.support.test.espresso.contrib がespresso-core以外でライブラリとして提供されているのですが、そこでは RecyclerViewActions が定義されています。中を読んでみると、このViewは onView で要素を取得して、それに対してactionしてねと書いてます。なるほど。 http://developer.android.com/intl/ja/reference/android/support/test/espresso/contrib/RecyclerViewActions.html 少し凝った使い方は公式でも用意されているので、参考になるかもしれません。 https://google.github.io/android-testing-support-library/docs/espresso/advanced/index.htmlMore