Skip to main content

What I learnt by NOT going to TestBash!

I've seen many blog posts about people posting about what they learnt by going to TestBash. It made me think about what I have learnt by NOT going to TestBash this year....

Firstly, I attended TestBash Brighton last year. I loved it, I learnt so much and came back passionate and engaged with the Testing Community. Over the course of the year however, my work changed significantly and I wasn't doing as much testing as I was before.

When TestBash came around this year, I had 3 QAs who asked about going. I said to them "Definitely go", we got the funding and got them tickets and off they went. I don't think they realised why I was so passionate about them going, and about how I was "gutted" that I wasn't going!

Image may contain: one or more people and closeup

So with 3 of the QAs who I work with being there, I was in constant communication with them, checking in on how it was going, what cool things have they learnt... They even brought me back an MoT Calendar and some TestSphere Cards! But that isn't all they have brought back...

They have brought back a fountain of ideas, they want to build up a community within ASOS (we have 150+ QAs - so we have the people), they want to try new games, go to new events, have ideas about what we can achieve within our domain... It's awesome to see them so invigorated and passionate!

I think that last one is important, Passion, I've learnt that it's very much something that needs to be nurtured, and it can stagnate, it can dwindle, but you need to get out and talk to other people to feed off of their passion, feed off of their enthusiasm and take that back into your workplace. Remember, smiling at someone can change someones day, in much the same way as showing and demonstrating passion towards something. It's infections.

I'm reading a book on how to build a successful community of practice, which I sent to one of the QAs who went, and she replied saying she'd bought the same book... Great minds think alike!

I have also learnt that I don't need to go, by sending people I work with, I get a lot out of it, and they get even more out of it. I'd much rather send others and let them experience it for the first time, than go again myself... Having said that I will be going again... It's just more important that others go!

One more thing I have learnt is that you can track so much stuff on Twitter! Every day during the conference/workshops I was checking the #TestBash on Twitter, it was almost like I was there... almost!

So, I feel that by sending 3 QAs, my passion for testing, for the community has been reinvigorated... hence the revival of this blog, and my first blog post in a LOOONNNNGGGG time. I have many more ideas lined up, but I thought I'd kick off with this as it's relevant and the reason why I feel invigorated about testing and the community again.

Comments

Popular posts from this blog

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 



By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

[AfterTestRun]
        public static void AfterTestRun()
        {
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))
            {
                CleanUpProcessByInheritance();
            }
       }

        private s…

Famous Movie Quotes applied to Software Engineering - Jaws

You're gonna need a bigger boat? How can that relate to Engineering?

Firstly, let me ashamedly admit, that I've never seen the whole of Jaws all the way through. It's on my list of films to watch, but whether I get round to it, is another matter!



Anyway, to apply this to engineering, it's almost like "you're gonna need more testers/developers"...

We hear this all too often when trying to push releases out the door, let's throw men at it... However, as we all know, a bigger boat/more men... isn't always the answer, it's not a guarantee of quality, or even a guarantee of getting things done quicker.

If you have a task that will take 2 hours, simply having 2 people work on it doesn't mean that it is halved, in fact often, the time taken to do the task remains at 2 hours, but the maintainability and the knowledge around that area is increased, so it's a price, in my opinion that is often worth paying.