Help from Test Managers

[testermike (Michael Crockett)]

Hello, I am new to this forum but joined as it looks like a great place to share and gain knowledge for all kinds of testing.

I wanted some advice from Test Managers. I started working at a new company about 6 months ago where they had no formal testing practices and processes or knowledge in house. My job is to develop and embed these processes so that everyone is working in the same way in as efficient way as possible.

This company is very big with a number of departments all working with a large number of systems each, including in house infrastructure etc… I have developed a framework designed to provide information for everyone to understand what will be expected from now on, and a roll out plan for how to accomplish this, I am now developing the test policy / strategy documents and this is where i wanted the advice.

How would you go about designing these? I have done this before for smaller companies but i am getting stuck now with the fact we have so many departments that need to be covered by these documents.

My plan at the moment is to develop an overall test strategy document which details the universal points that everyone needs to follow (sign off procedures, use to test environments and data, expected reporting etc…) and then have a document per department detailing how this strategy is to be tailored to meet their specific needs.

My problem then comes with the many different systems we have. The majority of these run in a BAU fashion with projects run as a separate entity (I plan on having a project test process for every project to follow from start up). In companies with a smaller number of systems i would look at creating approach documents that can be altered per release to bring them in line with new requirements but with this number of systems this is one hell of a job.

Am i approaching this the wrong way? Is this overkill in terms of process? I am looking at 4 or 5 departments, 200+ staff, and 10’s of systems to cover off and need an efficient way to cover all of this effectively.

I look forward to hearing back from anyone who can offer some advice.

[jesper (Jesper Ottosen)]

Welcome Michael,

What a task Here are some similar threads to get you started. A few suggestions would be to keep it short, in both numbers and length. Perhaps only a few generic and then some tailored by the delivery teams?

Test Strategy Documentation in an Agile world

Back in “ye old days” where I worked in an Waterfall environment when you could be designated tester on project ABC, there was always a requirement on a per project basis to write up a comprehensive test strategy document. As well as detailing the specific tests that would be executed, it would outline things things like: overall approach browser coverage what was out of scope(based on test case prioritisation of high, medium, low) So in the example of project ABC which was estimated at 3 mon…

Software Test Plan: What Should Be In It?

Test plans are something that come up a lot. People ask on different forums what a software test plan is, how do you write one, what should go into one, etc. @rocketbootkid recently wrote an article for the Dojo “How To Write A Software Test Plan: Learning What’s Important And Where To Start”. During our 30 Days of Agile Testing challenge, @jesper posted about what his test plans look like 30 days of Agile Testing, Day 26: What does your Test Plan look like? I think this ties in well with the…

Presenting to the business

A few months ago, I was given the role of Head of QA. One of the directors and I sat down to discuss the enterprise level goal of the QA department. We settled on “aiming for a zero defect company”. Obviously this is what we all, as testers, aspire to, but, as soon as code passes the “Hello world” stage, it becomes to all intents and purposes, an impossibility, but it’s there as something to push towards. Anyway, I digress (as I often do). One of the things we also discussed was visibility. One …

[testermike (Michael Crockett)]

Thank you very much for responding. I will read through what you have suggested to get some ideas of how this has worked in other places.

[hattori (George)]

Hello Michael,

Here are a few ideas to keep in mind. I hope they help. My perspective is from 25 years in a well-known R&D organization for a very large company. Over time I’ve seen many kinds of development/test processes applied. And, of course, there is no single, right answer. However, the principles and approach you use for your assignment are very important for a successful outcome.

“My job is to develop and embed these processes so that everyone is working in the same way in as efficient way as possible.” If there are “4 or 5 departments, 200+ staff, and 10’s of systems to cover,” I would guess there are already several different processes in place. They may not be known well outside of their respective organizations, and it’s a good bet that everyone is not working in the same way.

“I have developed a framework … and a roll out plan … I am now developing the test policy / strategy documents and this is where i wanted the advice. How would you go about designing these?” I would suggest enlisting technical representatives from the various affected organizations to collaborate. These are people who should know how things are done currently (both good and bad). They are the ones with insight for what will work for their programs. They can help refine your goals and suggest feasible process changes for identifiable problems.

You can expect lots of organizational inertia, so it is essential to get buy-in from the various departments. The proposed changes need to be as easy as possible, with the biggest payoff. And they may need to be phased in to allow for ongoing work. In short, I suggest a bottom-up approach enlisting others to help you succeed.

Good Luck!