In his two latest blog posts (here and here), James Bach again talks about ISEB/ISTQB certifications and how bogus he thinks they are. I couldn't agree more. Sure, I am ISTQB certified myself, but even before I attended that three day course (which for me turned out to be a two day course, being sick the first day) I knew that what was going to be presented to me wasn't the truth. Well, not the ONLY truth anyway.
I learned some things from this course, I admit that. But there were also other things that felt completely outdated and irrelevant. Nonetheless, I'm happy I attended (and even happier I didn't have to pay for it myself) since I'm of the opinion that lessons can be learned anywhere and everywhere. I like to read and learn about many different techniques, approaches and methodologies and mix them together where I see fit. Take a few goodies here and a few goodies there...
May 17, 2010
May 10, 2010
The inherited burden of test cases
My predecessor at work spent a lot of time creating test documents for each and every system we have, documents filled to the brim with different test cases. When I first begun working as a tester (and later on as test lead) at this company I found these test cases very well written and useful and they were very self-explanatory, making it easy for anyone (well, almost anyone) to step in and help out with the testing.
However, the times have changed. Since our big conversion from one graphics engine to another and the many design and functionality changes it brought to the table I've found the old test cases to be much too specific and just a pain in the a** to keep updated. And if they're not updated, they're useless.
So, I decided that some major changes had to be done and there were in reality only one way to go: Exploratory Testing. We will still have to use test cases to some degree, but with short descriptions of the scenarios, some expected results (not specific figures, but the formulas used to calculate the correct results) and information on where in the system to find these results. What used to be a 10 page document filled with test cases will now be one, maybe two pages long. A lot easier to manage and keep updated, and not as scary to look at.
There's only one problem; Finding the time to redo all these documents. We're under a extremely heavy workload and are already cutting corners to meet the (not so realistic) deadlines set by management. It doesn't help that we're currently sitting in an open landscape office, constantly being disturbed by everyone and their grandmother. But that's another story...
The documents will be updated and used as a starting point for our exploratory testing, that much I can promise. But when? Soon, I hope...
However, the times have changed. Since our big conversion from one graphics engine to another and the many design and functionality changes it brought to the table I've found the old test cases to be much too specific and just a pain in the a** to keep updated. And if they're not updated, they're useless.
So, I decided that some major changes had to be done and there were in reality only one way to go: Exploratory Testing. We will still have to use test cases to some degree, but with short descriptions of the scenarios, some expected results (not specific figures, but the formulas used to calculate the correct results) and information on where in the system to find these results. What used to be a 10 page document filled with test cases will now be one, maybe two pages long. A lot easier to manage and keep updated, and not as scary to look at.
There's only one problem; Finding the time to redo all these documents. We're under a extremely heavy workload and are already cutting corners to meet the (not so realistic) deadlines set by management. It doesn't help that we're currently sitting in an open landscape office, constantly being disturbed by everyone and their grandmother. But that's another story...
The documents will be updated and used as a starting point for our exploratory testing, that much I can promise. But when? Soon, I hope...
May 02, 2010
Setting things straight
Among the community of our users there are very high-voiced opinions about the quality of each release. Nothing strange about that, would be much weirder if they didn't care. However, there seems to be a tendency to always, ALWAYS, blame the testers when something doesn't work like it should (or maybe it works as intended, but it's not to their liking). Therefore I'd like to set some things straight:
1. The deadline.
We have a deadline for each release that has to be met. Usually, the Project Managers plan one week of testing (which, in my opinion isn't enough) but even if the developers fall behind our test week does not get extended, which means that we have to work miracles in order to test at least most of the things during just a few days.
2. Resources.
We are a small test department, very small. We also do not have all the different hardware setups we would like and therefore can't catch all hardware related issues that may appear. We are working on it though, trust me.
3. Go/No Go decision.
This one is important. I, as Test Lead, DO NOT decide whether a release is ready to be shipped or not! What I do is to give my recommendations and professional opinion regarding the current status of the release, it's then up to the Project Manager to decide whether to ship it or not. Believe me, my recommendations have been overlooked many, many times.
I'm not saying that our test department is perfect, not at all. I just want to point out that we do the best we can under the circumstances. I have an agenda to improve our test process, but it will take time. I'm not giving up yet though.
1. The deadline.
We have a deadline for each release that has to be met. Usually, the Project Managers plan one week of testing (which, in my opinion isn't enough) but even if the developers fall behind our test week does not get extended, which means that we have to work miracles in order to test at least most of the things during just a few days.
2. Resources.
We are a small test department, very small. We also do not have all the different hardware setups we would like and therefore can't catch all hardware related issues that may appear. We are working on it though, trust me.
3. Go/No Go decision.
This one is important. I, as Test Lead, DO NOT decide whether a release is ready to be shipped or not! What I do is to give my recommendations and professional opinion regarding the current status of the release, it's then up to the Project Manager to decide whether to ship it or not. Believe me, my recommendations have been overlooked many, many times.
I'm not saying that our test department is perfect, not at all. I just want to point out that we do the best we can under the circumstances. I have an agenda to improve our test process, but it will take time. I'm not giving up yet though.
Subscribe to:
Posts (Atom)
Posts
