19

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!

  • Comments are not for extended discussion; this conversation has been moved to chat. – user44108 Oct 23 at 12:15
115

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.

  • 2
    I think you right. This is assigned to me first time. Will do it and then inform the manager. Thanks – Kaushal28 Oct 22 at 16:16
  • 21
    One of the biggest lessons to learn in the workspace is when and how to respond to requests to help that are outside the norm - outside of working hours, outside of your strict job description, etc. On the one hand, you want to be helpful. On the other hand, you don't want to get stretched too far. I think this answer deserves upvoting for taking a middle of the road approach where you can be helpful in the heat of the moment, but still try to help steer the future. – dwizum Oct 22 at 19:47
  • 2
    Exactly. Do the work because it helps the team, but make sure your boss knows it shouldn't be a regular part of your job. Exceptions to a job should be just that, exceptions. If those exceptions keep happening, either job roles need redefining, people need to get moved in the company to full actual gaps, or they need to hire people. If it's permanent, it needs to be an official move and this is where negotiations open. Don't be a doormat, but also don't be a prima donna. – computercarguy Oct 22 at 23:56
  • 3
    @Kaushal28 Then it will be the same with manual testing, and this answer will not work for you. You are repeatedly being asked to do stuff outside your work description that you expressed you hate, please reconsider your future at this company. – Alexander Oct 23 at 6:57
  • 1
    There's another way than being too busy: refuse and start to look for another job. – hyde Oct 23 at 7:09
26

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.

  • 4
    As long as it is not one's own code. – paulj Oct 22 at 19:31
  • 4
    This kind of testing isn't useful for anyone. This kind of testing should be automated. The reason they are having issues are incompetent management making stupid demands. – Davor Oct 22 at 22:52
  • 11
    +1 there is definitely an argument that developers should use the software they create to be able to have better user empathy – HorusKol Oct 22 at 23:41
  • 7
    @Davor Manual testing is surely useful for many types of projects. There are plenty of questions about who should be doing the work, how much manual testing to do vs automated testing, exploratory testing vs following test cases, and all sorts of other considerations that QA teams figure out, but at least some degree of manual testing is usually a requirement. If nothing else, it's a way to expand testing besides strict conformance to specifications to a broader sense of identifying what's best for users and the product. – Zach Lipton Oct 23 at 4:33
  • 6
    @Davor Automated testing can't test everything, nor can it give you credible feedback for things like minor ui annoyances. Automated testing is fine for the low hanging fruit in terms of bugs, but its not the only testing that should be done. – GrandmasterB Oct 23 at 5:12
12

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

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.

  • 1
    Heh, I came to post that exact link. Probably the best thing to do is point out that if manual testing becomes a regular thing, you're going to leave. More diplomatically than that. And then if it happens, just leave, because developers are in high demand. I've been in the same position, made to do manual regression testing, then more testing, then more... it never ended until I simply left and got a new job because I was sick of it. – NibblyPig Oct 23 at 7:32
  • This is the key thing. If it's really a one-off, then fine. Likewise, if it's not all being dumped on developers (if testing is "just following a script" and this is a "everyone pitch in as an emergency one-off" then I'm sure those managers are also helping with testing... right?), then I say just help out. But if there's any indication of it becoming a regular thing, flag the above arguments and at least start thinking about your exit strategy. – delinear Oct 23 at 14:29
7

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$$$!

  • 3
    I sulked when my Boss assigned me a "testing job" (unlike OP, there was no deadline pressure). After 6 months of testing, I ended up automating most of the stuff AND afterwards, my code quality is improved significantly. As I saw other code, how people write good code, where we tend to make mistakes... It was a great learning experience. – Swanand Oct 23 at 7:24
  • 1
    UI testing is my forte (working at Testim.io) and automating it is super easy with an enterprise tool. Also - we generate tests for UI so there's that :] – Benjamin Gruenbaum Oct 23 at 7:39
7

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.

  • 1
    "Software that is not tested is useless because it is guaranteed to be buggy" - guaranteed to be buggy ?? Have some faith. It can't be guaranteed to be not buggy, but just because it hasn't been manually tested doesn't mean it will have bugs. I feel bad that that's your experience and I assume you're not a developer, otherwise you're saying "all my (your) code has bugs in it, test it to find them otherwise I won't fix it". Which is just increasing workload for the sake of it. – freedomn-m Oct 23 at 6:08
  • 8
    @freedomn-m All your code has bugs. Even the Shuttle software had bugs - are you really claiming you're better than that? The point is that you need to keep the customer in mind at all times. Most bugs aren't worth fixing, and most likely, there's better things you can do with your time. But that doesn't mean the bugs aren't there. But you can't even make that decision if you don't consider the bugs (discovered or expected). Ultimately, you're creating value for the customer. Why would you want to throw that value away because of a few stupid bugs? That's what testing is really about. – Luaan Oct 23 at 8:09
  • No, I'm saying I test it before it goes to QA. Not all developers are so sloppy to always, automatically release unfinished/buggy code. As I said, I'm not guaranteeing there are no bugs - that would be beyond complacent. But I can guarantee that some of my code does not have bugs, so "all your code has bugs" is just being rude. But no, not all my software released to QA has bugs and you can't guarantee that it's buggy. – freedomn-m Oct 23 at 13:36
  • @freedomn-m show me code that you haven't tested and I will show you a bug. Write some code. DO NOT RUN IT and hand it over. for anything non-trivial I guarantee a bug. – IT Alex Oct 23 at 13:40
  • 1
    @freedomn-m I'll reword a rushed post. I stand by saying "untested software is buggy", but absolutely that intend that "testing" does not (preferably should not) mean a separate QA team. – Keith Oct 24 at 3:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.