One interesting fact that I often come across working in startup environments that a lot of people I work with do not know what software quality assurance is all about. Usually it includes co-workers without technical background. People say ‘testing’ is easy and anybody can do it. That is not necessary true in my opinion. In this first post I would like to talk about the difference between testing and quality assurance and go in specific details between the two.
What is Testing? Testing is about finding bugs not preventing them. It does not necessary have to have a process or any specific methodologies. It could by just simple as doing ad-hoc testing or looking for bugs against the requirements if any exists. A lot of times you are essentially looking for bugs that are already there, you are not necessary preventing them.
What is Quality Assurance then?
I see QA as a process or a system that prevents issues and increases the overall quality of the product, team, department and company. How do we know if software is ‘high quality’? Well the outcome has to be customer satisfaction. If your customers are using and buying the software it means you are doing something right. So how do we know what customers want? Well, we have people for that which include: Business analysts, marketing, product managers and user/interaction designers UAT people. Working with many cross functional teams I’ve learned a whole a lot about customer quality. How it should look like, feel like, and how it behaves, Is it user friendly? Is it intuitive? Is it trustworthy? Does it meet the requirements? That is some of the questions I ask myself whenever I do QA on a daily basis. I guess I started getting carried away so let’s talk a little about Quality Assurance. What is it? It is a system or a process that has to be build up and maintained in order to work. It consists of: test cases, test planning, bug reporting, bug tracking, automation, gathering requirements, and interacting with different business owners. In the early stages of software development I participate in scoping, technical planning meetings to better understand the product looking at it as and individual and seeing it high-level and the impact it might have on other functionalities. Any good QA would make sure he is included in those meetings if you will involve in qa’ing that software. At that time you will start planning which can include writing test cases, test plan and flowcharts or even just noting down ‘areas to test’ that you will have to revisit once you get it from developers. Another part of daily routine is constantly talking to developers and asking them what kind of approach do they use to build “X” functionally? What kind issue caused my bug? All of that information helps me better understand the product/software and prevent issues in the future. It also helps me be a subject matter and even make good suggestions to new developers that are not that familiar with the code base. When I start looking for issues I constantly think what can the user do? Which flow can they go with and how can I break the software and make it fail. By the way I always find a way to break itJ. I make sure I find all these issues before our customers do.
Logging bugs- I commit myself to writing easy to read/understand bug reports. I write them in a way that if any new person were to read them they would have no trouble understanding. I also ensure to follow up on my bugs which include: a set of tags, filters and other tools that I use such as sticky notes, calendars, evernote etc. . So if I ever need to find a bug in our tracking tool I have no problem finding it since once in a while you need to go back and look at the ‘archived’ bug. I build a test automation framework which prevents regressions and saves us a lot of time and money. I recently build this script that runs around the site and takes screenshots of our partner search widgets to ensure the UI has not been broken. I have set of scripts that I run in Selenium IDE, RC and test runner. I recently put some of them up on bamboo (continues integration) and automatically get email notifications with the results. I work with server logs, database and other techy tools to help me prevent bugs and increase quality. These processes help me be a good qa and prevent issues before our dear customers see them. All these skills require technical background, engineering mind and a whole lot of curiosity and passion for quality. Anybody can test but not all can be a good software quality engineer. I hope I was able to explain this subject a little better and now you have a good understanding what QA is about.