I’m working for a system house as a software tester. The main business field is the developement of one big CIS/HIS (clinical/hospital information system). Over 30 in one system integrated „modules“ will be developed by several dev teams.
In theory the ratio between tester and developer should be 1 : 3.
True reality is: Our ratio is round abaout 1 : 10. Several areas and processes from dev are even not covered by testers! For other areas in dev the following is true: Testers have to do their work for several dev teams at the same time!
I’m one of them and I’m proud that I can write down my experience about that.
My first „big“ testing job – dev team 1
Two a half years ago I started my work as a tester for one dev team (I call it dev team 1) as a half time job during my study of informatics.
When I started, dev team 1 developed a completly new „product“. I started as a „team member“ of dev team 1. And it was a good time for me as a tester, because I don’t need to follow any processes, work instructions or needs to do the „monkey work“ of test case execution from predefined script based testcases or something „wrong going“ testing work like that.
With the product owner and the developers I felt free to „design“ the first testcases and liked to execute them. I had the time to do exploratory testing. I learned to use, „explore“ and „test“ the new product „from the beginning“ of it’s developement. And so I had the chance to define more and more realy good testcases. And that was one of the best experiences I ever made in sw-testing. We used only a bug tracking tool and especially I used it very often! I never found more bugs as I found in this time!
There was only one pilote customer and I could benefit from it! I learned from the customer how to use (or should use) the product, what problems and week points the SUT had and so one. I „explored“ the new product more and more and had more and more information about the week points! In some situations I knew what bugs will come up, when the developers tried to program certain code! Sometimes I don’t need to test. I knew the bug before it had been implemented! 🙂
It was a very „effective“ testing time! I learned a lot, I lighted the way! Although the ratio between tester and dev team 1 was 1 : 7 (I was the only tester) I found importand bugs and the guys from dev team 1 gave thanks about that to me! But: I was free with all what I did! I didn’t have to run a test management programm, I didn’t have do „log“ my testcass (I wrote some testcases in excel and it was good – those testcases are still present now!) I learned to write good bug reports in the bug tracking tool and of course: I had all time in the world!
Starting my current job at the Test & Verification & Validation departement
After a year of testing as a „free“ human, testing as a team member of dev team 1 I got the offer to do a fulltime job as a so called „System Tester“ in our departement „Test & Verification & Validation“.
From now on I never was a direct team member of dev team 1 – I become a team member of the verification departements. I had to work with several other testers. Now I had to test not only for dev team 1, but also for another dev team (completly other business process in our SUT). This second dev team (dev team 2) has still exist a long time before I started testing: Round about 500 customers – in different markets and countries. I started testing in dev team 2 with a colleague who had some experience as a tester in dev team 2. She showed me the main workflows and testcases. That was good.
But it was hard for me: The ratio in dev team 2 between tester and developer was round about 1:6. Although I now had a fulltime job as a tester (40 hours/week) I had to split my work between testing for dev team 1 and dev team 2 (50:50)!
The badest news was: I had to start with doing „monkey work“ in testing: Design and execute scripted based testcases in the test management tool and raise defects in the defect tool from the testing departement instead of free designing testcases, exploratory testing, and add bugs in the bug tracking tool! I also had to do „retests“ of cusomter based and fixed problems. That was new for me. All in all it was hard for me! It was a step back for me as a passionate tester! No time and more and more tasks and most of them unthankfully…
But otherwise I recognised that the testing departement was in a change! Have the test managers recognised, that the way of testing must be updated?
From now on I not only was a tester of software product – I was a human beeing which could talk to the test managers, brought in some good ideas, take part in discussions and so on! This was nice!
By the way: I made it to do good work for dev team 1, for dev team 2 and for my colleagues and the test management also!
Working for dev team 3
After 2 years of doing good testing work (although some „wrong“ thinking from test management and other stake holders concerning todays „testing“ approaches still exists these days – compare with above), I had to switch from dev team 2 to dev team 3. A new colleague in our testing departement took over my testing work of dev team 2.
The good is: I had the experience from testing for 2 dev teams so far. Now I was courious to work for a new dev team.
The guys from dev team 1 worked together in the same building. The guys from dev team 2 also worked togehter in the same building – only one developer worked for some interface functions for dev team 2 but in an other city!
Dev team 3 with it’s only 3 members of developers and one product owner was completly different organized: One developer worked as me too in the same city but in an other building. Developer 2 and 3 worked in an other city. The product owner worked also in an other city!
That was very bad! I figured out, that the comunication between me, and every member of dev team 3 was much more intensive. We used telphone, mail, chat – every day, every 10 minutes.
For me it was a new apporach of working. I can not say, that comunication with and between members of dev team 1 and dev team 2 was not so good. But theirefore, they worked togehter, it was just another approach of working.
Another thing I figured out was, that my mission as a tester had changed. For dev team 1 and dev team 2 I was a bug hunter! Year! There was no week I didn’t found any bugs and raised them in the defect management tool! And the guys from dev team 1 and dev team 2 where glad about it!
My mission was: „Find important bugs, before the customer finds them!“ I did it and it was a good testing mission for me.
But now I had to test for dev team 3. When I started testing, I wondered why so many problem defects from the customers have been raised and why so less internal defects have been raised!
I know it now. The product owner said one day in a telephone conference something like that: „Waiting! Waiting had profed to be successful!“
When I heard about that, I first time was shocked! Why should I test when these guys wants to wait, that the customer gets the problems and raise up the bugs? Definetely: My testing mission for dev team 3 was not to be the bug hunter! That was clear!
But I was courios about what the product owner had said. Why had waiting profed to be successfull? After a while I figured out: Dev team 3 implements solutions for 2 release streams, 5 countrys and round about 500 customers! I thought: „Hm, was that it?“ I thought further: „4 releases a year – shipping it out for every single customer! „Ok, seems, that this it was…“ And I thought further: Inherited areas: hard wired code (special deliveries for certain customers which pay very well! ughhh! a no go, but it’s reality!). 3 Developers from these days doesn’t have the time to resolve problems made 10 years before from other developers (inherited areas). I stopped thinking further. „That was the point!“
I changed my mind. Ok, I’m not the bug hunter for dev team 3! But I’m an important team member! I light the way! I do my testing work for dev team 3 and I find important and week points in the SUT! For dev team 1 and dev team 2 I would rise a bug in such situations! For dev team 3 I will talk with the team members about it! When they are agree, I will rise a defect – when not, then not! But ok, I can live with that. I’m not human beeing who fights for permissions to raise a bug! But all that is ok and I like to work as a tester for dev team 3. The only difference between working for dev team 1 or dev team 2 and dev team 3 is the following:
For dev team 1 and dev team 2 I’m a tester and my mission is: I’m a bug hunter!
For dev team 3 I’m a tester and my mission is: I’m the guy who lights the way! I know the week points of the product! I discuss about it with the team members and I help the product owner to make important decisions!
That was my experience so far. What experiences have you made as a tester?