Experience in Netherlands - as a Test Engineer

Its been more than two year since I am in Netherlands, working for a company named CIMSOLUTIONS as a QA Test Engineer. I was offered to work in here, and my passion to meet the "NEW" helped me to make my decision.

Two year is not a very long time to have a deep understanding and learning about something, but again long enough to have a good overview. Like I cant speak dutch in a very good level, but I can call for a decent small talk :). And it same goes with my experience in Software Industry here in Netherlands and how the trends and systems going around.

My first and yet impression about Netherlands is - its a very organized, clean and a beautiful country. But my impression regarding Software Testing Industry is not so high, and one of the biggest reason is trend of "CERTIFICATION".

When I was giving interview for this position from Dhaka, Bangladesh - I was asked whether I have any certification in Testing (some of the traditional ones  - not going to mention the names) or not. I was surprised to hear those names, coz back days some of the organizations tried to bring those in Bangladesh but couldn't succeed much due to SQABD. And also from our (me and along with members in SQABD) testing experience we already knew how far those certifications curriculum are lacking behind. There are enough writings in internet from very good Testers and Test Mentors (including few recent dutch guys too) why those certifications are not a good way to create a tester, and how those are backdated. But point is even after explaining those in the interview I was told that "Clients" want to see those certifications, and my curious mind started to wonder "WHY?"

But when I got here in Netherlands, and started working for the clients of CIM, and also started looking here and there to see how is the job market here, I got my answer of "WHY?". When I look at the client requests for a Test Engineer, or even the job advertisements over internet, I can hardly find any company who wants a Test Engineer with a resume/CV without mentioning those "CERTIFICATIONS" as their primary criteria. And eventually I even had to do two of those common Test Engineer certification later (and I am really not happy about it) to fulfill client's need (though the client now I am working for - they didn't ask for it, but I had intakes for some clients where the specifically mentioned it).

Its getting long though I have lot to write. But I am going to finish it up with a very recent experience that I had.

For the client I work now, I was the only Test Engineer working in the center of different development teams driven by Agile Scrum. My work pressure went too high when both app (iOS & Android) and Portal was at their final stage. So they recruited another Test Engineer to help me out (he is not from CIM). He eventually higher level than me and has a huge number of "CERTIFICATIONS" done. Right after joining, he started finding bug in the every working process, rather finding bug in the product. And later we came to know, he doesn't even know some basic SDLC structures such as bug flow & tracking system, system testing concept etc, and let alone very basic understanding of Scrum. Yet he was giving a lot arguments with everyone about all the faults (he thinks!) in our working process. And one day - he drew the historical "V MODEL" - and the very basic one ( infact this basic one is the base model for one of the very common Testing Certifications here - and still it is!) on the board to show us how the testing should be along with progress of SDLC! Before others seeing it - I asked him why the model he drew doesnt have any transitional phase? Is transitional phase not needed to be covered in SDLC? Then I asked him about RUP, he dragged me to the "Water Fall" :(.

One of problem of mine is when I do discussions verbally I forget to mention all the things. Else I could just give him the following link, which would eventually save me some times :)

The Death of the V-Model

BTW, apart from him, there are Test Engineers in NL I worked with in other project who are good, and they were not happy about those certifications either.

Thank you :)

Protect the room from entering the bugs rather killing too many inside it!

Protecting from Bugs, in real life case, its kinda impossible. Bug is inevitable. If someone says, we dont have any bug in our product, then I would say - You must be joking. From functional to atleast cosmetic issue, you cant avoid them. Then why I wrote protecting? Its just a scenario I would like to share that I face most frequently.

Finding too many bugs after a fix is done or feature is implemented and re-fixing those and these goes on and on, dont you find its too costly? It doesnt make you a great tester as you are rich in bug finding on a scenario like this. Then you may ask, where else you can find a bug when its not at your hand to look through!

A while back, a client requirement came up for a very small feature - We need to add "Term of Services" for the end users. Its the same thing as we see while registering for a forum or mail like Yahoo or MSN - some terms of service and "I Accept" or "I Decline". Very simple one indeed. So what a developer could do, is to add this small fix and ask a tester whether this is working or not in registration feature. But -

In our process we maintain specs (Yes, this is time consuming) and we do go several discussions (what we call meetings for the project) over the spec before finalizing it. But it doesnt say it needs to be point to point detailed but fair enough to cover the feature. And spec is also in our client requirements list, they want to see it too. So when in the discussion it was claimed to be the simplest fix with a small modification in spec, there my testers came up

- Have you considered registered users who are already using the system?
- Have you considered the users who use desktop clients or add-ins?
- What about those different types of non-registered users who can use a limited number of features without getting registered?
and more (dont want to mention as those wont be very understandable for all). And came out, this is not the small fix as it was thought to be.

I think you have already got my points, what I wanted to say in my subject (or title). You cant stop it from getting it in the feature while its avialble for test, but you can minimize it.

Thank you.

Long time .....

Whew ... A long break.. well rather saying a break, I should say a new start. Its been more than 2 years since I posted my last writing, where I started to discuss about Process Maturity (in perspective of Bangladesh Software Industry). And yes, as I said in my 1st post, I’m just trying to share my views and that is all. My experience in software industry is not much but from some point of view some of may agree with me.

When I started writing this blog, I was in Metatude Asia Limited (A familiar name in BD Industry!). And then I switched to Nilavo Technologies Limited, and there I took this long break. But I wish to continue now, hope I will. And I will try to share my learnings from both of these companies, interesting or uninteresting scenarios, while also keeping the focus for Process Maturity.

I remember, I placed a question in my last writing "Why processes are needed to be established in Software Development?" ... yes I remember this. And I will put my answer for this question later and before that lets some expierences :) ..

When I joined in Metatude, I found that it used to a process oriented development house, but in Nilavo, they used to think formal processes only exist in book or not possible in Nilavo. But from that position to Nilavo in today, where an established QA team is working (where they used to know a blackbox tester is enough) and the whole development team maintaining a regular process and boosted successive outputs, yes for sure that was hell of a challanging task. And thanx to my colleagues, my teammates and My Boss (Our CTO). Without their help , co-operation and acceptable attitude it was not possible.

And while sharing experience, I think I should start from Metatude, coz I have found a lot learning areas (both good and bad) and I think those are not too uncommon for those companies those are process oriented for long time. And I think should start my writings about Metatude experience from tomorrow, coz as its getting bigger more its getting painful for readers to read :).

Thank you.

I have started to write this Blog from my little experience over Software Industries in Bangladesh. I got two comments in my previous post from two experienced people. And I guess they are right from their perspective. Yes you are right when you are saying:

“To me the most important decision for a successful project is to choose right people at right time. Once you have a competent workforce, they should come up with what is best suited for them.”

This is right not only for SW development but also for all kinds of industries. But I don’t know Vaia whether you read the mails about ‘Lack of Quality People in IT Industry’ which was been discussed in SQABD few months ago.

Ok, let’s share some stories that I heard from one of my senior colleague. When he was in his previous company he used to take interviews to recruit new QA persons in that company. One of his most frequently asked question was: Why you want to join in QA? Mostly in reply he got answers like: “I need a job”, “I don’t know (or not good at) programming”, “Well I saw the advertisement and …….”, “It has a better offer (money)”, “Big company”, “Testing is easier than coding” bla bla bla… I guess these do mean something!

Well you can’t ignore these unless you change the view of QA and that must show the difference with Testers. QA’s task only to ensure the Quality of the Product but also to ensure the Quality of the Process (am I wrong?). I don’t know whether you met or not but I did, to whom Process is totally a new thing when they heard Process and even they question me back – ‘what is that?’ But I guess these should be in your considerations whenever you are thinking in perspective of Bangladesh but there should be a certain limit.

Well... well … I was in Process Maturity and now I’m with the recruitment, sorry. But recruitment should also be included in your process, in resource management plan. It should be defined in your process how much of the development gets delayed when you are in shortage of human resource (when someone from the team leaves the company) thus your success rate remains in a consistent state and you are not blamed from your management as they are getting as the process has been defined. And also recruitment time, quality, training these things also – so to get whatever is expected and process doesn’t get blamed and neither you.

Now one more scenario (also heard from my seniors): one big company (in Bangladesh) established a process and it took a long time established the process and hard labor of Process Engineering team. But the first product after the process establishment failed to get the market. This also means something.

Now I have one question (I have my answers but it will be better to have some views from others) – Why processes are needed to be established in Software Development?

Process Maturity in perspective of Bangladesh

Well I don’t know whether I have the proper knowledge to write about it or not. I’m just trying to share my views and that is all. My experience in software industry is not much but from some point of view some of may agree with me. I’m trying to focus some point from my R&D and knowledge-base.

To develop software every software development company needs a process. This process may be defined in bookish language or undefined (customized). Thing is that you need at least a process to develop it. Big (and few middle) size companies most follow structured (defined or customized) processes. But what about the other companies (small size and rest of the middle size companies)? And specially when you are talking in perspective of Bangladesh. I guess most of IT people in Bangladesh know about the local software market and what is condition of current IT industry in Bangladesh. Though it is better than it was before but still we are far behind from where we should be.

Small or most middle size companies which still starving for resources (both human and technology) are failing to meet the deadline and a quality delivery most time. Yet they maintain a process – their own process. How much matured their process is? – BIG QUESTION!

Now talking about Big and few middle size companies where structured processes are maintained. It may be few but not rare that some of these companies are also failing to meet deadline for a quality delivery. Less quality product delivered within time – I’m not counting those for these companies. So the process maturity is still a big question for these companies.

Now come to the Process Maturity Framework that we have around us. You can say – Follow CMM (I don’t know any other Maturity Framework exists or not). But then you have to think – how many companies can afford CMM (considering time and resource)? You can’t say all the companies which are not assessed for CMM (or follow CMM) don’t have a matured process to produce a quality product in time.

------------- To be continued …----------------------------