TestLinkでテスト計画のコンボボックスを切り替えられない

仕事でTestLinkというテスト計画/実績管理ツールの用法を確認していたのですが、その中で出てくる「テスト計画」というコンボボックス（ドロップダウンリスト、プルダウンリスト）をいくら変更しても、変更が反映されず元の選択状態に戻るという現象が出て困っていました。TestlLinkのバージョンは1.9.17です。

TestLink 1.9.17 テスト計画コンボボックス

日本語で検索してみても該当ケースが見当たらなかったので、TestLink開発元のMantis（課題管理システム）で課題（issues）を調べてみることに……。

testlink.org / mantis / View Issues

http://mantis.testlink.org/view_all_bug_page.php

View Issuesを選択肢、「Search」のテキストボックスに「test plan」と入力して絞り込み。出てきた結果を上から順に見ていくと「Trying to switch current test plan only works after refreshing the page（テストプランの切り替えが、ページをリフレッシュした後でないと反映されない）」という問題が報告されていました。これですね。不具合は新バージョンである1.9.18で解消されているようです。

0008468 / Trying to switch current test plan only works after refreshing the page

http://mantis.testlink.org/view.php?id=8468

実際にやってみたところ、F5を押せば確かに反映されました。さて、バージョンを上げるか、この暫定対応策で切り抜けるか、どうしたものか迷いどころです。

ソフトウェア・テスト PRESS Vol.5

ソフトウェアテスト教科書 JSTQB Foundation 第3版

気になる本「問題解決力とコーディング力を鍛える 英語のいろは」

職場の同僚がこんなのあるよ？と勧めてくれた本ですが、気になります。買おうかな。

問題解決力とコーディング力を鍛える 英語のいろは

問題解決力とコーディング力を鍛える英語のいろは [ 鈴木達矢 ]

IT系の仕事をやっているとどうしても英語に触れざるを得ないのですが、なかなかそのこと自体を認めようとすらしない人たちに遭遇します。元々が英語圏で開発された技術が大半である上、そもそものプログラミング言語自体が英語ベースの文法。英語圏の人に比べれば日本人は非常に不利な状況からスタートしているはずなのに、そこを埋める努力をしない。というか埋めないといけないと思っていない。

そういう人たちが別にどうなろうと知ったことではないのですが、そういう人たちがやり損ねた仕事や「この文章が分からない」というくだらない英訳や、ダサい名前のプログラムなどを訂正する作業にいい加減嫌気がさしているので、是非皆さんには英語を「Google翻訳でも何でも使って読めないことはない」というくらいにはなっておいてほしいので……そのとっかかり、啓蒙の切り口を知る材料になれば、という若干ダーク側寄りの前向きな動機で読んでみたいと思っています。

いや、たとえば、英単語の意味を知っているだけで、詳しいその言葉の技術的な意味を知らなくてもそういう名前がついた経緯などが推測できたりするわけですよ。そうすればカタカナで丸暗記しなくても、だいたいの意味や雰囲気がつかめたりするわけで。そうなるとカタカナ単語を丸暗記していた脳みそをもう少し他のことに使えますよね。そういうこと。そういうメリットをみんなが享受してくれれば、もっと仕事は楽になったり、もっと先のことを考えたりできるようになるとおもうのです。

というわけで若干前向きな言葉を書き連ねて終わりにしておきます。あとで注文しとこ＞本。

DBの「登録日」「更新日」の指定方法に関するメモ

業務システムを作っていると、結構データベースの各レコードに「登録日」「更新日」などを設定するようになっている設計を見かけます。ここのデータを誰がいつ書き込んだのかを記録することで、後々いろんな調査などに使うというものですね。

これ、過去に見たやり方がいくつかあるので、自分用の整理もかねて列挙しておきます（いや、ちょっと仕事で同じような話が出て自分でしゃべった内容を忘れないように書いておくだけです）。

44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)

SQLの中でその時点の日時を入れる

InsertやUpdate文の中で、データベースサーバーの日時を取得して登録/更新日に設定するというものです。一番一般的じゃないでしょうか。たとえばSQL Serverの場合「GetDate()」という関数を呼べばその時点の日時を得られるので、それを使って日時を記録します。
この方法だと、たとえば100件のデータを登録した際に、1件目と100件目では日時の「秒」あたりが変わる可能性があります。日時の取得は1行ごとに実施されるので、刻一刻と進んでいるサーバー時刻もずれていくためです。1回のデータ登録で日時がずれるというのは気持ち悪いと思う人もいるかもしれませんが、過去に1回だけこれが有効に働いたことがありました。
特に処理速度測定のためのログなどが織り込まれていないシステムで、データ登録や書き換えのパフォーマンスが問題になった際にこの登録日、更新日がデータベース処理のパフォーマンスを示す貴重なログとなったのです。というわけで、業務上「本日付でないといけない」といった要件がないのであればデータベースサーバーの日時を都度都度入れるのが案外最良の選択だったりします。

グラス片手にデータベース設計（生産管理システム編） （DB　magazine　selection） [ 梅田弘之 ]

SQL発行の前にいったんサーバー日時を取る

InsertやUpdateを行う前に、一度「日時を取るSQL」を実行してその時点のサーバー日時を取得。その情報を以後のSQLに埋め込んで登録日や更新日を設定するというもの。メリットとしては1回のデータ処理に関する日時がそろうことで、綺麗なデータができる、という点。
あとあと登録日をピンポイントで検索したいといった場合、これにしておけば「12月1日の13:10:23に登録した全データを取得」なんてこともできます。ただ、このメリットを享受したいのならば、個人的にはこういう「データ登録処理のログとしての登録日、更新日」と、「業務上の検索処理のためのデータ登録日時」は別の列として用意した方がよいように思います。
データにしても機能にしても、本来想定していた用途以外に使い始めると意外にいろんな問題が出てくるものです。たとえば、会社のPC起動や終了を出退勤の管理に使う、といった場合、「単にPCを再起動しただけで退社扱いになる」といったケースを想定しないといけないなど、本来、それ専用の仕組みを用意すれば考える必要が無い手間が出てきたりします。
やはり、データベースのデータ1つにしても「何のためにその列を作ったか」をきちんと考えて設計し、その考えを反映した作りを心がけるべきだと思います。
話が飛びましたが、SQL発行前にサーバー日時を取るというのは個人的にはこの「登録日/更新日」に関してはあまりおすすめしないと考えます。

ITシステム開発徹底攻略【電子書籍】[ WEB+DB PRESS編集部 ]

トリガー機能を用いて登録する

過去に1回やったことがあるのがこれです。データベース側のトリガーという機能を用いて、「データ登録、更新時にこの処理を行う」という設定を行います。この「処理」の中で「対象となるレコードの登録日、更新日に年月日を登録する」という処理を入れておくことで、各業務処理のSQLには登録日、更新日を入れる必要がなくなるというものです。
大量のデータを扱う処理などの場合、使うか使わないか分からない日付情報取得のためのSQLを毎回削れるメリットがある上、トリガー処理内で「接続ユーザーや端末情報も取得して記録する」なんて処理をいれることで厳密なデータ更新ログをとれるというメリットもありました。
ただ、初期データの大量登録や、登録日、更新日まで指定した日付にしてテストデータを作りたいといった場合はトリガー機能のON/OFFを切り替えるなど、少々手間は出ますが、システム運用が始まってしまえば結構メリットがある方法です。

というわけで、何気なく追加しがちな「登録日」「更新日」もその実装方法はいろいろありますし、それぞれ意味やメリット、デメリットがあるので、適当に設計して適当に実装しないようにしたいものです。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ