During any kind of software development, a quality assurance process is required if the code quality is concerned. During any human endeavor, including programming, mistakes (bugs) are unavoidable. So the main task of the quality assurance (QA) engineer, sometimes also referred to as a tester, is to identify and raise issues so that they can be fixed in a timely manner. As software types vary greatly so do the QA processes and tools used to test them. In this course, we will take a look at various types of testing (regression, smoke, etc) and learn when and where they are applied. We will also learn how to test mobile, web, and desktop applications and identify which tests can be automated (in another article we will also discuss the tools used while test automation)and how to go about doing that.
Who is this Course for?
No prior familiarity with QA processes is required to take this course. We start with the basics and carry on to advanced concepts in the field of QA automation. We assume, though, that you are familiar with basic HTML (for web UI testing) and REST protocol (for API testing).
What is BDD & TDD?
In the software-engineered world, you’ll hear the terms BDD and TDD casually tossed around. BDD stands for Behavior Driven Development and TDD stands for Test-Driven Development. TDD encourages writing tests before starting the development of a feature. So in the first run, the test obviously fails. After the feature is developed the test is run again and it should pass this time. Consequently, the codebase will have high test coverage which is a good software engineering practice. As you can see TDD is a developer-centric testing approach used for writing unit tests.
BDD on the other hand describes a feature or functionality in a human-readable language called Gherkin, understandable to various stakeholders involved in the project. In practice, we use IDE plugins to have nicely formatted scenarios in Gherkin and runnable methods in Cucumber for Java or Behave for Python. See it in action here.
QA Basics
Depending on the software under the test different tools and methodologies are used for testing but there are some fundamental testing principles shared among various testing approaches. Let’s learn about those principles.
Testing reveals the presence of defects, not their absence
No tester can assure that the software on having doesn’t have any issues. Perfection is hardly achievable in real life. Hence, as testers, we do our best to find and document bugs but we cannot say with absolute confidence that the software under test is bug-free.
Exhaustive testing is impossible
Simply put, you cannot test every possible scenario in which the product under test can break. That’s practically not feasible. Also, it doesn’t make sense because you can gain sufficient confidence in the performance and functionality of your software by strategically covering with tests the most important aspects of it. Meanwhile, automated testing tools exist that can generate a huge number of test cases thus giving you enough confidence in your tests.
Web UI testing
In web UI testing you, as a tester, try to make sure that the elements on the webpage function properly, are placed correctly, and look as intended. To test the functionality of web elements you would normally try interacting with them like clicking a button, choosing an option from a drop-down, etc, and see if they are behaving correctly. The correct placement is easy to check by a visual inspection of the page. Meanwhile, to have a correct look and feel certain CSS attributes should be present. All the described inspections can be done manually though it can be error-prone and time-consuming, especially if there are many pages to test. An alternative is to automate the testing process by writing tests that can run periodically and perform the mentioned tasks. Arguably the most popular tool for automated UI tests is Selenium but another tool called Cypress is also getting popular in recent years. In the Practical Testing Examples section, we are going to see both of those tools in action.
API Testing
Practically all modern web and mobile applications make some kind of API calls to the other servers on the web. Via API requests and responses an application interacts with back-end and third-party services to perform various tasks like user authentication, data retrieval, sending notifications and so on. So correctly functioning API calls are crucial for the application’s health. Though you can check an API call response on the UI side by trying to log into the system or validate data retrieved from a 3-rd party service, it is faster to test the underlying calls directly. Here’s when API testing comes into play. Commonly used API requests are GET, POST, PUT, and DELETE. Every API call consists of a request endpoint, header and body. The body content is usually JSON or XML. The most popular API testing tool is Postman. It lets us make all kinds of API requests and observe the responses. Some advanced features of Postman include Environments, Scripts, Collections, Mock Servers, and more. Besides Postman, we can use special programming language libraries like Python’s requests library intended for working with the APIs. This gives us more flexibility and deeper automation test coverage. We will explore these features in an example API testing project described in Practical Testing Examples section.
Mobile Testing
A popular open-source choice for testing mobile apps is Appium. It doesn’t require including an SDK or recompiling the app. The best part is you can still use the test automation tools you are familiar with like Selenium and it works with iOS, Android, and Windows apps. Both native and hybrid apps are supported.
Appium relies on client/server architecture to fulfill its task. The server listens to commands through its REST API method calls, executes the commands on a mobile device, and returns an HTTP response that represents the result of command execution. An immediate advantage of client/server architecture for testing is that tests can be written on your local machine. When executed it communicates with a cloud service like Sauce Labs to receive and interpret the commands. This is a more scalable approach as opposed to hosting both client and server on the same machine. The client libraries are written in Java, Ruby, Python, PHP, Javascript, and C#.
