ラズパイ[QA編]：タクトスイッチを押したらLチカ
ラズパイの勉強と通して、開発技術の習得とIoTのテストの議論を
進めていきたい思います。
さて、前回の開発編はこちら。
tettan.hatenablog.com
こんなのテストがいるのかと思いますが、
ちょっと考えてみましょう。
単純に考えると、こんなテストケースですかね。
| テストケース1 | テストケース2 | |
|---|---|---|
| 原因：ボタン | ON | OFF |
| 結果：LED | 点灯 | 消灯 |
これだと、単純すぎるので
テスト設計してみましょう。
LEDの状態に着目するとこんな感じでしょうか。
この状態遷移図のリンクを単純に網羅すればよさそうです。
あとは、LEDが点滅しているのですが、
今回は点滅させている理由がわからないので
こちらのテストはスコープ外とします。
この状態遷移図と先に挙げたテストケースとを比較すると
テストケースのほうには初期状態(LED消灯)が明示されていないので
テストが漏れるかもしれませんね。
と書いたのですが、よくよく考えると
ボタンを押したら点灯するので、
こんなテストは必要ないですね。
ただ、状態遷移図を書くと、テストケースのみと比べると
テスト実行の見通しが良くなるので、
やっぱりテスト設計したほうが良いと思います。
ラズパイ[開発編]：タクトスイッチを押したらLチカ
こちらの本でラズパイの勉強少しずつ進めてます。
Lチカのあとは、スイッチということで
「タクトスイッチを押下したらLEDがチカチカする」をやりました。
写真はこちら。
チカチカ具合がわかりませんが
とりあえず、以下のコードでボタン押下でチカチカできました。
import RPi.GPIO as GPIO from time import sleep GPIO.setmode(GPIO.BCM) GPIO.setup(25, GPIO.OUT) GPIO.setup(24, GPIO.IN) try: while True: if GPIO.input(24) == GPIO.HIGH: GPIO.output(25, GPIO.HIGH) sleep(0.1) GPIO.output(25, GPIO.LOW) sleep(0.1) else: GPIO.output(25, GPIO.LOW) sleep(0.01) except KeyboardInterrupt: pass GPIO.cleanup()
ということで次回は、これをテスト対象としてテストを考えてみたいと思います。
こんなおもちゃみたいなものにテストがいるのか。。。
ラズパイの勉強を始める
これからはIoTということで、ラズパイの勉強を始めました(笑)。
というか、1人だと続かないし、進まないので
会社で勉強会を始めました。
いろいろと煽りを入れてくれる人がいると助かります。
あと、みんな楽しそうで良かったです。
ということで、一通り道具をそろえました。
- ラズパイ本体
電源セットをこちらで購入
ホーム - Raspberry Pi Shop by KSY
蛇足ですが、KSYさんからのメールが私のgmailだと
迷惑メールに扱いになってました。お気を付けを。 - キーボード、メモリカード、HDMIケーブル、本、学習キット
これらもろもろは、amazonさんで購入
キーボード
メモリカード
HDMIケーブル
本
学習キット - すでに保有していたもの
ディスプレイ、ノートPC
今は、環境設定、Lチカまで終わって、
これから本格的にというところです。
このブログで記録を残していきたいと思います。
ブランコの件
奇妙なタイトルですが、詳細は後ほど、きっとわかります。
このエントリはこちらの続き。
テスト分析・テスト設計の勉強会でLTしてきたのですが、
その時に具体例として使ったのが
我が家を建てた際の分析と設計の話。
その話で、懸垂用の棒をつけれるのなら、
ブランコはそこに引っかければ良いのでは？
というコメントを頂いたので、それができない理由をお伝えします。
どうでもよさそうな話なんですが、
分析と設計の話に繋がってくるんですよ。
勉強会に参加していない人は・・・なので
では、解説しながら、ブランコの件を書いていきたいと思います。
- お家を建てるときの分析：住む人の周りの成果を整理する
我が家のケースでは、設計士さんの依頼で
「住まいづくりのこだわり」というテーマで
「私」、「妻」、および「みんなで」、
という視点でヒアリングシートに記入しました。
私の視点の例(妻記入)：
ワークスペースがほしい
本が多い。増える可能性もあるので、そのスペースがほしい
トレーニングに使えるものがあると良い
妻の視点の例(妻記入)：
家事導線、工夫したい。キッチン→勝手口→ゴミ置き場
みんなでの視点の例：
ブランコ？(妻記入)
妻の視点の導線はさすがです。私はたぶん出てきません。
あと、「ブランコ？」は庭ではなくて、
家の中で子供が楽しそうに
子供が遊んでいる姿を思い浮かべていたようです。。。
- お家を立てるときの設計：お家の図面を書く
図面では、見事、上記の項目が実現されていました。
ただし、ブランコ以外。
・ワークスペースと本棚は、吹き抜けのデッドスペースを利用
・トレーニングに使えるものは、一階天井の梁に懸垂用の棒を設置
・家事の導線は、お見事。ほぼ直線で10歩で完結します
・ブランコは、設計士の判断で却下
で、なんでブランコが却下なのかというと、
まず子供が小さい時しか使わないので、
お家のライフサイクルから見ると、頑張るところではない。
あと、吹き抜けの梁や懸垂棒に付けるとして、
ペレットストーブがあるので、
ブランコのふり幅を考えると難しい。
という判断でした。
前者は、分析の時点で概ね把握できていたとしても
後者は、設計士さんが設計図を書いて、
その課題解決を考えた時に
スマートに解決できないという判断でした。
さすがプロです。以下は、その証拠写真。
こちらは懸垂棒の写真。これだけだと、
そのままブランコがつきそうですが。
少し見にくいですが、上のほうに懸垂棒が見えます。
その下にはストーブと
ウッドデッキに出るスライド式のドアがあるので
ブランコをつけるのはあきらめるしかないです。
写真を見れば、この懸垂棒にブランコをつけるのは
無理なことが素人でもわかりますが、
ただ、それが設計の段階でわかるかどうかは別問題。
お家ができて、
ブランコをつけようとして無理でしたでは困るので、
分析や設計の段階で残念なお話をしてくれたほうが助かります。
また、どうしてもブランコがいる、ということであれば
設計の段階でどうにかできます。
よくソフトウェア開発の残念な例がありますよね。
我が家が残念なソフトウェア開発の例のようにならなくて良かったです。
ソフトウェア・グラフィティ
書評っぽい文体で書いてみました。
帯に「鬼才・岸田孝一」と書いてある。
読んでみて、それは間違いではないことがわかる。
プログラマをはじめとして、ソフトウェアにかかわる人には
お勧めしたい本である。
こんな歴史あったのかと、氏の歴史を通してわかる。
実はこの書籍は、感想文を書く(送る)ことを条件に頂いた本である。
なので、このエントリはその宿題である。
確か字数の制限があったようだが、忘れてしましまった。
この本は、大きく2つに分かれる。
それは、岸田氏の歴史と現在のSRAのキーパーソンの記事である。
前半も面白いが、また後半もSRAのすごさがひしひしと伝わる。
とりあえず、前半に絞って気になったところを引用しながら、
コメントを沿えていきたい。
プログラマの本来の関心は、そのプログラムをどのような構造に
設計したらよいかということに尽きるのだと、私は考えている。
この当たりの文章は、要するに内部品質と外部品質について
論じているように感じた。が、それが当たっているかはわからない。
あとは、ダイクストラ先生のGOTO文の話。
われわれは、最初から正しいプログラムを書く方法を探し求めなければならない。すなわち、プログラムを人間の目で読むことによってその正しさが確認できるような「正しいプログラムの書き方(設計/表現手段)」が必要なのである。GOTO文はこのような視点から見て、明らかに有害なのだ。
ダイクストラ先生に手紙を送って、講義ノートを取り寄せたらしい。
すごい行動力だ。見習いたい。
以下の文章が一番心に響いた。
開発環境という、自分の仕事のための道具立てを改善しようと考えるさいの本音は、要するに、みんなが、そして特に自分自身が楽しく好きなことをできるようにしようということにつきるでしょう。そうすれば、結果として、生産性の向上や品質の改善は自動的についてくる。そうでなければおかしい。
逆に、生産性向上や品質改善を第一義の目的にしてしまうと、楽しくないことや好きでないこともやらなければならなくなります。そういう環境作りはたいていうまくいきません。
現在、SEPGに近い立場で業務をしているので、個人的な違和感をストレートに表現されていて、100%同意できる論である。
しかしながら、全体を通して、哲学的な文章が比喩として用いられるので、
そのあたりの遊びが嫌いな人は、少し敬遠したほうが良いのかもしれない。
テスト分析・テスト設計勉強会で発表した
先日、こちらの勉強会でLTやってきました。
枠が空いていたので、私で良ければと連絡したら
タイトルのご要望まで頂いて、うれしい限りです。
タイトルが決まったのが1月上旬で
スライドの準備は、2週間くらい前から着手しました。
ただ、その前からどんな話をしようか、妄想してましたが。
当日のスライドはこちら。
(一部のスライドは事情により削除してます)
発表時間は15分だったんですが、30分くらい使って話す内容ですね。
案の定、駆け足の発表になってしまって
そのあとすぐに会場を後にしたこともあり、
聴講者には不評だっただろうなということで少しテンション下がってました。
ただ、後から知り合いに聞いてみると
思いの外、分かりやすかったようで一安心。
で、もう少し詳しく聞くと、"ブランコ？"の件が気になるとのこと。
ここから少し長くなりそうなので
別のエントリーにしたいと思います。
別のエントリーはこちら。
JaSST '17参加レポート
早一週間たちますが、記録のために参加レポートを残しておきます。
聴講したセッションは以下。
- 基調講演：ICT応用S&S製品の品質不良のリスクとSQuaREシリーズ国際標準 - その歴史と概要
- 教科書に載らないテストマネジメント
- テストと人工知能
- 品質保証活動の本質
以下のセッションはパネルのモデレータを担当しました。
- 普及が始まったテストプロセス改善技術 導入・実践着手のために考えるべきこと
準備は大変でしたが、モデレータは楽しかったです。
では、聴講したセッションのレポートです。
- 基調講演：ICT応用S&S製品の品質不良のリスクとSQuaREシリーズ国際標準 - その歴史と概要
タイトルの通り、確かに歴史の話をされてました。
品質特性の話が出てくると、
各品質特性に対してどのように評価に落とし込んでいくのかという
ところがやはり一番気になるところ。
GQMでメトリクス決めて評価すればいいでしょ、という話かもしれませんが
テスティングではなくて開発の初期の段階で
ある程度、練っておくほうが現実的にはスケールしそうです。
ただ、この種の評価をやるかどいうかは、
やっぱり製品やシステム、サービスで異なるでしょう。
QAリードあたりが、旗を振って推進しないと
現場レベルは回らないと思います。
- 教科書に載らないテストマネジメント
司会者のお題にパネリストが応えていくという形式。
テストというよりは、マネジメントの話が多かったように思います。
テストのマネジメントとしては、テストの質とテスト対象の質を
どのようにマネジメントするのかを言う話を聞きたかったです。
- テストと人工知能
今回のJaSSTで聴講した唯一のコアなテスト技術のセッションでした。
講演者の増田さんと伊藤さんからは次のテーマの話がありました。
増田さん
・AIを利用したシステムのテスト
・テスティングにAIを利用する
伊藤さん
・GUIの自動テストにAIを利用する
すべてのテーマが面白かったのですが、
AIを利用したシステムをどのようにテストするのかというのは、
すごく興味のある領域です。
テスト設計をどのような単位(コンポーネント)でやるのかは、
テストアーキテクトの腕の見せ所でしょう。
もちろん全体をどのようにテストするのかという難しい問題もありますが。
- 品質保証活動の本質
いつもかわいがってもらっている奈良さんの講演。
日立製作所の旧ソフトウェア事業部の品質保証の仕組みの話で、
奈良さんのキャラクタも重なって、
引き込まれるように聴き入ってしまいました。
本講演の私の解釈は、次の一文です。
「品質保証の仕組みをその時代のニーズや組織の制約に合わせて最適化してきた」
品質保証という深遠なテーマで地に足のついた議論が聴けて大満足です。
ただ、あえて追加で話が聴きたかったことがあるとしたら
品質保証活のネガディブなイメージをどのように払しょくするかという点です。
というか、上記の要望を会場でコメントしてしまいました。奈良さん、ごめんなさい。
一週間たった今、振返ってみて、非常に充実した2日間でした。
