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

  1. Hi there! This is my first visit to your post! We are a collection of volunteers and starting a new initiative in a community in the same niche. Your post provided us useful information to work on. You have done a extraordinary job! SingHost

    ReplyDelete
  2. Your article is very useful, thanks for your information.We look forward for your valuable information.
    https://www.apponix.com/

    ReplyDelete

Post a Comment

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 follow...

Coding something simple.... or not! Taking a screenshot on error using Selenium WebDriver

I recently wrote a little function that takes a screenshot at the end of a test if it has errored. What sounded very simple at the start turned out to be quite a bit of work, and quite a few lines of code to handle certain scenarios! It's now over 50 lines of code! I'll start with what I had at the beginning, this was to simply take a screenshot in the working directory, we are using SpecFlow and Selenium to run the tests, so we are going to check if the ScenarioContext.Current.TestError isn't null, if it is, then using Selenium, take a screenshot (note the below code is a simplified version of what I had at the beginning). [AfterScenario]         public static void TakeScreenShotOnError()         {             if (ScenarioContext.Current.TestError == null) return;             var screenshotDriver = Driver as ITakesScreenshot;             if (screenshotD...

The Stickman Tester... The full version complete with deleted "scenes"!

As some of you may have seen, a little while ago I performed a 99 second talk on the Stickman Tester for the Ministry of Testing. Owing to the fact that it had to be 99 seconds, this unfortunately meant that a verse was left out in order to keep it within the time frame! It's only now that I have found the time to put the deleted verse/scene back in, and re-record it and upload it! (It's now a 120 second talk!) It talks about a testers journey in an Agile team, about how not everybody has it as good as others, and basically talks about not giving up, keep searching, or trying to change your role to make it what you want it to be. Anyway, here it is, in all it's glory. Hope you enjoy it!