QA is a fairly well-known term in software engineering, but many people either don't understand the purpose of it, or don't understand how it adds value to the software development process. I'm going to discuss a few fundamental concepts that I wish I understood when I was a student.

Why QA? Quality assurance is an important part of software development because, despite all our best efforts, bugs are common. QA is a process for evaluating new changes to your software in order to catch those bugs, ideally before they make it into production.

QA is also often a role on a team (Quality Assurance Engineer), and I may inadvertently use the terms interchangeably.

How QA? Any software engineer probably implicitly understands the basic unit of QA: manual testing. This is exactly what it sounds like -- opening your software, then performing a sequence of actions to make sure that every feature of the app works as intended.

Aside from manual testing, you can also automate testing. Depending on the type of program, automated testing can look fairly different. However, generally speaking, the purpose is the same: a script that runs through various functions of your application, then evaluates the behavior and compares it to what its expected outcome is.

A few types of automated tests:

• Unit tests: testing the smallest testable parts of an application. Example: for a calculator app, adding two values together and making sure that the value returned is the sum of those two values.

• End-to-End tests: testing a "flow", or a sequence of behaviors and making sure that each step along the way works as expected. Example: an end-to-end test for a phone app might run through these steps:

1. Open app

2. Navigate to phone book

3. Select a specific entry from the phone book

4. Click on the phone number and make sure that the phone app dials that number

• Integration tests: sending requests to a live API and making sure that the response matches what is expected. It tests both the connection and the behavior of your app with a live response.

When QA? It's important to have a structured approach to testing, in order to be most effective and most efficient. So most teams will conduct different types of testing at specific points in the development cycle.

• During development: your code should have unit tests to cover about 70-90% of the lines of your code base. You should write those tests so that they pass, then run them regularly. This will ensure that you don't accidentally break a feature after you build it. Introducing such a change (that breaks an already-implemented feature) is called a "regression".

• After development: it's a good idea to have someone else review your work once you've finished writing a feature. The main idea behind this is that when writing a feature, most people focus only on the expected functionality, and tend to ignore undesired or unexpected behavior. So when testing someone else's code, it's important to make sure it doesn't just do what it's supposed to (testing "positive scenarios"), but that it DOESN'T do anything it ISN'T supposed to do (testing "negative scenarios").

• Before release: once your product is ready for release, it's good practice to do "regression testing", which is just a set of tests (manual, automated, whatever is most appropriate) that comprehensively test your app's functionality to make sure you don't have any regressions.

Testing Scenarios: when writing your tests, it’s important to cover a few categories of tests.

• Positive scenarios: what your program should do, if all goes well. Expected behavior. Most important type of test to write.

• Negative scenarios: what your program should do if there’s an issue. This will cover error handling, error messaging, empty states (e.g., if there is no data to display) and possibly logging for these cases. Not as important as positive scenarios, but any customer-facing technology should include coverage of what to do in case of failure.

• Edge cases/corner cases: how your program behaves if it gets some rare or unexpected input. This might include scenarios that might be impossible, or just rare. This is usually the last type of test to write, and may just be added to cover bugs that arise after deployment or behavior that wasn’t initially considered.