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. Hazid Kalem13 June 2018 at 14:46

    Get cracks softwares free downloadable sites

    https://www.technosizzle.com/
    https://sickbits.net/

    ReplyDelete
  2. RickSolis31 January 2019 at 09:28

    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
  3. gagan6 March 2019 at 02:49

    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

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...
15 comments
Read more

How to manage resources within new teams?

Working where I work we are constantly spinning up new teams to take on new workloads as business come up with new demands and new features they want developed and tested. The problem with this is how do we ensure the work of the newly spun up team is of sufficient quality. One method is by taking people from other established teams and placing them on the new team. This works great for the new team, but unfortunately it will oftenl eave the established team lacking in a resource whilst they try and fill the gap left by the person who has left. We are seeing this often with our offshore teams, it can be damaging to the team structure and the teams velocity, but try as I might, I can't think of another way around it. It's far easier to take 1 person from a team that is established than it is to build a whole new team from scratch. At least by leaving the core of a team in place, you should be guaranteeing that the new team are aware of any coding standards or any QA standard...
Post a Comment
Read more

Considerations when creating automated tests

We recently released to a number of teams our automated regression pack that has been worked on over the past few months. This regression pack tests legacy code, but contains a large number of tests.  As a bit of background, a number of teams are working on new solutions whilst some are still working on legacy code. With this in mind we constructed an email with a list of guidelines when creating new tests that need to be added to this regression pack.  I figured that these can be quite broad so should apply for any organisation, so thought it would make an interesting blog post...  So here goes,  when creating automated tests, it's important to consider and adhere to the following: - Think about data . The tests need to retrieve or set the data they need without any manual intervention - This should help them be more robust and easier to run without manual intervention. - The tests need to be idempotent - By making it so that each test is standalone and does...
Post a Comment
Read more