-like -contains? I still have to get used

In my journey to learning PowerShell I’ve stumbled upon -like and -contains, which are comparison operators.

-like is used to look for string matches and allows you to use wildcard characters like * (one or more characters) and ? (exactly one character). For instance, to look if the string test matches the string ThisTest, all I have to type is "ThisTest" -like "*test*", which is true. Likewise, both "ThisTest" -like "*test" and "ThisTest" -like "????test" return True.

I can’t hide the fact I’m pretty intrigued by the fact there’s no direct equivalent in Bash. The closest thing to -like I can think of on a Unix’ is grep – which is a command and not an operator. Speaking of which, grep-lovers should be aware that -like gives us a true value only if a full match happens. Therefore, "ThisTest" -like "test" evaluates to false.

The syntax for all comparison operators is the same: a -operator b. To be honest, for me this is logical for almost all operators (think -eq, -ge, etc.), but I still find it cumbersome to read when I use -like (or even -match): reading StringToSearch -like Pattern just doesn’t feel right.

The other operator, -contains, returns true if a collection contains the element on the right side of the operator. Easier shown than explained: "This","Test" -contains "test" is True. This works in a similar fashion to Python’s in operator. Again, though, discretion is advised. If we type "ThisTest" -contains "test" we’ll end up seeing False in the console. This is simply because, unlike in Python, strings are not collections.

A final note about the return value. We might expect all operators to return a Boolean value, but this is not always the case. Actually, quite the contrary: almost all comparison operators (that is, all but -contains and -is) return a Boolean value if the input to the operator (what’s on the left side) is a scalar. If we use a collection as input, then we are returned a list of matches. As an example: "This","Test","tesT" -contains "test" returns True but "This","Test","tesT" -like "test" returns Test tesT.

To know more, don’t forget to check the documentation: help about_comparisonOperators.

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

Advertisements

Learn-Syntax, a.k.a the verb-noun pattern for PowerShell cmdlets

If you’ve poked a little bit with PowerShell, you might have noticed a recurring pattern for command names. The pattern is called “verb-noun” and is followed by each cmdlet, that is, commands internal to PowerShell written in a .NET language – see for example Get-Help, Select-Object.

The list of Microsoft approved verbs can be retrieved by typing, surprise surprise, Get-Verb in the console. It’s also good to notice that:

  • There’s always a dash between the verb and the noun
  • The noun is always singular
  • Other products generally prefix the noun with something specific string (SQL for SQL, AD for ActiveDirectory, …)
  • Nouns are not abbreviated
  • PowerShell is not case-sensitive but all verbs and nouns are Capitalised (increases readability)

Initially I thought that the last choice was a bit controversial. In Bash you can find plenty of short names for commands (think ls, du, df, …) and I admit they’re quite convenient. On the other hand, given a finite – and luckily not so vast – set of verbs, it can actually be easy to guess the name of a command. Want to get a the date? Maybe Get-Date is just what you’re looking for! [Disclaimer: it’s not always that easy… I don’t know you, but Read-Host and Get-ChildItem are not exactly what I’d come up with if I looked for the equivalent of read or ls in Bash!]

Aliases can also be defined (for both cmdlets and functions) via the Set-Alias cmdlet. The big difference with Bash is that PowerShell aliases cannot include any parameter, which means there’s no way to set ll to be the alias of ls -l. However, you can always define a function, which is what happens with Get-Help and help.

As for cmdlet parameters:

  • They are always preceded by a dash
  • They use CamelCase (although, again, PowerShell itself doesn’t care too much)
  • They might be positional, optional, mandatory – you can find all such information by querying for help on a particular parameter: try Get-Help Get-Date -Parameter Format
  • You don’t have to type a parameter name fully, just the number of characters that make it unique (example: Get-Date -Format "%d" and Get-Date -f "%d" are the same)
  •  <TAB> auto-completion works for parameters too (pr0 tip: type just - and hit <TAB>)

Finally, some characters that need special attention:

  • semicolons are used to separate commands on the same line (much like in Bash and Python)
  • curly braces delimit script blocks (we’ll get to these in another post)
  • the pipe character is used to redirect the output
  • the backtick is the escape character

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

Get-Help! (In PowerShell)

Let’s get to the meaty part before delving into the nitty gritty details: PowerShell has got a rather comprehensive documentation, that can be access through Get-Help. This should be enough for you to get started, but if you want to know more, read on!

You can also type help and you’ll see you get to the same result. The only difference is, Get-Help is an internal command (so-called cmdlet) whereas help is a function that calls Get-Help and redirects the output through a pager (more). And you’ve also got man which is nothing but an alias for help to aid penguin lovers use the shell :)

Get-Help supports the wildcard * which is indeed useful to find matches in all the docs installed. If a single result comes back, that help page is displayed. If the search parameter matches more than two pages, a list is displayed in the console.

Once you’ve found the page of interest you can run the command against that document. However, at times you might want to use some parameters to get different results:

  • -Examples returns a list of examples on how to use the command in question
  • -Detailed gives you the detailed list of all the parameters the command supports
  • -Full gives you both examples and details

Do not forget to check out also the “about” files. They form a collection of documents the name of which always starts with about_ and discuss general matters (the use of While, …). Here’s a pointer to increase your appetite for knowledge: Get-Help about*.

On PowerShell version 3 the documentation is not installed by default. The main reason is that documentation can get old quite quickly and retrieving it when you need it is the best way to ensure you’ve got the freshest news. Update-Help as administrator is what you have to do to get it the first time and to update it afterwards.

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“.

First steps in PowerShell

Personally, I tend to resort to my two most favourite tools, Bash (Cygwin) and Python, to automate some of my day-to-day testing tasks.

As I work with Windows systems, I admit both options are suboptimal, especially because they’re not installed by default. Also, the fact that PowerShell is object-oriented, makes it more suitable for some tasks with respect to the other options available. [Disclaimer: I strongly believe there is no “my tool is bigger better than yours” thing and I do not want to convince those who think along those lines. If you’re happy with what you have, I’m happy for you. Move along.]

That’s why recently I’ve started to look into the magic realm of PowerShell. Here I list some information that got me move my first steps – hopefully they’ll be of use to all who embark on a similar journey:

  • Windows 8 and Windows Server 2012 have PowerShell v3 installed by default. Windows 7 and Server 2008 shave got version 2
  • You can choose to use one of the two hosts that come with Windows: the console and the Integrated Scripting Environment (ISE)
  • The console, being based on the same software used for the command prompt, suffers from some limitations – for instance, it can’t display double byte charsets. The ISE can, and it’s got some other advantages, like the ability to display TrueType fonts, and to have multiple PowerShell sessions as tabs. On the other hand, the ISE is not installed by default on Server OSs
  • If you type powershell in the command prompt or cmd or in the PowerShell console you switch instantly from one to the other system
  • In Console, if you press F7 you can see the command history as a popup window. Get-History gives you access to another buffer where commands are recorded.
  • Just like for the command prompt, clicking on the icon in the top left corner of the console window allows you to set your preferences for the window (buffer history, command duplication, height and width, colour, among the most commonly used)
  • The <TAB> key gives you auto-completion
  • Start-Transcript not only logs your command history as you type (like %logstart in IPython) but also records the output for most commands (legacy commands like ping do not have their output recorded). Stop-Transcript clearly stops the logging

This is part of a series of posts on PowerShell. Some of these tips come from the book “PowerShell in Depth“, which I absolutely recommend.

Casual testing of everyday tools – or why people get angry

A decent example of overcomplicated interface

A decent example of overcomplicated interface

Meet KX-TS580EX, a landline phone I’ve recently had to set up for a friend of mine. I’ll refrain from talking about the design, which, to me is not appealing, and go directly to the point instead. Functionality – or better, lack thereof.

Open up the picture, and you’ll notice the display says to set the clock. Now, have a closer look and tell me what action you’d perform to do that, assuming you’ve got no access to the device manual.

I’d look for a menu button, and, failing that, a clock button. To be precise, I’d also look for icons resembling such two functions. Nope, there’s nothing like that. So, the following step would be to decipher all the icons, and see which ones might be related. Here’s what you’ve got (top to bottom, left to right): a key, a 90-deg bent arrow on top of a straight line, “R”, something in between “a steering wheel” and the Mazda logo, the MasterCard logo, a loudspeaker, an arrow pointing to the center of a square, an arrow exiting from the center of a square, the mute sign (although I must admit I know it only because I saw it somewhere else), OK, and a couple of other icons we already are acquainted with.

Now, it turns out the menu is activated by pressing the button with the arrow pointing to the center of a square, probably indicating some kind of “entering”. Intuitive? Not at all. Not for me, and I bet, not for many other people. And I bet, those many other people get angry at the phone itself for that.

But we could go even further. Say, why do some buttons have icons on and above them? How do you access one or the other functions? Depending on the context? Or holding the button for a few second? What’s the steering wheel icon about? And what’s the MasterCard-like one instead? Why choosing an icon which is quite difficult to read to set up call deviation (it’s the second one from the top)? Why going for the obscure “mute” icon? Isn’t there anything more intuitive?

What’s the bottom line here? Two things to take away. First, keep it simple, stupid. Choose complex over complicated. Less is more. Second, as a tester, you’re responsible with the product as a whole. If you think it can be done better, if you believe some annoyances can be polished away, speak up and make sure to inform who needs to be notified. Just report it and motivate it. Worst case scenario it will be just a Wontfix.

Silly policies for the greater good might be not good at all

Documentation overload? – © by Frank Jepsen

There’s a policy at work: technical support cannot hand anything that comes from clients to testers or developers. Anything includes databases, configuration files, logins & password, and so forth.

While the aim is undoubtedly right, to protect clients’ privacy, the whole matter is totally pointless, not to say harmful.

Pointless because anyone, upon joining, signs a contract that explicitly says that disclosing any sensitive information is strictly forbidden. Adding an extra level of enforcement is far from being useful.

Harmful because it goes against testers and devs, by hindering their jobs. Ultimately, they are those who solve the problem for the client.

Share your data within your organisation!

Share it if it can speed up a tester’s life!

English: Program Hello World Česky: Program He...

Make a tester happy and share your code!

You’ve been meticulously written everything down so that anyone can reproduce the bug you found, and I thank you for that now that it’s my turn to test it.

Build version, check. Repro steps, check… almost! One of the first steps goes like “Write a script to insert 10k users.” I rapidly go through the attachments, nothing. Look for some other comments reporting a chunk of related code, still nothing.

Fellow tester, here’s my question to you: Did you code such a program to reproduce the bug? If not, then obviously you should have mentioned what you actually did. If the answer is yes, then why didn’t you attach it?

There’s no shame in sharing testing code. No tester will judge your coding practices, but the point is that not even a dev should be: this is not production code and its sole purpose is to speed up the testing process. Make no mistake, it helps if it’s cleanly written — I can assess its bug-free nature more easily — but it’s not a hard requirement. Another fact that shouldn’t be overlooked is that there might be something wrong in that script, something that invalidates the bug altogether. Hence, the possibility to analyse the original script makes it quicker to find any issue.

In a nutshell, sharing can really improve the quality of testing process.

Don’t forget when commenting bugs

Be explicit when reporting bugs!

Some aspects unsaid, others unclear, missing and fuzzy reproduction steps. All things that contribute to decreasing the quality of bug reports and comments, which eventually can slow down a tester’s (and a dev’s!) work.

Here’s a little list of what I think shouldn’t be missing when describing or commenting a bug:

  • Build number: explicitly write the build number in which you found the bug or you used to verify it has been fixed.
  • Use plain English: its not kool if u write it like this. It’s actually annoying. Also, a proper use of punctuation will increase readability.
  • No abbreviations/acronyms – unless you expand them first.
  • Clear reproduction steps: even though you think a step is obvious, write it. It might not be that obvious when you – or someone new – will have to test the bug again after three months.
  • Bonus: if the bug has to undergo triaging, write a very brief summary (“Still present”, “Looks good yet some other problems appeared”) right after the build number and left some empty lines below it (so it’s visually separated from the rest). You’d be amazed how much time you will save.

The starting point

Start Your Engines - by marksweb

Start Your Engines – by marksweb

I love testing, and I’d really like to get better and better at it.

That’s why I’ve decided to start this blog. To write about the aspects of the job I’d like to pinpoint, create some sort of personal best-practices, eventually hone my skills, and, who knows, generate some reaction and engage in new conversations with fellow testers.