Monday, 17 February 2014

Back to Basics: How to use the Windows Command Line

Those of us that have worked with computers for most of our lives, take the command line for granted. We know it exists, we know basically how to use it, and we know how to find the commands we need even if we can't remember them.

But, not everyone knows how to use the command line. I've had quite a few questions on the various courses I conduct because people have no familiarity with the command line. And the worst part was, I could not find a good resource to send them to, in order to learn the command line.

As a result, I created a short 6 minute video that shows how to start the windows command line, change to a specific directory, run some commands, and how to find out more information.



Start Command line by:
  • clicking on start \ "Command Prompt"
  • Start \ Run, "cmd"
  • Start \ search for "cmd"
  • Win+R, "cmd"
  • Windows Powertoy "Open Command Window Here"
  • Shift + Right Click - "Open Command Prompt Here"
  • type "cmd" in explorer (Win+e, navigate, "cmd")     
  • Windows 8 command from dashboard
Change to a directory using "cd /d " then copy and paste the absolute path from Windows Explorer.

Basic Commands:
  • dir - show directory listing
  • cd .. - move up a directory
  • cd directoryname  - change to a subdirectory
  • cls - clear the screen
  • title name - retitle a command window
  • help - what commands are available
  • help command - information on the command

If anyone wants more videos like this then please either leave comments here, or on YouTube and let me know. Or if you know of any great references to point beginners at then I welcome those comments as well.

Thursday, 13 February 2014

Introducing Virtualbox modern.ie Turnkey Virtual Machines for Web Testing

My install of VirtualBox prompted me to update today. And I realised that I hadn't written much about VirtualBox, and I find any videos I had created about it.

Which surprised me since I use Virtual Machines. A lot.


No Matter, since I created the above video today.

In it, I show the basic install process for VirtualBox. A free Virtualisation platform from Oracle which runs on Windows, Mac and Linux.

Also, Modern.IE, which I know I have mentioned before. The Microsoft site where you can download virtual machines for each version of MS Windows - XP through to Windows 8, with a variety of IE versions.

Perfect for 'compatibility' testing - the main use case I think Microsoft envisioned for the site. Or for creating sandbox environments and for running automation against different browsers, which I often use it to do.

I even mention TurnkeyLinux, where you can find pre-built virtual machines for numerous open source tools.

In fact the version of RedMine that I used on the Black Ops Testing Workshops to demonstrate the quick automation I created. I installed via a TurnkeyLinux virtual machine.

Oracle, even host a set of pre-built virtual machines.

A New Feature in VirtualBox (that I only noticed today)

I noticed some functionality had crept in to VirtualBox today.

The cool 'Seamless Mode' which I had previously noticed in Parallels on the Mac (as 'Coherence' mode) and on VM Fusion on the Mac called ('Unity' mode). This allows 'windows' on the virtual machine to run as though they were 'normal' windows on your machine - so not contrained within the virtual machine window.

I love this feature. It means I no longer have to keep switching in and out of a VM Window and can run the virtualised apps alongside native apps. And with shared clipboard and drag and drop, it seems too easy to forget that I ran the app from a VM.

If you haven't tried this yet. Download VirtualBox, install the Win XP with IE6 VM, and then run it in 'Seamless' Mode so you have IE6 running on the desktop of your shiny whiz bang monster desktop. Try it. Testing with IE6 becomes a fun thing to do - how often do you hear that?



Thursday, 6 February 2014

How to emulate mobile devices using Chrome browser

Google Chrome continually changes, which usually means good news as new features appear. Unfortunately sometimes it means changes to our existing workflow.
This happened recently when Google released a new version of Chrome, but moved the Emulator settings.
I eventually found them, and show you how in the video below:

Or for those of you that prefer to read, read on. I've added references at the bottom.
We have to start by using the Overrides in the Chrome developer tools settings. All the emulation used to exist here, but it has moved.
Right click, and Inspect, to show the developer tools. Then click the cog on the right to show the Settings. And show the Override settings.
So the first thing we do is make sure that we have checked "Show 'Emulation' view in console drawer".
Great.
So now where is the console drawer?
Close the settings and in the dev tools on any of these tabs, we can display the "Console drawer" by pressing the escape key, and lo the drawer did appear and an emulation tab was present.
And we can use the emulation tab to help us test.
In the demo video I show this in action on the bbc site.
Choose a device to emulate. I pick the "Samsung Galaxy Note II" because I have a physical device for that on my desk, and if I encounter any issues I can try the same functionality on my device.
Choose Device, Click Emulate, and you can see the screen size refreshes to a scaled smaller size.
You can amend the display settings using the 'Screen' options. By default it is shown scaled, but you can make if full size if you want.
But we still don't have the mobile site yet. So I refresh the screen. Using Ctrl+F5. And because Chrome is now sending the correct mobile headers for the Note II, we are directed to the Mobile site.
And now the issues.
I try and use the site. Click on the links. And nothing happens.
So, I change sensors and switch off the emulate touch screen. And we have a working site again.
This works on the Note, so it might be a BBC issue, or it might be a Chrome issue. But really it shows us the problems of testing through emulation, when we find suspected issues, we have to replicate them on a better emulator or a physical device.
But the Chrome emulation is so convenient on the desktop that for a first run check on the site, and certainly checking how your server responds to mobile headers, these are a great first step.
And you can stop the emulation by clicking the [Reset] button.
In the video I show a bonus, which I thought was an emulator bug, but seems to be by design by the BBC, where the Weather page does not redirect.
Chrome emulation? Very easy way to run a first check on the site, if you know how to access the functionality.
Additional References:

Tuesday, 17 December 2013

Software Development Summit 2013

I attended the Software Development Summit December 2013 in Helsinki.

I was fortunate in being asked to perform a keynote, and asked to fill in for a keynote speaker who unfortunately couldn't attend, so I did two keynotes. Lucky me.

You can find slides for the talks listed over on my Compendium Developments site.

I managed to catch up with Kristian Karl and learn more about the CI and testing regime at spotify, you can watch his Eurostar conference Experiences of Test Automation Webinar online (Q&A).

I was able to quickly hang out and see a few of the twitter enabled attendees: Johan Atting,  Johan Jonasson, Aleksis Tolonen, and my fellow Eurostar Committee member Maaret Pyhäjärvi

I did receive a pointer to FreeNest - an open source platform put together by students which is designed to help teams get up to speed with a set of collaboration tools on Ubuntu quickly.

But it was all over very quickly and I had very little time to chat with Ilari Aegerter or Gojko Adzic.

The only downside I had was that I had to miss Gojko's Keynote because I thought I was flying out early. Of course the London Fog had other ideas so instead of learning from Gojko, I was stuck at the airport instead of enjoying the end of the conference :).

SIGIST 2013 Panel - Should Testers Be Able to Code

I attended the SIGIST in December because I was asked to be part of a Panel with the starting discussion title of "Should testers be able to code?".

I was on the panel with Dorothy Graham, Paul Gerrard and Dr Stuart Reid

Embedded image permalink

Initial Notes

I wrote the following in an email to the other panel members during the run up to the SIGIST. It wasn't polished but represented my notes and pre-conf prep.

....

I pretty much have to ignore the title "Should testers be able to code?"

In my mind "Should", at that point in the sentence equals "An obligation to..."

We don't work in an industry where testers have an obligation to code. So any question about obligation has no place in my reality.

I've met developers who do not seem to feel they have an obligation to be able to code. Similarly I've met testers who do not seem to feel they have an obligation to be able to test, or managers who do not seem to feel they have an obligation to be able to 'manage'. The process of Software Development has a lot of fungibility built in and can work with many different skill sets and skill levels on the project.

Personally, I do know how code, and while I can code some things as well as professional developers I consider my coding skills intermediate. Therefore I hope to phrase my answers in the form "When testers can code the advantages are ..." "When testers can not code the disadvantages are..." and "My experience of having up to date and intermediate coding ability has been..."

I do hold some opinions that might pop up:
  • "Testers who can not code, should not write automation code" 
  • "Testers who can not code well, will write worse automation code than testers who can code well."
  • and I suspect that "Many failed test automation programmes are a result of testers not knowing how to code". 
  • "I've also seen developers write awful automation code, I think automation code may require some different coding and design styles than application code."
I've worked with enough teams and reviewed enough automation code over the years to have some evidence base for those opinions. But we have an industry that has pretty low expectations around automation skillsets and automation, and for some reason has lumped most 'automation' in the 'testing' realm.

But this panel isn't about automation. Automation != Testing.

Much of my recent on-line work has been about lowering the barriers to entry for people who do want to code or develop more technical skills. I prefer to help someone do something, if they express an interest.

Personally I try to learn as much as possible about the process, and skill sets involved in, Software Development. One small part of that involves 'coding'. Other parts include "Architecture", "Design", "Databases", "Modelling", "Protocols", "Tools", "Estimation", "Planning", "Communication" etc. etc. etc.

I don't think that any role ("Tester", "Developer", "Analyst") has exclusive right to a set of skills, techniques and knowledge: "testing", "coding", "modelling", "analysis" etc.

I value diverse skills across the team.

On the Panel

My brain, working the way it does, has forgotten most of the questions and answers, so I revisit the memory with some degree of trepidation, false memories may well rear their head.

I think many of the above notes were covered during the Q&A. I was able to pull on some of the material from my Helsinki Talk on 'Experiences with Exploratory Testing...' because someone in the audience said "Developers should not test their own code", and so I was able to riff off the T-Shirt slogan slide from that presentation.

Basically - statements like "Developers should not test their own code" and "Developers do not make good testers" are the kind of statements people post on internet forums, and we should relegate them to T-Shirt slogans so we can mock them and laugh at them. Developers do test their own code, and they can learn to test better. The sooner the 'test community' wipes this nonsense from its collective meme pool the better.

Because we were sitting down on the panel, my opinions were phrased in a less confrontational amanner nd with more humour than might appear from the written form on this page.

I remember saying things like:

  • Projects depend on teams. So we need the team to have a diverse set of skills. And when we build teams look at the gaps in the skillsets.
  • Keep investing in your staff to make sure they keep expanding and improving their skillsets.
  • Becoming a better programmer has helped me test better.
  • Becoming better at testing, has helped me write code better
  • I recommend the book "Growing Object Oriented Software Guided by Tests"
  • Teams are systems. As soon as you add a team member, or mandate that they do something, you change the system. Keep looking at and evaluating the system.
  • Programming means lots of different approaches because there are different styles: OO, Functional, Procedural, etc. They require different skills and models
  • Modelling is a vital skill for testers

We on the panel certainly had fun, I hope the discussions and alternative view points added value to the audience.

End Notes

I think one message that came through from everyone on the panel was that testers need to have the ability to demonstrably add value to projects.

Having the role 'tester' does not mean you automatically add value.

Having the ability to write code does not mean you automatically add value (you might write really bad code).

Each tester needs to identify how they can add value.

The current market vogue is for testers with coding skills.

If that isn't your thang. Then it might mean becoming an expert in UX and psychology so that you can add more value for user focused testing. It might mean a whole bunch of things.

Each tester needs to figure out what they can do to add value, and what they can do to demonstrate their capabilities to the teams or potential employers.

And keep improving.


Friday, 22 November 2013

How to use Jira to subjectively track and report daily on your testing?

A long time ago I coded a now defunct modelling tool to help me with my testing. Half the battle with managing and reporting testing involves deciding how you will model it for the project you work on.

Generic Modelling


The generic set of formal modelling techniques I use, I often map on to:
  • Entities
  • Lists
  • Hierarchies
  • Graphs
When using Jira, I have access to Entities and Lists.

Lightweight Subjective Status Reporting


On a recent project we wanted a lightweight way of tracking progress/thoughts/notes over time. I really wanted a subjective 'daily' summary  report which provided interested viewers insight into the testing without having to ask.

As part of my normal routine I have become used to creating a daily log and updating it throughout the day. Ofttimes creating a summary section that I can offer to anyone who asks.

How to do this using Jira?


We created a custom entity called something similar to "Status Tracking Summary".

Every day, someone on the team would create this, and title it with the date "20 November 2013".

We only really cared about the title and the description attributes on the entity.

The description took the form of a set of bullets that we maintained over the day to document the status e.g.

- waiting for db schema to configure environment
- release 23.45 received - not deployed yet
- ... etc.

Over the day we would maintain this, so at the end of the day it might look like

- db schema and release 23.45 deployed to environment
- initial sanity testing started see Jira-2567
- ... etc.

I initially thought that the title would change at the end of the day to represent a summary of the summary e.g. "Environment setup and sanity testing", "Defect retesting after new release". But this never felt natural and added no real value so the title normally reflected the date.

Typically, as a team of 3-4, we had 5 - 15 bullets on the list.

Use Dashboards to make things visible


To make it visible, we added a "Filter" on this entity, and added Filter display gadget to the testing dashboard which displayed the last 2 status updates.

This meant that anyone viewing the testing dashboard could see subjective statements of progress throughout the day, and historical end of day summaries throughout the project.

But people don't like writing reports


I have grown used to tracking my day through bullets and actions that I take it for granted that everyone can do this. Still, I had initial concerns that not everyone on the team would add to the status and I might have to chase.

Fortunately that didn't happen.

The team used the Dashboard throughout the day to see what defects they had allocated to them, and to work on tasks and defects in the appropriate state. Therefore they always saw the subjective daily status report when they visited the Dashboard and updating it became a natural task during the day. 

You can report Daily, with mininal overhead


Very often stakeholders ask us to prepare daily reports. I find that creating, and updating, a summary log throughout the day often satisfies that requirement. 

As a team, building it into our documentation process throughout the day added very little overhead and made a big difference to the stakeholders had to our testing.

Friday, 1 November 2013

iOS Screen Capture, Streaming and ScreenRecording tools for Mobile Testing

I listed the results of my investigation into Android Screen Capture, Streaming and ScreenRecording tools for Mobile Testing, now time to turn to iOS.

Note that I'm not really covering static screen capture here, since short cuts are built into each operating system for static capture.

iOS is pretty locked down. And without jail breaking, your options are limited.

However, iOS has a built in screen sharing capability called AirPlay, designed to be used for streaming to your Apple TV. But that hasn't stopped some enterprising developers building AirPlay servers for both Windows and Mac OS computers.
Both applications are easy to use and offer much the same capability, so which you choose will depend on your evaluation on the machines you use.

Both are insanely affordable. And both have a version for Windows and Mac OS.

AirServer offers more configuration options, although it worked fine out of the box for me. AirServer offers a 7 day trial.

Reflector offers a trial where you can star as many sessions as you want. But each session only lasts for 10 minutes.

To capture your on-iOS-testing, 'airplay' the iOS screen to your desktop or laptop computer, and then use a screen recording tool like Camtasia, BB Flashback (or its big brother BB Test Assistant) and capture the screen movies there.

This doesn't let you interact with the actual iOS device from your computer, but goes some way to making your testing recordable and reportable.