Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I've been given the task to train our manual testers to become developers in test (write test automation!).

Some have basic programming knowledge (either dabbling in PHP or reading stuff) and some who have no experience. Note that I do have teaching experience, but with real students, not employees, and one concern is that they will not put extra hours except the 20% management gave them for the transition.

Language to be taught and used: C#

We have 8 hours per week to do this and should decide if they will make it in 2 months. I am thinking of a combined approach:

  • use a manual such as Head First C# (although I'm not happy with the labs, they're mostly games and I don't want to add UI complexities)
  • have them read from the manual
  • do labs with them, solving more and more difficult problems and explain the theoretical stuff as well
  • have them do a bigger project towards the end

Some questions:

  • do you have a better suggestion as far as manuals go?
  • do you have a better approach? Focus less on labs?
  • what kind of assessments should I use and how often?
  • should I let them do a bigger project (bank system or small game) and how much time should I invest in that?
  • ideas on labs?
  • other resources ?

Any other tips would be most welcomed!



migration rejected from Dec 15 '14 at 1:20

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, GlenH7, MichaelT, Bart van Ingen Schenau, Jonathan Eunice Dec 15 '14 at 1:20

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

I think this belongs on – Jeff Yates Jan 31 '11 at 17:04
I agree with Jeff. However, I wanted to comment on the first concern that the employees won't put the time in: Basically there is a business reason for management wanting the employees trained. Usually this involves a change in their job description. As such any of those employees should recognize that lack of interest / failure will mean removal. – NotMe Jan 31 '11 at 17:06
Interesting (difficult) problem, thanks for sharing. – Konrad Rudolph Jan 31 '11 at 17:14
The testers I have run into seem to have a better mindset for programming than many of the programmers I have worked with. They just don't particularly want to be developers. – Jesse Millikan Jan 31 '11 at 17:32
This leaves many questions. What programming language will they use? Is C# what they will work with or did you decide to use it for teaching? What kind of system will they work with and how complex will the tests be that they write? How much time do you have (three weeks? six weeks?) If possible I would try to go for problems that are similar to the tests, no games. – thorsten müller Jan 31 '11 at 17:38

8 Answers 8

up vote 3 down vote accepted

Make the whole "class" project-based, not just the end.

Figure out what you want the project to be, and then piece it apart into sections you can turn into lessons. Each lesson having an assignment which ends up being used directly, or involved in the final project.

For each area, Do not provide them with all of the necessary info, at least easily (aka make sure they learn that google is their friend). Give them enough so they don't feel overwhelmed, not but enough so that they can complete all of the assignments/projects using the information you provide. It is very important that they pick up the same skills we use everyday in our work (knowing when to check manuals, forums, SO, etc...)

Also, consider making at least the final project a group project. People think differently. Group members can help fill each other's gaps in terms of their knowledge.

Good luck! I've taught programming in various roles during my time in uni and it had a very big impact on how I approach the subject matter.

Oh! and students-are-students, the only different here being that your student's motivation might be more directly financial than the norm (which is not to say regular students motivation's aren't financial; I attended uni during the dot-com boom)

Great insights, thx! – Bogdan Gavril Jan 31 '11 at 17:43

I'm a big fan of the pattern of teaching used by Ruby Koans. They give you a bunch of broken ruby tests and have you progress through the tutorial by running them, watching them fail, then fixing each one as you go. I've reviewed it myself and used it to acquaint a few friends with the Ruby language with notable success.

I would recommend creating a similar battery of tests using your language/framework of choice. Each "class" would consist of you covering the basics by fixing basic tests via the lecture to give them an idea of the basic concepts for that lesson. You can have them working along on their local system to fix the tests as you fix them. At the end of the lecture, you can have them repair a separate-but-related test file, asking for assistance from you as necessary.

Not only will this teach them the language, but they'll also be learning how to write tests as a consequence.

It's a very original ideea. Sadly porting to C# would take quite a bit of time. I will consider adding smth similar to one of the lessons. Thx for sharing this !! – Bogdan Gavril Jan 31 '11 at 18:39

I would do something that motivates them. I don't think reading a book will, it doesn't work with my students, and I believe it only works with self-teaching people, which is not the majority. Determining what motivates them seems tricky in your case.

My approach would be to do lab sessions with them and repeat the following cycle:

  1. Explain something briefly (like 20-25 minutes). The explanation should be like a screencast, with you writing code and compiling, and running it. That is, you "doing" something useful. In your case, useful might mean something related to their job (but not always).

  2. Propose some exercises that you know they can do easily with what you have explained. The first exercise could be simply to replicate what you have done. And the next to extend the solution in certain ways.

  3. Spend time with everyone to see how they are doing, and then spend more time with the ones that are not following so quickly (and give the good ones more work so that they are not bored).

If you know the subject well, this is an approach that works very well for me. The idea is always to try to do something useful during the class. I'm sure Head First C# contains some ideas, but I haven't read it.

As an example, the other day I did the following (my class is C++, and I was teaching STL containers, and efficiency). I gave the students two text files: a book from Project Gutenberg, and a complete word list for the language of the book (in my case Spanish). You can find both on the Internet. The idea was to produce a list of those words that appear in the book that are not in the word list, like names of people, places, whatever. It was not perfect, since the word list in Spanish doesn't contain conjugated verbs, and therefore a lot of wrong stuff came out in the solution, but the idea is that it was a small project for the session (2 hours), and the students were a little curious about what would come out. The best students will do it quickly, and the others will often be driven by envy, and work harder just to catch up with the others. That is always a good motivation, I exploit it a lot.

Now, for this you would need to think about 4 simple 'projects' every week. While thinking about the problems, I suppose you will see connections between them and could make them last a couple of classes or more, and end up with something more substantial. To put another example, in this course I mentioned already, we ended up writing a simple SRT (subtitles) editor in Qt. Nothing fancy, but they found it useful, and that counts a lot.

In summary, any programming class needs motivation and I think there is no better motivation than to reveal the computer as an incredibly powerful tool to do repetitive and automated stuff. If you can quickly show that to them, everyone will notice and they'll be interested. By the way, at no point I did say this was easy.

Oh, one last thing: avoid the Fibonacci series and the primes, they bore everybody except the nerds.

Great comments. Especially about motivating the ones who are slower and how not to go for primes and fibonacci (was going to soon he he). – Bogdan Gavril Feb 21 '11 at 18:56
Sadly I cannot choose 2 right answers... – Bogdan Gavril Feb 21 '11 at 18:57

The biggest issue I see here is that your developers aren't writing unit tests before a check in occurs. Its great to have that pseudo-whitebox testing that occurs here, but I think you are going to see a lot of unit tests written by the team look like this:

public void testApple(Object apple) throws Exception{  

Just to satisfy the requirements of a passed test, this is equally true for developers. I would recommend having them read the documentation within the classes that they are writing tests for and if it doesn't make sense then the developers need to re-write the documentation. Also showing them how to execute a unit test via a script and integrate it into CruiseControl or whatever build tool you use would be of the most benefit.

I can't really make sense of this answer. I don't have developers, I have manual testers. How could I possibly explain CruiseControl if they don't know what a ctor is? – Bogdan Gavril Jan 31 '11 at 21:38
@Bogdan You most certainly do have developers, or do you have some way of creating code that I am unaware of? I use CruiseControl for all builds, perhaps because I haven't looked at it in some time, but what does that have anything to do with object instantiation? What I am getting at is your team that writes the code should be doing the majority of this stuff and the testers should be filling in the blanks. – Woot4Moo Jan 31 '11 at 21:48
In this organization TEST and DEV are separated. Test has to come up with a strategy to automate (i.e. program) the testing of the product (unit tests for ex). For historical reasons, the company has manual testers to do some work and we are moving towards programmers in test (button pushers are at 10% cost in China :D ). The question is how do I transform these guys in programmers (for the TEST team) in 2 months! – Bogdan Gavril Jan 31 '11 at 22:11
@Bogdan fair enough. I really am not sure as two months time is barely enough time for a developer to get their head around the process at a company let alone learning a new language. – Woot4Moo Jan 31 '11 at 22:14

Plan on replacing 1/2 of them with experienced DTEs (development test engineers). Start recruiting the DTEs now. Some people are just not capable of writing code, or at least code that makes any sense. You need to practice group code reviews for each test before they check them in. I would create a number of test templates where you copiously explain what you are doing in each step.


Try out with something simple and then increase the level of complexity, make sure simple things are understood before going for complexities because complex things evolve from simple things.


With limited time, you should do many small examples on all important things, and the most conmon pitfalls. For the rest, You better assume, they are intelligent beings.


You could also get a subscription to, they are starting an excellent series on C#, presented by the Chuck Norris of StackOverflow - Mr Jon Skeet!


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