Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Denisenko氏はこのように述べた。氏は,モバイルテストのテストピラミッドに従って、開始時からテスタが関与するようにアドバイスする。テスタは品質指向の開発者として、他の開発者が高品質のソフトウェアを提供するのを指導し支援することのできる存在であり,手動テストは将来的になくなっていくだろう、と氏は言う。モバイル開発はベンダロックされた分野だ。市場に2つの大手ベンダがあって,オペレーティングシステム,アプリケーション,開発,テストの方法を左右している,とDenisenko氏は言う。多くの企業は、この両方のプラットフォームで自動テストを開発することのできる,万能な自動テスト開発者(ユニコーン)を探し求めているのだ。モバイルに携わるオートメーションエンジニアは、少なくともKotlin、Swift、Java、Objective-C、そしてiOSとAndroidの動作原理を理解する必要がある上に、オートメーションエンジニアからは手動でアプリケーションをテストする能力を期待されていることになる。これは非現実的だ,とDenisenko氏は言う。モバイルアプリは開発期間が短いことで知られており,ほとんどの場合,QAは製品が市場に出回った後の極めて遅いタイミングで実施されている,とDenisenko氏は言う。このため開発チームは、テスト担当者を置かない開発に以前から慣れており,それがテストプロセスの設定に多くの問題をもたらしている,というのだ。最初はゆっくり始めよう,と氏はアドバイスする。開発者と共同で,最初にテスト自動化フレームワークを構築し,スプリントに自動化機能を取り入れ,ひとつのレグレッションシナリオを取り込むのだ。Webやバックエンドに比較すると,モバイルプロジェクトは非常に小規模である。従って独立した自動化チームを設けるのは現実的ではなく,スクラムチームがそのタスクを実施すべきだ,とDenisenko氏は言う。テスタの役割は,開発者が高品質のソフトウェアを提供することを指導し支援することにある,と氏は述べている。"テスタは品質指向の開発者であって,手動テストは将来的になくなるか,あるいは姿を変えることになるでしょう。"テスト可能なコードとテストを開発することによって,開発者自身にテストを実施させたいとする企業が増えている,とDenisenko氏は指摘する。手動テスタから自動化エンジニアになった自身の経験から,氏は,それまでのテスタの役割が,テストを担当するソフトウェア開発者ないしコーチに変わりつつあることを感じている。Denisenko氏に,テスト自動化が失敗する理由と回避策について聞いた。大きな理由はテスト設計です。テストカバレッジを決定する場合、一般的にはユニットテストが70パーセント、インテグレーションテストが20パーセント、E2E自動テストが10パーセント,というテストピラミッドを使用します。モバイルの世界では、このようなテストピラミッドにはならず、砂時計型やアイスクリームコーン型になることがほとんどなのです。多くの場合、独立した自動化チームを用意するということは、チームの主眼がE2Eテストの自動化にあることを意味しています。そのためには、テスト設計に従ってリソースを分散した方が合理的なのです。ピラミッドを使用した方が、アプリケーションに起きていることをよりコントロールできますし、問題点をデバッグする時間を短縮できます。いくつか理由がありますが、状況によって違います。UIテストを行えば、実環境のあらゆる状況における動作をカバーできると考えています。それらのテストを行えば、APIテストやバックエンド、クライアント統合テストなどが省略可能だと考えていますが、それは間違いです。プラットフォームの制限によってテストできないことが、モバイルではたくさんあるのです。単純な例は、外部アプリとの間のディープリンクやプッシュ通知です。ひとつ忘れがちなのが、バックエンドとアプリケーションUIとの間にあるレイヤが多すぎるために、うまくいかないことがたくさんある、ということです。挙げただけでも、サードパーティ、バックエンド、ネットワーク、アプリケーションのネットワーク実装、UIなどがあります。問題がその中のどこで発生したのか、詳細な情報を提供してくれるようなフレームワークは、私の知る限りではひとつもありません。結果として、プロジェクトは保守不可能なテストを抱え込み、テストの自動化に失望することになるのです。新しいモバイルプロジェクトはいつもMVPから始まって、大規模なものに膨らみます。アプリケーションのテスト容易性はいつも考慮外です。UIテスト以外は設計されていません。問題の場合もあります。統合テストはモバイルテストの新たな波なので、それが何であるのか、どうやってやればいいのかという点に関して、すべての開発者が十分な知識と理解を持っている訳ではありません。学ぶ気さえない者もいるのです。自動化されていないプロジェクトに参加する時は、決してキャッチアップゲームをプレイしようとはしないこと。テスト自動化フレームワークを開発する時は、可能ならばベンダのテストフレームワークを使用すること。オープンソース・ソリューションは一般的に、最新OSバージョンから6ヶ月遅れでサポートをリリースする傾向がある(従って最新OSでは自動テストがまったく機能しない)傾向がある上、サポートが中止されることも多いのです。別のプロジェクトで開発されたテストを流用しないこと。自分自身のテストの開発やメンテナンスに集中できず、テストの統合と修正にスプリントを丸ごと費やす羽目になります。ネイティブな言語を使用すること。開発者は怠惰なので、テスト目的のみでrubyやpythonを習得しようとはしません。品質は共同責任であり、チームメンバ全員が貢献すべきものです。次のようなガイドラインがあります。ユニットテストや統合テスト(コンポーネント間の統合)、UIテスト、機能UIテスト、E2Eテストというように、異なるレベルでのテストの実施を推奨しています。できる限り自動化されたテストを使用して、さまざまなレベルでテストを行う方法を習得している開発者の世代を増やそうとしているのです。そのためのチュートリアルも多数作成しています。Googleのテストコミュニティは議論も活動も活発です。Appleは対照的に、ユニットテストとE2Eテストの開発を推奨しています。同社は開発者に対して、ユーザが実施に使用するようにアプリを自動化することと、E2Eを自動化でカバーすることを提唱しています。個人的な意見としては、ベンダは開発者やテスタに干渉せず、戦略の選択を彼らに任せるべきだと思っています。ルールを追加して制限を設ければ、新たな、優れた、革新的なものが作り出される可能性を削いでしまうことになります。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。