There was a comment (by Pawel) to my last post that included a series of questions. I decided to pick them up and answer them in the open, so maybe they'll inspire you people to discuss this further.
1. How many users you expect to use the software you've been recently developing?
It is supposed to be deployed and used simultaneously at over 3 thousand locations.
2. Do you develop web software or desktop software?
This project is desktop software, but a previous one and one coming up is a webapp so generally this is irrelevant.
3.1. How do you test?
We have automated test suites. Well OK, we are aiming for those, close to the truth is: we are growing our test suites, automated of course.
The customer also does manual acceptance testing of his own, but that's his free will. As I wrote I came to the project late so it is not fully covered by both unit level nor acceptance level tests, but we have them exercised all the time. People are running unit tests locally as part of the Test Driven Development method. Of course they're supposed to be run automagically on the integration machine as well.
3.2. Do you have testers?
Not quite. There was no tester on the team. It's a small team, now having 3 full time developers and 2 half-time. Some time ago I asked one of the half-time developers to get to know FitNesse and now she's our acceptance test guru, so yes she may be thought of as a tester, but I wouldn't call her that. To my knowledge she's more a developer in the role of a tester. A full blown tester has more testing-specific knowledge than she does at this point. But she's getting there.
She's now in the process of educating the rest of the team about writing automated acceptance test, and will be the person to aid them later.
3.3. And how do you mimic production environment?
The integration machine is a production class unit. How did we make it production-like? Well we just did, I don't get the question. I think there is no generic answer to this, every project is specific in this matter so please tell me about your problem.
4. Do you deploy bit by bit to production so users can use the bit of software you finished and tested and give you some feedback?
Well not quite ;), The relationship with the customer was formed and agreed to a long time ago so I wasn't able to change that, so he's not on-site. We rather integrate the modules after each increment and our internal customer (customer proxy) does the checking. The real customer has longer response times and testing cycle than we require to keep on moving. But as for now it works well (I know it's a risk but we're handling it well for now).
5. When do you fix bugs?
Depends what severity and size. Severe bugs we fix on the double. Minor bugs we schedule according to importance like regular features during the weekly planning game.
6. Do you build software every day/night?
No need for that, this is also project specific. The build takes a few minutes, it's a small team, luntbiuld (or cruisecontrol) does the job of checking our VCS regularly (or at least it should, up until now we had this manual - don't ask me why) and building the project when changes were detected.
7. Do you babysit software you finished providing bug fixes, technical support and deploying new releases when needed?
Yes, depending on the agreement with the customer but in the vast majority the customer buys also maintenance support and/or has new feature ideas. Mainly it's because we need to babysit this software we go to all the lengths to have all those tests in place. It brings the maintenance costs down very quickly.
Subscribe to:
Post Comments (Atom)
1 comment:
Hi again Ilfrin,
Thanks for answering my questions. Now I know how you deploy and test your software and what strikes me most is: you don't have testers. Developers test and customers test but no designated people who assure you about software quality. Hmmmm... How can you actually live without them?
In my opinion developers don't have too much time to focus on testing. They're basically too focused on development and so often they can't play sceptical role of putting themselves in potential customer position ("Oh sugar! I didn't know that somebody can have name with apostrophe. I used dasasdas as a name and it always worked!").
On the other hand customers shouldn't be testing at all. If they start playing with software and find too many problems they will get upset straight away (but I don't think they'll turn to cannibals so quickly).
You may say: "But we follow agile way and we have unit testing. We don't need testers!". Unit testing is a good concept to check the code itself. Still, there are other aspects of software that are quite difficult to test with unit testing. Examples: user interface, localization, static information stored in databases and files. It's nearly impossible to check these without testers.
Moreover, it's good to have real people checking what you've done as oppose to cold machines which will never really understand requirements. Software testing software...? I think it's Sci-fi.
See more about testers at: Top Five (Wrong) Reasons You Don't Have Testers.
Post a Comment