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.

Advertisements

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.