Pages

September 20, 2014

URL With Parameter Opener v1.0

Analysts in our project really liked my extension JIRA Issue Opener and ordered me one more similar extension, which have to open URL with one parameter. Basically the same extension, but without adding /browse to URL.

They need it because they often need to open prototype URL with different page ID-s: http://prototype.example.com/project/index.php?id=888, where last number 888 can be changed according to page that you want to open.

So I made new extension URL With Parameter Opener and now I am a little bit confused what should I do with JIRA and Fisheye Commit Graph Openers – seems like I don't need them anymore.
URL With Parameter Opener

September 17, 2014

JIRA Issue Opener v1.1

New version of JIRA Issue Opener with better trimming system is available!


JIRA Issue Opener

In latest version
  • All spaces in the beginning and in the end will be trimmed
  • Skype formatting will be trimmed:
    [16.09.2014 13:34:34] Irina Ivanova: KEY-776
    will be recognized as KEY-776

Fisheye Commit Graph Opener v1.3

New version of Fisheye Commit Graph Opener is available.


In latest version
  • Name change: fisheyeGraph became Fisheye Commit Graph Opener (more clear and intuitive)
  • Autocomplete size is enraged from 3 to 5 rows
  • Added error message for blank value

September 15, 2014

Testing In History, Part III

One more set of historical videos about [not software] testing.

British Pathe doesn't have normal embedding system, so all links will be opened in their website.

Safe As Lightning Man-Made Lightning (1941), 00:52

Glass Research AKA Pilkington Glass Works (1959), 02:02

Acoustic Chamber (1962), 01:58

Golf Ball Test (1961), 01:40

Seat Testing (1950), 00:49

Testing Domestic Appliances Aka Electric Gadgets (1958), 02:09

Safe Testing (1958), 02:59

Safety Straps Beware (1960), 02:08


See also previous parts:
Testing In History: Part I – Stress Testing
Testing In History: Part II – Functionality Testing

September 13, 2014

Some Examples Of Testing Tables And Views In Database

In our project testers are using database (DB) all the time. We query/modify/delete data in test databases to check data flows, to configure something or to just make testing faster (sometimes it's way faster to change some value in DB than to change it through application).

That means, that testers can also test the DB objects – tables and views.

Usually I test them after creation – if I have to test some new component in which the table or view has been added/modified, then I always test this table or view. And in this post I write about some common but not trivial problems that I see at work.

Popular question: should I test DB object, if .sql file of creation was made by analyst?
Definitely yes, you should. Generally analysts don't know much about DB rules and they may not see what problems may create "smelly" structure. Not to mention the fact, that you should always test not only developers, but analysts (and everyone!).

How can I test tables?
Here are some concrete tips that I haven't seen in other articles.
  • If there is field like STATUS and field like IS_DELETED find out what's the difference between them (if you want to delete row should you set STATUS=DELETED or IS_DELETED=Y)? Often they are used for the same purpose and you actually don't need one of them. If you keep both and they do the same thing you will end up to change always both values, which is double work.
  • If there is some value with foreign key its type and size should be the same as primary key to which it refers. Example:
    table USER has PK column NAME(VARCHAR2 55)
    table ACCOUNT has FK column USER_NAME(VARCHAR2 50)
    type of ACCOUNT.USER_NAME is wrong, because it's shorter than the column which it refers to. So you can insert some long username into USER table, but you won't be able to create account for that, because ACCOUNT table can't save that long username.
  • Column type and size should match the data. For example, it seems like column for the telephone number should be the NUMBER, but actually people want to write their telephone numbers with spaces and dashes, so the column type should be rather VARCHAR (you should also check does appropriate application field has necessary constraints – you shouldn't allow to users insert symbols into field that saves data into NUMBER column).
  • NULLABLE property should match the logic. If some field is not mandatory in the application, then appropriate column should not be NOT NULL.
  • Almost all tables have (or should have) primary or foreign keys, so you should understand them. If some column refers to the data from another column – it should be the FK for sure.
  • Table and column names should be logical and clear without documentation. This may seem obvious but a lot of testers are afraid to ask to change the names, because they thing that it's not important (we already have bad name, ok then, nobody wants to change it, lets move on). But actually it is important, because good names saves your time in the future when you need to come back to this table and can't remember what was this bad name for.
  • Learn about database normalization. There are some rules in organizing tables and fields to minimize redundancy.

How can I test views?
Testing view means basically testing the SQL query what creates the view. So you need to know SQL to test does query return all necessary data and doesn't return unnecessary.
  • Double rows with identical data is common problem in queries with OUTER JOIN conditions. View shouldn't return double rows even if it seems harmless (you never know how you gonna use this view next month, maybe you need to count all rows).
  • You need to understand difference between OUTER and INNER JOIN. OUTER JOIN may return more data than you need, INNER JOIN is faster.
  • Usually you don't want to see cancelled or deleted rows in view. Analyst may not write that condition in specs, because he thinks it's too obvious and developer may not write this condition, because it wasn't mentioned in specs. So be sure you understand the purpose of view, to decide should it return cancelled rows or not.
  • You may have some table with properties or parameters in your DB and view can take some parameters from this table. In that case it's possible that in test DB you have (and always had) only one parameter, but in live – two or more. Developers often don't have permissions of live DB, so they don't know the real data. Be sure that query can work with multiple rows in this parameter's table (maybe developer used = instead of IN).
  • Be sure that data in the view is logically correct. For example, I had once one view with two columns in it: DOES_DOCUMENT_EXIST and DURATION_OF_DOCUMENT. And I found some rows where DOES_DOCUMENT_EXISTS was N, but DURATION_OF_DOCUMENT > 0 – obviously if document doesn't exist duration should be 0. In that case error can be in raw data in tables, not in view (then you should find out why data is wrong).
  • If queried table has ID column which you don't need in view – keep it anyway. ID is the easiest way to find row in the table, so keep this possibility.
  • Not exactly the DB thing, but some field in application may take value from view. You may check does size and type of returning value match the size and type of field. For example, what happens if you return value with maximum possible length? Or may be your field takes values from two columns (sums two texts, for example)? What happens if both texts are with maximum size?
  • SQL query should be easy to read, so if it's complex query be sure that every table has unique and clear alias, columns are in right order (for example, START_DATE is right before END_DATE or ID is at the beginning), column names are unique (if query returns two ID columns from different tables be sure the name of each column is changed to something like USER_ID and ACCOUNT_ID) and the whole query is formatted. Even if you understand the complex query now, you may forget about it in a year, so make it as easy as possible to save the time on understanding.
  • NB! Dangerous step, if you don't understand how view is working don't do that! Run query of the view in live DB. It may identify performance problems (live DB usually contains more data than test DB) and in DB testing it is always good to work with real data.

If you also support customers, then probably you are the person who uses DB more ofter than others. Which means you are the person who should care about DB structure and keep it clear and tidy.

September 12, 2014

JIRA Issue Opener v1.0

In our project we use JIRA. And sometimes someone in our team doesn't send link to issue, but sends only its key (I don't know why). So I wanted to somehow simplify JIRA issue opening process with its key.

I found 3 existing Chrome extensions that cat do that, but they had their own cons:
  • JIRA assistant for Google Chrome
    First of all – it's too complicated. There is a lot of functionality that I don't need. For example, you need to insert not only URL of your JIRA, but also username and password (I don't want to save that info in extension). It also makes address bar in your browser into JIRA console after typing "jira " – I can't use searching because of that (when I want to google something about JIRA I start with "jira..."). And finally, there is no autofocus in field where I can insert key, so I need to do one extra click.
  • SearchInJIRA
    Simple, nice (design is very similar to mine), but I didn't understand what king of URL you need to insert into Options. Some magic URL of the JIRA search – I don't know that one.
  • GoToJIRA
    Again simple and nice. And again, problem with the URL. In the Options you need to insert URL/browse/KEY-OF-THE-PROJECT (and into extension field you need to insert only final number), which makes impossible to use extension, when you have many projects.

So I did one more extension which simply opens issue in new tab, using your key – JIRA Issue Opener.

You can read details about it on page JIRA Issue Opener v1.0 and find source code on GitLab.




See new posts:
September 17, 2014 JIRA Issue Opener v1.1

September 8, 2014

Scripting For Automated Update (Tomcat 6) [DEPRECATED]

UPDATE: This post describes old version of the script. New version is located in new GitHub repo github.com/iriiiina/version-updater – see post Bachelor Thesis "Version Update Automation Using Scripting Language Bash".


Last month I tried to explore is it possible to improve versions updating process in our project? By improving I mean make it faster or easier. Here are the results.

Challenges
  • 21 modules
  • more than 13 environments
  • on average developers publish about 10 versions per day (of different modules)
  • 2 application server technologies: Tomcat and Oracle WebLogic

Process
Before improvement the process of updating version was the following:
  1. developer makes some changes and publish a new version of module with this changes
  2. tester logs in into the server of the environment he want to update and download published version
  3. (this step is only for WebLogic) tester precompiles the downloaded file with bash script
  4. tester undeploys old version
  5. tester deploys new version with bash script
  6. tester change the version number of the module in the versions tracking system
For testers it takes approximately 3 minutes per version (depends on module and server technology).

Process improvement options
I saw 2 ways to improve process:
  1. Start to use some software for deploy automation, for example Chef, Ansible, Bamboo, Jenkins.
  2. Improve existing scripts, so testers could skip steps 2, 3, 4 and 5.

Problems of first option with new software:
  • Chef and Ansible are the easiest one for the beginning, but for the project which already use Atlassian products is more logical to use Bamboo (then you can link version with JIRA issues).
  • If still use Chef or Ansible, then basic levels (free of charge) does not meets our requirements, so we need to buy advanced levels. Again, it is not very reasonable when you have free possibility to user Bamboo.
  • Bamboo needs to use agents for job execution. In our project we will need about 10 agents, which is quite expensive.
  • Any software installation, configuration, maintaining takes too much time and effort.
  • The final time and effort of the whole update process for testers is actually the same, as the time with improved script:
    • you still need to open the software, which is the same as logging in into the server
    • you still need to define environment, module and version, wich is the same, as run the script with parameters
    • you still need to change the version number of the module in the version tracking system

So I decided to improve existing scripts. Scripts are general-purpose, so I needed to write only 2 (for Tomcat and WebLogic), which I can copy to any server.

Solution
Now human doesn't need to insert commands by hand and wait for the response of each step, so it saves about 2 minutes (script for many modules update saves even more time). And the process is definitely easier that it was, so the goal is achieved.

Also there was performed one very little change in scripts, which according to the principle of Pareto provides the greatest benefit – colored output. First scripts gave meaningful output, but the whole text was white – it was quite difficult to read it. New scripts give errors in red, success messages in green and process messages (for example 'Downloading the file...') in cyan, so reading of new output takes seconds.

Summary
This post could be my answer on the eternal question 'do testers have to write code?'. For all people who work with computers (including testers) programming is not the goal, but the tool to achieve some goal. The most common example – it's the tool to improve some process. So if you want to be effective in your work you need to use tools for improving your processes and not being able to write some code should not be the reason why you can't perform improving. Of course, you can ask someone else to write some code for you, but again it's way less effective than to write it by yourself. In my opinion, even librarian, who works on computer could write a code, to improve books registration process or something like that.

So, good tester who is looking for options to work effectively should be able to write some code.

fisheyeGraph v1.2

New version of fisheyeGraph v1.2 is with improved design!




See new posts:
September 17, 2014 Fisheye Commit Graph Opener v1.3

September 4, 2014

fisheyeGraph v1.1

New version of fisheyeGraph v1.1 is with autocomplete!
In latest version
  • Autocomplete for key word's field
  • Space trimming in key-word and REPOSITORY values
  • Design and texts improve in Options page
  • Icon improve



See new posts:
September 8, 2014 fisheyeGraph v1.2
September 17, 2014 Fisheye Commit Graph Opener v1.3

September 3, 2014

New Chrome Extension fisheyeGraph v1.0

I use FishEye at work to track and search code changes. And my most favorite page there is Commit Graph. In our project we use a lot of different repositories (I have 4 pages of them), so usually finding right repo takes more time, than I want.

That's why I made a simple Chrome extension fisheyeGraph, which opens Commit Graph of required repo in new tab – you need only to insert key word of repo (which you need to specify in Options):


You can read details about it on new page – Chrome Extension fisheyeGraph v1.0 and find source code on GitLab.

In next version I am planning to do autocomplete (it's actually already done, but I can't make work JQuery in extension).

For me this extension saves 30 seconds on each repo opening – some of the pages, that I need to open in order to get to Commit Graphs by hands are heavy – using extension I just skip them.



See new posts:
September 4, 2014 fisheyeGraph v1.1
September 8, 2014 fisheyeGraph v1.2
September 17, 2014 Fisheye Commit Graph Opener v1.3