Fake Testers or Unskilled Testers?

Sajjadul Hakim’s recent post Masters of Illusion - Fake Testers (part 1) has mentioned some important attributes of a Tester or Test Manager and categorize those testers as ‘fake testers’ who don't have such attributes available. A wonderful post, I really enjoyed reading that post. In the follow up comment Monirul Islam asked couple of important questions, part of comments are “…..Is it something like that when a tester is identified as a fake tester she is completely valueless to her company? Should the company terminate her as soon as possible like we do in the case of fake money?”. His comments make me think about the fact and by this post i’m trying to answer his questions. Before reading further of this post you may interested to read original post and comments from here: Masters of Illusion - Fake Testers (part 1)

@Monirul, you have asked important questions where you indicated to all testers, not only test managers, and that should be because this is a generic problem in BD but not for the test managers only. Here I like to share my thoughts based on my own experiences and ofcourse considering BD context (may not same in other countries):

• There are very few testers in BD with the mentioned attributes (especially demonstration skill) but it doesn't mean that we don't have enough skill testers or potential testers. In BD, there are many good and potential testers but their demonstration and communication skill is not good enough hence feel shy to demonstrate on publicly.

• Reasons for the above are, many BD testers didn't get proper guideline/instruction from Seniors/Team Leads/Managers. Also BD testers got hardly any training on testing (corporate or public).

• Considering the above, i'm not interested to call them as 'fake testers' rather i would like to call them as 'unskilled testers' or 'incomplete testers' or even 'uneducated testers' whereas many of them are potential enough.

So, my answer to the both questions is, NO. Those testers are not valueless to the company instead they can be valuable to the company and apparently they should not be terminated rather they need to be guided properly, trained up by expert (not only by his/her so called Test Manager cause there's very few Managers in BD who have such skill, also many Test Managers required such training and guidance by the expert). So, public workshops/trainings are very much demanded in BD context.

According to my understanding and practices (many of you may have some other ideas or practices), BD testers also need to do the following to increase knowledge and skill:

• Do testing as much as possible even after becoming Team Leader or Manager.

• Learn and think about testing & test ideas.

• Participate on Weekend Testing (also mentioned on the original post of Sajjadul Hakim)

• Join on uTest and participate on uTest test cycles as much as possible which will help to increase testing skill, communication skill, to build network with testers around the Globe and in addition you will earn money for your each approved bug and test cases. Don't forget to participate on uTest forum discussion to know more.

• Follow famous testing blogs regularly and also read some previous posts of them as your interest (some famous testing blogs are listed in this blog)

• Participate and/or read online discussion regularly on the several testing forums.

Dear readers, please share your experiences and practices which definitely will be helpful for BD testers.

Enjoy testing, enjoy learning!!

------

How important to write test cases?

What i meant by test case?

First of all i should clear-up what mean to me as test cases. For me, test cases are list of test ideas by which test ideas can be listed as bullet order, row wise or any other format convenient to me for particular project or client. It also required to add tips or guideline for those test ideas which i think other can face difficulties to understand my test idea such as (but all are optional):

• Required test data to execute the test if my test have required any specific data.
  
• Environment related information if my test required to make any specific changes on the test environment.
• Steps to execute the test if there have any complicated step to execute the test.
• Also need to add tips for any special thing to follow while executing.

Be sure, here i'm not talking to add any straight-forward tips/guideline on test case for the testers, just want to add those thing which i feel un-usual to understand my test ideas.


Why required such test cases?
I know, many of the intelligent testers, test experts, consultants, will argue with me - why you required such test cases? Are you want to feed your testers? You should teach your testers - how to test, how to explore, how to use heuristics, how to use oracle, blah...blah...blah. Here i completely agree that i should teach my testers. And also i use those test cases to teach my testers, here might have another question....How?
Here i like to share my experience and context but others might have different context (i don't know). I have some well experienced intelligent testers, some are minimum experienced (less than 1~2 years) but promising, some are cub newbies and some are even fresher in my team. I never can expect i will get all the well experienced testers in my team (that will exceed my company budget!). So, what will happen when i assign to test a particular feature to an experienced/expert tester, suppose (s)he will generate 20 test ideas to test that feature. What if, i assign same feature to test to a cub newbies or even to a minimum experienced tester, will (s)he able to generate all the 20 test ideas which can generate by an expert tester? even-though, they are intelligent enough and i teach them how to test, how to explore.........often not possible because an experience tester learn/know more test ideas by his/her experience and those ideas may not be able to generate by an inexperienced testers, even though (s)he is promising and intelligent enough. So, finally what will happen if i assign to test a feature to cub newbies? (s)he can miss some important test to execute, by which some significant issues can be uncovered on that feature. Here test cases which contained listed test ideas will guide them for proper testing, help them to know several test ideas....and so on.

What more to do with test case?
Motivate testers to think beyond the test cases and to generate more test ideas while executing and list-out those test ideas by which it can be possible to know particular tester's thoughts, intelligence, exploring capabilities...and so on. Here another thing is related to my organization but may not in other organization, there are many clients want to see the test cases to ensure test coverages, which is valid and better than blindly trust to the test team and i think it somehow reduces some risk in some degree according to my context.

Readers, i like to know your point of view and experiences in this regard to clear-up my understanding and to remove misconceptions if i have any!

Enjoy testing! enjoy learning!
-----

(!) NOTE: There are few small updates made on the original post (mostly changed the choice of words for proper interpretation).

Comments are worthy for any blog post

Any blog post got a proper shape with the comments on it. Without comments a blog post can turn to dead-metaphor. To be sure, all the great blogger valued their blog reader who occasionally and/or regularly put comments (i.e. reader's view on the subject matter) on the blog posts.

Recently I had commented on Michael Bolton's blog post "Testers: Get Out of the Quality Assurance Business" but was not published and sent a mail to me "Hi Selim...It's not that I haven't published your comments because they're bad. I haven't published them because they're so good, and they're worthy of a thoughtful reply. I haven't done that yet, but I will. Cheers,---Michael B".
---I was surprised how a great blogger gave importance to his ordinary blog reader and also gave importance to any comment on his post.

After couple of days Michael Bolton posted a separate post to answer my question in response to my comment starting with the kind words like “Here’s a case where a comment and question were worthy of a post of their own”. Here is the link of that post http://www.developsense.com/blog/2010/06/doing-development-work-vs-doing-quality-assurance/

What a great effort done by a great mentor in the field of testing for an unknown tester!!

Also i should appreciate blogger like Pradeep Soundararajan, always i got quick response from him whenever i put any comment to his blog post or send any mail to him or for any instant messages.

What I conceived, commenting/questioning is the most beneficial way to eliminate misunderstanding/misconception and also it is a easy manner for stating my thoughts to get expert opinion against my thoughts. I believe, if my comment/question is not that much worst then it will be responded by author or even from other readers which will assist me to assess my thoughts. In one response Michael Bolton said “responding to comments is a reward in itself”, which is true indeed.

What i'm trying by this post, is to inspire Bangladeshi testers (who are silent) to read famous testing blogs and start commenting/questioning based on your own thinking and understanding, even start own blog. By this way Bangladeshi testers can be known to the world of testing community.

Enjoy Blogging! Commenting! Questioning!

Lessons learnt on WT-34

Session detail:
Bangalore Weekend Testing session WT-34
Date : Saturday, 8 May 2010
Time: 3:00pm to 5:00pm IST GMT+5:30

Mission:
Rate the website www.printme.com

Overview:
Rate the website www.printme.com on a scale of 1-5 on the following parameters.
1) First Impression
2) Navigation
3) Content
4) Attractors
5) Findability
6) User Satisfaction

You may check http://www.mcil.co.uk/review/7-10-criteria.htm for detailed information on what these parameters include.

Score each website issue out of 5, where 0 is not applicable at all, 1 is extremely poorly represented and 5 is extremely well represented. The issues with an asterix are generally considered to be detrimental to most websites and thus if they are applicable to the sites you are reviewing you might decide to allocate a negative score where -1 acknowledges that the feature is a minor distraction/irritant and -5 indicates a major distraction/irritant.

Lessons learnt:

At the beginning of the mission, I didn't open the url which I have to test or rate (i was obviously wrong). First, I go through the mcil page to know all the criteria for the parameters because some parameters were not clear to me (i.e. Attractors, Findability). Hence, i have spent some time on reading those criteria which made me more understandable about the mission, and soon realized i have less time to test. So, having quick review of the site, I have rated the site for the each of the given parameters and submit. Richard asked me a obvious question “Its the first challenges isn't it Selim - when you get access to a system and documentation, where do u start”? And I answered honestly that, i was thinking it would be good if i start from documentation for better understand about the mission but later i realized i should have a quick look on the site first. Richard gave his comment about what approach he suggest for the same, "Personally - If I have access to the system, I will go there first, play with it, and learn about it by doing. Then go back and forth between docs/instructions and the system. When I 'feel' confident, I will start testing."

One important comment from Richard about the mission was “The thing I realised was that the exercise at today's WT was all about how you approach the problem, not the problem, not the solution. Its all about being aware and working out I had choices. My challenge was to work out how I would know what choice to take - by reviewing the instructions, asking questions, and trying things.”

Time pressure always a trap for the testers. Hence, Markus Gärtner gave an interesting comment like, “time is not an obstacle, time pressure is a symptom of a trap”.

One of the participant's opinion about the session was "Guys it was overall a good show, this session was very interesting and was able to learn new things from testing knowledgeable persons like Richard and Markus". This is true indeed.

Enjoy Weekend Testing!

Fun way to learn on Weekend Testing

Many of you already know about Weekend Testing community
http://weekendtesting.com/
A group of dedicated testers whose vision is to learn and improve the
craft. This is a fun way to learn to test any software. Any tester can
join on any weekend testing session from anywhere through Skype subject
to prior registration. Nowadays, testers are participating on weekend
testing from all over the world and there are several Weekend Testing
chapter (Bangalore, Europe, Newzealand-Australia, Mumbai, etc.). You can
know more about Weekend Testing from here http://weekendtesting.com/about-us

Enjoy Weekend Testing!

Sum-up the learnings of Scenario Testing

Scenario Testing is one of the most important testing activity of a software testers, both functional and non-functional testers. I have tried to summarize the learnings of Scenario Testing based on BBST course http://www.testingeducation.org/BBST/ScenarioTesting.html and some other read.

About Scenario Testing

Scenario test involves a story about how the program is used, including information about the motivations of the people involved.

Scenario tests are realistic, credible and motivating to stakeholders, challenging for the program and easy to evaluate for the tester. Scenario test provide meaningful combinations of functions and variables rather than the more artificial combinations you get with domain testing or combination test design.

To perform Scenario Testing we have to imagine a real world situation, which involves a complex use of the Application. In scenario testing, we create a hypothetical situation the program could be run through, and then we run through it ourselves based on that situation. This helps us to evaluate the program's real-world adaptability, as well as help us to test many functions that are not frequently used or tested (or simply aren't tested thoroughly enough).

A well-designed scenario has five additional characteristics:

• The test is based on a story about how the program is used, including information about the motivations of the people involved.
• The story is motivating. A stakeholder with influence would push to fix a program that failed this test.
• The story is credible. It not only could happen in the real world; stakeholders would believe that something like it probably will happen.
• The story involves a complex use of the program or a complex environment or a complex set of data.
• The test results are easy to evaluate. This is valuable for all tests, but is especially important for scenarios because they are complex.
  

Designing Scenario Tests

Designing scenario tests is much like doing a requirements analysis, but is not requirements analysis. They rely on similar information but use it differently:

• In designing scenario tests, a tester doesn't have to reach conclusions or make recommendations about how the product should work. The task of a tester is simply to expose credible concerns to the stakeholders. In addition, the scenario tester's work need not be exhaustive, just useful.
• The tester doesn’t have to respect prior agreements. (Caution: testers who belabor the wrong issues lose credibility.)
• In designing scenarios, think of the states that the application can be in, via various actions by a given user. For example, on shopping website, you can design a scenario based on a series of actions that leads to selecting a particular grocery, putting it in a shopping basket, giving credit card information, and authorizing the purchase. You could try a valid credit card number and then various types of invalid credit card numbers. Those are the actions that you want to simulate in your testing.
• Scenarios should be real life examples of system use.
  

The actions and the state are the conditions that you are seeking to validate with the test case. Conditions can be considered things like valid actions, invalid actions, pass actions, and fail actions.

Useful benefit of Scenario Testing

• Scenario testing is used to create large test cases that model real use of the application by covering multiple requirements. These tests are used to find bugs in the system, learn the product, and find requirements problems.
• Scenario testing helped us to focus on a user situation that was motivating and realistic.
• Scenario testing is an excellent way to perform in-depth tests with many of a program's features all at once and evaluate how well they work together.
• Scenario testing helps a tester place themselves into the position of the user, a task that is often very difficult. By working through a scenario test, a tester has certain conditions that help keep them more aware of certain ways a program acts.
• Scenario testing allowed us to view the program through a different mindset, one through which many of the customers might also be viewing the program. By scenario testing, we have a much better chance of understanding how customers will feel using the program and how we can help make it easier to use the program.
  

Summary

• A scenario test is a story that describes a hypothetical situation by simulating a real-life use of the application under test.
• A scenario test should be designed to expose credible concerns to the stakeholder about the application under test.
• In designing good scenario tests, you should consider the actions and states of the application that you are seeking to validate.
• Scenario Testing are not designed for early testing. Other approaches are better for testing unstable code in early.
  

Hope this post will helpful to you. Enjoy Testing!