Successful QA testing: 10 tips from the Lemon.io specialist

I’m a QA specialist at Lemon.io. I’ve been working there for quite a while — and I’ve had no time for idleness and boredom. Our company is a young and promising talent marketplace connecting European web engineers with American startups. To reach all our (rapidly evolving) business goals, we need a whole web infrastructure — an efficient CRM, a few chatbots, an application for tracking time and rates, and a full-scale website. Every day, our programmers and product managers implement something new: we’re a startup, and startups don’t grow unless they experiment, expand, and fearlessly move forward. 

Some crucial questions of the QA

Sooner or later, each QA engineer gets interested in the personal qualities that affect their work and starts posing important analytical questions. How does their scope of responsibility influence the final product? What are the crucial features of the efficient QA test? How to make QA reveal all the potential troubles with the product? Unless you analyze what you do, the superficial daily routine of testing, trials, errors, and corrections becomes boring and teaches you nothing. Not my way. 

In this article, I will share ten tips that inspire my work and help me test all the new features we’re rolling out. I will try to analyze my daily routine — and share some pieces of advice that will come in handy for readers — both QA testers and those who’re just interested in the QA workflow. 

What will I cover:

• methods of QA testing and their dependency on the specific programs or apps;
• changing the routine after the initial dead ends;
• inspiration sources;
• turning into end-users; 
• QA testing process at Lemon.io;
• some resources for boosting qualification

…and more.

However, first of all, it’s essential to devote some space to basic explanations. Not all developers know what the daily job of QA software testers looks like. Therefore, I will, first of all, explain what QA testing is in general, its main types, and, last but not least, elaborate on the topic of the QA testers. How do these specialists ensure smooth workflow of the programs and applications?

 What are QA and QC testing? 

QA (or Quality Assurance) testing is a process of testing the new product’s performance and quality with the help of standardized procedures and metrics. Properly constructed products should deliver consistent results during testing. 

Briefly speaking, QA entails all the core activities aimed at implementing standards, ensuring that the new piece of software meets definite requirements. All the QA procedures are process-oriented.

Quality Control (QC) procedures, contrariwise, are oriented on the end product’s quality and focused on final outcomes. The QC activities are product-oriented. 

Most companies emphasize quality control, helping to deliver the best possible product to their customers. However, the market demands are often pushed to the front at the expense of customer-centricity: startups urge their product teams to release new features ASAP, forgetting about quality and hoping for seamless process flow (that rarely happens).

Just remember how often (more times than you can count) you came across bugs and unexpected software behavior or just plain and irritating slowness of operation. It’s just the task of QA and software testers to address all these issues.

QA: the past and the present

Formerly, QA testing was performed after the core developmental stages: once a program or an application was completely ready and functional, it was passed over to a tester team that had to fix the bugs and major performance issues. Such a process had many drawbacks — the major being time-consuming and expensive procedures of redoing and amending the product. Post-production QA testing often prolonged all the processes and made the final release date extremely difficult to estimate. Nowadays, in the Agile environment, all the teams collaborate and improve QA testing skills and the product on an ongoing basis. 

Here’s what QA specialists and testers perform before getting the product to market:

1. Generating requirements;
2. Arranging estimations;
3. Developing a plan;
4. Completing documentation;
5. Performing daily sprints;
6. Defining the finished product;
7. Test.

The role of QA testers 

Ours is a digital age. New applications, websites, online tools, and services come to life daily. Software products, online games, and web platforms have to be checked/vetted before release. That’s why QA and QT specialists are second to none in the software industry and all the development cycles. Generally, QA testing can be of two kinds — either it’s manual or automated. 

Below, we’ll briefly name and describe the main work duties of a QA tester. 

1. System specification analysis and review. QA specialists run multiple tests making sure that new products satisfy all project requirements. The list of obligatory tests can include probing the system limits and functionality in the desired environment (e.g., via a real-time simulator).
2. Functional testing and problem identification. QA professionals perform multiple tests and bug fixes. Also, they run additional final tests before the product release.
3. Reporting bugs and errors to the development team. QA testers are expected to track their findings and compose bug reports with all the necessary information about the found issues, examples of these issues, and performed steps for their resolution. 
4. Cross-functional collaboration with QA engineers helping easier changes implementation. As a QA tester, one should incessantly cowork with cross-functional teams to ensure quality at each stage of development. Assessing risks and identifying and resolving dangerous issues ends only after the final product release.

10 tips for a successful QA testing

Make your work captivating

QA testing is a daily routine, so even the most bright testing aces will sooner or later feel bored of the same checking procedures — unless they will (and want to) bring something new.  My point is that every QA professional should constantly use different testing methods. This will help them to be productive by finding previously undiscovered defects and getting interested in the product’s convenience for end users.

Generally, there are not many manual testing methodologies (black box, grey box, and white box, depending on the tester’s level of knowledge about the system in question). However, every QA engineer knows that there are quite a few kinds of testing, and one always has some extra options up the sleeve. 

Personally, I use exploratory testing, smoke testing, regression testing, sanitary testing, and integration testing most frequently. One of the most complex (and my favorite) testing is exploratory. Its complexity is in its multilayered nature: a QA tester should not only tick the basic checkboxes (Does everything function properly? Do the buttons perform the requested functions?) but explore the functionality of the whole product from top to bottom, imagining all the possible modes of usage and preventing potential bugs. QA gurus like James Bach or Bret Pettichord consider exploratory testing the most efficient.

Be creative

“Out of the box thinking” (or, as my former colleague calls it, “user thinking”) is a crucial part of every QA tester’s routine. Every day, we use all our ingenuity and creativity, collect the use case, performance, and implementation ideas, and turn them into tests. Creativity helps QA engineers provide information about product readiness for release — unless you start thinking out of the box and check all the possible variants of usage, moves, actions, and interpretations, you’ll surely miss something (and lose to an unknown user who’ll discover bugs thinking differently).

There are several inspiration sources for me at Lemon.io: first of all, my team is always ready for dialogue and discussion. Secondly, it’s the ever-changing product and, last but not least, the end users. Not a common set in outsourcing.

Imagine yourself an end user and show empathy

It’s not easy to imagine the potential problems and bottlenecks other users can come across. We’re all different. We think differently and employ strategies while getting acquainted with new products and services. However, that’s precisely what QA specialists do. We always try to empathize with users, reveal their ways of thinking, and act ahead of their potential steps of using products and services.

Subconsciously, all the developers believe that their code does not contain errors — just as QA engineers cherish the thought that they have covered all the functionality with tests. However, to truly achieve that, one should switch to the user role as often as possible.

To do this easier, use the product reviews of real users and employ the exploratory testing methodology. For instance, a mobile app tester can examine user reviews in online stores. They usually hint at how users employ the apps in question. Analytical tools tracking all the user moves also provide a lot of handy data. Demo versions of the new features are also worth mentioning: at Lemon.io, we roll them out, collect all the bug reports, and fix everything before the final release. 

Analyze everything

QA engineers always need to imagine the final state of the product very early — preferably at the development stage. It helps us to understand the product’s behavior in production and how the end user will get the best of it. It is essential to be able to percept the product in two parallel projections: as a functioning wholesome mechanism and as an assembly of multiple parts; each of them should be perfectly functional and working.

The second goal is unreachable without a deep understanding of how each component affects the rest of the product. This will help to think over a strategy for exploratory testing of the new functionality. 

Read the requirements, ask questions, and communicate with the team

Examining the requirements and product design helps to analyze the product and determine the points the requirements’ creator might have missed. Each question to the team adds to the overall clarity of the product mechanisms. Regular meetings are also helping to see the product from various angles and understand the feature’s influence on the product. (To boost usability, it’s advisable to perform beta-testing among focus groups and end users.)

Learn and explore

Changes are inevitable — even in routine procedures — and a skillful QA engineer should be open to these changes. Be it new design trends, web architecture fashion, technological progress, or something else — we must adapt and continue researching the products we’re working on and the products we’re likely to start working on soon. Exploration opens eyes to new quality assurance practices and ways to achieve greater results. Personally, I learn every day. I scan the DOU website (where all the new tech ideas in the Ukrainian dev community are published), subscribe to newsletters, and attend online conferences like https://testingstage.com/. 

Build a community around your QA practice

One of the ways to build a QA community is by arranging tech talks inside the team. We’ve been practicing it at Lemon.io, — and this strategy has proven extremely efficient. Such meetings are an environment for basic knowledge sharing. Moreover, they help everyone on the team learn about the other team members’ key testing skills, interests, and passions in software testing tools. After such informal teambuilding events, my colleagues know what I’m passionate about and how I can help them with their potential troubles — and I learn about their strengths. Moreover, it’s a perfect opportunity to synchronize in the live mode: not everyone is a Jira fan. 

Choose a QA management tool

Xray, TestRail, Zephyr, TM4J, TestLink — and that’s just a list of tools I used personally. If I had to enumerate all the possibilities, I’d probably fumble with it for half of the day. Which one to choose? That’s a tough question. Everything depends on several factors: what’s the budget, what are the team preferences, will there be automated testing, etc. Btw, we at Lemon.io use TestRail. Pretty good.  

Use regression tests

Testing the main features once is never enough. The regression tests should be improved and deepened with every iteration of code repository additions. The reason is simple: every new feature can (and will) interact with the already tested functionality — and somehow influence it. For QA specialists, it’s necessary to be sure that the new code chunk doesn’t cause the crash of all the previously developed elements. That’s why I’d advise keeping to regression tests. Make them part of a daily routine, especially if your product scales and develops quickly and constantly.

Employ analytics

Don’t throw the testing results away at once. Keep them for future comparison. Decide which QA metrics to track and keep records of every performed test. Use this data to determine where new bugs are likely to occur. Old data will help you to design new tests that address actual and potential problem areas. One more piece of personal advice: add the bug scenarios to the upcoming test cases. They can influence the whole functionality of your product (also in the previously properly functioning areas).

Need some extra knowledge? Squeeze it from our FAQ!

• What are the top 3 quality assurance skills for a QA engineer?

  If you think a decent QA analyst should just be technically savant and able to find actual or potential bugs in the workflow of the given product, you’re a bit wrong. A proficient QA analyst needs more than technical aptness and knowledge of methodologies and programming. Soft skills are also a must for a true professional. Our top 3 include critical thinking, social skills, and flexibility
  
  How do these skills help in testing? Let’s analyze it together.
  Critical thinking helps to evaluate each situation from as many sides as possible, consider the customers’ perspective and amend the product so that it fits as many customer categories as possible.
  Social skills entail productivity of working collaboration and efficient communication. Without them, it’s much harder to cooperate with different teams involved in product creation, whereas such cooperation should be each tester’s daily routine (since it’s the most direct and effective way of learning about product details). 
  Flexibility is one more key social skill for each QA pundit. Different projects require various tools and techniques, and a QA specialist should jump from one to another seamlessly and quickly.
  

• What are the QA engineers’ responsibilities? 

  Below are the key work objectives and responsibilities of a QA engineer. Let’s describe them in detail!
  
  Analysis and review of system specifications. QA specialists run multiple tests making sure that new products satisfy all project requirements. The list of obligatory tests can include probing the system limits and functionality in the desired environment (e.g., via a real-time simulator).
  
  Identification of the functional bugs. QA professionals perform multiple tests and bug fixes. What is more, they run extra final tests before the product release.
  
  Sending bug reports to the production team. QA testers have to track their findings, send bug reports with all the essential information about the found issues, and perform steps for their resolution. 
  
  Cross-functional collaboration with QA engineers helping easier changes implementation. As a QA tester, one should incessantly cowork with cross-functional teams to guarantee quality at each stage of development. Evaluating risks and identifying/resolving dangerous issues ends only after the final product release.
  

• What is the QA role in Agile? 

  Agile software development practices have been developed to establish a collaborative and efficient approach fostering speed, collaboration, and functionality. Agile-based startups have quicker development cycles and turnaround times — primarily thanks to faster and more productive communication between different teams. Nevertheless, higher production speed often impairs the final product quality — and that’s precisely the place for a QA team to come in.
  QA becomes an integral part of development — bringing validation and ensuring the stability of the product. Within the Agile development, testing, and production teams work together daily, they are well informed about each other’s workload and possibilities. Hence they can coordinate their efforts more effectively. The client’s brief becomes a primary manual for collective work — and instant feedback (collected and expressed via Jira or some other teamwork app) enhances its quality. What are the basic pros of Agile-based development? Relevance, stability, quickness, and orientation on the result. 
  

• Is manual QA a poor use of time?

  Any LinkedIn community, online forum, or comment section under the topical article will surely give you some posts/comments foretelling the doom of manual QA testing and strongly advising you to come to the bright automated side. However, although manual QA can be a bottleneck, that’s only a part of the story. Every all-encompassing testing strategy should include a manual component if the end product is designed for human users. When it comes to exploratory or interface testing, we still beat the machines in the long run. No QA program can predict the whole scale of UX situations — ergo, no QA program can eliminate all the potential bugs. Usability problems can kill the new app’s popularity entirely — and who else can check out all the usability issues except humans?
  What’s more, for all the critics who point out the slowness of manual QA as its primary drawback, it’s useful to remember that manual software testing services allow crowdsourcing QA and significantly improve the timing.

• Does manual testing have a future? 

  It surely has — but which strategies will prove the most winning and beneficial in the future? Here’s a concise list.
  1. Concentrate on exploratory testing. Easier systems with predictable feedback and minimal randomness degree allow pre-planned tests. However, predicting the outcomes with AI or blockchain is difficult — just as considering all the unexpected variants. Diversifying data tests and evaluating the decisions against specific metrics will give more useful data.
  2. Rely on previous experience. Testing products developed on top of new frameworks still allows relying on older data, tests, and results — e.g., to compare them with the new ones.
  3. Never give up learning. New technologies and frameworks are overwhelming, but you should at least understand the basic principles of their functionality and implementation so that you can test systems more efficiently.