So, we’re working on conjoining our quick development and structured development groups, at work.
First off, to define those …
- Quick Development
- I intentionally renamed this after initially calling it “rapid development” because RD is a defined methodology of development, which isn’t what I’m talking about. QD is, if you will, just development of scripts and small applications that consistently need a short turnaround. Get the project Monday, and if it’s a big project maybe get until the following Monday. But frequently of the “we need this by noon” variety. Small things, change this text, whip up something that provides the user with XYZ, etc.
- Structured Development
- The SD team, on the other hand, gets requirements, builds design documents, has a QA team associated with them, and frequently can get 6-12 months for a significant update.
Now, I’m not saying that the SD team doesn’t get “uh oh! the code in this app is wrong, it needs to be fixed before anyone goes home tonight!” issues (Error Reports, they get a high priority), and QD gets some tasks that take months, like completely changing how the system works. But QD is much less formalized and closer to “whoever reads their email first grabs whatever’s come in” in the morning, while SD has weekly meetings to assign out new tasks. Because no one expects them to be done immediately anyway, a few days here and there doesn’t slip the deadline any
But, as I said, they’re trying to conjoin the two teams. Which makes sense, why have two sets of developers? Except it’s running into some problems. First of all, the two teams use entirely different programming tools, in general. Java and PHP share little in common. Second, the mindsets are drastically different “I wonder if anything is on fire?” vs “What is on fire now?”. And then there’s the QA process. QD does their QA by internal testing. Usually the developer runs some tests based on vague commandments in the requirements. And if you ask for guidance, what you get is “Click around and make sure everything works.”
Now with QD expected to use QA for testing, we’re having to document our QA tests. And most of our tests are either vague (“I clicked a few things and nothing exploded”) or non-existent (“They said to change this to do X, now it does X”). This has led to some amusing issues of late.
On one project, we were asked to write a script that generates an email and lists the records matching X and Y. So we wrote the script, working with the people who needed the email to make sure we were matching X and Y correctly. When the script was done, we had them tell us that the email was correct and matched what they wanted. Then we had to send it to QA. Uh? OK. Here’s the script. Testing procedures? You run it. What’s the output supposed to be? Ask the people who want it, or I can give you the output from the last test I did and you can make sure it still matches itself … You want to test the automated execution of the script? But that not working is user, not coding, error! *sigh*
The other I’m still working on. This literally had directions of “Try various View links and make sure it displays the right stuff.” For my own testing I had expanded it to note the various KINDS of links to make sure I checked multiple options. I noted the various uses and the various conditions that should work or not (as in, if you change the date to before today to look something up, you can’t create a new entry in the past. Only the future. But today is OK, even before now today, as long as it’s still today. But not after 8pm, because that’s not today anymore, it’s tomorrow, but still show today … see why I needed notes?) Now I’m working on formalizing the testing for the QA team to test the latest updates.
It turns out that the set of options for just CLICKING AND LOOKING had 16 different variations. Maybe only 8, but to make sure that various links work I had to end up looking at the same generating page multiple times, but with slightly different data. Make sure that entries created by admins show up differently than entries created by users, make sure that if you choose column A and then change the date that you still get column A on the new date. Now make sure that picking column B leaves your date alone. Three views of the same page, but different tests.
I’m truly fearful of the vast number of tests for creating and editing entries. Because there are two types of entries, and each type has 3 or 4 sub-classifications. And they’ll all need to be tested. And that’s just for tests that should succeed. Then I need tests that should fail, to make sure the failure is meaningful and functional. Wheeee
Hopefully by the time this posts I’ll have finished the test listing and can fill this in with how many total tests there were in the end. But I’ll be shocked if it doesn’t clear 100. If it gets near 200, I won’t be done when this posts, because this is boring and that’d be like 40 a day … plus other projects that get higher priorities 
