How to get the most out of being a manual tester

Question

As a student, I have just got my first co-op job as a manual tester. I know it is as intellectual and demanding a job as a coder, but I cannot help thinking the other way around. I love being a coder but it is my first job. So I am asking you for any advice on how I can get the most out of the manual black-box testing job, i.e how can I use it to improve my coding skills. Many thanks.

Answer 1

Maybe you can try to automate some of the testing?

Write some scripts that will prepare the application for the manual test (start it, log on, load test data set, etc),

Write some regression scripts that will compare the output from the previous version with the output from the version you are testing.

Answer 2

Learn a *Unit framework and plug the different cases in as you go.

Answer 3

Try to break it as a coder:)

Sql Injection, Script injection, etc,etc:) It should make it funnier:)

Answer 4

Testing is sometimes more challenging and rewarding than the development. In the teams I work with quite a lot of best developers come from the test engineer background.

First of all this work could give you a unique perspective on the development prospect. Some developers believe that tester are mean and picky and find issues in perfectly nice code. Some testers believe that the developers are lazybones and are happy with half-cooked code.

Seeing the situation from both sides of the fence is definitely an experience worth having as it will reduce the amount of miscommunication and misunderstanding later on in your career.

Second of all tester get to write test cases. Test cases are great because they help you to think about the functionality of the system, instead of the classes and their methods and properties etc. The goal of writing the software is to make good useful software and not to achieve the excellence with your coding skills. Therefore thinking about your application from that angle is definitely helpful. Writing test cases now will help you to write good architectural documents later.

You could pusth your team/company to move towards testing automatisation. Sometimes this fails because testers don't know how to write automation code and try to use record-and-play interfaces. But if you could actually code the tests you have much better chance of success. Just be aware that the automation is a significant effort and should not be taken lightly. Classic books say that the effort doubles then the manual testing is done in parallel with automating it. I tend to agree.

Answer 5

In addition to what has been said about automation, make sure you show interest in the entire lifecycle. Chances are that anything you find in a test was not properly documented in requirements and wasn't properly unit or integration tested prior to you ever seeing it. Anything you can do to help improve the earlier chain of events will help to educate you and make everyone's life easier.

Just watch out for egos and tread carefully when you find them.

Answer 6

I was in the same position that you some years ago, and for me being tester helped me a lot when coding, it will happen without you noticing it.

Mostly you will be more careful with user input, orphan links, etc and generally you will be more detailed. From my experience, it was a very good position and I think it definitely changed my style of programming

Answer 7

Automate the simple things you do frequently when manual testing. This doesn't always mean the actual testing, in most cases automated functional testing becomes harder and you get less for your time the further away you get from the code and the closer you get to the interface and the human brain.

So for example; when testing do you need to copy files and enter some values to run the software? Automate that. Do you need to have data populated in a database to help your tests? Automate that. Once simple stuff is automated and running smoothly you can tackle harder stuff.

Another bit of advice is to read and understand the source code commits that fix the bugs that you find if possible. You can learn a lot this way.

Answer 8

If it's web related, find one of those frameworks where you can script your keystrokes and/or mouseclicks to do a sort of faux unit testing. It will increase your productivity and you can become something of a ninja with it, using it to get to the thing you really need to test without having to deal with the fifty pages that came before it.

It could wind up getting your foot into the door of automated testing and, if you impress folks, you may be able to get into the development department since it's obvious you can script really well.

Answer 9

If you've been hired to do manual testing, then that's what you should focus on.

Automated testing is great, and if your company isn't doing that they really should be. However, you're not there to tell them how to run their business. The number one thing on any job is to do the assigned work. That's especially true at entry level.

My suggestion for how to make this a learning experience that will help you with a future career as a developer is to take note of what kinds of problems you find in other people's code. Knowing what the common mistakes are can help you avoid making the same ones in your own code.

For example, some bugs are just coding errors, such as being off by one when looping through an array. Others are misunderstood requirements, flaws in the high-level design, or failure to check for unexpected/invalid inputs.

Also, try to follow up with the developers after a bug has been reported to try to get more info about the root cause of the problem, how they went about fixing it, and what the impact to the project was. Just be careful about this: programmers and QA testers tend to have an adverserial relationship. They're not going to like you telling them that they're stuff doesn't work, especially the senior-level ones. Make sure they know you're trying to learn from this, not criticize. If possible, pick a "mentor" from among the developers to help with this part. That way you have one main contact who is expecting to have this kind of conversation with you.

The main thing you can probably get out of this co-op is to see how software development is done in the real world. From your seat as a tester, you'll get a chance to see more of the "big picture" than you would as an entry-level developer, which is a really good thing when you're first starting out.

If you think you've got a future with this company, either in QA or as a programmer, this is a good opportunity to learn about their product and industry. The best programmers aren't just heads-down bit monkeys. They know not only what their code does, but why, and how that benefits the people who pay money to use it.

Good luck.

Answer 10

You can:

• Learn to isolate a problem. When you find a bug, try to find the smallest subset of actions that reproduces this bug - programmers will thank you for this, and you'll have learned an important skill set.

• Learn to communicate technical issues properly. It takes a lot of skill to write a good, detailed bug report.

• Learn to think in terms of limit cases and twisted uses of the system. This will make you write better unit tests later on.

I truly believe that all programmers - including senior ones - should spend some time doing manual testing every year, if only to see things from a different perspective, and to gain some respect for the testers they work with (and I put that in practice myself)

Answer 11

Multitask and practice programming every spare second you have. When I had a boring job maintaining some crufty old Perl build scripts, any time I wasn't doing work, I was learning more advanced Perl, looking up new algorithms, writing prototypes in Haskell, etc.

Answer 12

During planning:

• Take the time to comprehend the functional specifications or change requests for your assigned area. Your programing knowledge gives you an edge here.
• Question the contradictions and holes. Hopefully you have access to the design docs while development is still in progress. I've often identified issues in the product before testing began by questioning unclear design documents.
• Think through all the boundary cases, negative conditions and combinations of conditions. When in doubt, work with development. You don't need to know the actual code they are using, but your programming background will help you write a through test model.
• Don't worry about automation. Every new tester comes in and sees a hundred ways to improve testing, automation is usually top on the list. The only thing that should be automated for black box testing is some test setup if it is a time-consuming action that is unrelated to the function being tested. (For example, automatically creating 20 courses in a Learning Management System (LMS) to test self-enrollment scenarios. The course creation is not the focus, so saving a few hours of mindless work is desirable.) It's okay to ask about automation, but don't assume you are the first to think of it.

During testing:

• Write clear, detailed specific bug reports. Think about all the information you would want if someone found a bug in your code. Break the issue down to smallest specific actions that consistently break it. Include steps to recreate and examples of your test data.
• When you find an issue, try to narrow the problem down by testing alternatives to the broken function. (Simple example, in a browser-based product, you get an error closing a dialog with the close button. Do you also get an error when you close with the window close button (X)? Whatever the answer, include it in the bug report.
• Be nice. Testers and programmers are on the same team. If the developer seems like an idiot who doesn't understand anything you are saying, back up and assume that you are the one who doesn't understand. It saves a lot of misery and changes your attitude quickly. It's easier to communicate when you are humble and teachable.