Skip to main content

Another Tech Develops Day!! Developing myself and developing others!

As of last Friday, another Tech Develops day is in the books!

It was an absolutely epic day, in true ASOS fashion (no pun intended) they just keep getting better and better! I had my special Tech Develops T-Shirt on and was ready to go!

I started off with hosting some 99 Second Talks, where we had ADMs, QAs and Developers talking for (you guessed it!) 99 seconds about topic(s) that they are passionate about! It didnt' even have to be Tech Related, we had one person talking about their love of Pugs, and what made this extraordinary was he joined the company just 3 days ago as a Princes Trust graduate! I don't think I would have had the confidence to have done something similar, so massive respect for that!

Image may contain: 6 people, people sitting

We had a talk about Conversational E-Commerce and what the future holds in that space, I spoke about Checking & Testing in a nice little poem that I'd created the night before (I felt massive pressure following the "success" of The Stickman Tester... I hoped this lived up to it). We had an ADM tell us how Rock & Roll and Software Development have some massive parallels! We also had talks about the Test Automation Pyramid (and what is wrong with it), what people learnt from James Bach coming to the office a few months ago and how sometimes Failure really isn't an option...There were many more!

Thanks to the awesome people at Ministry of Testing, they gave us all a free trial for the day for the DOJO, I found it difficult finding the time to make use of it, but I'm sure others used it! We'll be looking at how we can incorporate team licenses going forward hopefully.

Image may contain: 3 people, people sitting, table and indoor

In the afternoon I spent some time at a great talk about "Quality Quests", and it was great to see two people so passionate about the work they are doing, this particular talk is about gamifying some aspects of Continuous Improvements within teams and making it visible so that people can see what is happening, as all too often, teams become very much feature driven which can only lead to pain and heartache in the long run!

Image may contain: one or more people and people sitting

We finished up (before Friday drinks) with a round of TestSphere, as always, this was very enjoyable! We had people reminiscing or telling horror stories about how they have felt victimised in their role in the past, or we had people stalling whilst trying to think of a story! No matter what happened, it was a great way to get to know other QAs and to talk about things that have happened that other people may (or may not) relate to.

All in all, as with every Tech Develops day, I have finished it absolutely exhausted! It's not just about developing me, but it's about developing others and giving others the opportunity. I'm already making plans for the next one to top this one!


Comments

  1. Hello, i read your post from time to time and i own a similar one and i was just curious if you get a lot of spam remarks? If so how do you protect against it, any plugin or anything you can recommend? I get so much lately it's driving me crazy so any assistance is very much appreciated. best online marketing

    ReplyDelete
  2. It’s actually a nice and useful piece of information. I am happy that you simply shared this helpful information with us. Please stay us up to date like this. Thank you for sharing.
    web design and development company

    ReplyDelete

Post a Comment

Popular posts from this blog

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

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

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