Author: lsim001

Why I switched from Mac back to PC

| lsim001

“OMG!!!! WHY??!!” said everyone I told about my decision to swap back to a Windows machine from Mac.

In a later post I’ll talk about the implication of my choice of hardware (and software). But for this post I wanted to talk about why I decided to swap ecosystems.

As a test consultant I’ve been using a Mac for the past few years. However quite often I work at places where my colleagues use PCs which oftentimes means a Windows machine. And I’ve noticed is that it is much more difficult to set up your local development environment on a Windows machine. At times the tooling wasn’t compatible across platforms. 

When things don’t work out for our fellow Windows users we would try to help them out but eventually give up if we can’t get it working. Ever hear someone say “You should just get a Mac.” or “You should use Ubuntu.”? Because of corporate policies this is likely not possible. 

It recently dawned on me that as a consultant I should not just live in the siloed and safe Mac environment and actually learn how to work on platforms my colleagues use as well. This would actually allow me to advice and give  guidance on how to set up a Windows machine to do development/testing work on.

At the end of the day it doesn’t make sense to ask your employer to change systems because you don’t know how to use it. Personally I believe that even though testing is my specialisation and learning test tools is important. It is equally important to be able to help set up these tools on your employer’s environments. Otherwise you may struggle to deliver at a high level.

The NWEWT Experience

| lsim001

The first ever NWEWT (North West Exploratory Workshop on Testing) conference happened last weekend (1st to 3rd of April) in Liverpool. I want to start off by saying Thank You to Duncan and Emma for doing a stellar job of organising the event. I definitely felt privileged to be part of the conference.

It was my first time at a peer conference and I didn’t know what to expect and was a bit anxious about the whole thing. But the whole thing got off to a great start with dinner on Friday night which most of the attendees of the conference attended. For my starter I had ordered soup and was served an empty bowl (Yes…a bowl of soup without the soup.). On hindsight I realised this was an apt metaphor of how little I knew compared to my peers. The dinner was a good way to meet everyone and get to know a bit about them before the conference started in earnest.

The topic of the conference was Regression Testing. We were meant to present our experiences and thoughts on  regressions testing. Over the course of the next two days we would hear talks from almost all the attendees and have discussions about what was presented. It was very interesting to find that a few of the talks mentioned that although they started thinking they were doing “regression testing”, they realised soon after that they weren’t actually testing for regression of their system. They were just testing. This definitely matched my experience as well. In fact since earlier this year I’ve stopped using the term after I heard someone pointed out that “regression” meant returning to a former state. In my mind that meant the definition of regression testing would be to test if the system under test had returned to a former state. In my current context that would be virtually impossible.

The other big takeaway for me was that we should focus on risk during testing. Although this seems obvious it is something I often need reminding of. @nortern_tester talked about using the FIBLOTS mnemonic to help identify risks. @Arborosa also mentioned that continuous testing involved continuously assessing your risks.

Anomaly Detection is also something I will be doing some research on after @DanAshby04 mentioned it like a million times. I think he’s trying popularise it as the next testing catch phrase.

NWEWT has also sparked off a new wave of enthusiasm to run a LEWT (London Exploratory Workshop on Testing) which I hope I’ll be invited to.

Apart from learning about testing I also rode my bike (motorcycle not bicycle) up to Liverpool. A round trip of 488 miles. 5 and a half hours up and 5 hours on the way back. It is the longest ride I’ve ever done and will constitute more than 10% of my annual mileage. The 5 hours back went by very quickly as I spent most of it reflecting on the conference. Most of the 5 and a half hours going up was spent wondering if I would get blown off the road by the crazy wind.

Some thoughts on my LetsTest 2015 experience (or Why you should go to LetsTest)

| lsim001

I just came back from LetsTest 2015 in Runö. For those that don’t know what LetsTest is, its a Context Driven Testing conference with a focus on workshops rather than lecture style presentations. Another thing that makes LetsTest different from most conferences is that accommodation and food is included. This really puts you in an environment to learn and socialise with your peers. The venue is in an idyllic location and some of the workshops are actually run outdoors.

Continue reading →

Setting up an Amazon Electric Beanstalk instance

| lsim001

Amazon Web Services (AWS) offers a whole bunch of services that enables us to deploy and host services, store process data, scales these services etc. It involves dealing with load balances, security, operating systems etc. In short it’s not exactly quick and easy. So Amazon released Elastic Beanstalk to help make deployment, versioning and scaling and general management of these services easier.

From a testing point of view AWS can be a good place to host your Jenkins instance, create a test environment and even run your tests. And Elastic Beanstalk is an easy way to set this up. Below I’ll walk through how to deploy a basic Docker application on Elastic Beanstalk.

Continue reading →

Setting up a remote git origin

| lsim001

I’ve been using git at work for the past few years and absolutely love it. I also use it for my home projects. In all cases I use Github to hosts the remote copies/versions of my projects. Github is a great service but when you have a free account (as I do for personal projects) your project will be public. However recently when I had some personal projects I didn’t necessarily want/care to make public as they were largely PoC or Hello World type projects but I still wanted to use version control. So I decided to set up my own remote git repository. This turned out to be not as I expected.

Continue reading →

3 Steps to set up a temporary Jenkins server

| lsim001

Every now and then I’ve had to set up Jenkins (usually locally) either to test an idea out or because I’m waiting for one to be set up by the “Environments” team. Setting up Jenkins is pretty straight forward but it does have a foot print and can be troublesome further down the track if you don’t tidy up or forget about what resource its taking up. For example, Jenkins uses port 8080 by default. However this is a common port that is used by other web apps which mean you could end up with a conflict. (which is easy to fix if you remember installing Jenkins months ago or that it’s the app that’s using the port.)

One way of avoiding these sorts of problem is by setting up Jenkins in a virtual machine. This means you can quickly get everything up and running and tear it down quickly. And with the current tools this is easier to do than ever.

Continue reading →