views:

60

answers:

4

I started as a software engineer at the company I'm currently at. Over time, I was either the only one willing to or capable of taking responsibility for various systems, and so I was "promoted" to being IT Manager. Now, during my time as software engineer, I would create functional tests for the various software modules I would build, and as a result, even today I am able to quickly test various parts of the system that I have worked on. However, there is a large large code base with little to no coverage from the other various developers who have been working here.

Now, as IT Manager, I want to be able to test that all the parts of the system are working, but there is:

A) no budgeted time dedicated to creating code test coverage

and

B) No desire from the "chief software engineer" to start creating testing suites to help me monitor that the software is functioning.

I don't expect the software team to drop everything they are doing and spend 2 weeks creating test suites, but it would be nice if they started expanding the test suite coverage over time so I can confirm that the various parts of the system are working.

So boiling it down, how do I get the software team to start building test suites?

Other caveats:

A) I'm still asked to do software projects in addition to managing our IT dept (a unix engineer, desktop support guy, and related office and production equipment)

B) My unix admin has a really hard time getting production systems up running the full code base, and we aren't getting good help from the software team. He can't run any kind of diagnostic to see where the web app is failing on the new installs. The VP of the company keeps telling me to go in and do print_r's in the code to see what is happening. This sucks!!!

+1  A: 

That's a good question. And if there was one correct answer to it, much more software projects would be successful and deliver high quality.

I don't think, that it is a good idea to make such a change top-down. It has to be driven from the developers themselves. So trainings in TDD direction would be good, but that is a long time invest, which takes time.

If you want a faster solution you should consider functional-, acceptance-, and systemtests. With these test you test pretty much the whole application through all layers. If you are developing web applications you should consinder using Selenium to automate your test. It is easy to create test with it (Selenium IDE).

But using only such tests (not Unit-tests) don't give you the advantages coming from TDD.

Automating your tests is crucial.

michael.kebe
+1  A: 

Do you have a Test or QA team?

I would first start to see if they have Test Cases that they use to qualify the build. If not you will have to develop these test cases to test the core functionality of your product.

The next step would be automating the test cases.

If the application is poorly developed without any troubleshooting tools or debugging features it would be tough until these are added as requirements for next release.

My 2 cents.

akhilah
No test team, no QA team... The development team is basically responsible for their own QA. They do take QA seriously, but they don't automate QA tests via a test suite for acceptance testing.
Zak
+1  A: 

First, you need to investigate Test Driven Development so that you are comfortable explaining it in terms that your developers will understand, as well as your management. Since you seem to be developing web applications, and you have technical skills, I suggest that you take the plunge and choose an open source tool for testing web applications, get it installed, and start building tests for anything that you develop yourself.

Twill is an example of the kind of testing tool that you would need.

Then, as manager, you need to entice developers to follow your example, and reward them for doing so. And punish them, when they don't use the testing framework and it leads to preventable problems. As soon as you get one such incident, you should be able to get your boss on board, and pick up some momentum.

Overall, remember that the objective is to do less work to get a good result. Cutting corners is a way of doing less work, but leads to the risk of bad, or spectacularly bad results. Keep management informed of the risk levels and potential costs at risk.

Don't just force people to do testing for testing's sake. It has to help them be more productive so choose the first projects for it carefully.

Michael Dillon
+1  A: 

I'll have to disagree with michaelkebe- these changes need support from the executive level, in addition to a few key developers, in order to fully succeed.

Without that support, you'll just be some developers who look like they are 'wasting time on writing tests for stuff that already works.'

There needs to be a clear vision, and it needs to be repeated loudly and often.

I'm not necessarily advocating for Agile here, but often times it clicks for business owners.

If you can sell them on that, the things that you're excited about (delivering software fast, easy maintenance, automated testing, etc.) will fall into place.

Nathan