はてなブックマーク

ログラスさんのQAでこのような記事を出されています。 note.com その中にある品質富士山というのが本当に素晴らしいのでその良さを語りたいと思います。 品質富士山の詳細はこちらから確認してください： 8/8(木)_Findy_ワンチームで勝つ:プロダクトチームの中でのQAエンジニアのふるまい事例 - Speaker Deck 最初に見た感想 まず「なんてわかりやすい図解なんだ！」と思いました。 それからじっくりと見て、「なんて誠実に作られたモデルなんだ！」と思いました。 品質富士山のいいところ 私なりに品質富士山のいいところを言語化したいと思います。 パッと見て何が大事なのかわかる これはモデルとしてとても優れていると思います。 パッと見て山だなとわかる。 名前も品質富士山、と大変わかりやすい（変換しやすいのも地味に嬉しい） モデルとしての表現の秀逸さ 上に向かって、下の部分を達成した

QAの部署から開発の部署に移ってから１年が経った。 感情の赴くままにその感想を書いていこうと思う。 QAでの経験を活かすのは普通にできなかった 「QAでの経験を活かして高品質なアプリケーションを開発します！」と昔の自分は息巻いていた。 しかしそれはとても難しかった。というか、今もできていない。 そもそもQAできてなかった どうして昔はQAができていたと過信していたのだろうか？ 僕は新卒で入社してから６年近くQAをやっていたが、実際はQAの真似事をしているだけで、「ただの設計書の誤字脱字チェック」であったり、品質分析とは名ばかりの「バグを分類ごとに数えてそれっぽい良いカンジの報告書を作ること」であったりテスト設計と言いながら実際は「その場の思いつきのテストケースとそれっぽいテスト計画書作成」とかをやっていた。本当は品質を保証なんかできていなかったし、品質向上もできてなかった。 QAの時は、た

転職挫折エントリ（SIer QA→Webエンジニア） みなさまこんにちは。 今回私が転職に挫折しましたので、よろしければ何かの参考になればと思い経緯を公開させていただきます。 ※想像以上に伸びたので、ブコメを拾って脚注を追加しました。そんなことしてる暇があったら開発しろって？うるせえ今からやるんだよ！ 当方スペック まずはじめに私の大まかなスペックです。 27歳 地方国立大の情報学科を卒業 SIerのQA*1として5年目*2 うち７ヶ月は開発（レガシーシステムだったので言語はCOBOL） 社外活動も多少取り組んでいる プライベートでの学習はソフトウェアテストが中心、開発はあまりやってない なぜ転職しようと思ったのか？ 理由は以下の通りです。 ゆくゆくは自分でアプリ開発をしたい→それにつながるアプリ開発の仕事がしたい しかし現職でアプリ開発の部署に移るのは難しそう（運用保守の案件になる可能性

清水吉男さんが永眠されました。 初めは実感がわきませんでしたが、時間を置いて少しずつ、そうか清水さんが亡くなられたのか、と悲しみを噛みしめる思いでいます。 清水さんと私 清水さんのことを知ったのは、僕が社会人一年目で半分社内ニート的なことをして過ごしていた時に、清水さんのホームページを見つけたのが最初でした。 ソフトウェアエンジニアのためのホームページ Presented by System Creates Inc. その後、日科技連のコンテンツ"Quality One"で、清水さんの文章を読みました。特に衝撃的に印象に残っているのが次の記事「論文を書くことの大切さ」です。当時はこの記事を印刷して、持ち歩いていました。 https://www.juse.or.jp/sqip/mailnews/qualityone/sp2/index.html#03 「格物 致知」としてソフトウェアの世界全

これはソフトウェアテスト Advent Calendar 2017 - Qiitaの8日目の記事です。 アドベントカレンダーの昨日の記事は、テストを書くときに心がけていること - Qiitaでした。 テストコードを書くときのコツについて分かりやすくまとめられています。ぜひ読んでみてください！ さて、わたしはQAと開発の関係を良くするパターン・悪くするパターンと題して書いていきます。 QAと開発の関係 QAと開発は、一般に（少なくとも私の経験上は）密接な関わりがあります。例えば私の周りでは、以下のような関わりがあります。 開発部門が作ったプロダクトをQAがテストする 開発部門の開発プロセスについてQAがアドバイスしたり、一緒にプロセスの改善を考える 開発部門の品質評価、不具合分析についてQAがアドバイス、サポートする しかし、ここで重要になってくるのがQAと開発の関係性です。 QAと開発の関

ソフトウェアテストの小ネタ AdventCalendar2017（3日目） 僭越ながら、3日目を@mhlycこと私リリカルが努めさせていだたきます。 qiita.com前回はオムそば氏の記事でした。「市場バグを引き起こした優秀なデータたち」という記事で、次にテストするときに試してみたいネタが載っていてテンションが上がりました。 teamomusoba.hatenablog.com エンジニアに「は？」とキレられたバグ票ワースト5 さて本題です。 テストを生業にしている方は、バグ票、チケット、障害連絡票など呼び方は様々だとは思いますが、いずれにせよテストでバグを見つけた時にそれを報告するレポートを作ると思います。 今回はそんなバグ票の中で、僕が過去にやらかしてきた選りすぐりのワーストプラクティスをお届けします。ぜひ反面教師にしていただいて、有意義なエンジニアライフを送るのに役立てていただきた

この記事を書いている動機 Twitterである方が「ほとんど専門外だけどもっとテストのことを知りたい」みたいなことを書かれているのを見かけて、最初はその人に直接リプライしようかと思ったのですが、もしかしたらガチの初歩からテストの勉強したいって人は他にもいて、意外に需要あるのかも？と思ったのでブログとして書くことにしました。 目次はこちら。ガチの初心者の方でもわかるような資料を選んでいます。 この記事を書いている動機 テスト入門にちょうど良さそうなスライド（手前味噌含む） テストをやることになった新人が読むべき最初の記事 この3冊は必読。しかし最初から全てを読まなくてもいい 何はともあれ「第１章（導入部）」は絶対に読もう 「仕様書通り」だけがテストではない テストプロセスについて テスト観点 is 何 問題 テスターと開発現場 おわりに テスト入門にちょうど良さそうなスライド（手前味噌含む）

ソフトウェアテスト勉強会～テスターと創る開発現場～ 先日こちらの勉強会に参加してきました。 tohoku-dev.jp 参加した感想と今後の抱負について、つらつらと書いていこうと思います。 @m_sekiさんのお話 Rubyのコミッタをされている@m_sekiさん。CheckingとTestingの話を皮切りに、テスターと開発者のロールについてお話しされていました。CheckingとTestingの説明については@m_sekiさんのアップされている資料をご覧ください。 speakerdeck.com 開発者とテスターのロール @m_sekiさんは、開発者とテスターのロールについて以下のように説明されました。 開発者 ほしいものを実現する 仕様を具体化する 実装を考える プログラムを書く・直す テストする テスター ほしいものを実現する 仕様を具体化する 実装を考える プログラムを書く・直す