Testing Archives - DaedTech

Oct
12

Fundamentals of Web Application Performance Testing

Category: Language Agnostic Tags: DevOps, Stackify, Testing | 1 Comment

Editorial note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there, take a look at their offering that can help you with your own performance testing.

Software development, as a profession, has evolved in fits and starts over the years. When I think back a couple of decades, I find myself a little amazed. During the infancy of the web, hand-coding PHP (or PERL) live on a production machine seemed perfectly fine.

At first blush, that might just seem like sloppiness. But don’t forget that stakes were much lower at the time. Messing up a site that displayed song lyrics for a few minutes didn’t matter very much. Web developers of the time had much less incentive to install pre-production verification processes. Just make the changes and see if anything breaks. Anything you don’t catch, your users will.

The Evolution of Web Application Testing

Of course, that attitude couldn’t survive much beyond the early days of dynamic web content. As soon as e-commerce gained steam in the web development world, the stakes went up. Amateurs walked the tightrope of production edits while professional shops started to create and test in development or sandbox environments.

As I said initially, this didn’t happen in some kind of uniform move. Instead, it happened in fits and starts. Some lagged behind the curve, continuing to rely on their users for testing. Others moved testing into sandbox environments and pushed the envelope besides. They began to automate.

Web development then took another step forward as automation worked its way into the testing strategy. Sophisticated shops had their QA environments as a check on production releases. But their developers also began to build automated test suites. They then used these to guard against regression tests and to ensure proper application behavior.

Eventually, testing matured to a point where it spread out beyond straightforward unit test suites and record-playback-style integration tests. Organizations got to know the so-called test pyramid. They built increasingly sophisticated, nuanced test suites.

Web Application Testing Today

Building upon all of this backstory, we’ve seen the rise of the DevOps movement in recent years. This movement emphasizes automating the entire delivery pipeline, from written code to production functioning. So stakes for automated testing are higher than ever. The only way to automate the whole thing is to have bulletproof verification.

This new dynamic shines a light on an oft-ignored element of the testing strategy. I’m talking specifically about performance testing for your web application. Automated unit and acceptance testing has long since become a de facto standard. But now automated performance testing is getting to that point.

Think about it. We got burned by hand-editing code on the production server. So we set up sandboxes and tested manually. Our applications grew too complex for manual testing to handle. So we built test suites and automated these checks. We needed production rolls more frequently. So we automated the deployment process. Now, we push code efficiently through build, test, and deployment. But we don’t know how it will behave in the wild.

Web application performance testing fixes that. If you don’t yet have such a strategy, you need one. So let’s take a look at the fundamentals for adding this to your testing approach. And I’ll keep this general enough to apply to your tech stack, whatever it may be.

Aug
31

By Erik Dietrich

Getting Started with Behavior-Driven Development

Category: Language Agnostic Tags: BDD, C#, TechTown, Testing | 4 Comments

Editorial note: I originally wrote this post for the TechTown blog. You can check it out here, at their site. While you’re there, have a look around at the different training courses they offer.

You’ve probably heard of behavior-driven development (BDD). However, if you’ve never practiced it, you may perceive it as one of many in a nebulous cloud of acronyms. We have BDD, TDD, DDD, and ATDD. All of these have a “D” standing for “driven” and another one standing for either “development” or “design.” Apparently, we software developers really like things to drive us.

I won’t engage in a full “DD” taxonomy here, as this post concerns itself with behavior-driven development only. But we will need to take a tour through one of these in order to understand BDD’s motivations and backstory.

Behavior-Driven Development Origins and Motivation

To understand BDD, we must first understand test-driven development (TDD). Luckily, I wrote a recent primer on that. To recap briefly, TDD calls for you to address every new thing you want your production code to do by first writing a failing test. Doing this both verifies that the system currently lacks the needed functionality and gives you a way to later know that you’ve successfully implemented it.

With TDD, you deal in microtests. These distinguish themselves by being quite specific and granular. For instance, you might assert that you get a null reference exception when invoking a method with a null parameter. You’ll pardon non-technical project stakeholders for a distinct lack of interest in these microtests.

BDD evolved from asking the question, “Why don’t we do this for tests that the business might care about?” It follows the same philosophical approach and logic. But instead of worrying about null parameters and exceptions, these tests address the system’s behavior at the capability or feature level.

Behavior-driven development follows the TDD cadence: express a current system deficiency with a failing test. But this time the failing test is, for example, when I deposit money into my checking account, I can see the reflected balance. Work then proceeds on that feature until the test passes. At this time, the team considers the card complete.

Jul
30

By Erik Dietrich

Choosing an Acceptance Test Framework

Category: The Life of a Programmer Tags: Acceptance Testing, Monitis, Testing |

Editorial note: I originally wrote this post for the Monitis blog. You can check out the original here, at their site. While you’re there, take a look at their monitoring solutions.

I can still remember writing my first automated tests in a professional setting. Notice that I didn’t say unit tests, and for good reason. At the time, some 14 years ago, I hadn’t heard of unit tests. Instead, I simply automated the process of manually testing my software.

This may sound somewhat facile, but it actually speaks to core principles in the programming profession. As a relatively inexperienced programmer, I understood the importance of testing my work. I also understood the importance of automating manual, error-prone process. And so, of my own accord, I examined and then automated my previously manual testing efforts.

Don’t get me wrong. By doing this, I reinvented a wheel simply because I did not know of its existence. Folks had created automated unit test frameworks for this exact purpose. Had I known, I could have better spent my time learning and using these things. But, in spite of the waste, I did learn something. I learned that, under the covers, test frameworks just represented yet another instance of automating an important manual process.

What is User Acceptance Testing (UAT)?

I led with a tale about unit tests because testing software components applies to everyone that writes software. I mean, you always test your own software, even if you don’t think you’re doing so. Whenever you compile, you test your code to see if it compiles. Granted, you aren’t executing the most sophisticated, high-value test known to man. But you are performing a test of sorts.

But what if we look beyond our own dev boxes a bit? What if we look at other forms of testing?

For almost any software that we write, other stakeholders will perform other sorts of tests. These stakeholders includes users or user-proxies, who perform an activity known as user acceptance testing (UAT). In its simplest incarnation, this involves users or their proxies using the software and evaluating whether or not they find it acceptable.

This can come in various shapes and sizes. In some cases, actual users perform formalized beta tests, perhaps for pay. In other cases, someone from the QA group might do a quick run-through and give a thumbs-up or thumbs-down. But whatever happens, these tests capture the user’s experience and perspective.

Jul
11

By Erik Dietrich

How to Write Test Cases

Category: Language Agnostic Tags: Software Process, Testing, Unit Testing | 7 Comments

Editorial note: I originally this post for the Stackify blog. You can check out the original here, at their site. While you’re there, check out Stackify’s APM offering.

As I’ve mentioned before on this blog, I have a good bit of experience writing unit tests. In fact, I’ve managed to parlay this experience into a nice chunk of my living. This includes consulting, training developers, building courses, and writing books. From this evidence, one might conclude that unit testing is in demand.

Because of the demand and driving interest, I find myself at many companies, explaining the particulars of testing to many different people. We’d like some of testing magic here, please. Help us boost our quality.

A great deal of earnest interest in the topic lays the groundwork for improvement. But it also lays the groundwork for confusion. When large groups of people set out to learn new things, buzzwords can get tossed around and meaning lost.

Against this backdrop, I can recall several different people at asking, “how should we/our people write good test cases?” If you’re familiar with the terms at play more precisely, you might scratch your head at this question given my unit testing expertise. A company brought me in to teach developers to write automated unit testing and someone is asking me a term loosely associated the QA group. What gives?

But in fact, this really just begs the question, “what is a test case?” And why might it vary depending on who writes it and how?

Oct
6

By Erik Dietrich

Get Good at Testing Your Own Software

Category: The Life of a Programmer Tags: Testing | 2 Comments

Editorial Note: This is a post that I originally wrote for the Infragistics blog. I’ve decided that I’ll only cross post here when I can link canonical and give you the entire article text. That way, you can read it in its entirety from your feed reader or on my site, without having to click through to finish. If you do like the post, though, please consider clicking on the original to show the post some love on its site and to give a like or a share over there.

There’s a conventional wisdom that says software developers can’t test their own code. I think it’s really more intended to say that you can’t meaningfully test the behavior of software that you’ve written to behave a certain way. The reasoning is simple enough. If you write code with the happy path in mind, you’ll always navigate the happy path when testing it, being hoodwinked by a form of confirmation bias.

To put it more concretely, imagine that you write a piece of code that reads a spreadsheet, tabulates sums and averages, and reports these to a user. As you build out this little application, one of the first things you’ll do is get it successfully reading the file so that you can write the other parts of the application that depend on this prerequisite. Over the course of your development, you’ll be less likely to test all of the things that can go wrong with reading the spreadsheet because you’ll develop kind of a muscle memory of getting the import right as you move on to test the averages and sums on which you’re concentrating. You won’t think, “what if the columns are switched around” or “what if I pass in a Word document instead of a spreadsheet?”

Because of this effect, we’re scolded not to test our own software. That’s why QA departments exist. They have the proper perspective and separation so as not to be blinded by their knowledge of how things are supposed to go. But does this really mean that you can’t test your own software? It may be that others are more naturally suited to do it, but you can certainly work to reduce the size and scope of your own blind spot so that you can be more effective in situations where circumstances press you into testing your own code. You might be doing a passion project on the side or be the only technical member of a startup – you won’t always have a choice.

Let’s take a look at some techniques that will help you be more effective at testing software, whether written by you or someone else. These are actual approaches that you can practice and get better at.

Exploratory Testing

Exploratory testing is the idea of finding creative, weird ways to break the software. One of the things you’ll find is that users have an amazing capacity to use software in some of the most improbable and, frankly, stupid ways that you could ever imagine. “I hit saved and then poured water into the disk drive, and the save didn’t work.”

You want to cultivate the ability to dream up crazy things that users may do and ask yourself what would happen. A great way to do this is to observe non-savvy users using your software or, really, any software. They’ll do weird and unexpected things – the kind of things you wouldn’t – and you can make note of them and use these as ideas for things to do to your own software. Visit a forum for QA folks or user support people to vent about the dumb things they’ve encountered, and use those. Build an inventory that you can launch at your stuff.

Pitfall Testing

In addition to developing a repertoire of bone-headed usage scenarios to throw at your software, you should also understand common mistakes that will be made by regular users. These are not the kinds of things that will make you do a double take but rather the kinds of things that happen all the time and would surprise no one.

Did a user type text into the phone number field? Did the user accidentally click “pay” four times in a row? Any fields left blank? These are the kinds of common software errors that you should catalog and get in the habit of throwing at your own software. If you practice regularly, it will become second nature.

Reasoning About Edge Cases

Edge cases are subtly different from common pitfalls. Edge cases are the way your software behaves around specific, meaningful values to your code. For instance, in our spreadsheet example, perhaps you’ve designed the software to handle a maximum number of lines in the spreadsheet input. If you accept 10,000 lines, get in the habit of testing 9,999, 10,000, and 10,001 lines to see how it behaves. If it gets those three right, it’s exceedingly likely to get 4,200 and 55,340 right.

Picking edge cases gets you the most bang for your buck. You’ll get in the habit of locating the greatest number of possible bugs using the least amount of effort.

Helpful, Not Infallible

Building up an arsenal of things to throw at your software will make you more effective at testing your own stuff. This is a valuable skill and one you should develop. But, at the end of the day, there’s no substitute for a second set of eyes on your work. Use the techniques from this post as a complement for having others test it – not a substitute.

DaedTech