Hello! Blog is just starting!
Keep your ear to the ground!
New posts are coming!

4th FEBRUARY 2015

Most common testing issues

Doesn’t matter it’s GUI input field or command line parameter. There are some basic criteria you may take into consideration before you push your code to repository.

Value ranges

Often problem may be value range mismatch between input validation and database. Letting user enter large integer number while database stores only tinyint (0 to 255). Or designing currency input  where negative value is enabled by default but not desired in the business case. This applies to string length as well.

Example: donation amount field where user can enter negative value.

Interval as an input

When this is solved by implementation of two input parameters/fields (from and to) you may meet following problems:

Usually value ‚from’ is expected to be lower (or equal) then value ‚to’.

Example: in most implementation attempts searching by (date > 01.01.2015 AND date < 01.01.2014) is not desired but returns no result letting user peacefully persist in error.

Moreover, lack of validation may result in serious business damage if the query does return a result (in meaning:  from -∞ to 01.01.2014 and from 01.01.2015 to ∞) but user won’t be aware of mistake he did.

Intervals – open or closed

Consider open and close interval issue. Depending on business case it may be desired to use one of them.

GUI – Tab order

There is tab order! Yes, some users does use it! Please note that every time you add new input field or just reorganize them tab order won’t change automatically. It’s really annoying when you tab randomly over all window’s controls just because somebody forgot that. And in fact, it looks a bit unprofessional when you jump from the oldest to the newest control revealing design history of the window.

26th SEPTEMBER 2014

PowerShell and command line quotes- surprise!

Version: Powershell 3.0

Calling PowerShell from Windows command line

If you want to call any PowerShell script passing parameters there are at least two ways to do that.

From PowerShell console:

Or from windows command line:

Hereby I say, syntax of the second one is wrong and may lead to serious problems in business.

What happens in the second case then?

All the parameters are being passed to windows console and parsed. For cmd.exe doule quote means moreover „do not split” or „keep it together”. In this case it has no meaning at all. Powershell will receive only:

And this are four parameters!

By the way, do you know PowerShell Community Extensions? This toolset contains EchoArgs which I find useful in case of proper parameters passing check. Just replace application/script name with EchoArgs.

And here we go! The first example:

And the second one: (the wrong one)

A good practice

In my opinion a good solution is to use single quotes when passing parameters to PowerShell from Windows command line and double-single-quotes for passing apostrophe.