Hi Selim,

I am so glad that you chose to continue this discussion with your
opinions. Although I do not agree with a lot of your opinions, but
that only gives us an opportunity to analyze our differences further.

By the way, please do not take some of my candid remarks personally :)


> Here I used "us" widely to represent BD (obviously some extra ordinary
> genius are not included here) not my team. Me and my team performed
> well, still doing well and client is highly satisfied so that still we
> are doing that project with some other projects for that client. I feel
> proud for all of team members.

It is encouraging to see that one after one, through discussions,
people are expressing their successes and how they outperformed others
internationally.


> I started my software development career as Trainee Programmer and
> continued upto Development Team Leader, it was taken less than 3 years.
> During these period I wrote some Test scripts to test my own code (using
> Perl, PHP, Shell script) and also sometimes given support to Testing
> team by reviewing their Test cases to ensure functionality coverage.
> Then Management proposed me to join in the QA department (actually this
> is mainly Testing department but known as QA) because that time QA
> department really needed some skill resources. I have taken this new
> challenge without any hesitation.

A little off topic. This is actually very typical of management. When
they perceive the testers to be lagging behind the programmers, they
choose to put a good programmer in charge. They did the same with me,
and within 5 months on the job I failed miserably. I was a good
programmer but I did not have the required testing skills then.
Hopefully, people see me a lot differently now :)


> By this way I started my journey in the QA and assigned in a project
> which was Media Converter for 3G mobile phones where tester was
> executing thousands of test cases manually for each build. It was
> ridiculous for me. I wrote a shell script which execute all these test
> cases automatically, log the execution results and generate summary
> reports from those results.

A little off topic. Do you think you had automated their testing? Can
sapient testing (I prefer this instead of writing manual testing) be
mapped to automation scripts? You did not automate their emotions that
plays a role when testing. You did not automate their attention to
related features or side effects not intended in their test ideas. You
did not automate their intelligence to come up with new test ideas
during execution of planned test ideas. You did not automate their
investigation. You may want to read the following quote from a
previous conversation I had with you almost a year back:

=========[Quote Starts]========
Ref: http://tech.groups.yahoo.com/group/sqa_bangladesh/message/948

As testers, we are investigators, much like those in books and movies.
We are told to investigate something whose complexities are least
understood, i.e. software. We are able to spot and analyze clues to
problems that are generally overlooked. We ask questions that were not
perceived by others. We expose the illusions about the software. Our
clients are fascinated by our reports.
=========[Quote Starts]========

These are fundamentals of sapient testing (manual testing), even if
you are running regression tests.


> Recently I was taken QA
> department responsibilities for few months as an acting QA Manager and
> top management wanted to continue with me. But I have personally
> communicated and informed them that still i am not fully prepared for
> that position and I have more interest on technical side rather than
> managerial tasks at this moment like people management, preparing
> appraisal for all department members, lot of managerial reporting,
> meetings etc. I believe I will get opportunities to do these managerial
> tasks in the future but once i engaged it will be taken me to the far
> away from the technical side.

I admire your honesty. Would you agree that there is a lot more to
testing than being technical?


> By the way of QA journey I lead two offshore testing projects, one from
> Finland and another from Japan. Me and my team got few opportunities to
> work with some potential international testers from Finland, Japan,
> India. I am confidently saying, our skill as a tester better than them
> (ofcourse we learned lot more thing from them). And they appreciate us
> without any hesitation.

Good job! You should have mentioned your great achievements in your last post :)


> As I mentioned earlier I have participated in a
> professional training on Software Testing in Pune where I have learned
> lot of new things undoubtedly, I discussed with several other
> participants to know their skill and knowledge level and tried to find
> out my gaps. I found only one gap, they are using some automated testing
> tools which are really very expensive. Whereas I am familiar with few
> free tools. But I have confidence enough, if I get opportunity to use
> those tools then I will do it efficiently.

There are so many automation tools out there, that I doubt any one can
get proficiency in all. I doubt that even they had experience with
some of the free automation tools you were using. I wouldn't call it a
"gap".


> This para may not acceptable by somebody, I passed ISEB/ISTQB foundation
> certificate on Software Testing exam by my own costs. In order to
> achieve this certification i studied a lot, given some effort and money
> but i never feel even not for a single moment that i wasted time and
> money. But i am looking forward for the next certification. I am truly
> speaking, if anybody ask me what benefit you get by this certification
> then i can easily say - it increases my confidence level, testing
> knowledge (not skill, everybody should try to increase his skill level
> by himself based on his knowledge) and what Nazmul Huda said "will get
> some HR attention" which may create some opportunities for my career and
> then this up to me how to make success any opportunity, it's required
> skill, effort, efficiency and lot more other things are related to a
> success.

Would you really want to work for a company whose HR will give you
attention for your certification, and will not consider you (or
consider you over a certified candidate) even if you just show your
experience as a tester? Do you really think they would value your
testing skills once you are hired? Because to them, you would probably
be just a commodity (i.e. just another certificate holder) :)


> But I agree with Michael Bolton what he said in a para in his "Why I am
> not yet certified" article that "Saddest of all, they noted that in
> Britain and in several countries on the continent, almost all businesses
> that are hiring testers require applicants for entry-level jobs to have
> the ISEB/ISTQB certification. I'm pretty certain that this will have
> several nasty effects. First, it is likely to discourage people from
> entering the testing field the way many of our best testers have
> done--by accident and opportunity. In turn, this will make the
> profession more insular and less diverse. In turn, this will prevent new
> ideas from reaching the craft. This is very bad". I am completely agree
> with him, any company shoudn't hire anyone like this way.

Well, if we keep encouraging certifications, this may even happen in
BD. The certifiers propaganda will be much louder and influential than
you, when it comes to who a company's HR listens to. Tahmid's account
gives an indication of just how bad it can get:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/1409


> Here I like to NOTICE, after getting any international certification, if
> anyone will feel i became something in the world, i have nothing more to
> do then "I AM STRONGLY SUGGESTED TO THOSE GUYS DON'T SPEND YOUR TIME AND
> MONEY FOR ANY CERTIFICATION, IT WILL BE HARMFUL FOR YOUR CAREER"

Thank you for saying that. But you see, they are not the only players
in the game. What about the message the certifiers preach, or the
opinions of HR?


> I read some questions posted by Shahriar and also read your comments
> against those. You commented on some QA and historical questions, i do
> not know more about CSQA and CSTE but i didn't find any historical
> questions in the ISEB/ISTQB syllabus.

So I guess you are implying that at least the tests by QAI are baseless :)


> In one questions A,B,C,D all
> options are correct where D is A and B (here you have to choose best
> one). You categories this as a silly question, i am thinking
> differently than you that this is not that much silly rather it is a
> tricky question. You will find many questions more tricky than this in
> the real exam which will make you confused to choose right answer but
> you have limited time to answering all these questions.

They don't give you any context. They don't describe in what scenario
does the questions apply. The only tricky part about the questions are
that you need to read their minds (or their so-called Body of
Knowledge) about the answers to the questions. You need to give me
examples, and you can be sure I will give you my detailed analysis on
your answer to the so-called tricky questions. :)


> For answering
> those need clear and proper understanding on those areas not bookish or
> ISEB definition, here I am emphasis on "NOT BOOKISH DEFINITION". This is
> something like, you have to do regression testing for a system within a
> day.

This is nothing like that. When you are asked to do regression testing
for a system within a day, you are very aware of the context. You know
the domain under test. You will give priority to certain tests that
you anticipate will reveal important problems, based on discussions
with the project team about the updates in the release. You will
choose not to run certain tests if you do not anticipate the risks to
be of significance. You will probably have created a checklist of some
minimal test areas you would want to consider, based on historical
failure cases you had encountered in past releases. This is just an
example of the kind of information you will probably have with you to
strategize how you will go about doing your testing in the 1 day
deadline. Nothing like this remotely compares to certification tests.


> To do this efficiently within given time, we should have priorities
> the test based on system's complex functional areas and those areas
> where likely to be found more bugs. According to ISEB "what need to be
> test first, what need to be test most and what not to be test".

Are you suggesting that these are rules, i.e. that these won't be
prioritized differently based on the context you are testing in?


> Everybody talking about foundation certification and based on this they
> decided certification is not that much useful for anyone's career. What
> about ISEB practitioner certificate on Test Analysis "or" Test
> Management. If any testing expert can manage this practitioner
> certificate i will SALUTE him. Very few Testing expert in the world is
> able to manage this certification.

Do you have any questions from this test for us to analyze? I would
like to learn more about this.


> You used an example in another post about a Bangladeshi initiator about
> ISTQB. I think, that is his lack of knowledge not over the world.
> Infact, at this moment i dinn't know any one of Bangladeshi organization
> who is able to manage accreditation of ISEB training provider. Only one
> ISEB accredited training provider for foundation level certification
> (not intermediate or practitioner) in the whole south Asia region which
> is Quest Solutions in India.

Ah ok. Lucky us that they didn't find there way into BD :)


> If you carefully read my comments, i used EXPLAIN not DEFINITION. I
> never expect any bookish definition from anyone, even i do not memorize
> any exact definition from any of renowned books. I just want to know
> what is his/her understanding level about his/her working area. I think,
> as a tester everybody should have some curiosity to learn about Testing
> and QA. When a tester fail to properly explain any basic things about
> Testing, i assume his learning curve is very poor. And i believe anybody
> will not able to do anything better without this learning curve.

Would you say, that you would prefer someone who can demonstrate his
testing skills over someone who can explain it? Also instead of asking
questions like, what do you understand by regression tests, you may
talk to them about their thesis or any pet projects they worked on or
a product from their last company. You can listen to their details
about the product and suggest a particular feature change, and ask
them what tests they would actually execute if they were to release it
within a certain time duration (you state the time). You can ask them
why they chose to execute certain tests, or why they ignored others.
This would be a more lively and engaging discussion, than asking them
to explain a terminology. That would be an interview to look forward
to, and you can bet that the candidate will be recommending others to
your company, even if he fails. I understand the interviewer needs to
be a really good tester to pull this off.

Do we really need to see if they have heard of or remembers
terminology jargons, especially when in testing, these are universally
interpreted differently by people from different schools of testing? I
would rather try to understand his learning habits, i.e. books,
articles, forums, discussions etc. to judge if he is really serious
about a career in testing. I know many testers who concentrate more on
improving their testing skills rather than studying testing jargons.
After all, we need to hire testers who can actually test.


> I don't always believe, a tester who can execute test cases potentially
> and find more bugs is a good tester, all these activities goes to the
> Dynamic testing but Static testing includes - review requirement
> specifications, documentations, design specifications, code etc. I know,
> most of the BD Testing/QA department are not mature enough to do Static
> testing, infect i do not know anyone of them. But experienced tester
> should have some curiosity to know what are the whole testing scopes,
> what are the basic techniques to do these.

Read my quote above on some other roles of a tester.

Do you really think, the explanations of Static and Dynamic testing
expresses the whole scope of testing an application? If someone knows
what is static and dynamic testing, will they know that they need to
ask questions about their product similar to the ones I was asking
Hasan and Tareq:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/1350
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/1365


> Here I like to mention if you
> have some tester in your team who has good development experience as
> well as testing experience is good for Static testing.

Now I am confused what you mean by Static testing. This is what I
meant about using jargons. We are both probably interpreting it
differently, although our definitions are probably similar. Here is
how wikipedia describes it:

==============[Quote Starts]===========
Ref: http://en.wikipedia.org/wiki/Static_testing

Static testing is a form of software testing where the software isn't
actually used. This is in contrast to dynamic testing. It is generally
not detailed testing, but checks mainly for the sanity of the code,
algorithm, or document. It is primarily syntax checking of the code or
and manually reading of the code or document to find errors. This type
of testing can be used by the developer who wrote the code, in
isolation. Code reviews, inspections and walkthroughs are also used.
==============[Quote Ends]===========

Does this sound something a tester would do, or something the
programming team would be doing at a regular basis?


> If i go back to
> the around one and half years back, one newbie was asking for suggestion
> in this group that "he has both the options development team and QA team
> to start his career, from where should start his career". I was
> suggested him "if you have interest and option to join in development
> team you should join the development team and then after 1 or 2 years if
> you feel interest in QA then you can switch to the QA dept. (i can not
> remember exactly what was the comment)". I was suggestion him based on
> my personal experience not from any book or anyone's comments or article
> because I was getting some benefit by this way. I was disappointed that
> time by you or someone else (i can not remember)

I was probably the cause of your disappointment :) I have a way of
doing that by expressing opinions that goes against traditional
beliefs :)

Let me remind you what I replied:

==============[Quote Starts]===========
Ref: http://tech.groups.yahoo.com/group/sqa_bangladesh/message/948

Tester do not need to come from a programming background, but having
that experience does help. More knowledge you have the better you can
investigate and preempt problems. So why stop at just learning
programming. Why not database development, server administration,
technical writing, people management, project management,
investigative skills of a detective or doctor, experimenting skills of
a chemist, human psychology, customer support, business analyst, law.
I can think of many activities of a tester where all these and many
more skills are extremely handy. If you can't relate to any of the
mentioned skill with testing then I will elaborate.
==============[Quote Ends]===========

Now get ready to be disappointed further :) Testers don't even need to
come from Computer Science. But sure, Computer Science helps :)


> If i ask an interview question "What makes a good test engineer?",
> answer will be something like this -
> "Should have "test to break" attitude, takes the point of view of the
> customer, should have strong desire for quality, tactful and diplomatic,
> good communication skill both oral and written, previous software
> development experience and lot more other things."
> I know, for the above given answer's many testing experts will argue
> with me about "previous software development experience". But still i
> believe and realizing myself this is really good for a tester (NOT
> MANDATORY) because it will help a tester to use automated testing tools,
> to do static testing efficiently, to visualize internal structure of a
> module, to realize what kind of mistake a developer can do during coding
> etc.

I suppose that could be a skill you would want in a project similar to
the one Tareq described:
http://tech.groups.yahoo.com/group/sqa_bangladesh/message/1358

But, of course you knew I wouldn't agree with you in general, since
you did not provide any context like I just did.

You seem to put a lot of stress on automation. Are you aware of the
automation pitfalls?

In any case, a lot of the automation tools nowadays are becoming
non-programmer friendly. For example, JMeter allows you to write very
complex load testing scripts without writing a single line of code.
Selenium IDE allows you to write automation scripts in a tabular
structure with very simple HTML (whose complexities can also be
hidden). Also, I wouldn't think so narrowly about test automation
tools. How about tools like generating test data with "Perlclip", or
building multibyte character strings with "Windows Charmap", or
checking windows registry updates with "Regmon", or monitoring
processes with "ProcessMonitor", or monitoring TCP/IP sockets with
"TCPView", or HTML validators, debug proxys for tampering HTTP
requests etc. I mean any tool that assists in testing.

I understand that you may need programming experience for writing
shell scripts or creating your own tools. But I don't see all testers
needing programming skills for that. I implemented a concept that
James Bach refers to as Test Toolsmiths:
http://www.satisfice.com/presentations/agileauto.pdf

Also, do you really need to be programmers to "visualize internal
structure of a module"? I mean you can do that without code reviews,
i.e. with high level diagrams. Of course it all depends on the
complexity of the project, but generalizing it may not be a good idea.


> About use of Cyclomatic complexity for testing, what we get from
> cyclomatic complexity metric? we can measure structural complexity of a
> procedure or module. If we use a tool for generating cyclomatic
> complexity metric for a given procedure or module then we can easily
> identify which module or procedure has more complex code (to do this
> source code of the system is required or cooperation from development
> team). That will help us to prioritize test, especially for regression
> testing. I am frankly talking still i am not able to use this metric in
> my own test but i am searching for a suitable tool (free) to do this
> efficiently and effectively.

Thank you for admitting that you do not use it. These actually look
pretty good in university thesis papers or in the un-practioner's
approach book, "Software Engineering: A Practitioner's Approach by
Roger S. Pressman". Just a joke to loosen things up :)


Regards,
Sajjadul Hakim
http://rapidtester.blogspot.com/