Dry Run Testing: Simulating Before Shipping, Explained

UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 7.7 Free with a free account

Dry Run Testing: Simulating Before Shipping

System Analysis and Design · Chapter 7: Implementation, Testing, and MaintenanceSection 7.7 · lesson 52 of 697 min · free with a free account

← Exploring the Different Types of Software TestingNext lesson: Keeping Software Alive: The Maintenance Phase →

Earn 3 college credits for System Analysis and DesignRecommended for credit by NCCRS · Computer Science 390 · self-paced · one payment, lifetime access
Enroll in System Analysis and Design · $250 →Download the syllabus (PDF)

In this lesson

Simulating code and deployments before they run for real.

  • Define desk checking, and explain when it is used
  • Trace program logic by hand with a trace table
  • Explain what a go-live rehearsal is, and why teams run one
  • Explain how dry runs complement automated testing

Transcript

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

Implementation, Testing, and Maintenance

Dry Run Testing

The cheapest bug to fix is the one caught before anything runs. This section is about dry run testing, simulating before shipping. We will cover desk checking and trace tables at the code level, go-live rehearsals at the deployment level, and how both fit alongside automated testing.

Figure 7.7

Simulate It Before It Happens

Dry run testing works through a system's logic, or a process, as a simulation. Nothing is actually executed on a computer, or carried out in the live production environment. It happens at two levels. At the code level, early on, an analyst or developer traces an algorithm's logic by hand, before any code is run. At the process level, just before deployment, a team walks through the actual steps of the deployment, before the real cutover happens. Both catch problems while they are still cheap to fix, before a mistake shows up in running code, or in front of live users.

Desk Checking

Executing Code in Your Head

Desk checking is reading through code or pseudocode line by line, mentally executing each step, to verify the logic before ever running it. It needs nothing but the code and a careful reader. That makes it one of the cheapest testing techniques there is. It is most valuable early in development, before an environment even exists to run the code in. It is valuable for critical algorithms, where a logic error would be especially costly to discover later. It works well as peer review, because someone other than the author often catches assumptions the author no longer notices. And it is one of the best ways to learn to read code carefully, which is why even experienced developers still practice it.

Trace Tables

Tracing Logic by Hand

Desk checking relies on a structured tool, the trace table. A trace table records the value of every relevant variable after each step of an algorithm, so its behavior can be followed by hand, one line at a time. Here is some pseudocode meant to add up the numbers one through four. Line one sets sum to zero. Line two starts a loop, with i running from one to four. Line three adds i to sum on each pass. Line four ends the loop, and line five prints the sum.

The Trace

Step by Step, Variable by Variable

Now trace it, recording what each variable holds after every step. After line one, sum is zero, and i has no value yet. On the first pass through the loop, i is one, and sum becomes one. On the second pass, i is two, and sum becomes three. On the third pass, i is three, and sum becomes six. On the fourth pass, i is four, and sum becomes ten. Then line five prints ten. The trace confirms the algorithm is correct. One plus two plus three plus four is ten.

Finding a Bug

The Same Trace Exposes a Mistake

The same technique surfaces a bug just as easily. Suppose line two had read, for i equals one to five, by mistake. The trace table would show a fifth pass, with i equal to five, that should never have happened. Sum would end at fifteen, instead of ten. That wrong loop boundary is visible on paper, before the code is ever compiled or run. So when a trace table shows a variable reaching an unexpected value on the final pass, it points straight at a logic error, like this one.

Go-Live Rehearsals

A Dry Run of the Deployment

A go-live rehearsal takes the same idea, simulate it before it really happens, and applies it to the deployment process instead of to code. The team walks through the actual sequence of cutover steps, either in a staging environment, or simply talked through in order. A rehearsal verifies five things. That the steps are in the right order, and nothing is missing. Who owns each step, so nothing stalls waiting on an unclear owner. Exactly how to reverse the deployment, if something goes wrong. Which steps take longer than expected, so that surprise does not happen during the real event. And that stakeholders and users are notified at the right points.

The Common Idea

Cheap and Private, Not Costly and Public

A go-live rehearsal offers exactly what desk checking offers at the code level. It finds a problem while it is still cheap, and private, to fix. During the live event, the same mistake is both more expensive, and visible to real users. This is why the rollback check matters, even if the real deployment goes smoothly. A rehearsal cannot guarantee a smooth cutover. Without it, a real problem during cutover would be the first time anyone had ever tried the rollback steps.

Complements, Not Competitors

Dry Runs Alongside Automated Testing

Dry run testing does not compete with automated testing. The two catch different things, at different points. Dry runs happen before code is ever run, or before a live deployment. Automated tests run after code exists and can execute. Dry runs need no working environment. Automated tests need an environment, or a test harness. Dry runs catch logic errors, missing steps, and misunderstood algorithms or processes. Automated tests catch regressions, across many scenarios, quickly and repeatedly. A dry run costs only human time. Automated tests cost more to set up, but are nearly free to repeat. So a team that says thorough automated tests make dry runs unnecessary has it wrong. Automated tests verify code that already runs. A go-live rehearsal verifies the deployment process itself, which automated tests never cover.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Dry run testing simulates logic or a process before it runs for real. Desk checking reads code line by line, mentally executing each step. A trace table records each variable's value after every step of an algorithm. And a go-live rehearsal walks through the actual cutover steps, before doing them for real.

Key Takeaways

What to Carry Forward

To pull this together. Dry run testing simulates code logic or a deployment process before it actually runs, catching problems while they are still cheap to fix. Desk checking reads through code or pseudocode by hand, to verify its logic before it is ever run. A trace table records each variable's value after every step, making an algorithm's behavior, and its bugs, visible on paper. A go-live rehearsal applies the same idea to a deployment, surfacing sequencing, ownership, rollback, and timing problems before the real cutover. And dry run testing complements automated testing rather than replacing it, because each catches different problems at different points.

About System Analysis and Design at UPI Study

System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance 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 System Analysis and Design with UPI Study

From business problem to working systemSystem Analysis and Design teaches how analysts study a business need and turn it into a system design: requirements, UML and data-flow models, interface and database design, implementation and project management. It is a core course in information systems and IT 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

System Analysis and Design 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 Dry Run Testing: Simulating Before Shipping

What is desk checking in programming?
Desk checking is reading code or pseudocode line by line and mentally executing each step to verify the logic before running it. It needs nothing but the code and a careful reader, which makes it one of the cheapest testing techniques. It is most useful early in development, for critical algorithms, and as peer review, because another reader often spots assumptions the author no longer notices.
How do you use a trace table to check an algorithm?
A trace table records the value of every relevant variable after each step, so an algorithm can be followed by hand. For a loop adding 1 through 4, sum goes from 0 to 1, 3, 6, and 10 as i goes from 1 to 4. If the loop wrongly ran to 5, the table would show an extra pass and a final sum of 15, exposing the boundary error.
What is a go-live rehearsal and why do teams run one?
A go-live rehearsal is a dry run of the deployment, walking through the actual cutover steps in staging or by talking them through in order. It checks that steps are complete and correctly ordered, that each has an owner, how to roll back, which steps take longer than expected, and when stakeholders are notified. It finds problems while they are still cheap and private to fix.
Do thorough automated tests make dry run testing unnecessary?
No, dry run testing complements automated testing rather than replacing it. Dry runs happen before code runs or before a live deployment, need no working environment, and catch logic errors, missing steps, and misunderstood processes. Automated tests need running code and catch regressions quickly and repeatedly. A go-live rehearsal also verifies the deployment process itself, which automated tests of the code do not cover.

About the System Analysis and Design course

How many college credits is System Analysis and Design?
System Analysis and Design (Computer Science 390) 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 System Analysis and Design cost and what is included?
$250, paid once, with lifetime access: all 69 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 System Analysis and Design take?
It is self-paced with no deadlines. The 69 lessons total about 9 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 System Analysis and Design.

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

Enroll in System Analysis and Design →Download the syllabusEvery course with PRO →
System Analysis and Design
3 credits · NCCRSEnroll →