Breaking Websites: The Importance of QA Testing
Before a website or app goes live, there are people like myself that are charged with finding every conceivable way to break that website or app so that it works perfectly in any environment on any device at any time. It’s an essential part of the development process that has become more challenging and complex, and even more important as technology changes.
Over 15+ years of building and tearing down websites and applications to help assure their ultimate performance for the end user, I’ve encountered just about everything. To help share that experience, here are some of the most frequently asked questions that I receive on QA testing, including how different testing methodologies are used and how I anticipate potential issues or breakdowns in a program.
Question: What do you do as a tester within a company like Azavar that is creating websites and apps?
Answer: I always bill myself as someone who breaks things. But more accurately, I try to find the issues and the problems on a website or an application. To do that, I need to know what it’s supposed to do, what it’s supposed to look like and then I take it from there. I’m looking to identify what’s going to break and how it works as opposed to what it should do or what it actually does.
Here at Azavar, I end up doing a lot more than testing. I have a great deal of input into the actual designs because this is an agile shop. I often get involved upfront with the applications and my opinions can be used throughout the development process.
Question: Are your testing protocols primarily manual or automated?
Answer: Most of the testing we do is manual testing. Automation is good for regression, allowing you to go back and retest things following changes. But manual testing is always necessary with new functionality in the application.
The problem with regression using automated testing is it becomes a maintenance problem. The testing turns into a system that must be updated and monitored.
Question: What you did before you came to Azavar?
Answer: For about 15 years, I worked in testing for the Options Clearing Corp. I started in system assurance testing and I’ve always tried to keep in mind that as testers we are representing what the user wants and needs, which sometimes can get lost in development. I’ve seen people design things that worked beautifully, but wasn’t what the customer wanted.
Question: Can you give an overview of the types of QA testing methodologies?
Answer: Waterfall takes place after the project is pretty much complete. The tester comes in and must analyze the whole system. The problem with waterfall is that any necessary major changes are often not made at that time.
An Agile methodology includes two-week sprints of development and testing, so we’re able to identify more areas to develop and then test as we move forward. Agile provides a little more flexibility, but can also be a challenge if for example, the front end of the product is not yet developed.
Question: With the agile methodology and two-week sprints, does that often place a lot of pressure on you as the tester because of time constraints?
Answer: That happens, but usually the functionality is kind of small compared to waterfall. I felt much more under the gun within waterfall methodology than I have in the Agile, primarily because I’m working much more closely with the developers. I’m aware of what’s coming up next and we can be prepared to be ready to test when the project is ready.
Question: It seems interesting that the QA testing would be in sync with the developers when they’re creating something. How is that possible?
Answer: The developers will create the project on their own machine or within their own environments where they will do a unit test of it, just its functionality by itself. Then when it goes to staging, it becomes more of a system test where I could test it with interaction with the other components of the system.
One challenge is you need to keep regression testing everything that has been there before that might be impacted by any new changes. When you put something in, sometimes there can be an unexpected reaction somewhere else in the system.
Another way to identify an issue is go back and run the entire system. Quite often, the problem isn’t so much testing the new function as making sure it didn’t break the old functionality.
Question: Are there unique challenges with testing an ecommerce website, app or other program from your perspective?
Answer: It’s usually similar, except for the complexity between various pieces, particularly in placing orders. The ecommerce process can include placing the order, interfacing with the clerk, creating or managing packing slips, generating the invoices and interfacing with outside systems.
Question: Are there common issues that you have your eyes open for when you’re involved in a project?
Answer: There are a lot of different potential issues and you never know what issue is going to come up. Adding the complexity of different types of mobile devices, including responsive testing, has added another level of complexity within testing.
But there are many things that I’ve learned from experience. Every time you look at a new project, my first thought is “where else could this possibly break?” I’m always look for “edge issues” such as inputting the highest possible value for a field, or what happens if you input zero. Sometimes special characters will throw off an entire system.
Question: What does automated testing consist of?
Answer: There are testing programs that will let you record screen actions and then repeat them to learn how a process works, or doesn’t work. There are also automated programs that you can build into the actual system. We’re using something similar right now that keeps checking the code for breaks and signals the developer that something is broken.
Question: From your perspective, how has technology affected QA testing over the years?
Answer: Testing has become much more technical, with a lot more queuing and referencing of data. The necessity of testing across a wider breadth and depth of programs, devices and platforms has also been impacted.
Each program must be tested across numerous browsers. You can see problems with Internet Explorer that you don’t get in Chrome. I’ve seen problems with Firefox that are completely unique to that browser. Testing overall has become a lot more complicated.
There are also more possible points of failure. The screen can look perfect on your computer, but look terrible on your phone. Your functionality can become useless if it’s not properly tested.
Question: What do you think the future will look like for testing in the next few years?
Answer: I don’t expect it will change all that much in the short term. We see a lot of reporting tools that allow us to track outcomes. But I still think a lot of testing is going to be manual testing. It’s still going to primarily require experience and knowing what to look for.
Gary Bonolo is a quality assurance team lead with Azavar Technologies. He has over 20 years of experience in QA testing using a wide array of strategies, methodologies and technologies.