Monday, July 25th, 2011 11:42 pm
and pages to go before i sleep
To say work is trying to drive me crazy borders on a lie; I hit crazy last week and completed part of it today in a fit of sheer dark rage against the machine to create a document/application map.
Short version: the web application has pages and pages of questions for a client applying for benefits. Once it's done, you submit it and then it creates a PDF file with all that information (or most of it) neatly organized in the standard form for a paper application for benefits. So the information is in a different order, so to speak. But even moreso.
So after much frustration, I screenshotted every page of the online application while I was filling it out as completely as possible, then printed it, then submitted it and printed the 1010. Then I opened up a spreadsheet with eight columns, four for the document file with every question on it by section and header and the second four the coordinating question/location in the web application itself.
The things that makes this all extraordinary is that there is not one of these I can access. That anyone has. The people who are programming this have to have made one of these or--I mean, they can't possibly be doing this without this kind of basic documentation. But there we go; every time we request, they act like they have no such thing. Which they do, but after a lot of thought and a lot of talk, I have a theory whey we almost never get the documentation, even the unofficial.
Well, several theories, but here are the ones that seem to be likely:
1.) Because we haven't gotten to code freeze yet--yes, until code freeze, tehy can change up things while we are testing it--they want flexibility to keep changing things and not have to explain themselves to the testers (more than they do; honestly, they're right in that I'd be first and foremost questioning every damn change and when it occurred and why).
2.) As long as we don't have proper full documentation, then things that may not be mistakes but are user unfriendly or things testers may be skipped. Damn straight I'd be testing everything on it at least a dozen times. So yeah.
3.) They actually don't have an updated version but only the original, which is covered in red pen and not, you know, available anywhere.
4.) Without documentation, they can say that a defect isn't a defect and we have to accept it. Then they can update the official document with that and once it's there, we can't say it's wrong because it's official.
The thing is, it's almost probably number three and to a lesser extent, one. And because developers, in their heart of hearts, cannot imagine that anyone can't intuit what they're doing as being Right and Of Course. And I think there is also the fact that documentation does in fact screw over developers sometimes because of the way the state goes about auditing them; it's stupid, but the more detail you go into, the more if something goes wrong, you get blamed. I don't blame them for being wary on what they put down for official, because it can go to lawsuit territory at any time, since the state is sued a lot.
There is also having to put all your wording through Communications to make it more readable to clients and succeed in making it a nightmare to read. It's like, IDK, elementary school legalspeak. That slows things down tremendously, because anything that can be said in four words is of course impossible for people applying for benefits to understand or something; make it fifteen words.
I originally started it because I couldn't find where X question on the document was in teh application itself. Then it grew up into a massive file detailing all the questions on the PDF file, their sections, subsections, the type of question and the type of answer (text box, radio buttons, etc) and the corresponding section, subsection, question and type of answer on the application. Some of it is really intuitive. Some of it is unfindable unless you know precisely what you are looking for, and even then, I have three or four questions that I have no idea wtf is up with them and where/how they're even answered.
Currently, the map is spreadsheet-only text based; if I can figure out a way to do it, I'm going to create a complete walk through of the application using screenshots and a search so it's easier to find specific things. But I have no idea how I'm going to do it or get approval for it, either. Because again, did I mention how documentation--any documentation--can be taken as proof of something? It's hard to explain, but it's one of the reasons I get that developers are very careful about what they release and why. There's a lot of unofficial documentation that isn't shared in between departments, or even between people; they can't without bringing down the wrath of higher-ups for X reason (I've been hit by this before).
That's why I've only shared the map with one person so far to check my work if he wants to; I'm not sure if I can share it or rather, how to go about it. If someone has it isn't the problem; the problem is if they try to put out a defect and cite it as proof, and then someone tracks it down and drags me in to ask why I'm spreading unsanctioned information. I'd tell them exactly why, but I'd still get a hit for it.
It's so stupid, but it's how things work; only open source, apparently, has the luxury of complete disclosure. Or various attempts, anyway.
This does, I acknowledge, appeal to my anal love of spreadsheets, but God it's frustrating sometimes to have these sorts of limits. We're testers and this stuff shouldn't be considered anything less than necessary to our jobs. And yet.
That is my work vent for the week. Since it is also my period, I am guessing my mood about this will take an upswing when a.) it's over and b.) I get a test to pass. Please God.
Short version: the web application has pages and pages of questions for a client applying for benefits. Once it's done, you submit it and then it creates a PDF file with all that information (or most of it) neatly organized in the standard form for a paper application for benefits. So the information is in a different order, so to speak. But even moreso.
So after much frustration, I screenshotted every page of the online application while I was filling it out as completely as possible, then printed it, then submitted it and printed the 1010. Then I opened up a spreadsheet with eight columns, four for the document file with every question on it by section and header and the second four the coordinating question/location in the web application itself.
The things that makes this all extraordinary is that there is not one of these I can access. That anyone has. The people who are programming this have to have made one of these or--I mean, they can't possibly be doing this without this kind of basic documentation. But there we go; every time we request, they act like they have no such thing. Which they do, but after a lot of thought and a lot of talk, I have a theory whey we almost never get the documentation, even the unofficial.
Well, several theories, but here are the ones that seem to be likely:
1.) Because we haven't gotten to code freeze yet--yes, until code freeze, tehy can change up things while we are testing it--they want flexibility to keep changing things and not have to explain themselves to the testers (more than they do; honestly, they're right in that I'd be first and foremost questioning every damn change and when it occurred and why).
2.) As long as we don't have proper full documentation, then things that may not be mistakes but are user unfriendly or things testers may be skipped. Damn straight I'd be testing everything on it at least a dozen times. So yeah.
3.) They actually don't have an updated version but only the original, which is covered in red pen and not, you know, available anywhere.
4.) Without documentation, they can say that a defect isn't a defect and we have to accept it. Then they can update the official document with that and once it's there, we can't say it's wrong because it's official.
The thing is, it's almost probably number three and to a lesser extent, one. And because developers, in their heart of hearts, cannot imagine that anyone can't intuit what they're doing as being Right and Of Course. And I think there is also the fact that documentation does in fact screw over developers sometimes because of the way the state goes about auditing them; it's stupid, but the more detail you go into, the more if something goes wrong, you get blamed. I don't blame them for being wary on what they put down for official, because it can go to lawsuit territory at any time, since the state is sued a lot.
There is also having to put all your wording through Communications to make it more readable to clients and succeed in making it a nightmare to read. It's like, IDK, elementary school legalspeak. That slows things down tremendously, because anything that can be said in four words is of course impossible for people applying for benefits to understand or something; make it fifteen words.
I originally started it because I couldn't find where X question on the document was in teh application itself. Then it grew up into a massive file detailing all the questions on the PDF file, their sections, subsections, the type of question and the type of answer (text box, radio buttons, etc) and the corresponding section, subsection, question and type of answer on the application. Some of it is really intuitive. Some of it is unfindable unless you know precisely what you are looking for, and even then, I have three or four questions that I have no idea wtf is up with them and where/how they're even answered.
Currently, the map is spreadsheet-only text based; if I can figure out a way to do it, I'm going to create a complete walk through of the application using screenshots and a search so it's easier to find specific things. But I have no idea how I'm going to do it or get approval for it, either. Because again, did I mention how documentation--any documentation--can be taken as proof of something? It's hard to explain, but it's one of the reasons I get that developers are very careful about what they release and why. There's a lot of unofficial documentation that isn't shared in between departments, or even between people; they can't without bringing down the wrath of higher-ups for X reason (I've been hit by this before).
That's why I've only shared the map with one person so far to check my work if he wants to; I'm not sure if I can share it or rather, how to go about it. If someone has it isn't the problem; the problem is if they try to put out a defect and cite it as proof, and then someone tracks it down and drags me in to ask why I'm spreading unsanctioned information. I'd tell them exactly why, but I'd still get a hit for it.
It's so stupid, but it's how things work; only open source, apparently, has the luxury of complete disclosure. Or various attempts, anyway.
This does, I acknowledge, appeal to my anal love of spreadsheets, but God it's frustrating sometimes to have these sorts of limits. We're testers and this stuff shouldn't be considered anything less than necessary to our jobs. And yet.
That is my work vent for the week. Since it is also my period, I am guessing my mood about this will take an upswing when a.) it's over and b.) I get a test to pass. Please God.