【READYFOR】実践!フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
![フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first](https://cdn-ak-scissors.b.st-hatena.com/image/square/28b19d0bba428e8c31bb6b838741856ee5ea92c6/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fb570fd447ae141b3bd53a6e6870219e4%2Fslide_0.jpg%3F17293649)
【READYFOR】実践!フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました!」「Aクラスのドラゴンを相手にしてる最中だってのに!」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野(しっぽ) (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
筆者は元々デザイン系の出身なので、ソフトウェアのテストというものを真剣に考えたり調べたことはあまりなかった。この記事では、そんな自分がブラックボックステストをやることになり知った、組み合せテストにまつわる問題について説明する。 本記事の概要 テストにおいてパラメータの組み合せが厄介な性質を持っていることに気付いた 組合せテストの負荷を軽減する「ペアワイズ法」というものがある ペアワイズ法を使って無料でテストケースを生成できるPairwiserというWebアプリケーションがある 組み合わせの数が多すぎる あるWebサイトに、以下のような典型的な検索UIがあったとする。この画面を対象にブラックボックステストを実施したい。 検索UI: 文字列の部分には以下のような文字列を入れてテストしたい。 一般的な文字列 未入力 極端に複雑な文字列 極端に長い文字列 チェックボックスの部分はオンとオフしかない
単体テスト 結合テスト システムテスト(機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト(シナリオテスト) 運用テスト 現場(案件)によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト(Integration Test)以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ
概要 この数年 「QA(Quality Assurance)エンジニア職」 という職種が重要視されております。 所謂、品質保証です。 2000年代には、求人自体も少なかった職種ですが、昨今はIndeedやスタンバイなどの求人情報専門の検索エンジンで 「QAエンジニア」 「テストエンジニア」 「品質管理エンジニア」 で検索すると大企業からスタートアップまで多くの掲載求人がヒット・掲載されています。 最近は、企画段階から 「QAエンジニア」 が参加し、プロダクトUI・UXの意見交換や、仕様書レビュー、テストフロー、リリース判定基準、どのテストレベルを対象とするか策定する。 そのため、QA職種だからこの範囲(領域)だけという決まりはありません。 また、QA職種詳細については 「品質担当でも名称がいろいろ」 に記載しております。 「QAエンジニア」 って、そもそもどのような役割なのでしょうか? 下
機能テスト、制御フローパステスト、システム統合テスト、ビルド検証テスト..... これらは、用語の最後に全部「テスト」がつくので同じ類いのことを指しているように聞こえますが全く違う概念です。 ソフトウェアテストがわからないとか、やっていてわけがわからなくなるという人がいますが、この全く違う概念の区別がつかないのが大きな原因なのではないかと思っています。 この件をわざわざnoteに書こうと思ったきっかけは、このにしさんツイートがとっても的確で素晴らしかったからです。 このツイートのきっかけは、シナリオテストが技法なのかテストタイプなのか?という問いかけでした。 「シナリオテスト」って、JSTQBの定義では技法です。けど、実際の現場では、テストタイプとして使われる時もあれば、テストレベル、またはテストフェーズとして使われることがあります。これは「機能テスト」にも言えることです。つまり全く違うこ
はじめに これはシステムエンジニア Advent Calendar 2016の22日目の記事です。 色んなプロジェクトでのテスト体験や自分で学んだことをもとに、ポエムを書きます。 言いたいこと 普通にテストをこなそう 面倒だと感じたら、テストの設計か作業プロセスに問題があるから見直そう テストでは検証したいことを決めて、それに集中しよう ソフトウェアテストについての知識はざっと知っておこう 前提 本来はSIの現場で考えた場合、 UAT(受け入れテスト)やST(システムテスト)などにも言及すべきかもしれませんが、 あくまで僕個人という開発者目線なのでUT、ITが中心の内容になっています。 なんで作業が捗らないんだろう? Javaを用いた金融系の業務システムをつくっているある日でした。 自分の作業がなんか思ったように進まないなぁということに気づきました。 「何に時間を使っているんだろう?」 な
はじめに 複雑な仕様を整理する。テスト担当者の仕事の1つはこれです。 ソフトウェアが仕様通りに動くかどうかを確かめるのがテストの役目です。ですが、複雑な条件が絡み合った仕様をテストする場合には、まず仕様を把握し、理解しなければなりません。これがなかなか骨の折れる作業です。 もちろん、この悩みはテスト担当者に限ったことではなく、開発設計者にとっても同じように悩ましい問題でしょう。次から次へとクライアントから降ってくる、追加の要求を、すっきりと仕様に整理して、不具合のないシステムを作ることは決して簡単な仕事ではありません。 とりわけ、やってくる要求は既存のシステムの仕様とは無関係にやってきます。追加の仕様を設計、実装する際には、既存の仕様と整合性をとらなくてはなりません。「とりあえず」、で修正してみたものの、テストをしてみると、不具合が発覚。再度修正したら今度は別のところで不具合が発生…
Latest version 0.8.6 for Eclipse 3.2, 3.3, 3.4, 3.5 [2011/10/17] Version 0.8.6 for Eclipse 3.2, 3.3, 3.4, 3.5 Released.[2011/10/17] [0.8.6] Changed a exception handler of djUnit class loader. [Fixed bug] Mojibake of djUnit class loader message. [Fixed bug] SWT's "no more handles" occurs. [Fixed bug] Coverage target line(finally clause) bug with asm1.5.x. Bytecode process was improved. Version 0.8.
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード(または実行結果)を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
Androidアプリのテストに関する課題 Android端末の普及は世界規模で増加の一途をたどっています。2011年秋冬モデルが発表され、発売予定のものを含むと日本で発売中のAndroidの携帯端末は100機種に迫ろうとしています。読者の皆さんの周囲を見渡しても、電車や街角でAndroidを採用したスマートフォンなど携帯端末を使用する人をよく見かけるのではないでしょうか。 そして、スマートフォンに留まらずタブレットやミュージックプレイヤー、電子ブックリーダー、POSレジ、テレビなど、さまざまなデバイスがAndroidを搭載し始めています。Androidの採用が増えるにつれ、Androidアプリの種類が増えるので、アプリの開発案件も増えることになります。実際、本稿を読んでいる開発者の方の中にも、すでにAndroidアプリの開発に取り組んでいる方も多いのではないでしょうか。 筆者も普段の業務の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く