Skip to main content

Getting QA and Developers working closer together as one

Currently where I work there is a lot of discussions around how we can get the QA members to work closer with the developers, almost as 1. A friend demonstrated what they think, and I agree with the following:


It demonstrates where QA and Developers were 5 years ago, where we are now (where we work, I understand that it will vary dependent on the organisation and the methodology) and where we will "hopefully" be within 2 years. I don't think it's unrealistic, however, people need to have buy in and want to improve themselves.

How can we achieve that though is a big question? I think one of the major hurdles is getting QA and Develoeprs on the same level playing field, get them talking the same talk, help QAs get technical... which leads me to the next image, something that I found on the internet:



We as QAs need to get technical, we need to understand code, we need to understand system architecture, we need to be able to discuss technical solutions with developers this will make us better testers and will enable us to work closer with developers.

A common rebuttal of the above is that there are other skills that QAs need such as analysis, problem solving and it would be a shame if we lost them... to which I simply reply, why can't we have both?

How can we get more technical? There are many ways, sooo many courses are online that you can take at your own pace, you can work with the developers and ask them questions about the code they are writing, get involved in writing automated tests, create your own application to practice on the possibilities are endless.

Then there's getting developers more involved in your acceptance test writing, doing ATDD (Acceptance Test Driven Development) where the developers review the test you have written and decide whether they have Unit/Integration/JS tests around that, then you can mark that as appropriate and not have to write a UI test around it for instance. This approach helps the developers feel a part of QA and truly appreciate what it is that we bring to the table, and rather seeing us as someone who finds fault in their code, see us as someone who helps them write better code.

Another one is releasing good quality software on a consistent basis, if the team are being successful and achieving their sprint goals and releasing software then they will feel unified and feel as one. Everyone will see the value in the work everyone else is doing and in doing so, you will all become closer as a group.

Finally, and one that I think gets overlooked, is socialising as a team, going out for lunches, going out after work for drinks, just build a team spirit. It's easy to do and more often than not, it's fun to do as well. Never underestimate the power of being friendly with your coworkers/developers.

So that's some ways of how QAs and Developers can work closely together, are there any ways that you can think of that will help?





Comments

  1. I think ultimately the QA & Dev roles should merge - there is no reason why a good developer shouldn't also be responsible for ensuring the quality of their own work, and there's no reason why a good tester shouldn't be able to apply their natural analysis and problem solving skills to be able to write code. Ultimately, the goal of the two roles is the same - to produce awesome software, and the division of responsibilities between the roles seems primitive to me.

    ReplyDelete
  2. I encourage tester's to "get technical" to improve rapport within project teams, to add benefit at code reviews, and to gain a little credibility. But it is a two way street and I appreciate the challenge of bringing developers and testers together.

    We made a change recently in our organization where developers are responsible for demonstrating requirements. They demonstrate them through unit testing (either manual or automated). Where some requirements are more challenging to evaluate, the development and testing team collaborate on creating tests.

    By making this simple change, quality becomes a team sport and everyone makes a contribution to a great product.

    ReplyDelete
  3. Keep up the great work, I read few blog posts on this site and I believe that your website is really interesting and has loads of good info.
    Selenium Training Chennai
    software testing selenium training

    ReplyDelete
  4. The blog will useful to improve my knowledge about testing. Thanks for sharing this valuable blog.
    Selenium Training in Chennai | Selenium Training

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

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

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