My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
This is the seventh in a series of answers to 100 Interview Questions for Software Developers.

The list is not intended to be a "one-size-fits-all" list. Instead, "the key is to ask challenging questions that enable you to distinguish the smart software developers from the moronic mandrills." Even still, "for most of the questions in this list there are no right and wrong answers!"

Keeping that in mind, I thought it would be fun for me to provide my off-the-top-of-my-head answers, as if I had not prepared for the interview at all. Here's that attempt.

Though I hope otherwise, I may fall flat on my face. Be nice, and enjoy (and help out where you can!).

This week's answers are about testing.
  • Do you know what a regression test is? How do you verify that new changes have not broken existing features?
    You answered the second part of the question with the first: you run regression tests to ensure that new changes have not broken existing features. For me, regression tests come in the form of already written tests, especially unit tests that I've let turn into integration tests. However, you could write a regression test before making a new change, and it would work as well.

    The point is that you want to have some tests in place so that when you inevitably make changes, you can ensure they didn't cascade throughout the system introducing bugs.

  • How can you implement unit testing when there are dependencies between a business layer and a data layer?
    Generally I'd let that unit test become an integration test. But if the time to run the tests was becoming too long, I'd build a mock object that represented the data layer without hitting the database or file system, and that would be expected to decrease the running time significantly. Dependency graph from JDepend

  • Which tools are essential to you for testing the quality of your code?
    I don't know if anything is essential. If you've got asserts or throws, you can always implement testing yourself, and a good eye for bad code helps as well. That said, to reduce psychological barriers to testing, it would be nice to have tools already made for this purpose.

    Luckily, we have such tool available: unit testing frameworks and static code analysis tools in your language of choice.

  • What types of problems have you encountered most often in your products after deployment?
    Most recently I've encountered very specific integration errors, and written about some ideas on fixing the polysystemic testing nightmare.

  • Do you know what code coverage is? What types of code coverage are there?
    Generally I'd thought it refers to the percentage of code covered by tests. I don't know what the second question here refers to, as I thought it referred exclusively to testing.

  • Do you know the difference between functional testing and exploratory testing? How would you test a web site?
    I have to admit that before being asked this question, I wouldn't have thought about it. My guess is that functional testing refers to testing the expected functionality of an application, whereas exploratory testing involves testing without knowing any specific expectations.

    As far as testing a web site, I'll have plenty of unit tests, some acceptance tests, perhaps some in Selenium or a similar offering, as well as load testing. These aren't specific to web apps, however, except for load testing in most cases.

    I'm very interested in feedback here, given my misunderstanding of the question. If you can offer it, let me thank you in advance.

  • What is the difference between a test suite, a test case and a test plan? How would you organize testing?
    A test suite is made up of test cases. I'm not sure what a test plan is, aside from the obvious which the name would suggest. As far as organizing testing: I tend to organize my unit tests by class, with the method they test in the same order they exist within that class.

  • What kind of tests would you include for a smoke test of an ecommerce web site?
    Again, here's another where I didn't know the terminology, so having to ask would result in demerits, but knowing the answer of "what is a smoke test?" allows us to properly answer the question:
    In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing.
    Smoke testing

    In that case, I'd click around (or more likely, write an application that could be run many times that does the same thing, or use that application to write Selenium tests) looking for problems. I'd fill out some forms, and leave others blank. Ideally, it would all be random, so as to find problems with the specs as often as possible without actually testing all the specs, since the point seems to be to give us a quick way to reject the release without doing full testing.

  • What can you do reduce the chance that a customer finds things that he doesn't like during acceptance testing?
    The best thing to do is to use incremental and iterative development that keeps the customer in the loop providing feedback before you get down to acceptance testing. Have effective tests in place that cover his requirements and ensure you hit those tests. When you come across something you know won't pass muster, address it even though it might not be a formal requirement.

    There are undoubtedly underhanded ways to achieve that goal as well, but I'm not in the habit of going that direction, so I won't address them here.

  • Can you tell me something that you have learned about testing and quality assurance in the last year?
    Again I'm going to reference my polysystemic testing nightmare, because it taught me that testing is extremely hard when you don't have the right tools at your disposal, and that sometimes, you've got to create them on your own.

As far as reading goes, I'd start with literature on TDD, as it's the most important yet underused as far as I'm concerned.

What advice would you give?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner