Tests, TDD, Unit Test, QA and similar. What is the difference between concepts about tests?

Asked

Viewed 3,902 times

41

In the question of the goal 5 different tags for "testing" I noticed that I have some difficulty understanding all these terms about tests.

Certainly tests have been very important throughout the course of software development. With this proliferate concepts and the alphabet soup is increasing.

What differentiates the concepts involved in tests? Acronyms and formal definitions are easy to discover.

Software testing, unit testing or unit testing (is there a difference?), functional testing, TDD, quality Assurance, Acceptance testing. Is there any other related term that is very important to be highlighted?

2 answers

41


Software Testing

Using the terms of Wikipedia:

It is the research of software in order to provide information about its quality in relation to the context in which it should operate. This includes the process of using the product to find its defects.

Testing is the most general term to see if a particular software works. It can be an entire product, part of it, a method, etc.

The test can be performed by the developer himself, a specialist tester, or a system user. This can occur at any stage of the project, depending on the adopted model (cascade, iterative, evolutionary).

In most projects there is a testing phase, when usually the features of the version are closed the biggest focus of the team is to discover and fix defects still hidden.

Tests can be divided into several types and classifications.

Knowledge about the software

  • White box test: when evaluating the internal functioning of the software. For example, if certain methods perform correctly.
  • Black box test: when evaluating the behavior of the software, through its interfaces. For example, when the user uses the system to see if it returns expected values after a calculation.

The nature of the test

Tests can be performed at various levels and for various purposes:

  • Unitary Test: tests specific parts of the system, such as classes and methods.
  • Integration test: tests several components of a system running at once.
  • System test or Homologation or SIT (System Integration Testing): system execution from the user’s point of view, although not performed by the end user.
  • Acceptance test or UAT (User Acceptance Testing): test performed by the user to verify that the software is in accordance with what was contracted.
  • Regression Test: tests already performed are run again after modifications to the software to ensure that there was no unexpected side effect.

Non-functional testing

In addition to verifying that system implementations are correct, certain types of tests verify non-functional aspects of it. For example:

  • Test of Performance (Performance): checks system performance with a normal load of users. For example, the average response time is 2 seconds with up to a thousand users.
  • Load Tests (Volume): checks the maximum capacity of the system, i.e., the point where it hangs or fails to respond in an appropriate time.
  • Resilience Test (Stress): checks the behavior of the system and its ability to recover from unexpected failures such as power outage, database failure, access spikes.

Test automation

It is possible to perform all types of tests without automation. On the other hand, there is great advantage in automating some of them for effortless repetition of the same.

A Unit Test can be executed by creating an independent class or script to test methods and classes. In Java, it would be a method main.

But if used in an automation framework, the same Unit Test can be run as often as needed. It would be a Regression Test at no additional cost. In Java this can be done with Junit.

Test Driven Development (TDD)

TDD is a test-based development methodology. The main idea is to reverse the "traditional" sequence of development by putting the test first, before implementation.

You write each test according to the respective requirement. So you can track progress as each test fails and succeeds.

A lot of people write Unit Tests and think they’re doing TDD. It’s not the same thing. It turns out that teams that adopt TDD usually use automated Unit Testing to speed up the process.

Have a little more information about testing and TDD in this my other answer.

Quality Assurance or Quality Assurance (QA)

QA is not directly related to software. It is an area that tries to ensure quality in all aspects of a project or service through audit processes.

It has its own techniques, certifications and processes. All this is independent of the software development cycle.

  • 5

    There is a very important conceptual confusion about TDD here and the other linked response. They suggest that you need to have the requirements, write the tests, and then pass the tests - all plural. TDD is exactly the opposite: You need to have 1 tiny requirement, write 1 test and then pass the test, then you refactor and write the next test. TDD wants to allow the evolution of the requirements throughout the project. Each test ensures a small requirement and the test suite ensures that nothing has been broken. TDD gives the feeling!

  • @I agree in part. I changed the two answers to take the plural, because the original idea is to actually write each test individually, or at least have the ability to do that. Since TDD was based on XP, the idea is to evolve the system architecture gradually. In practice this rarely works because in a team with developers working in parallel the result would be parallel architectures, duplicate code and a huge job merging. It is best to have a lean initial architecture and at least the most critical requirements tests from the start.

  • @Caffé I also agree that TDD allows building the system incrementally, but to say that TDD "allows the evolution of requirements throughout the project" is exactly the opposite of what the author of the TDD himself says (see video at the end of the other answer). If the requirements "evolve" in the sense that they change over time (are unstable), then at each change the previous tests no longer represent the expected behavior of the system, therefore TDD may not be suitable unless it is worth it or it is possible to rewrite the tests countless times.

  • I watched the video now again (I watched this Angout and the others live at that time). I really can’t figure out where Kent Beck suggests that evolving requirements are not supported by TDD. All philosophy (and tools - including XP and TDD) developed over several years and formalized later in the Agile manifesto is reasoned in the fact that requirements change throughout the project. CHANGEOVER is the foundation of Agile and therefore the reason for its tools as TDD. Even another Agile tool is Seamless Integration, where the problem of laborious merges is solved.

  • Philosophy aside, what I have seen in practice is TDD, accompanied by other practices, working yes. Of course you have to learn how to do it first, and wikipedia and other misguided articles on the Internet unfortunately don’t help much. And of course TDD is not the only thing that works. I learn a lot every day from other programmers who do a fantastic job and make a lot of money for their companies and who don’t even know what TDD is (although some think they know).

  • In time, @utluiz, I’m not trying to give you anything new. It is clear to me that although we express ourselves in different ways about these concepts, you know them well. My intention is just to show another point of view for those who pass through here - the view that TDD works and is useful precisely in projects where requirements change.

  • @Caffé Perfeito. I probably didn’t give a complete and realistic picture of what I think about TDD. I defend methodology as a lifestyle, not only as a specific practice within development projects. However, my answer stressed the criticism I have on how the process ends up being executed in practice. The truth is that most of the projects I see start well, but end up abandoning TDD when many changes occur or in later stages because it takes a lot of work to refactor the tests as the requirements change.

  • Of course, one could argue that this is the result of the laziness of developers, inexperienced professionals, insufficient time, bad architecture, etc. But as the vast majority of companies suffer from these problems, so rarely can TDD in its pure form be well applied. As for the video, I probably made a mess. I think it was David who said something about TDD not being viable for certain types of projects. But although he’s right in one way or another, he still sounds like an immature teenager complaining about the previous generation.

Show 3 more comments

-6

I have to disagree on the above colleague’s parts.

About the SQA methodology - Software Quality Assurance, which consists of monitoring the processes of software engineering and development. This principle is based on a strong definition of requirements, coding, code refactoring, testing, version management, among others.

It is clear the idea that SQA is directly connected with the ideas of commitment of Performance and Quality. Being these same ideals that the TDD seeks to achieve, being directly linked according to my opinion.

The process of carrying out system development from the testing initially appeared in the mid-2000s along with the practice of Extreme Programming, with the idea of starting development by routine testing.

With an agile manifesto, which brought the LEAN culture to software development and practice of Extreme Programming, we came to take a new mindset to carry out our work as developers. We have absorbed the 5 principles of the LEAN mentality:

  1. WORTH;
  2. VALUE FLOW;
  3. CONTINUOUS FLOW;
  4. HARD-WORKING;
  5. PERFECTION.

Mary Poppendieck, who perfected the LEAN methodology for software development brought us 8 principles:

  1. Eliminate waste;
  2. Amplify knowledge;
  3. Develop with quality;
  4. Postpone decisions;
  5. Fast deliveries
  6. Respect people
  7. Continuous improvement;
  8. Optimize as a whole.

If we analyze both LEAN thinking and XP practices, we will see that they seek software perfection and deliver a quality product to the customer. Always focusing on the prevention of failures, therefore the use of TDD.

The use of TDD aims precisely to develop a software with a clean coding, based on the practice of YAGNI (you will not need it) and a system without errors, based on the LEAN methodology, to deliver a quality product to the customer.

A good way to prepare to perform the TDD, through assert, is to add an accepted criterion in the User Story that will give rise to the code. Ex.

AS A ... I WANT ... SO THAT IT IS POSSIBLE ...

The ... endings will help you understand what should be written in the assert of your test, so that from it you start coding and finally arrive at the expected result.

ps. I wrote about it on my blog.

  • 2

    Disagree on what exactly? Besides, SQA is different from QA. And what process does not seek performance and quality? TDD and SQA are at opposite ends of process classification. Anyway, how to talk about Lean and XP answers somehow the question asked?

  • I believe that when we are talking about Quality Assurance and TDD in the same topic we have no way to take QA away from software. Even more, I think it’s important to mention where the TDD culture came from, which was exactly, if you don’t know, the LEAN methodology of Toyota (based on jidoka), as well as the XP culture. In which they aimed at continuous improvement and delivery of a quality product.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.