"テスト/QA"投稿一覧

KAWASHIMA Yoshiyuki

エンジニア

レビュワーの認知負荷を軽くするのが優しさだと考えています。
認知負荷を軽くするには、コード変更量よりも、コードの変更理由が一つであることが望ましいと思っています。
既存の設計上の課題のため、変更理由が一つであってもたくさんの差分が発生するケースはあり得ますが、それは1つのプルリクエストである方が認知負荷は軽いと判断しています。

またどんなに少ない変更量であ... 続きを見る

小川 純平

エンジニア

jQuery は最近はだんだん使われなくなってきていますので、JavaScript 一般としてお答えしますと、私の観測範囲では、Web エディターだと最近は Stackblitz を使っている人が多いです。(※) CodePen もそれなりに使われています。JSFiddle は、使っているところもあるような気はするのですが、私の観測範囲だとあまり頻繁には目にしないですね。
勿論、使ってい... 続きを見る

杉田大樹

プロジェクトマネジメント

最近のスマホの価格は高いなと思います。
一方で、今までが安すぎた部分もあるなとも思っています。
スマホも高性能になり、買換え周期が3〜4年なども珍しくありません。
単年あたりのコストに換算するとあまり変わらないのかもしれないですね。
むしろ、スマホを買い替える時のアプリやデータの移行など、昔よりは便利になったとはいえ、めんどくさいなと思う気持ちが購入の障壁に... 続きを見る

北野勝久

エンジニア

最終的な価格だけに目が行きがちですが、iPhoneの場合は下取りプログラムが充実していので、二世代くらいの周期で買い替える場合、手出しは10万円程度で買えることが多いのではないかと思います。（もちろん購入する端末にはよりますが！）

私自身の感覚としては、毎日これほど使うものもなかなかないだろうなと思っていて、PCと同等価格になっているのは自然な流れなのかなあ、と想像しています...

Dai Fujihara

プロジェクトマネジメント

アジャイルコーチとして、これからの開発にマッチする品質保証の支援をさせてもらっています。あくまで経験に基づいた一般論になるので、状況に応じてですが参考になればです。

まず、今までやってなかったことをいれると「遅く」なります。品質保証のプロセスもそうだし、スクラムの導入、自動テストなども同等です。よって、チームの出力量という意味での生産性は落ちると思います。
続きを見る

Dai Fujihara

プロジェクトマネジメント

とある大きな会社さんの開発方法で聞いたネタです。その組織は、プロダクトチームにQAエンジニアがいて、横断QA組織もあります。

プロダクトチームのQAエンジニアの仕事は、チームに貢献してチームの目標を達成するです。比較的チームに閉じた活動がメインになります。

横断QA組織は、複数のプロダクトチームを横断した視点でQAを行います。大抵の問題は結合時に起きるの... 続きを見る

Dai Fujihara

プロジェクトマネジメント

アジャイルコーチとして支援する現場でよく起きている状況です。

こういう壁を乗り越えるために、アジャイルチームを作るわけなのですが、なかなかチーム組成が難しいのであれば、「共通のゴールを作ること」からはじめてみてはどうかとおもいます。

なんでもいいので、共通のゴールがあれば、自ずと協力せざるを得ませんし、失敗したときに言い訳もできません。
続きを見る

和田健太郎

エンジニア

プルリクの巨大化による弊害はおっしゃるとおりなので、上手く解決したいところですね。
背景などは組織やプロダクトに寄っても変わるので、あくまで個人の体験として回答いたします。

■プルリクは小さくする（ために設計からレビューする）
・「小さくしよう」というスローガンだけで現場が実践できれば世話なく、基本的には理由があるという前提で当たります。
・概ね... 続きを見る

Takuo Doi

エンジニア

状況による部分が非常に大きいので、期待されている形の回答ではないかもしれませんが。

まず、なぜ「レビュアーに優しいプルリクエスト」にしたいのかから考えてみてはいかがでしょうか？
恐らくですが、レビューがボトルネックになって生産性が落ちていると感じているからかとは思います。
ですが、その時間は、品質と保守性を向上させるためには必要な時間なのかもしれません。<... 続きを見る

kentaro haneda（jumbo）

エンジニア

無理に自動化せずともまずはちゃんとテストの体制や仕組みを見直してもいいかなとも思いますが、小さくやっていくとするとリグレッションテストなどをしやすくするアプローチもいいと思います。
細かい機能などは変更頻度も多いでしょうし、追従するコストも発生しやすいと思います。
ビジュアルリグレッションテストを徐々に入れていくことで、変更箇所がリリースに対して想定通り・想定外であることを気づ... 続きを見る

Dai Fujihara

プロジェクトマネジメント

アジャイル開発におけるQAの実現などを手伝っていますが、広義で自動化はとても大切なプラクティスになりつつあります。狭義でのテスト自動化は最重要とも言えます。

# 分岐を含む表示系
- ビジュアルリグレッションテスト（VRT）で十分だと思います。
− もっというと「〜が表示されていること」とかでAssertionをいれなくてもよくなります。データを用意して表... 続きを見る

まきやま

エンジニア

Androidは業務の場合、7以上のサポートをしていますね。
両OSに言えることですが、ユーザー数の割合や開発における課題感と、サービスとして多くのユーザーをサポートすることのトレードオフなど踏まえて総合的に判断することが多いので、一概にこうというのはなかったりします。

どのOSバージョンまでサポートするかは、サービスによっても考慮する部分は違ってくると思っています... 続きを見る

Taketo Yoshida

エンジニア

昔iOSエンジニアをやっていましたが、iOSは比較的に皆バージョンアップしてくれるので-2くらいまでサポートしていましたね。後はアナリティクスを見て、コンマ何％を下回っているものはもう切って良いよねという判断の元決めていました。

横江 亮佑

エンジニア

Android だと Material Design を取り入れた 5 系かそれより下かで大きくAPIが変わりますね。
さすがに 4.4 系など 5 未満を使っている人は減ってきているので、
企業の運営するアプリでも「Android 5 未満は非対応」とするアプリが増えたかと思います。
つまり minSdkVersion が 21 ですね。

それ... 続きを見る

Shoichi Namba

エンジニア

1種類ずつです。（iOSはiPadもあるので実質3Androidも含めると3種類ですが。あと昔のAndroidの機種は残ってますが確認にも使っていません）
なので本気の人に比べるとだいぶやる気不足な感じはしています…。

とはいえむちゃくちゃ流行っているアプリを作れないことには、頑張って動作確認しても困るパターン出会う確率も、実際に困る人も殆どいないと思いますので、そ... 続きを見る

Katsunari Takeda

プロジェクトマネジメント

一般論かつ漠然とした考えにはなりますが、評価制度がMBO型か、コンピテンシー型かによって変わってくるのかと思いました。

- MBO指向であれば、実務で関わることが多い（CPO）配下
- コンピテンシー評価であれば、どちらかというとCTO配下

といったところではないかと。

評価の仕方が満足だった/良かった的...

Suzuki Yutaro

エンジニア

今は開発業務でなくても「プロジェクトに入って要員として問題なく稼働した」という実績を残す時です。
開発に関わるとなると、「プロジェクトの要員として稼働する」「開発業務の一部を担当し、実装する」と、やるべきことが増えます。

実績もないのに副業をするのは所属する会社にも「副業」として関わる先にも迷惑をかける可能性が高いためお勧めしません。
あなたにとっては「副... 続きを見る

kaku

エンジニア

副業となりますとスキル面のハードルが上がるため、初心者はおすすめできないと思いますね。

萩原 北斗

エンジニア

ATDD の取り組み自体は良い考え方だと思います。
スクラム開発の文脈では PO（PdMと同等と定義します） が受け入れ基準となる Acceptance Criteria（ここでは受け入れテストと同義とします） を定義することが謳われていますし、その原理主義的に言えば Shun さんのお考えも不自然ではないと思いました。

一方で、気を払ったほうが良い点としては、実経... 続きを見る

nmatsuo63

データ分析

開発のボトルネックを探ると、Webアプリ開発後の脆弱性診断がボトルネックになりがちかと思います。

弊社ではリリース後にDASTや専門家診断を実施しており、それぞれを同時並行で進めたとしても3週間〜5週間ほどかかってしまっています。

アジリティとセキュリティや品質をどうバランスして対応されていますでしょうか？