Skip to main content

What makes a QA so happy!?

Here's an interesting statistic for you (granted from the USA):



When I stumbled upon this article, I had to read the list twice, really? Being a QA Engineer is the second happiest job!? Someone had better tell that to some people I work with... I joke ;)

What is it that makes this job so happy then?
To me, it's the challenge of learning new things on a constant basis, the past few weeks have been spent trying to get my head around Espresso an automation API from Google for Android apps, I haven't spent as much time as I would have liked with it, but it's definitely challenging, and very rewarding. If I get to spend a whole day on it, then that does make me happy, so there's that I suppose.

Then there's the opportunities to constantly try and think of better ways of doing things, improving how we test so we can spend more time well, testing. It's rewarding coming up with tools or processes that improve peoples work life, just over a month ago I wrote a small program that would update a number of acceptance tests against a PBI in TFS, to save my team from doing it manually, things like that make me happy, knowing they can spend less time doing laborious tasks and more time doing what they enjoy.. Testing.

There's also the argument that regardless what happens, if you have a deployment to a test environment that isn't working, then you've found bugs, you've found issues, you can try and fix it... or if it is finally working, then great! You've got it working. Eric Jacobsen describes it a bit better here (and also the inspiration for this blog post)....

There's also the non technical side of things, being involved in communications from the start of projects, finding out what is going to happen, has this been thought of, really analysing what it is that is going to be developed. So working with a wide array of people, Business Analysts, Developers, Product Owners, Development Managers, you get to talk to so many people and you talk to them on different levels, which is really rewarding, and does make me happy.

So there you have it, these are just some of the things that make me happy, I'm definitely interested in what makes you happy as a tester? And also interested as to what makes Database Administrators so happy!? I think I might go and ask that question now!!!
Labels:

Comments

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