To everyone with experience in implementing a testing process or testing department.
I have the following situation:
A medium sized software developing company that has grown dramatically over the last five years. Their programming lacks structure and there is hardly any documentation. Because some senior programmers left the company in the last year there is a lack of knowledge of the structure of the code. This resulted in instable software with a lot of complications. Customers are complaining and threatening to leave, which creates randomly build solutions that are hardly being documented again. The result is an uncontrollable development disaster.
As a first step the company wants to implement a structures testing process to get a better product quality and also clarify what the problems are exactly. People don't have time to do things other than their work, are insecure and therefore collide with colleagues on a regular basis.
I want to set up a project team to create a test proces that will be accepted because the involved departments developed it themselves, but it looks like the management of the company will resent the idea of freeing people up, since they are understaffed already.
What would be a workable approach for a situation like this. I've already got some ideas of my own, but I'd like to get some feedback from pro's. I myself have experience in implementing several kinds of processes but have never been involved with a company that is in such an awkward state as this one. People are motivated, but overloaded with work that was generated by problems with customers, creating new ones for the future.
How does one slowly break through such a destructive cycle? Especially without having the whole company freak out and fall apart even faster.
All input is highly appreciated.
Sounds as though you have a real up hill struggle in front of you to get things off the ground!
I really think that first thing you must do is as you say get 'buy in' from all involved departments and from management. If this is proving difficult why not sell the idea on a 'trial' basis to let them see what can be acheived? (Im sure that after your trial they will realisee the benefits).
I would then suggest that you get the test people involved as early as possible in your development lifecycle and work as closely with the developers as possible. There is a great deal of merit in the 'old find and fix it early'.
If you are not doing so at the moment, incremental builds with even just a small number of changes is beneficial, this will allow test staff to get upto speed with changes and test it early as you go rather than have loads of changes and possibly lots of defects in in-frequent major builds.
Implementing a structured testing process will definatley benefit your company and this forum can be a good tool for advice in aiding your implementation, there are lots of us here who have went through similar situations.
Do you have source code control? If things are spinning out of control (as it sounds) it is vital that you can identify things. This gives you a sense of control that something is keeping track of what software you have and tracking who is changing it and what the changes are.
Having source code control gives you a more stable platform from which to build processes from.
It may be worth keeping the group small to start with. This will enable you to put some structure in place rapidly. From this hope fully the benefits will be seen and management will be more willing to accomodate your requests.
I think it would be nice to get everyone round the table but unaimous decisions are difficult to agree on and often take a long time. This isn't a show that the managers would be happy with.
If everyone is busy they may be pleased if someone takes a leap and gets things started. Put forward proposals as it is easier for others to look at things and say what is bad and agree than look at a blank page and say what they want and agree. Keep people interested by keeping them informed. Be very open to comments from everyone and try to compromise and include something from everyone (if possible) as this will help them feel that it is their project too.
Thanks for the advice! Both Coling and Trewshrew. My thoughts are basically a mixture of your suggestions. Looks like making a step myself with obvious input from others will make a decent start. The next phase would be to create a small project group with a representative of all departments involved and urge development to establish software code control (which is presently absent).
I must say I'm not very keen on keeping democratic sessions in this company, since all have different views and corporate management doesn't even have a clear view on what direction they want to take the firm to in the future.
At this point I think the biggest struggle will be overcoming the various internal political issues at hand. Which shouldn't be too hard when I can show some decent results of my own ideas.
Keep suggestions coming on how to operate in an environment like this, cause I'm really eager to implement a solid good functioning test process. It would mean a break through for this company and a kick for me! :-)