ITmedia Biz.ID：オフィスソフトで100段落の“長文”ダミーテキストを自動生成する
WordやPowerPointでちょっと何かを試したいとき、適当な文章（ダミーテキスト）を作成したり、既存の文章からコピペする場合がある。実はもっと簡単にダミーテキストを生成する方法があるのだ。 WordやPowerPointで資料を作っているとき、ちょっとしたダミーテキストが必要になる場合はないだろうか。また、後輩に使い方を教えたり、自分で新機能を試したりするときも適当なサンプルが必要になったりする。そんなとき、適当に文章を作成したり、既存の文章からコピーする場合が多いが、実はもっと簡単にダミーテキストを生成する方法があるのだ。 オフィスソフトには、ダミーテキストとして利用できるサンプルテキストの生成機能が用意されている。まずはWordとPowerPointの場合だが、文頭に「=rand()」と入力してみよう。オートコレクト機能が有効になっている場合は、ダミーテキストが生成されるはずだ。
QA と QC とテストエンジニアリングの違い [google]
Google Testing Blog より，QA と QC とテストエンジニアリングの違いについて． Google Testing Blog: The difference between QA, QC, and Test Engineering コミュニケーションを円滑に進める為に「用語の定義」は非常に大切だが，重要なのは世間一般の定義よりも，その組織 (や関連組織間) で定義が統一され，役割が明確になることだと思う． ということで，これはあくまでも Google Testing Team の見解に過ぎないが，まあなにかの参考にはなるかな，と． まず QC (Quality Control) はというと… In the classic definition QC is short for Quality Control, a process of verifying predefine
ユーザーテストを行う企業文化（インタラクション・デザインの未来）: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 設計を詳細な段階まで落とし込んでしまう前に、プロトタイプを作ってユーザーテストをすることは、Webサイトのようなインタラクティブシステムをつくる上ではとても大事なことです。 そのことはユーザーテストを繰り返すたびに実感できることです。 ユーザーテスト＝ユーザーの行動に訊ねる、そして、感じとるよくユーザー視点に立つといいますが、頭で想像するだけではやはり限界があります。 なので、ユーザー視点に立ったつもりであれこれ考えて根拠のない仕様確定を行うよりも、早い段階で簡単なプロトタイプを作り、実際のユーザーの行動に訊いてみるほうが実はずいぶんとラクだったりします。 この場合、ユーザーの行動に訊くのであって、ユーザーの意見を訊くわけではありません。 ユーザーテストは、いわゆる他のユー
googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]
昨日に続きますが、ディベロッパーサミットでgoogleの開発プロセスについて聴講してきました。Googleは一味異なるプロセスや組織をお持ちのようです。請負開発をされている方には新鮮なのではないでしょうか。工藤氏はGoogleのインフラ寄りの話、小松氏は開発プロセスの話で講演されていました。サービスインフラも開発プロセスも私にとっては身近な話ですが、ここでは、小松氏の講演について書こうと思います。講演では、極めて異例/エキセントリックというプロセスは話されていませんでしたが、以下は、特徴的と感じました。 異なる観点から複数のレビューを実施していること。いわゆるperspective-based readingを実施しているそうです。役割分担型レビュー（reviewというよりはおそらくinspection）で、セキュリティやユーザインタフェースの観点から見たデザイン/ソースコードの妥当性検証
![googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7f2a4ced7f91e578679d11d5fcc8f34c5d080289/height=288;version=1;width=512/https%3A%2F%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-83-100x100.png)
ウノウラボ Unoh Labs: The Joel Test
こんばんは、naoya です。 今年の初めに Joel on Software 日本語版が出版されました。その本の中でソフトウェアチームの良さを計測するためのシステムとして、Joel 氏はジョエルテスト (The Joel Test) を書かれています。 今日は、まだ入社して２週間しかたっていない新人の naoya がウノウでの取り組みをジョエルテストにかけてみたいと思います。 1. ソースコード管理してる？ もちろんです！ウノウでは、svn を使ってソースコード管理しています。 2. ワンステップでビルドできる？ ウノウで開発しているウェブサービスは、すべて php ですのでビルドするという概念がありませんが、クイック POPFile のようなパッケージ製品はインストーラまでを含めてワンステップでビルドできるようになっています。クイック POPFile では、バッチファイルを使って簡
ウノウラボ Unoh Labs: テスターを雇わない経営者の誤った理屈 best5
こんにちは！ やまもと＠テスト番長です。 みなさんはJoel on Softwareという本（とWEBサイト）をご存知でしょうか。 以前ウノウラボでもnaoyaさんがThe Joel testのエントリを書いています。 サイトの記事をひとしきり読んだあとで、本は買って積んであったのですが 先日ふと手に取りぱらぱらページをめくっていたところ、 テストについて書いた面白い章があったのでご紹介します。 ■ 第22章 テスタを雇わない（間違った）理由、ベスト5 1.バグは怠惰なプログラマから出てくる →人は誰でもうっかりミスを犯します。他人の目から見たチェックをすべきです。 2.私のソフトウェアはWeb上にある。バグはすぐに直せる →リリース後の修正はずっと高くつくものです。 3.ユーザがソフトウェアをテストしてくれる →会社の品質に対する印象を悪くします。 4.テスタとして優れた資質のある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
