How should I respond as a developer if manual testing is assigned to me?

Question

I'm software engineer at a private service based company. Even as a developer, we generally get repetitive development tasks.

Now today my manager asked me to help with manual testing to meet the project deadline. However, as a developer I hate manual tasks and especially manual testing. (I'm not talking about unit testing which should be performed by developers before handing over the build to testers.)

Also the project delay is because of continuous changes in customer requirements, but the manager wants to absorb all such efforts required by those changes and deliver the project on time and that's why he asks developers to help in testing.

In such situations, I can't not say I don't know how to test as the instant reply would be that the testing is just following instructions written in test cases.

So what should be the reply in this case? I hate testing!

Answer 1

If it's a one-time thing, do the testing. Your team needs you. QA is drowning. Take over some of their workload and stay in contact with them to make sure you do the job, and you do it well.

After having proven yourself as someone who can be relied on in a pinch, you can then tell your manager man do I hate manual testing, and maybe they'll keep that in mind next time they're short on testers.

The only way to not do manual testing is to make yourself busy with something else, that has higher priority. Otherwise, that's your job.

Answer 2

You should do the testing.

In addition to all the workplace related reasons that its a good idea to do it, consider the development benefits (i.e., to you) of doing such functional testing. There's a good chance you'll notice new bugs or quirks that need to be fixed as you run through the product in a way that's different from how you normally use it. These would be things even testers may not notice. IMO, a certain amount of testing like this is good for developers to be doing.

Answer 3

There's advice from Joel Spolsky, beloved co-founder and ex-CEO of the StackExchange network. He has written blog articles with names like:

• Top Five (Wrong) Reasons You Don’t Have Testers
• Why testers?

You can read those and present some of the arguments to your boss.

No matter how hard it is to find testers, they are still cheaper than programmers. A lot cheaper. And if you don’t hire testers, you’re going to have programmers doing testing. And if you think it’s bad when you have testers churning out, just wait till you see how expensive it is to replace that star programmer, at $100,000 a year, who got sick of being told to “spend a few weeks on testing before we release” and moved on to a more professional company. - Joel Spolsky, reason 5.

_{[Emphasis mine]}

However, even if you do manage to change your company's way of working, this won't happen overnight. You'll have to do it this time. Remember that you get money in exchange for it, if that helps.

Answer 4

Just Do It...

You are being asked to do manual testing because you did not help automate the testing. Be glad that it is painful and something that you don't like to do. Hopefully, all the other devs on your team feel the same way. After suffering through the pain of testing manually, ask yourself: "Why do devs at other companies not have to go through all this manual testing?" And I assure you, plenty of companies ship quality software without extensive manual testing. The answer is: automation.

...Then Automate It

If you already have good unit test coverage, then great! How close is it to 100%? Do you have integration tests which assemble modules of your software and test for coordination? No? That's the next step in automation. You will have to use your judgment to decide what modules need special attention.

Finally, do you have acceptance tests? If your software is UI-driven, then you will need something like Selenium/FitNesse/etc. If it is service-oriented, and can be tested with a simple web request, then I suggest something which might be non-standard but which I found to be very useful: write your acceptance tests as performance tests, using Gatling. Ok, this sounds crazy, but hear me out...

Gatling Tests

Gatling is powerful because you write the test specification in Scala. If Scala isn't your development language, then you will need to learn some basics in order to write tests. But trust me, it's worth the investment! For a performance test, you want to construct a variety of fairly representative requests for your service, and Gatling makes this easy. You can read data from configuration files and generate any kind of request object you like. Then, you can hit the service under test as hard as your test runner workstation can send requests and process the responses (which is generally much faster than the service can handle the requests).

Now I run both Smoke Tests and Performance Tests. They are exactly the same. The only difference is that Smoke Tests run exactly N times, for small N (like, say 3), while Perf Tests run for duration T (like, 15m). Both kinds of tests generate requests randomly. Some people will object that determinism is better for reproducibility, and there is merit to that argument. But I like random generation for coverage, because sometimes you will get "interesting" requests that trigger an obscure bug, and that leaves a log trail that you can investigate.

Performance-as-Acceptance

But you need to know if your software works...not whether it's fast. What does this have to do with correctness? Well, everything! You see, there is one funny thing that happens in large companies which have dedicated testers. The testers end up looking for, and triggering, abnormal/problematic conditions in the code, to see what happens. But really, developers should also be detecting those conditions. Ideally, they should at the least, log an ERROR when something happens that would cause an SDET/SET to file a bug report. Which means that good SDEs and good SDETs should be doing some redundant things relative to each other, which is actually a waste of very expensive time.

Instead of writing an external test that explicitly checks for these error conditions, it's much better for the service to be very aggressive in data validation at all stages of the computation, and to log anything anomalous. Then, part of your perf test will involve checking the logs (I hope you have log forwarding set up, like Splunk or similar). In particular, you want to see if any ERROR or HTTP 5xx occurs during your tests (either smoke or perf). If they do, then you know you have a problem worth investigating.

Now, what you have done is turned your perf test into an acceptance test generator. For this to work well, your request generator needs to have good coverage. Ideally, it should hit all parts of the domain for every request field, even if you shape the distribution to be "realistic". For instance, suppose you run Twitter, and you need to see if the TweetService works correctly. A request will likely just be something like: (username, message). You clearly need to exercise the full range of possible usernames (length, characters allowed, etc.), as well as messages (again, length, characters allowed, embedded links, etc.). Your generator might prefer to create shorter messages on average, but it should still create max-length messages sometimes (meaning, they should occur many times over the course of your perf run).

UI Testing

Although I have used both Selenium and Fitnesse, UI testing is not my forte and I cannot give you detailed guidance here. Unfortunately, I do not think it is possible to generate random tests for UIs the way you can for services. This makes it a very different beast. Even so, automation >>> manual testing. Find a framework, get buy-in from your team, automate your tests, $$$profit$$$!

Answer 5

You might think your "job" is to be a developer. It is not that simple.

It is bring any skills and abilities you can to serve the business and the customer. It happens that as the business sells software, that usually means it needs people to write code.

But: Software that is not tested (somehow, ideally automatically) is useless because it is guaranteed to be buggy.

Common practice: Developers release software to QA that is full of bugs. Any dev worth their salt tries to do otherwise; not all succeed.

Do you believe that all your code is bug free? Have you implemented automated tests that cover everything ? Have you designed software to limit possible issues and catch any that might occur?

What you also need to take from this is a chance to realise that manual testing is horrible and that if at all possible QA should be automated. So next time, you will know that none of the bugs are in your code, right?

You need to muck in and help the business succeed.