新着記事

Viewing posts by 渡辺美由紀

TORICOの品質管理業務 2. 検証に必要となる知識


こんにちは、品質管理チーム (QCチーム) の渡辺です。
ちょっと遡りますが、わたしがQCチームに初めて配属時とこれまでのお話をしましょう。

どこにでもシステムは組み込まれている

 わたしはこれまでは運営業務のお仕事が中心でした。
リアル店舗では接客、商品仕入れ、コーナー作り、特典作成、Web店舗では通信販売、電子書籍販売、バナー、サイトページ、企画などのページ作成、またカスタマー業務と幅広く携わってきました。
 お勧めの作品がお客様の目に留めてもらうために、工夫を凝らして試行錯誤して、作品の売行きが好転すると、次回も頑張ろうと意欲が湧くものでした。
そのために、システム開発者に協力をお願いし、サイトのレイアウトや企画を伝えては、変更やシステム開発をしてもらっていました。
漫画のコマをページに載せたり、スクロールしても付いてくるキャラ画像を設置してもらったり、特典のダウンロード機能を付けてもらったりと、工夫を凝らしたシステムを作ってもらい導入してもらいました。
現在も漫画全巻ドットコムサイトで継続されている全力推し宣言もその一環でした。数年後にお勧め作品がすべてアニメ化になった時は、心の中でガッツポーズしたものです。
わたし自身のWeb業務は、HTMLタグで色や文字を変更したり、時にはサイトのプログラムリニューアルで当時人気のBootstrapに切り替える作業や自社レジ作成のお手伝いをしていました。そんな中で、Web初心者よりは“Webを理解している”と思ってました。

 ご興味あればこちらから ⇒ 漫画全巻 全力推し宣言ページ

あの頃のWeb知識は初心者と一寸法師の背比べ

昨年10月にQCチームが立ち上がり、配属されたわたしは、今までの経験が活かせると大いに喜びました。
なぜかというと、業務内容が「デバッグ作業」という、サイトの中でお客様が検索や購入する操作をセッションごとにテストいき、操作中に不具合は出現しないか、レイアウトは崩れていないか、バグ発見次第に開発者へ報告する、ということだったからです。
また「開発中システムのテスト検証」もお客様にみせるサイトに関わる事なので、どちらもいままでの経験が役立っています。
そしてもう一つのミッションが「セキュリティ強化対策の検証」です。
この3つの業務を通して、システム開発者のお話を聞く機会も増えてきて、ようやく、わたしの持つWeb知識があまりにも少なくまた基礎が無いことが気づきました。開発者では良く会話の中に登場するAPI、プロトコル、AWSなど、単語の意味が分からない。いまや小学生から習う“インターネットの仕組み”も理解していませんでした。

Web知識は本から取得するのも一つの手


 そんな時に上司より良い教材を提供された、SB Creative刊『イラスト図解式 この一冊で全部わかるWeb技術の基本を読みました。
インターネットの基礎知識からセキュリティの脆弱性の脅威まで幅広く扱っていて、単語も調べられるので、とてもに役立っており、いまでも読んでいます。

本の詳細は出版社サイトへ⇒『 イラスト図解式 この一冊で全部わかるWeb技術の基本 』

読んでいくとスマートフォンでおなじみの「アプリ」画面は、chromeの画面と同じ「ブラウザ」であるなど、目から鱗なお話もあり、面白いです。
まだまだ、初心者に毛が生えたレベルのわたしですが、ここからもっと知識を蓄えて開発者たちの会話が分かるように努力していきます。

TORICOの品質管理業務 1. システムの動作検証の流れ



こんにちは、品質管理チーム (QCチーム) の渡辺です。
QCチームのお仕事の中に『システム動作の検証』というお仕事があるので、少しお話をしようと思います。

検証とは?

検証とは、2つの意味があります。
一つは、仮説が正しことを証明するために調べる事、もう一つは、しっかり調べ事実確認する事です。
わたしたちのお仕事の検証は前者の[仮説が正しことを証明するために調べる事]です。
どの部分で検証するかというと、システム開発担当が、構築したプログラムをサイトの本番環境(お客様が閲覧する環境)へ反映する前にわたしたちが検証を行っています。
ここでは検証の環境に応じて、テスト環境ではテスト検証、本番環境では本番検証と使い分けしておきます。
【参照】実用日本語表現辞典【検証】

完成されたシステムでも仮説?

開発者は依頼された仕組み(システム)をプログラミングします。この時の環境はローカル環境(開発者のパソコン内)だったり、開発者同士の共有環境だったりと、外部には絶対に流出しない環境で作成され、完成した段階で、本番環境にもっとも近いテスト環境に反映されます。
開発者の環境では完成しているのだから、もうすでに仮説ではなく定説になるのではと思われるかもしれません。
しかし、ここで問題なのが、正しく動作するという『証明』が開発者の環境下のみというところにあります。
わたしたちのお客様はいろんな端末を使って、サイトに訪れてくれます。
そのお客様が開発者と同じ端末で操作が行われることはそう多くないのです。
そのため、開発者の環境下の端末だけでは、完全には『証明』が出来ないのです。

QCチーム作業が始まる

ここからが、わたしたちQCチームの作業になります。
テスト環境に反映されたシステムをテスト検証します。
テスト項目書に「〇〇をクリックすると◎◎が開く」とあれば、そちらに沿って正しく動作をするかを調べます。
システムが正しく動作していれば「結果=◎◎が開く」となります。こちらで1項目クリアになります。
一見、すぐに終わるのでは?と思われがちですが、端末やブラウザを変えて、同じテスト項目を繰り返し行っているので時間がかかります。

端末は複数台を常時稼働

主に使用している端末はパソコン、スマートフォンのiPhone、android、ブラウザは、edge、chrome、firefox、safariにて行っています。
ボタンを1つ押してページが切り替わるという単純なテスト検証でも少ないても6回は行っていることになります。
また操作する人が変わると同じ端末であっても、なぜか結果が変わることもしばしばあるので、できるだけ数人で行うようにしています。

気になる事はとことん

そして、少しでも気になることがあれば、同じ操作を繰り返し行い、これは正しく動作していると納得いくまで行います。
何か引っかかる事がある場合、本番反映された時にそれが致命的なことになりかねないので、原因が判明するまでは検証を繰り返します。
どんな操作を用いても正しく動作することを「証明」するには、何度も繰り返し検証をしてみるということがとても重要なことなのです。

最後は本番環境

テスト検証にて、動作確認が終わったら、本番に反映されます。
テスト環境が本番環境に一番近いとはいえ、本番環境においても動作を『証明』しなければなりません。
また、稼働中のサイトなので、お客様がいつシステムを使用するか分かりません。
そのため、速やかに追加したシステムが正常に動作をするか、既存システムも動作しているかを素早く検証する必要があります。
そして、全てのシステム動作の検証が終わり、ようやく追加プログラムが正しい事を『証明』できたことになるのです。

以上、QCチームの『システム動作の検証』について、掻い摘んで解説してきましたが、いかがだったでしょうか?
この記事を通して、少しでもわたしたちのお仕事に興味を持っていただけたら、幸いです。
Search