Well our company is about 100 people but the majority of that is the call center. We have a very small staff of actual survey programmers / QA people. We use the ConfirmIT tool that's built on jscript (which seems to suck hard) and for that we have 3 or 4 programmers we also have 3 programmers for Cold Fusion. Mind you we're missing 1 ConfirmIT programmer and 1 ColdFusion programmer due to maternity leave. Our main ConfirmIT programmer is self taught.
We have 3 main QA people of which I am one. I have no real idea of how I became the manager since I've only been here for 2 years.
We already have a consistent testing process, however the problem we have is that survey logic is usually in flux between very simple and very complex. Using the ConfirmIT tool to do the complex stuff means we're actually pushing the tool beyond it's limits. This usually means that our processes are changing from project to project. Also, we have very short turn around time, usually 2 weeks is the longest something ever goes before it gets fielded.
I really have no fucking clue how I can improve quality when there's so many areas for human error (our clients like to fuck around with surveys hours before launch but refuse to move timelines to accomedate).
I haven't had the "joy" Six Simga yet I did "experience" the Myers-Briggs personality test. The idea behind it being that if everyone knew everyone elses personality type they would know how to be approach the person on a day to day basis. The whole thing is all about conflict avoidance. It sounds great until you realize that if even one person blows it off (like the company jerk) then everyone else is basically bending over backwards to keep that person happy.
That's what that test was intended for? I had no idea.
I took it once. I'm a "Mastermind", which I think it pretty cool.
Well, technically if the test says you're a "Mastermind," it's from the Kiersey Temperament Sorter, which is based on the Myers-Briggs but not exactly the same. It's a slightly more pop psych version of it.
I also got the letter-result - INTJ, so I believe it was the Myers-Briggs test.
Andrew_Jay on
0
Options
tuxkamenreally took this picture.Registered Userregular
Well our company is about 100 people but the majority of that is the call center. We have a very small staff of actual survey programmers / QA people. We use the ConfirmIT tool that's built on jscript (which seems to suck hard) and for that we have 3 or 4 programmers we also have 3 programmers for Cold Fusion. Mind you we're missing 1 ConfirmIT programmer and 1 ColdFusion programmer due to maternity leave. Our main ConfirmIT programmer is self taught.
We have 3 main QA people of which I am one. I have no real idea of how I became the manager since I've only been here for 2 years.
We already have a consistent testing process, however the problem we have is that survey logic is usually in flux between very simple and very complex. Using the ConfirmIT tool to do the complex stuff means we're actually pushing the tool beyond it's limits. This usually means that our processes are changing from project to project. Also, we have very short turn around time, usually 2 weeks is the longest something ever goes before it gets fielded.
I really have no fucking clue how I can improve quality when there's so many areas for human error (our clients like to fuck around with surveys hours before launch but refuse to move timelines to accomedate).
See, for a staff of 10 "effective" workers, I don't think trying to fully implement CMMI is the proper approach--just institute its practices where it's applicable. The key things I note are:
- Your tools may not be suited for what you're trying to accomplish. Is there something more tailored to what you do that would help you produce things more quickly or easily?
- You say the survey logic varys widely. At its core, it's still just a survey and it can't be that complex (a branching menu system, when you get down to it). Your programmers must have a design for said survey that they are following when they make it; do your testers get this design to base their runthroughs and test procedures on?
- Your processes should *not* change from project to project. Ideally, you are always doing the same things; you might be running different test procedures for each survey, but you are always testing a survey, going over design, so on.
- Requirements creep is a thorny problem. Depending on the quality of your services and how much you charge, you can either sit and take it so that you appear "responsive", or draw a hard line and say 'if you want this done on X, you must stop requesting changes by Y. We will help you with any questions or concerns you have up until Y, but in order to provide proper testing time and maintain quality, if you request a change after the deadline we will move X back by at least 1 business day.'
(Guess which choice I prefer.)
Being "responsive" to the detriment of quality in the final product doesn't help your customers; it's more likely to piss them off if you got their last change in, but the survey breaks. You can and should enforce limits on their input as time goes by; that's one of the prime reasons why software projects fail.
See, for a staff of 10 "effective" workers, I don't think trying to fully implement CMMI is the proper approach--just institute its practices where it's applicable. The key things I note are:
- Your tools may not be suited for what you're trying to accomplish. Is there something more tailored to what you do that would help you produce things more quickly or easily?
We've looked into developing our own tool however upper management thinks that the development time/cost (we have a small in house team of about 5 people) would be prohibitive. I'm sure we've looked into other tools but found that what we have works for us because we've invested so much time into finding work arounds for issues that we've encountered.
- You say the survey logic varys widely. At its core, it's still just a survey and it can't be that complex (a branching menu system, when you get down to it). Your programmers must have a design for said survey that they are following when they make it; do your testers get this design to base their runthroughs and test procedures on?
The programmers more or less get the same design that we do. The client gives us a word document outlining questions / options and all programming logic, these range from relatively simple to fairly complex (answer lists that pipe in based on respondent region / brands that pipe based on a priority list). So yeah, we have something to work off of when we do our runthroughs and procedures.
- Your processes should *not* change from project to project. Ideally, you are always doing the same things; you might be running different test procedures for each survey, but you are always testing a survey, going over design, so on.
Our processes don't change from project to project and like you've said we're doing different test procedures. I think one of our main problems is that in the 2 years I've been here we've gone through 4 or 5 programmers and when you figure in our small development team this is a fair bit of our knowledge bank that's gone. we've had trouble implementing solid processes in the programming area and I imagine if we finally have a core of programmers long enough for them to write standards we'll eliminate a lot of the problems we face.
- Requirements creep is a thorny problem. Depending on the quality of your services and how much you charge, you can either sit and take it so that you appear "responsive", or draw a hard line and say 'if you want this done on X, you must stop requesting changes by Y. We will help you with any questions or concerns you have up until Y, but in order to provide proper testing time and maintain quality, if you request a change after the deadline we will move X back by at least 1 business day.'
(Guess which choice I prefer.)
Being "responsive" to the detriment of quality in the final product doesn't help your customers; it's more likely to piss them off if you got their last change in, but the survey breaks. You can and should enforce limits on their input as time goes by; that's one of the prime reasons why software projects fail.
Yeah this is the one that's really a huge problem, because at the core you're trying to keep the client happy and still accommodate them and their needs. However this usually just has the effect of stressing out everyone involved on the project because usually telling them 'No' doesn't work, so my days get lengthened depending on how much of a dick a particular client is.
Yeah this is the one that's really a huge problem, because at the core you're trying to keep the client happy and still accommodate them and their needs. However this usually just has the effect of stressing out everyone involved on the project because usually telling them 'No' doesn't work, so my days get lengthened depending on how much of a dick a particular client is.
It won't work unless you make this absolutely clear at the outset of the process, institute a hard deadline for major changes, and stick to it. Make them sign something if you have to. Do not cave; if your customer starts to make grumblings about requirements changes near the deadline, remind them that they had their chance. Your goal is to make the customers think harder about what they need to have (you, too) earlier in the process so that they do not come back two days before deadline and say 'oh, by the way, we need this in French and Spanish too'. It's okay to bend a little bit on minor changes, but you want your gross design to be laid down and stable by the time the test phase comes around.
To that end, you can come up with some standard questions to ask in the requirements-gathering phase--what is your audience? What kind of information do you need? Will you have to ask different questions based on answers to some of your questions? Et cetera. Likewise, you can develop common procedures for doing things in your tool (how to branch menus conditionally, basic question logic, database setup, so on) so that your developers have a knowledge base to work from.
Yeah this is the one that's really a huge problem, because at the core you're trying to keep the client happy and still accommodate them and their needs. However this usually just has the effect of stressing out everyone involved on the project because usually telling them 'No' doesn't work, so my days get lengthened depending on how much of a dick a particular client is.
It won't work unless you make this absolutely clear at the outset of the process, institute a hard deadline for major changes, and stick to it. Make them sign something if you have to. Do not cave; if your customer starts to make grumblings about requirements changes near the deadline, remind them that they had their chance. Your goal is to make the customers think harder about what they need to have (you, too) earlier in the process so that they do not come back two days before deadline and say 'oh, by the way, we need this in French and Spanish too'. It's okay to bend a little bit on minor changes, but you want your gross design to be laid down and stable by the time the test phase comes around.
To that end, you can come up with some standard questions to ask in the requirements-gathering phase--what is your audience? What kind of information do you need? Will you have to ask different questions based on answers to some of your questions? Et cetera. Likewise, you can develop common procedures for doing things in your tool (how to branch menus conditionally, basic question logic, database setup, so on) so that your developers have a knowledge base to work from.
Oh we have contracts but it usually just turns into the Project Manager / Salesperson who are the point of contact with the client going "ok, we can do it for you but only this once". It's been recognized as a very real problem but it seems that it's just not being fixed. I think this is something that I'm going to definetly have to push for.
Aso for the standard questions we don't need to know who the audience is, the information they need is contained in the questions they'll ask, as with follow up questions.
To that end, I'm going to pass on this conversation. I discussed CMMI with the R&D Manager and we figured out that we're already somewhere between being level 2 or level 3 because we already have a standard set of processes that we can run over and over (and do). I'm going to be researching our competitors to see if there's areas of weakness that we can shore up by doing something different. I'm also going to be looking into automating some of the redundant tasks and just check the outputs for success / failure.
On Topic: Being involved in QA I don't think Six Sigma is retarded (from what I've read of it) however I know that not everything can be expected to be tested using the same set of rules.
Shlank on
0
Options
tuxkamenreally took this picture.Registered Userregular
edited July 2007
Just remember: The point of being a hard-ass about it at the beginning is so that you have the opportunity to be a little flexible on small stuff at the end, should the need arise.
Posts
We have 3 main QA people of which I am one. I have no real idea of how I became the manager since I've only been here for 2 years.
We already have a consistent testing process, however the problem we have is that survey logic is usually in flux between very simple and very complex. Using the ConfirmIT tool to do the complex stuff means we're actually pushing the tool beyond it's limits. This usually means that our processes are changing from project to project. Also, we have very short turn around time, usually 2 weeks is the longest something ever goes before it gets fielded.
I really have no fucking clue how I can improve quality when there's so many areas for human error (our clients like to fuck around with surveys hours before launch but refuse to move timelines to accomedate).
See, for a staff of 10 "effective" workers, I don't think trying to fully implement CMMI is the proper approach--just institute its practices where it's applicable. The key things I note are:
- Your tools may not be suited for what you're trying to accomplish. Is there something more tailored to what you do that would help you produce things more quickly or easily?
- You say the survey logic varys widely. At its core, it's still just a survey and it can't be that complex (a branching menu system, when you get down to it). Your programmers must have a design for said survey that they are following when they make it; do your testers get this design to base their runthroughs and test procedures on?
- Your processes should *not* change from project to project. Ideally, you are always doing the same things; you might be running different test procedures for each survey, but you are always testing a survey, going over design, so on.
- Requirements creep is a thorny problem. Depending on the quality of your services and how much you charge, you can either sit and take it so that you appear "responsive", or draw a hard line and say 'if you want this done on X, you must stop requesting changes by Y. We will help you with any questions or concerns you have up until Y, but in order to provide proper testing time and maintain quality, if you request a change after the deadline we will move X back by at least 1 business day.'
(Guess which choice I prefer.)
Being "responsive" to the detriment of quality in the final product doesn't help your customers; it's more likely to piss them off if you got their last change in, but the survey breaks. You can and should enforce limits on their input as time goes by; that's one of the prime reasons why software projects fail.
Games: Ad Astra Per Phalla | Choose Your Own Phalla
We've looked into developing our own tool however upper management thinks that the development time/cost (we have a small in house team of about 5 people) would be prohibitive. I'm sure we've looked into other tools but found that what we have works for us because we've invested so much time into finding work arounds for issues that we've encountered.
The programmers more or less get the same design that we do. The client gives us a word document outlining questions / options and all programming logic, these range from relatively simple to fairly complex (answer lists that pipe in based on respondent region / brands that pipe based on a priority list). So yeah, we have something to work off of when we do our runthroughs and procedures.
Our processes don't change from project to project and like you've said we're doing different test procedures. I think one of our main problems is that in the 2 years I've been here we've gone through 4 or 5 programmers and when you figure in our small development team this is a fair bit of our knowledge bank that's gone. we've had trouble implementing solid processes in the programming area and I imagine if we finally have a core of programmers long enough for them to write standards we'll eliminate a lot of the problems we face.
Yeah this is the one that's really a huge problem, because at the core you're trying to keep the client happy and still accommodate them and their needs. However this usually just has the effect of stressing out everyone involved on the project because usually telling them 'No' doesn't work, so my days get lengthened depending on how much of a dick a particular client is.
Bottom-paged.
It won't work unless you make this absolutely clear at the outset of the process, institute a hard deadline for major changes, and stick to it. Make them sign something if you have to. Do not cave; if your customer starts to make grumblings about requirements changes near the deadline, remind them that they had their chance. Your goal is to make the customers think harder about what they need to have (you, too) earlier in the process so that they do not come back two days before deadline and say 'oh, by the way, we need this in French and Spanish too'. It's okay to bend a little bit on minor changes, but you want your gross design to be laid down and stable by the time the test phase comes around.
To that end, you can come up with some standard questions to ask in the requirements-gathering phase--what is your audience? What kind of information do you need? Will you have to ask different questions based on answers to some of your questions? Et cetera. Likewise, you can develop common procedures for doing things in your tool (how to branch menus conditionally, basic question logic, database setup, so on) so that your developers have a knowledge base to work from.
Games: Ad Astra Per Phalla | Choose Your Own Phalla
Oh we have contracts but it usually just turns into the Project Manager / Salesperson who are the point of contact with the client going "ok, we can do it for you but only this once". It's been recognized as a very real problem but it seems that it's just not being fixed. I think this is something that I'm going to definetly have to push for.
Aso for the standard questions we don't need to know who the audience is, the information they need is contained in the questions they'll ask, as with follow up questions.
To that end, I'm going to pass on this conversation. I discussed CMMI with the R&D Manager and we figured out that we're already somewhere between being level 2 or level 3 because we already have a standard set of processes that we can run over and over (and do). I'm going to be researching our competitors to see if there's areas of weakness that we can shore up by doing something different. I'm also going to be looking into automating some of the redundant tasks and just check the outputs for success / failure.
On Topic: Being involved in QA I don't think Six Sigma is retarded (from what I've read of it) however I know that not everything can be expected to be tested using the same set of rules.
Games: Ad Astra Per Phalla | Choose Your Own Phalla