Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話 - トレタ開発者ブログ
こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。 初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。 見直しのきっかけ トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。 製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。 入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいち
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
英語ドキュメントが読みやすくなるテクニックで仕様書を読んでみる
たとえ国内で仕事をしていても、IT系の最新情報やドキュメントはほとんど英語のため、英語をすらすら読めるようになったほうがなにかと捗ります。そこで、翔泳社から刊行した『現場で困らない！ ITエンジニアのための英語リーディング』よりテクニックを四つ紹介。さらにAPIリファレンスや仕様書などを実際に読んでいきましょう。 重要なテクニックはたった四つ 本書『現場で困らない！ ITエンジニアのための英語リーディング』で紹介される、英語をすらすら読めるようになるテクニックはたった四つしかありません（もちろん英語の基礎やある程度の語彙は前提となります）。 一つ目は「英語の語順で理解する」。学生時代の名残からか、英語を読むときにどうしても日本語のように文章の後ろから前へ戻るように訳してしまいがちです。しかし、これはNG。英語の語順のまま意味を理解していくほうが素早く読めます。 二つ目は「スラッシュ・リーデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
