Skip to main content

Becoming a better Tester... One day at at a time...

We can all become better testers, only some of us lack motivation, or some of us have the motivation but just tend to lose interest...

One way we can tackle this, is by attempting to become a better tester one day at a time.

It's much easier to tackle each day, and do something each day that makes you a better tester, than it is to say in 1 month I want to be a better tester.  Firstly, it's hard to define how you can become a better tester, but for me, one thing that would make me a better tester is to read more blogs and learn from experiences of others. With this in mind, I've made it a challenge to read at least 2 blogs a day from a testing blog feed.

This is far easier than if I had set a goal to read 60 blogs a month for instance, it's also more manageable. If I don't do it one day, it's not the end of the world, but it's important to not lose heart.

Also, I find it good to establish a daily habit, I like to read 2 blogs en route to work on a morning, by having a daily habit, it enforces positive behaviour.

You obviously won't enjoy every blog post that you read, but once you get a feel for what blogs you like, then you can subscribe to them and read them as part of this regular reading session.

I understand that not everyone has time to read blogs on their commute, but even during a lunch break, it doesn't matter, what's important is the routine and setting side time to do this, and to help you become a better tester.

Other things that might be interesting and to help you become a better tester could be:


  • Start up a blog and post once a week/2 weeks/month (it's up to you and how you feel about writing)
  • Become more involved in the QA Community and reply to discussions on the various outlets there are (linkedin, Software Testing Club etc.)
  • Start mini projects for yourself (e.g. I've recently started one using Watin to test a website)
There really are many more, and I wouldn't like to say you should do this, as I do believe this is something that is down to the individual, and it's no point me saying you should do this if you don't really believe it will make you a better tester. :)


Labels:

Comments

  1. Srinivas Kadiyala30 September 2013 at 03:59

    Nice post, Thanks for sharing.

    Srinivas Kadiyala
    @srinivasskc

    ReplyDelete
  2. Chris Kenst30 September 2013 at 21:03

    What type of project / attempt are you making with Watin?

    ReplyDelete
    Replies
    1. Gareth Waterhouse1 October 2013 at 00:22

      Hey, early says at the moment. Just getting it to interact with a website and do some basic tests with it. Once I've got to grips with it then I'll look at pushing it further etc.

      The website I've started to use is easyJet altho I may change it to asos so I can have more interactive tests with databases etc in our test environment.

      Delete
  3. F14 Team3 October 2013 at 08:00

    This comment has been removed by the author.

    ReplyDelete
  4. F14 Team3 October 2013 at 08:02

    Nice read!

    Thanks,
    www.f14testing.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