Skip to main content

QA Vision for the next 12 months

I was recently asked about a vision for QA over the next 12 months, where would I like QA to be and how am I planning on achieving that...

I thought I'd write where I  want QA to be and document the progress over the next year or so, and hopefully achieve most, if not all, of what I want.

Firstly, a big problem where I am currently is performance testing, we hand it over at the end of a project to a third party who then run performance tests on it and come back with results, there are a number of issues that are wrong with this, mainly being we are leaving something that is incredibly important right to the end of a project, so any issues are extremely difficult to fix. So the first thing I want to do is embed Performance Testing right into the sprint, and actually try and do it in an Agile way, I read a blog post here  and really want to try and achieve that, we have the tooling to do it in house, so why wouldn't we do so? Sure it will require some help from experts at the start but eventually we should be able to bring it entirely in house at the end of it. The benefits of this are that we will have less shocks at the end of a project, a smoother release process and a quicker time to release as there is no 2 week period that is needed for performance tests to run. To achieve this we will need better acceptance criteria around performance, and education around best coding practices but this is a big goal and I really want to achieve this. I would argue this is the highest priority of all what I want to achieve over the next 12 months.

Next up is to have some form of induction process for new QAs, currently there isn't one. New QAs are put into teams and there is no induction over system architecture, QA processes, automation framework nothing at all. I want to rectify this, the problem being that this is time consuming, and can vary from team to team slightly, however the goal is to make it as generic as possible whilst still giving huge value to new members. The advantages of this would mean that QA members can hit the ground running quicker and hopefully have less time wasted asking questions and waiting for answers, all the information can be in this induction pack that they will complete.

We do a lot of releases, but as of now there is no automated test pack for a release, we are in the process of rectifying this, by creating an automated deployment test pack that can be run in production and pre-production, and will verify the core functionality of the website. The goal would be to have teams run this test pack as part of CI on a nightly basis, with the benefits being that teams will have confidence that their code is working as it should and the actual deployment and release will be quicker and hopefully smoother. This will increase the time taken to deploy new code, which is essential if we are to achieve more regular releases.

I also feel that we unfortunately have no clear process for security testing, we have done security testing in the past, but I feel that the approach needs to be documented and a clear partnership with the third party established. We need to manage this properly, so we don't end up in a similar position to where we are currently with our performance testing.

I would also like to work on having a clear career development plan with the QA members in the teams, similar to what I've documented here but make it official and so it's clear what skills are strong and what skills QA members need to work on to progress to the next level. I feel that this would also help give visibility over areas that we are lacking in as a QA community so we can look at addressing those weaknesses.

Mobile automation to be used and adopted by all the teams, so both android/iOS applications and the mobile website have some form of an automated test pack that can be run. We know the tooling we want to use, it's just a matter of setting up the framework so that tests can easily be added and created by the teams. (FYI, the toolset is going to be Espresso for android and kif for iOS).

Finally, I wish to develop a strong culture of Research & Development, a place where QAs can work on individual projects that will ultimately benefit the team, I'm not entirely sure how to get this started, but a simple way is to have regular meetings for people to chat about things that they think would be good for their team(s). Then there's also going to conferences and things like that, speaking to other people and finding out what they have worked on and what they have done well and not so well. Maybe even come the end of the 12 months, host an external QA event for the public to come and see and get people speaking at, and realising that ASOS isn't just about fashion, but about the technologies that help deliver it to the multiple platforms.

These are the main points that I wish to achieve, I'm sure there will be others added to this over time, but I'm positive there is enough there to keep me and others busy in implementing the above! This obviously needs buy in from everybody involved, but I strongly believe that if we achieve the above we will have a very strong QA department, and one that is fun and challenging to work in.

I will definitely keep you all posted, do you have a QA Vision for the next year? what do you wish to achieve with your work?

Comments

  1. The writer has written this blog in the most artistic way. Splendid!
    resumeyard.com

    ReplyDelete

Post a Comment

Popular posts from this blog

Delusions of Testing

So I've got in touch with my old QA friend, Richard Lee and we spoke about guest blogging on each others blogs... Richard is an IT Professional for a FinTech based company in London. His activities vary from Release Manager, Build Manager, Database Administrator. Working in a Microsoft workshop, his expertise lies in MSBuild/Workflow/Powershell/SSAS/SSIS/SSRS/SQL, basically whatever isn’t anyone elses’ problem is Richard's problem! When not solving other peoples problems he can be found blogging at redphoenix.me , and jogging to and from home, where he lives with his heavily pregnant wife. Hello, my name is Richard, and I am a former tester. Like most people and their careers, I fell into testing; I first got into testing about 6 years ago, after I had graduated. I went to a university where the attitude was that you should try to get on a graduate scheme with one of the big companies. If you weren’t interested in that, well, good luck with getting any support from ...

QA is Awesome!

No real point to this post other than I have had the song stuck in my head and figured I could change it slightly and quite easily make QA is Awesome! Oh and I haven't even seen the movie all the way through! But for some reason that song is incredibly catchy! Not much point to this post in fact, just thought I'd put it out there :)

Treating Test Code as Production Code

It's important when writing automated tests to remember that the code you write should be up to production standards, meaning any conventions that you have in place should be adhered to and that it should follow good design patterns. Too many people often say why does it have to be as good as production code, it's "Only" a test, so long as it passes then that's fine... To answer this we need to look at why we want our tests to be written in such a structured and efficient manner: - Maintainability - by making the test code structured and efficient, it becomes far easier to maintain and in doing so changes in the future can happen quickly as the test isn't linked to anything that it shouldn't be and it's easy to understand for a new set of eyes. - Durability - Again by making the tests structured they should be resistant to changes, if you change a variable name for instance then it shouldn't effect the unit test unless it absolutely has to....