Software Testing Essentials: Methods, Mindsets, and Techniques for Quality Assurance

UPI Study › Courses › Software Engineering › Free lessons › Lesson 4.4 Free with a free account

Software Testing Essentials: Methods, Mindsets, and Techniques for Quality Assurance

Software Engineering · Chapter 4: Rapid Development, Testing, and Software EvolutionSection 4.4 · lesson 27 of 1039 min · free with a free account

← Guiding Products Forward with the Stage-Gate ProcessNext lesson: How Software Changes Over Time: Evolution and Maintenance →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Methods, mindsets, and techniques for quality assurance.

  • Explain the testing mindset, and why 1 passing run proves little
  • Distinguish unit, integration, and system testing
  • Distinguish black-box from white-box, and manual from automated
  • Combine level, approach, and method as independent choices

Transcript

Everything said in the video, section by section (1,248 words). Read along, or search it.

Rapid Development, Testing, and Software Evolution

Software Testing Essentials

This section is about software testing, and it starts with something more basic than any technique. A mindset. From there, it covers the three levels at which testing happens, and the two basic ways a test can be designed. It closes with the choice between testing by hand, and automating it.

2 Testers, 1 Login Form

Confirming vs. Testing

Two people test the same login form. The first enters a correct username and password, sees the right page open, and marks the form as working. The second enters the same correct details, and then keeps going. An empty password. A username with no matching account. A password many times longer than expected. And two logins submitted at nearly the same moment. The second tester turns up three separate problems the first never had a chance to find. Nothing about the first check was careless. It simply confirmed what everyone already believed. And that is not really testing.

The Testing Mindset

Looking for Defects

Testing is the act of executing a program, or part of one, with the intent of finding defects. It is not merely showing that the program gives the expected answer, for an expected input. That carries a built-in limit worth stating plainly. A passing test shows that the software worked for that specific case. It does not show the software is free of defects. No number of passing tests can prove that defects are absent. But a single, well-chosen failing case is enough to prove that one is present.

Table 1

2 Mindsets, 1 Feature

So there are two very different mindsets a tester can bring to the same feature. A confirming mindset runs the case the software was built to handle, and stops once it passes. It is likely to miss empty input, extreme values, and cases nobody anticipated. A skeptical mindset deliberately tries to break the software, with unexpected or extreme input. It treats a passing result as one data point, and keeps looking for the input most likely to expose a problem.

Levels of Testing

3 Widening Scopes

Testing also happens at more than one scope. Unit testing checks one piece on its own, apart from the rest of the system. A single function, method, or class. Integration testing checks how separately built pieces behave once they are combined. It catches problems at the seams between them. And system testing checks the whole assembled product, against its overall requirements. Each level widens the scope, and each one is suited to catching a different kind of problem.

Table 2

What Each Level Catches, and Misses

Here is what each level is good at, and what it tends to miss. A unit test catches a calculation error or an edge case inside one function. But it can miss two correct pieces that do not work together. An integration test catches a mismatch at the boundary between two pieces. But it can miss a requirement the whole system fails to satisfy. And a system test catches the finished product failing a stated requirement. But it may not reveal the specific internal cause of the defect it detects.

Designing a Test

Black-Box and White-Box

Level describes how much of the system a test covers. A separate question is how the test itself gets designed. Black-box testing designs tests from what the software is specified to do, its intended inputs and outputs. It does not look at, or rely on, how the code inside is written. White-box testing designs tests using knowledge of the code's internal structure. It deliberately exercises specific paths and branches. Neither approach is superior. Each is suited to catching problems the other is likely to miss.

Figure 3

What Each Test Can See

This figure shows the difference in what each kind of test can see. A black-box test sees only the input going in, and the output coming out. The code in between is hidden. So it catches cases where the actual behavior does not match the specification. A white-box test can see the paths inside the code, and deliberately drive each one. That includes a rare branch, like path B here, that might never run under any input a black-box test happened to choose.

Table 3

Black-Box vs. White-Box

Here are the two approaches side by side. For black-box testing, the tester needs the specification. For white-box testing, the tester needs the code, with its logic, branches, and paths. Black-box testing is good at catching behavior that does not match what was specified. White-box testing catches internal errors, including branches that never run. A typical black-box test enters a negative number into a field that expects a positive one. A typical white-box test is written to force a rarely reached error-handling branch to run.

Table 4

Manual vs. Automated

A third, separate question is how a test actually gets carried out. In manual testing, a person executes the steps by hand, and judges the outcome. In automated testing, a script executes the steps, and checks the outcome against an expected result. Automation costs more upfront, to write and maintain the script. But once built, it can run again at almost no cost, which is valuable after every change. Manual testing costs little to start, but each repetition costs about as much as the first. And manual testing stays essential wherever human judgment is the real thing being tested, like whether something looks or feels right.

Putting It Together

3 Independent Choices

Level, approach, and method are three separate questions, asked about the same test. They are not alternatives you choose between once. A real testing effort answers all three, often differently, for different parts of one system. For example, a discount calculation might get an automated, white-box unit test, run every time the code changes. The full checkout flow might get a manual, black-box system test, judging whether the whole experience feels right. And a payment interface might get an automated, black-box integration test. It sends a request, and checks the response, with no knowledge of the internals. Together, combinations like these are how quality assurance is actually carried out during construction.

Think About It

Apply the Ideas

Here are a few questions to think about. Think of an app that only seems to fail in unusual situations. An odd input, an unusual screen size, or a slow connection. What kind of testing might have been skipped? For a simple calculator's division feature, what is one black-box test, and one white-box test, you might write? What does each one actually check? And for a feature built once and rarely touched, versus one that will change constantly for years, which would you automate, and why?

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Testing means executing a program, or part of one, with the intent of finding defects. Unit testing checks one piece on its own. Integration testing checks pieces once combined. And system testing checks the whole product against its requirements. Black-box testing designs tests from a specification, without reference to the code's internal structure. White-box testing designs tests from the code's internal structure, to exercise specific paths. And test automation uses a script to run the steps and check the outcome, with no person repeating them by hand.

Key Takeaways

What to Carry Forward

To pull this together. Testing means executing software to find defects. A passing test shows only that one case worked, never that the software is defect-free. A skeptical mindset, which tries to break software, finds problems a confirming mindset will miss. Unit, integration, and system testing widen in scope in turn, from one piece, to pieces combined, to the whole product. Black-box tests come from the specification, and white-box tests come from the code. Each catches what the other misses. Manual testing is cheap to start but costly to repeat. Automated testing is the reverse. And level, approach, and method are independent questions, which a real testing effort answers differently across one system.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Software Testing Essentials: Methods, Mindsets, and Techniques for Quality Assurance

Can software testing prove that a program has no bugs?
No, testing can show that defects are present but cannot prove they are absent. A passing test only shows the software worked for that specific case. No number of passing tests proves a program is defect-free, while one well-chosen failing case is enough to prove a defect exists. That is why testing is defined as running software with the intent of finding defects.
What is the difference between unit, integration, and system testing?
They differ in scope. Unit testing checks one piece, such as a single function, method, or class, on its own. Integration testing checks how separately built pieces behave once combined, catching problems at the seams. System testing checks the whole assembled product against its overall requirements, though it may not reveal the internal cause of a defect it finds.
What is the difference between black-box and white-box testing?
Black-box testing designs tests from the specification, using only inputs and expected outputs, without looking at the code. White-box testing designs tests from the code's internal structure to exercise specific paths and branches. For example, a black-box test might enter a negative number where a positive one is expected, while a white-box test forces a rarely reached error-handling branch to run.
When should you use automated testing instead of manual testing?
Automated testing pays off when a test must be repeated often, such as after every code change. A script costs more upfront to write and maintain but then reruns at almost no cost. Manual testing is cheap to start, but each repetition costs about as much as the first, and it remains essential when human judgment, like whether something looks right, is being tested.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →