Testing Archives

The Vital Role of QA on Your Next Project

Quality Assurance (QA) testing is vital in achieving any software product’s technical requirements, development, and design. Testing helps deliver high-quality applications with few errors. Moreover, QA testing enhances the software’s accuracy, efficiency, and usability. As technology evolves rapidly, users increasingly demand excellence in performance, reliability, and usability from software applications. In this ever-changing software development landscape, Quality Assurance (QA) becomes indispensable.

The Importance of QA

Enhanced Product Quality

QA helps identify and rectify defects early in the Software Development Life Cycle, ensuring that the final product meets or exceeds user expectations. QA teams contribute to the software’s overall excellence by conducting thorough testing and implementing best practices.

Cost Savings

Detecting and fixing bugs during the early testing phase is far more cost-effective than addressing them post-deployment. QA helps minimize the risk of costly rework, customer dissatisfaction, and potential legal issues, ultimately saving time and resources in the long run.

Improved Customer Satisfaction

High-quality software translates to satisfied customers. By delivering reliable, user-friendly products free of glitches and errors, businesses can build trust and loyalty among their user base, increasing customer satisfaction and retention.

Risk Mitigation

QA helps mitigate the risks associated with software development, such as security vulnerabilities, performance bottlenecks, and compatibility issues. Through comprehensive testing and risk assessment, QA teams identify potential threats and take proactive measures to address them before they escalate.

Compliance

In industries where regulatory compliance is mandatory, QA ensures that software products meet the required standards and guidelines. By adhering to industry-specific regulations, businesses can avoid legal repercussions and maintain their reputation in the market.

Collaboration between development and QA teams

Also, collaboration between development and Quality Assurance (QA) teams is crucial for smoothly delivering high-quality software products. This partnership enables transparent communication and efficient processes and guarantees that the end product aligns with user needs and expectations.

Early Involvement for Proactive Issue Identification

Engaging QA teams from the outset allows for the early identification of potential issues, enabling proactive resolution and preventing defects from proliferating throughout the development lifecycle.

Alignment of Efforts for Efficient Testing

By understanding project goals and priorities, QA teams can tailor their testing strategies to focus on critical features and functionalities, ensuring efficient use of resources and faster time-to-market.

Fostering a Culture of Quality

Collaboration between development and QA teams promotes empathy, trust, and teamwork, fostering a quality organizational culture.

Continuous Improvement and Innovation

The exchange of feedback and lessons learned encourages constant improvement and innovation in development and testing processes.

Conclusions

Remember, the success of your software relies on its quality and timely launch. Quality assurance staff play a crucial role here. When choosing a partner for quality assurance, trust recommendations, and expertise.

At Oktana, we have a proven track record of working with different companies. Recently, we partnered with a US Fintech and implemented an automated QA process, introduced best practices for quality assurance, and optimized time management to detect bugs promptly. As a dedicated staff augmentation team, we seamlessly integrate with our customers’ operations and have strong collaboration and alignment.

Contact us to explore our services and discover how our extensive knowledge at Oktana can assist you in launching a successful project.

QA testing methods for better products

Agile processes inspire a more collaborative environment for the design and release of digital products. This methodology, particularly popular among tech and innovative entrepreneurial companies, brings a new high-speed workflow that companies must be able to meet. In this context, QA testing methods are more important because of their ability to increase efficiency and improve work processes within the tech industry.

Having consistent QA testing procedures will increase your customers’ satisfaction, which will be reflected in long-term commercial relationships. QA has a direct impact on revenues, so it’s important that leaders include QA engineers in the entire process of digital product development. A strong QA team provides a wide range of tests that make sure digital products work, and saves companies a lot of money and working hours. Let’s go over some of the QA methods our team applies.

Smoke testing

Smoke testing is very helpful to review whether the most crucial features involved in an app or software are working properly. It’s a primarily scripted testing method that provides a quick big picture view of your digital product. Smoke testing aims to ensure overall functionality. It’s a useful starting point to get the bigger picture of the digital product and proceed with other more specific methods. It’s also a source of data to decide if it’s time to continue to production or conduct other tests. As part of our QA strategy, we perform smoke testing all the time with Tok, our Chatter messaging app. This is particularly helpful to ensure our new versions are 100% ready to be released in AppExchange.

Regression testing

Regression testing requires tests to be performed for every single area of functionality for the app or software after a change has been made. When bugs are found and the team does their best to fix them, the programming code changes. Each time the code is changed, it may impact other functionality that wasn’t supposed to be affected and may result in new bugs that need to be fixed. Regression testing helps us trace any unexpected impact from alterations. We helped Zola, a wedding registry, planning, and retail company, to test their web and native mobile apps. Regression testing provided great results and new learnings for both of us.

Sanity Testing

Sanity testing is not performed to verify the core functionality (such as regression testing), but to double-check the rationality (sanity) of the digital products. It focuses on one or two (or a few) sections of the software. If any of them doesn’t retrieve the expected result; then the build should not continue with more rigorous procedures that may demand an extra investment of time and money. This method is characterized as being narrow, deep, and normally unscripted.

Exploratory Testing

This method encourages the QA team to “explore” the application and play around with it to identify and report any possible bugs. Test cases are not required in advance. Actually, experimented teams use it to gain time before the Requirement Documents are not available yet. We are not talking about a lack of procedures; we are talking about the possibility of discovering, learning, and executing tests simultaneously. That’s why exploratory testing is widely used in agile environments. We highly recommend this method in your testing strategy because it uncovers issues that another functional testing wouldn’t be able to, it puts an emphasis on the UX, and trains your team to become more intuitive and creative.

Other tests:

Besides the three methods listed above, others may be included in the test plan according to the QA engineering criteria and, of course, the nature of the digital product. Here are some of them:

Unit testing, the core of QA testing: This procedure aims to isolate functional pieces of code and test them separately. This way, the QA engineer makes sure every single part of a system works properly. This first scan provides predictability for the QA team to test at a higher level.

Integration testing: When programmers write code, it interacts within a more complex system and those interactions must be tested with the same strictness. So, after unit testing has been successfully conducted, isolated functional pieces of codes are tested together.

Stress-testing: Facing the unexpected is a part of life and it’s necessary to embrace it. Even though a digital product was thought to meet some criteria, it’s very likely that during its life cycle, exceptional situations will be presented. The QA engineer pushes the software to its maximum potential to discover bugs or points of improvement that are hard to identify in regular scenarios.

End-to-end testing: In this type of test, the entire application or digital product is tested from a user perspective. It aims to analyze all possible ways a user can interact with the digital product and then, identify and register every point of improvement. The user is the center of this testing method, so the data reported can be particularly useful for the UX strategy.

Our commitment to QA testing

Because we have helped a lot of customers build and boost their digital products around Salesforce, we understand the importance of QA testing. Having a strong QA process not only means meeting our customers’ expectations but also implies money and time savings for our company. Tok, our Chatter messaging app, and other Lightning web components remind us every day that QA testing is a procedure that never ends, but is worth all the time and energy we put into it.

Agile Testing Mindset: A change to empower quality

Let’s start at the beginning. When we talk about Agile development, we have an almost inherent perception of producing high-quality software in the shortest time possible. In addition, to maximize the value of the business by delivering part of the solution, which generates value, incrementally, and iteratively. With this idea in mind, we began the design and deployment of a multidisciplinary team in an Agile framework. However, in reality, it can be seen that quality tends not to be the priority in the team since it is often displaced by the pressure of time-to-market that stakeholders, with good reason, exert throughout the workgroup.

This phenomenon, recurrent in most of the projects in which I have been able to participate, obviously leads to a greater problem. On the one hand: We comply with the requirements, we deliver the product on time, we launch the releases; in short, we deliver more and more work. However, on the other hand, the quality of the product and the motivation of the work team are damaged, which generates stress and reluctance in the people involved in the development of the product in the long term.

Agile Testing approach

An alternative approach that attempts to solve this phenomenon is called Agile Testing. It was born as a test practice that follows the principles of agile development. This approach is composed of activities that ensure the generation of quality software throughout the agile framework. By knowing the level of agile maturity of the team -including the company where those involved in the production of the product operate-, these activities are executed based on a list of responsibilities and a framework that synchronizes and directs the “test-driven development”. Promotes early and cross-cutting participation of software testing at all levels of the production process.

What is new about this Agile Testing approach is determined by the involvement of the “Whole Team”. That is, everyone is responsible for quality. Everyone has a responsibility to ensure that they deliver a high-quality product. Everyone has the slogan to contribute to the quality of the software. This approach uses the technical skills of team members to proactively and early check their work at the pace of the project. It seems that by common sense we should carry out these activities; however, sometimes common sense is the least common and more so when there is pressure to deliver the work in the agreed time. I don’t mean to deliver less work, I mean to change your mindset. To stop appointing the quality engineer as solely responsible for the quality of the product. I mean, we all get involved in quality and take advantage of our technical and soft skills to enhance it.

A crucial problem that I notice in the implementation of agile practices is the lack of commitment of the workgroup to participate in the activities that are defined, which leads to demotivation for continuing the practices tending to distort them. In my experience, training, and deploying agile teams, I can conclude that we should first develop the agile “being” and then the “doing”. For this reason, the team must internalize the Mindset for the execution of the tasks to be carried out in the project. Agile Testing is a framework that tries to solve this problem by emphasizing the Mindset of people and encouraging them to get involved in the quality of the product developed at each stage of the development process.

Agile Testing Manifesto

There is Agile Testing Manifesto -similar to the Agile Manifesto- which aims to guide the commitment and behavior of the team. It supports defining the correct parameters that the team can follow within an agile framework. This Manifesto prioritizes the “being” that those involved should be clear about to start any project and then execute each iteration. In this regard, Samantha Laing and Karen Greaves (2016), in their Book “Growing Agile”, express the following:

“Testing throughout OVER testing at the end”: This would mean changing the paradigm and making early involvement of quality activities. That is, change the Quality Control for Quality Assurance.
“Preventing bugs OVER finding bugs”: This means that we must break the traditional premise of “our mission is to find all defects”. On the contrary, we must really work as a team so that defects can be avoided in advance.
“Testing understanding OVER checking functionality”: That is, understanding the business, what the user wants, why he wants it, and not just comply with the documented specifications.
“Building the best system OVER breaking the system”: It refers to focusing the tests to develop a better system. Collaborate and lend our knowledge to build the best possible software.
“Team responsibility for quality OVER tester responsibility”: I reiterate, the key point to deliver a quality product is to have the entire team committed and work together to generate a better result and make a difference. All engaged in agile activities and practices.

Now, within this new framework, there is a new role that will have the mission of collaborating with the team at a functional and technical level. This new role called Agile Tester must have the ability to communicate agile practices. Likewise, it will guarantee that all those involved are concerned about the quality of the process from the role where they are located. The Agile Tester will have a technical mastery and focus on the business. In this regard, Lisa Crispin and Janet Gregory (2009), in their book “Agile Testing: A practical guide for testers and agile teams.” propose 10 principles that the Agile Tester must develop and are the following:

1. Provide continuous feedback to the team and the business

2. Keep actions and decisions simple

3. Enable face-to-face communication

4. Practice continuous improvement

5. Focus on people

6. Deliver value to the customer

7. Respond to change

8. Self organize

9. Have courage

10. Enjoy

These principles dominate the development of soft skills. In addition, they have a close relationship with the Mindset of an agile team. Finally, they empower the leadership that is needed to direct, motivate, and guide the activities that diminish over time in a traditional agile situation.

For the implementation of the Agile Testing Manifesto and the principles, we can make use of various dynamics and liberating structures. These try to help people internalize the new paradigms in the entire work team. However, the key to this new framework is having the team’s commitment to do things differently.

“If we want different results, let us stop doing the same.”
Albert Eisten

Learn more from our team here, or check out our services.

API Testing with the Karate Framework

This article has two goals. The first is to find interesting information about API Testing with Karate. The second is to help you discover how interesting test automation is and dive deeper into the knowledge behind the passionate job of testing.

And why testing and not Quality Assurance? In this topic, I follow Michael Bolton when he says “Testers: Get Out of the Quality Assurance Business” Words matter and this is a matter of expectations management: we cannot promise something we cannot accomplish.

Michael Bolton

The Forgotten Layer of the Test Automation Pyramid

When we think and design a testing strategy we should not forget The Forgotten Layer of the Test Automation Pyramid: The service layer.

Here is where we need to mention the test automation pyramid. This concept is introduced by Mike Cohn in his book Succeeding with Agile.

He describes three levels of test automation, their relationship, and their relative importance. The base layer consists of unit tests and the top layer corresponds to user interface-level tests.

Many times when we start testing without a proper strategy we end up doing the opposite: investing most of the time and the effort in UI tests, which are more expensive to develop and maintain than unit tests. Also we can forget to develop tests for the service level, that’s why they call it the forgotten layer.

As Joe Collantonio described some years ago now, API testing is becoming more and more important. So even if we agree or not with the test automation pyramid schema, it reminds us that we have to pay attention to API testing as part of our strategy.

Software Development Life Cycle

We’re into a spatial representation of the job. As we move down in the testing pyramid, the tests are cheaper, easier to develop, and can find issues in earlier stages, which makes them easier and cheaper to fix than in later stages.

This can be seen as moving left in the Software Development Life Cycle (SDLC), so many teams are involved in Shift Left Testing. Is that enough? It’s not, but it’s a really good move. Which is the next step? Continuous testing. Involve testing in every stage of the SDLC, doing it efficiently, doing it repeatedly, as part of the whole process.

Here is when selecting the right tools becomes important: a testing tool that can integrate with our CI (continuous integration)/CD (continuous delivery) systems is a great value.

API Testing Resources

As API testing becomes more and more important, we can find a lot of sites to help us learn more about it. I can suggest just a couple of them which I found very useful:

Learn more about the Karate framework

Why is Karate so attractive? Because it’s an open-source tool that combines API test-automation, mocks, performance-testing, and even UI automation into a single, unified testing framework.

Let’s take a look at some of the benefits:

Language neutral
Suitable for non-programmers
Elegant DSL syntax
Built on Cucumber / BDD Syntax
Integrates into existing CI/CD
Good documentation
Good demos

This Hello World example gives an idea of how simple yet powerful it is.

Peter Thomas provides a deeper explanation in his Webinar on Micro-services Testing With Karate.

I found really good arguments about how we can leverage the goods of Karate for our own project. Learn more in the following example: Karate, the black belt of HTTP API testing?.

Some points that look interesting are:

Tests = Documentation: tests are so easy to read that you can document your API with your tests. And as you have to maintain your tests as the API changes, you have your documentation always up to date.

Simple: Karate takes care of complexity so you don’t have to worry about Json processing as Karate takes care of that.

Re-use Karate tests in Gatling to do performance testing: having the power of Gatling based on the API tests you already have is a big win.

Comprehensive and detailed reports: Karate brings powerful and detailed reports that makes reading the status of our tests very easy. It’s also helpful to debug and troubleshoot problems when you get failures. If you add the benefit of Gatling reports it’s like having two superpowers.

Data Driven Testing: you can run your tests through tables.

Mocks fake HTTP servlet: you can execute your tests with a mock server that implements your API.

Karate vs Rest-assured

Do you need to decide which tool suits better for your needs?

Refer more about the following comparison here.

Extra sources about Karate API Testing

I found very useful the following example in Test Guild site.
You can also check this demo.

Conclusions

I found Karate can be a great option for automating the checks in the forgotten layer, integrating it in your CI/CD schema, also re-using your tests as the documentation of your API and for performance testing.

Is the right tool for you? It depends on your particular project, your needs, and your team. If you want to add the API testing to your strategy, you don’t have too much time and you want to make it simple, it seems like a great option.

Learn more from our team here, or check out our testing services.

Selenium Automation in Salesforce

Lightning and its components have more auto-generated code than other apps, this usually makes the development in Salesforce easier, faster, and more stable! Keep reading and learn more about Selenium Salesforce Automation.

From an automation perspective, this makes things harder and forces us to be more creative when finding locators and interacting with apps. Some things like the ID’s auto-generation and the possibility of multiple attributes with almost the same code makes us rethink the way we locate the WebElement.

In order to select these elements, we need to use all that is in our hands. To do so, we need to understand more about locators.

In general, deciding on which kind of locator is better is like debating whether winter or summer is better. You will have people going for CSS and other people going for Xpath.

The important thing here is understanding when to use each and how to use them in the best way.

CSS:

Most people consider that CSS is better because the operation of finding an element with CSS is faster than Xpath and most of the time it’s easier to read.

Ten years ago the difference in time was a couple milliseconds, but nowadays with the processors we have, it’s just a fraction of a millisecond.

XPATH:

Xpath is the most powerful method. For example, it allows us to go forward and backward in the HTML, lets us search for the text of an element and it’s easier to find a sibling with it.

Unfortunately, there is a bigger learning curve so people tend to fear it.

So, which one should I use to automate Salesforce tests?

It depends on many things. For example:

Is your team already using one of them?
In most cases, the priority is going to be maintainability, so try to keep using what your team has already been using.

Are the elements you are trying to find complex and hard to identify?
In this case, Xpath can be a good choice as we need as much power as we can.

Both of these are things to consider when deciding between CSS and Xpath

How to find a CSS locator:

In browser:
Right click -> Inspect Element ->Console

There are two ways to look for elements, we can use a single $ symbol or use it twice, like $.

When using the single $ symbol, we are looking for the first element that meets the criteria that we specify.
When using the $, we are looking for the list of elements that meet the criteria.

I recommend to always use the $ so we can see the full list of elements that meet these criteria. Be aware that our locator is pointing to multiple elements because this could cause issues in our automation.

Search for element type (button, div, a, span, etc):
$(“elementType”)

Search for attribute (src, title, placeholder)
$(“[attribute=’attributeValue‘]”)


Example: $(“[title='Users']”)

Search for id:
$(“#elementId”)


Example: $(“#username”)

Search for class:
$(“.className1.className2”)

Example: $(“.slds-clearfix.slds-card.detail-panel-root”)
Also: $(“[class=’slds-clearfix slds-card detail-panel-root’]”)

If you want to select a class just for one of the classes you can do something like this:

$(“.detail-panel-root”)

Also you can use the wildcard: $(“[class*=‘detail-panel-root’]”)

Select the child of a specific element:

Status


$("parentElement childElement")
$(".test-id__field-label-container span")

How to find an Xpath locator:

In browser:
Right click -> Inspect Element -> command+f

Search for element type (button, div, a, span, etc):
//elementType

Search for attribute (src, title, placeholder)
//elementType[@attribute=’attributeValue‘]

Example: //span[@title=’Users’]

Search for class:
//elementType[@class=’className‘]

Example: //div[@class=’slds-clearfix slds-card detail-panel-root’]

Search for an element with a partial attribute (contains):
//elementType[contains(@attribute,’attributeValue‘)]

Example: //div[contains(@title,’123′)]

Search for element’s text:
//elementType[text()=’Text you are looking for‘]

Status

Example: //span[text()=’Status’]

Search for an immediate child:
//elementType[@atribute=’attributeValue‘]/inmediateChildType

Example: //div[@id=’test’]/span

Search for a grandchild or any other descendant:
//elementType[@atribute=’attributeValue‘]//descendantType

Example: //div[@id=’test’]//a

Search for a sibling:
//elementType[@atribute=’attributeValue‘]/following-sibling::siblingType

Process Name
Test



//span[text()='Process Name']/following-sibling::div/input

Why is it I can find an element in the Developer Tools, but Selenium can’t?

Generally this happens for two reasons:

There are multiple tabs open and Selenium is looking into the wrong one.

We can fix it executing the following line in our test:

driver.switchTo().window(driver.getWindowHandles().toArray()[{numberOfTabsYouWantToUse}].toString());

I.E: driver.switchTo().window(driver.getWindowHandles().toArray()[0].toString());

The element you are looking for is inside an iframe.

You can verify if it’s in an iframe or not by right clicking on the element you are trying to find and then click in the Console tab. Then you will see if the dropdown is in top ( the default content) or if it’s in an iframe.

If you are in an iframe, you have to switch to it in your test in order to interact with its elements. To do this, you can use the following code:

driver.switchTo().frame({iframeWebelement});

I.E: driver.switchTo().frame(driver.findElement(By.cssSelector(“iframe”)));

Learn more from our team about developing on the Salesforce Platform, or check out our Salesforce custom development services.