読者です 読者をやめる 読者になる 読者になる

Dreamland-夢と想いと小さな工夫

自分の中にある想いだったり日常の工夫だったりをすこしずつ書いていこうかなぁって思ってます。

仕事中にアウトプットできたらいいのにな、という思い

最近テストの自動化に対する仕組みつくりを手がけています。

開発経験が無いので、テストコードを書くのも、テストプログラムを構成するのも、データ駆動の仕組みを入れるのも、自動実行や自動報告の仕組みを入れるのも、ぜーんぶズブの素人からのスタートで、それでも・・・

・ページオブジェクトを用いたSeleniumのテストスクリプトをつくる

・テストの準備段階の処理クラスを別に作成して呼び出す(Selenium)

Excelからデータを読み込んでデータ駆動のテストができるようにする(Selenium)

テスト管理ツールからSikuliのテストをキックさせてスクリプト完了をもって成功と判断させる(エラーが起きたら失敗とする)

・Jenkins+Maven+JUitを用いてSeleniumの結果をテスト管理ツールに反映させる(今試行中)

というところまでたどり着きました。

 

コードを書く機会がほっとんど無かったあたしでもできるんだからみんなもできるよ、うん。

 

上記の活動を通して実感したのは、

これまでたくさんの人がいろいろ試行して、それをブログにUpしたり質問サイトに投稿したりしていることで、助けられているところが大きいなぁ、ということと、

「こんなことできたらいいな」を実現してくださった方々がそれを公開してくださっているからこそそれを組み合わせてやりたいことができるんだなぁ、ということ。

 

そういう活動の大切さが身にしみました。

 

だから私もできるだけ自分の失敗や体験をUpしていきたいな、って思います。

ただ、ひとつ厄介なことがあって・・・

職場でやっていることを公開するには自分の環境で再度やらなきゃいけない。

同じことを復習するという点ではそのほうがよいのですが、時間には限りがあって私の体力にも限りがあるので、それが確実にこなせられない;

本当は職場でやったときにすぐ情報を公開できるのがいい。新鮮なうちに情報が出せるのがいい。

だけど職場ではアクセスが禁止されているんですよね。このブログサイトにしても。。。

 

機密情報の漏洩を防ぐことは大事。心がけるのも大事。

だけど、なんでもかんでも禁止すればいいっていうのは違う。

だって、インプットは構わなくて実際恩恵を受けているんでしょ?

だったらアウトプットする・・・義務とまではいわないけど、そういう貢献って大事だと思う。それができないのはなんだかなぁ・・・

ていうのもひしひしと感じました。

 

そもそもそういうお試しは個人でやれよ、という意見もあるかもしれません。

でも、企業はそういう活動を応援する側になるほうがいいんじゃないかな?

テスト対象分析のためにモデルを描いてみる試み

現場でも最近テスト設計という言葉は当たり前に使われるようになり、テスト設計を推進しているところですが・・・

よく耳にするのは、「仕様書が無いとテストは考えられない」という一言。(従って仕様書がある程度完成しないとテスト設計ができない。と。)

よっぽど未知の世界の商品でないかぎり、ある程度は考えられるでしょう???と私は思っているので、このギャップはなんだろう?と考えてみることにしました。

きっと彼等はそもそもテスト対象の分析がうまくできないのではないか?全体像をつかむ訓練ができていないのではないか?という仮説をたてました。

事あるごとに、まずは全体像を絵に描いてごらん、登場物を出してごらん、という話はするのですが、なかなか描こうとしません。これは私にも当てはまるのですが、絵にすると絵をがんばって描こうとしてしまうんですよね・・・・・

でもUMLとか全く勉強していないとやはりハードルは高い・・・(そもそも私もぜんぜん描けない・・・)

そんな折、TEF道で開かれた勉強会の資料を拝見して「ドメインモデリング」というキーワードを得ました。

・・・これなら簡単に描けるんじゃね??

ネットを調べるうちに、エンティティと線だけでとりあえず描いてみるというのはどうだろう?と思いました。

 

現場で適用するために、モデルに対して以下の要件を持っています。

・ラフに、こういうモノが登場してこんな処理をするよね、を示したい。(だいたいの認識を共有するのに使いたい)

UMLの知識が無いと全くわからないのは嫌(簡単な説明でだいたい分かるくらいがよい)

・自由に描きたい

・既存のモデルのお作法に引っ張られたくない(ガチガチに守るということはしたくない)
・だけどゆくゆくはクラス図や他の図に発展するとよいと思っている
・エンティティと関係線と関係の記述は必要
・既存のフリーツールを使いたい。パッと描けるのがよい

 

ということで、astah communityを使ってクラス図を利用して描いてみよう!という試みが始まりました。まずは世の中にありふれたログイン機能に対して描いてみました。

当たり前にベースドキュメントは無いです。単に世の中にあるログイン機能とはだいたいこんな感じだよね?を示したものです。

 

こねこねしてできた作品がコチラ(ドメインモデル・・・??)

f:id:shiozi:20151207203459p:plain

クラスを描くと難しく考えてしまうので、エンティティと線で描いてみました。

矢印は流れがあるところに矢印を使っています。
集約と汎化の記号は使ったほうが便利だと思ったので使っています。だけど1:多とかいう数についてはまだ意識して書いていません。単に「このエンティティはこういうものを持っている」「このエンティティを具象化するとこんなものになる」程度の意味で使っています。

この程度なら、あまりモデルに慣れていない人でも、インプットとなる情報から、気になるワードを出すだけ出して、関係線で結んでみることができるかな、と思いました。

ログイン機能の図を職場のメンバーに見せてみたところ、そこそこ納得してもらえました。

 

で、こちらの図に対してプライベートなSNSに投稿したところ、なんと久保秋さんから「ロバストネス図にしちゃったほうが良い気が・・・」というアドバイスがやってきました! 

 ろ、ロバストネス図かぁ・・・あ、でも、描けそう。

ネットで画像検索するといろんな図が掲載されていて、いろんな図を見ながら描いてみたのがコレ

f:id:shiozi:20151207203349p:plain

 再び久保秋さんからアドバイス。

コントローラーはシステム内に収めるのがよく、バウンダリーはシステム間のインタフェースとして扱うとよいということで、インタフェースとシステム内の処理シナリオを意識して再度描き直し!

f:id:shiozi:20151207204827p:plain

確かにそれぞれシナリオが見えるようになりました。
処理がより明確になりました。おぉぉ!

そして、これならUIに馴染んでいるブラックボックスなテスト担当者に、UI操作の裏でこんなことが起こっているんだよーというのを理解してもらうのに役立ちそう!

あ、でも、これ、ちょっと描きすぎているかも・・・メンバーに説明するのはこれくらいで良いかもしれないけれど・・・これは臨機応変にズームイン・ズームアウトさせるのがよさそう、と感じました。

ちょっとすっきりさせるためにまとめて、最終的にこうなった!

f:id:shiozi:20151207205246p:plain

なお、図の左下にコメントを入れている件について、この図ではエンティティにどんなものがあるかというのは描かないほうがよいと思うのですが、思いついたらまずは描いておくということを止めないようにしようと思っています。最終的に邪魔なら別の図に分ければよいかな、と。

そして、この図をもとに開発側と認識合わせを行なって、そこからテスト要件を載せていくとよさそうだな、と思っています。その工夫はこれから考えるところです♪

私はユースケース図は描いていないのですが、ドメインモデルとユースケース図を描いてからロバストネス図にいくほうがよいようですね。たぶん私は最初のモデルを描いている時点でユースケースが思いついているのだろうな、と思っています。

 

ログインだけでなくいろんなシステムや機能のドメインモデルを描いていくつもりです。

自分の中の探索的テストに対する感覚

探索的テストは、

コンテキストによって様々な解釈があると思うし、

それらがいずれも正しいとも間違っているともいい難いものだと思う。

ただ、ある程度の共通認識は必要なわけで、

それはなんだろう?と考えたくなるのはわかる。

 

私個人としては、

私自身が思考によりコントロールできる要素と

自分が本来備えているものなので人に説明したところで伝授できない要素がある

と認識している

 

コントロールできるのは、その製品やソフトウェア全般に共通する情報から探索内容と狙いどころを決めること

コントロールできないのは、直感と、なんだかよくわからない遭遇(なんかもってるっていうやつ)

いつもはこの両方をなんとなく駆使しているなーと感じている。コントロールできる範囲で絞り込んで攻めているのだけど、それとは別個にコントロールできないものが稼働している感じ。

 

でもって、この両方を持ち合わせている人は世の中にはそんなにいないんだな−という感覚も持っている。最近感じるようになった。

つまり、探索的テストは誰にでもできるといえばできるけど、成果がでるかどうかはやはり差が出てしまうもの、だと思っている。

 

ドメイン知識を持っているほうが探索的テストをしやすいのは、コントロールできるものをたくさん持ち合わせているから

天然と呼ばれる人のように何のスキルもなく不具合を見つけまくるのは、コントロールできないものを持ち合わせているから

天邪鬼はどっちかなぁ?!コントロールはできないよね(笑) 人と違うことをやりたがる性分だと不具合を見つけやすい。じゃぁ人と違うことを考えればよいのかというとそれだけではなく、直感の要素を含んでいると思う。

 
もう一つの視点から考えてみる・・・
目的によっても探索的テストは異なるものになると思う。
 
・振る舞いを見ないと見つからないものを見つける探索的テスト
スクリプト作成の無駄を省くための探索的テスト
スクリプトテストが不十分なのを補う探索的テスト
 
それぞれに注目する箇所が違うから、思考も違う。
自分たちがやりたいのはどれ?を明確にしたほうが戦略も立てやすそう。

(あんまり明示的に戦略を立てることが無いので曖昧にしかいえない^^;)

 

ともあれ、昨今スピードが求められる時代において

探索的テストを如何に駆使するかがカギとなることは確かで、

探索的テストは少なくとも思考が必要であり、指示通りが前提の作業者としてのテスターでは務まらないことは明確である。

テスト担当者のレベルアップが必要だよ、ということが早く世の中に広まるといいと思う。

アパレルのお話

そういえば・・・

以前アパレル業界のお仕事の話をツイートしたときに、

これ、ソフトウェアテストだったらどうなるのか表現してみてって宿題もらっていたのでした^^;

ということでその宿題をこなす前提のお話をここに書いておこうと思いました。以前ツイートしたものを載せます。

 

アパレルの世界では、流行色やテキスタイルやラインなどを踏まえて「だいたいこんなイメージ」っていうデザイン画を描き、そこから人間が着用することを前提として生地の特性を踏まえた上で型を作ります。この型を作るのがパタンナーの仕事。このあとは量産か一品モノかでちょっと工程が変わります。

絵を立体にするというのもなかなか大変です。更にそれを生地で実現するのは結構頭をつかうんですよ^^;どの繊維でどんな糸でどういう組織(織り方編み方や密度などで生地の特性が変わってくるのです)の生地を使おうか?それをどうやって膨らまそうか?どうやって立たせようか?などなど。

更に、中身は動くわけですから、動いたときにどうなるかを考慮しなければなりません。 着れたけど動けない・・・( ̄◇ ̄;) 人形を演じるならともかくw 動くためにはゆとり、もしくはあきというものがなければなりません。あるいは伸縮性。

つまり生地特性によってパターンは変わりますし、ゆとりやあきのとりかたはデザインの維持と相談になります。 ここがパタンナーの力量が問われるところですねー

そして着脱ができなければなりません。 実際縫製検査してるときにあった事例ですが(ということは確認を怠って縫製までしちゃったわけですがw)着れない・・・( ̄◇ ̄;)なんてことになります。 これもデザインと生地により選択肢がいろいろ。

ちなみに量産の場合はパターンメーキングのあとにグレーディングというサイズ展開作業が入ります。これはこれで難しい。。。これをパタンナーがやるかどうかは組織によるかと。あと、そこらへんの量産モノはある程度型が決まってるのでCADでやります。さすがにCAD普及してると思うけど・・・

こう書くとデザイナーさんは楽に見えるかもしれませんが、世の中の流れをキャッチするのはやはり相当いろんな情報を集めていると思うです。。。私は技術専攻だったのでデザイン方面はちょっと疎いσ^_^;でも売れるものをデザインしなきゃビジネスとしては成り立ちませんから、やはりデザイナーも楽ではないと思うのです。また、パタンナーと一緒に考えていく姿勢がなきゃ良い形の服が出来上がりません。

でもってパタンナーさんはデザイナーのイメージを汲み取り、素材とにらめっこし、着脱や人間の動きを考慮した上で最適解をだすという役割を果たします。 よって、パタンナーのほうが面白いという感覚は私ももってます^ ^ でも作業トロいからパタンナーにならなかったけどw

で、どんな職に就いたかというとアパレル業界のテスト屋さんになったと・・・笑

仕事の中で一番面白かったのは、デザイン検品と呼ばれるもの。

パタンナーが頑張ってパターン作成したあとは、実際の生地でまずサンプル品をつくるのです。そこから量産のゴーサインを出す前に、様々な観点からこの製品に起こりうる問題を想定し、それを回避する案を提示していくのがデザイン検品のお仕事。

その観点は人の動きによる力のかかり具合だったり、生地の特性による強度のバランスだったり、素材の組み合わせによるお手入れの仕方だったり(取り扱い絵表示や注意書きのあたり)着用目的に対する懸念事項とその対策だったり・・・ 抽象化するとソフトウェアも同じかなーと思います。

ちなみに中途採用同期のおにーさんと二人で言ってたのが、「一人前の検品担当って、欠点に呼ばれるよね?」でした。 他の人て同じように検品してても見つけるんだよねーって。 その感覚も違いはないなと思ったりしてます。 でもって、見つけるのが楽しいと思ってたかというとそれは違うなぁと。

どっちかというと、こうしたほうがいいよね、こういう対策とりましょうか?って考えてアドバイスするのが楽しかったです。結果を踏まえてどうするか一緒に考えたり提案したり。

だからソフトウェアに対しても、テストだけをするというのではなく、その後どうしたら良いかを一緒に考えたいなぁって思っています。

これのソフトウェアテスト版をつくれと・・・^^;;;が、がんばろ。

 

仕様を理解しないでテスト実行してもよいのか?

ちょこちょこ書こうと思いつつ・・・

Blogを習慣にできている人はすごいなぁと思う。

 

最近のできごと

テスト担当者は仕様を理解していなくてもよいのか?

 

たぶん周りの人はみな「そんなことはない」と言うと思う

だけど現実はどうかというと・・・

テストスクリプトに書かれていることが理解できればそれでよいと(暗黙的に)思っているテスト担当者がいる。

 

そして

仕様を理解する=仕様書を読む、仕様書に書かれていることを(表面的に)理解する

ということではないのだけど

仕様書に書かれていることがすべてでありそこから発想することができないテスト担当者もいる。

 

なんというか、仕様書依存症みたいな人もいる

仕様書が無いとテストを考えられないと言う人も結構いる。

 

そういう人たちは、そのテスト対象の持つ役割や機能を説明できないケースが多いと感じている。

 

誰かの投稿で「6歳の人に説明できないのであればそのことを理解しているとは言えない」といった言葉を見たことがある。

6歳に伝わるかどうかはさておき、機能にたいして枝葉を取っ払って簡潔に「こういうこと」と説明できる訓練が必要なんじゃないかな?

 

うーん、でもそれ、私もできてないよね、まだまだまだ。

だから職場の勉強会メンバーとそういう訓練をするところから始めようか、という話をしています。これから少しずつ実践するつもり。

ある程度訓練のしかたがわかってきたら現場のメンバーに広めていきたいと思っています♪

はじめのいっぽ

初めてソフトウェアテストの世界に入ったとき
本当になんにも知らない人だった
ただひとつだけ
テストは別の業界で一人前になっていた

繊維のテストがある
糸のテストがある
生地のテストがある
服のテストがある

強度のテストがある
色持ちのテストがある
デザイン検品がある

いわば負荷を与えた状態にして行うテストがある
繰り返しによる劣化具合を見るテストがある
テストの結果からどう対応するか決める
直せないこともある。タグなどの注意書きで対応することもある
問題が起こればなぜそうなったのか原因を探る

似てるところがいろいろある
それを実感するようになったのはつい最近のこと
抽象化することに慣れてきたっていうことなのかなぁ?(*^ー^*)

こんなちょっとしたこと、これから書いていこうと思ってます。