Database testing example

A vast majority of business applications store and retrieve data. Many applications use databases for this purpose, owing to a variety of reasons such as a standard and methodical way of storing information, performance and security. In addition to testing the application software, we should also be testing the database. You can avoid a number of bugs if the database schema used by your application is created correctly. What is more, a correct database schema prevents having to implement a complex logic in your application to handle the different scenarios that can lead to data problems, and consequently application bugs affecting its users. First, view my video, Database testing and SQL tutorial for beginners.

Second, view my video, SQL Queries Tutorial. Now, work with another example below.

Now let us look at a simple database that may be used by a school to store its student information. Since the number of rows and columns is small, we can inspect the data and look for problems manually. Of course, when testing tables with a large number of rows, you need to design and execute SQL queries, but let us not worry about that right now. The intention is to look for database issues, both existing and potential.

Here are the problems with this database:

1. Missing tables

One can see that the Grades (Classes) exist just as a column in the Students table. Grades are really a different entity. This school may have a Grade 3 even if there were no students enrolled in it yet. And this is not apparent from the current data. There should be another table for Grades and each row in the Students table should point to the corresponding Grade via a foreign key.

2. Missing or incorrectly named columns

The Fees table has an ID column. But what ID is this? Is it the Fees ID or the Student ID? If it is the Fees ID, then there is no linkage between the Students and Fees table. If it is the Student ID, it should be named as such to avoid confusion for the developers.

3. ID columns

The Students ID column is has a text datatype. This means that every query reading this column will have to parse the value to rid the leading zero or zeroes. A more severe problem is that text based indexes are slower than numeric indexes leading to slower performance.

4. Dates

One cannot make out the date format from the Date of Joining column values. It could be mm/dd/yyyy or dd/mm/yyyy. This means that every query on the Date of Joining column has to know the date format before it can parse and process the value.

These are not the only problems with the data presented. There are more. Can you spot them?

I hope that this analysis would have piqued your interest in database testing and you would show this interest in your own software testing.

How to write a resume that is selected?

If you are looking to change your job in software testing, the first challenge facing you is to write an effective resume. That is, a resume that would get short-listed. In this post, I will share with you tips that will increase your resume's success rate. I have divided these tips among three sections - Preparation, Execution and Post-Execution.

Preparation

Going by the number and frequency of new job postings on popular job sites, you may have too many choices. However, you should not start chasing all. There isn't enough time to do so. You need to realize that the recruitment activity is a process with the following steps. The next step is taken only if the prior step is successful.

a. Sharing details of the job and the candidate

b. Review of these details

c. Interview

d. Verification and decision-making

e. Joining

Take the time to visualize your ideal job. Use the following questions to clarify your thoughts and be as realistic as you can.

a. What role would you like to play?

b. What kind of organization (small or large, product-based or service-based or hybrid, conservative or modern and so on) would you like to work with?

c. What location(s) would you prefer?

d. What kind of salary you would like to draw?

e. What working conditions (shifts/ hours, organization culture, benefits and working culture) do you prefer?

Once you have a good handle on the kind of job you would like to have, it is time to move to Execution.

Execution

By Execution, I mean the actual task of writing the resume that would be selected. Let us say that you have come to know about a job vacancy that is similar to the job that you are looking (see the Preparation phase above). Now, you should take the following steps:

a. If the job posting is in writing, read it carefully. If you received a call, jot down notes from that call. Note down each keywords in the job posting. Keywords are the essence of the job posting. For example, if you are looking to be a Software Test Engineer, the job post may contain keywords like "Test Plan", "Bug Reports", "QC processes" and so on.

b. The next step is to gather more information about this job. There are several ways to do this.

  1. Browse the organization's website. If you read the relevant sections, you will have a better idea of the work they do and the vocabulary they use. Add more keywords to your existing list.

  2. If you know someone working in the organization, give him or her a call.

  3. Talk to the poster. They may just highlight the main points of the profile they are looking or provide extra information. Let the poster know that you are interested in the job and would be sending them your resume.

c. By now, you should have a very good idea of the job. It is time to go through your list of keywords and ensure that the keywords applicable to you are included in your generic resume. Adding a keyword once may not be sufficient. For example, if "Automated Testing" is a keyword and you have experience in automated testing, you may include it in the following ways:

  1. In the summary section, mention Performed Automated Testing in XYZ project

  2. In the Tools section, include the automated testing tools e.g. QTP, WinRunner that you worked with

  3. In the project responsibilities in XYZ project, mention Created automated test scripts

d. Review the major sections of your resume and ensure that they are structured. The Summary section, the Organization/ Projects section and Qualification sections should be clearly separated. Follow a uniform order within each section e.g. list the organizations you have worked with in reverse chronological order and do the same for your qualifications.

e. Make sure that your resume is current. If should include your latest organization/ projects.

f. Ensure that you have provided all relevant information within each section. For example, if the job posting mentions Bachelor's degree in Engineering as a requirement, you may want to include details like College/ University/Year of Passing/ Grade if you are comfortable and it is legally acceptable to share this information.

g. If your resume does not already mention your achievements (awards/ recommendations/ recognition) during work or college, ensure that it does so now.

h. Review the job posting and your list of keywords again and read your resume. Expand the relevant phrases and sentences. Do not highlight the keywords by making them bold (this looks desperate). Reduce or summarize the non-relevant phrases and sentences.

i. After final review of your resume, you should be ready to send it to the job poster.

Post-Execution

If you get the call to schedule an interview, congratulations. If not, wait for 2 or 3 business days and call the job poster. Maybe they received too many resumes and did not go through your resume (carefully). You should the reasons due to which you are suitable for this job. Use your list of keywords to your advantage. Follow up is very useful in securing an interview if your resume is not selected automatically. If your resume is not selected even after follow-up, it is likely due to some information not shared in the job posting e.g. the organization wanted only candidates experienced in a particular industry domain. Ensure that you ask questions to unearth such information in future.

If you have made the effort to understand the job well, presented your resume in line with the organization's expectations and/or followed-up, chances are high that your resume would get short-listed and you would get a call to schedule an interview. The next challenge is to be selected in the interview. Watch this space for tips on that topic.

Planning and execution problem solved

I like doings my testing tasks really well. In fact, I prefer not starting a task to doing it in a sloppy way. Now, this created a problem whenever I was working on a project. There were many tasks to perform every day. In the past, it used to take a lot out of me in taking the actions related to my task. First, I used to understand the task and then estimate its priority (to schedule it accordingly). Then, I planned the approach to perform my task and identified each sub-task that required to be done. I performed each sub-task and tracked my progress frequently. After completing each sub-task, I reviewed it. Then, I reviewed the entire original task first with respect to each sub-task and then with respect to the original objectives. Finally, I communicated my task completion to the relevant people.

Why did I end up expending a huge mental and physical effort in performing each task? Other than my desire to really shine at the task, I found that I repeated a lot of planning that I had done in the past on similar tasks. Attempting to excel at my task is welcome. It gives me the satisfaction that I am not doing the task mechanically. However, re-thinking everything is definitely overkill. Not required in a majority of tasks. Definitely not desirable in every iteration of the task.

I needed to solve this problem. That is, I had to balance my wish to do really well with my need for speedy execution. Here is how I created my solution to this problem. First, I identified a couple of non-trivial tasks that I had to repeat. In my case, I selected 1) Review of test cases and 2) Creation of the monthly test results. Later on, I realized that this solution can be applied to any other repeated non-trivial tasks such as 1) Design test cases, 2) Execute test cases and 3) Log bug reports. Second, I made available to myself an ample time slot when I would work on nothing else but this selected task. Third, I started working on the task. But there was an important difference to the prior executions this time. I documented my approach making notes as I went along the task. For example, starting the test cases review, I listed each item that I had to plan e.g.Whether to do a high-level or detailed review or a hybrid review, Sequence in which to review the test cases, Level of detail in my review comments. While actually performing the reviews, I listed each sub-task as I remembered it e.g. Check if each requirement in scope of the test case is covered, Check if each design is covered in the test case, Check if there is an incompleteness in steps or expected results or test data, Check for duplicity within a test case or among two or more test cases.

Finally, I ended up with a nice long list of sub-tasks (with comments) that I needed to perform to do justice to my original task. Some sub-tasks were linked to the understanding of the task, some to the planning, several to the execution and the others to the own review. Now, every time I faced this task, I did not go about it in my earlier way. I got my list out, looked at the list of sub-tasks and started executing them. Whenever I remembered a missing sub-task, I just inserted it in the appropriate place in the list. This practical list was really my own task execution procedure.

How does this help you? If you are like me and want to perform due diligence on your important tasks, your own procedure will help you do just that. You will no longer need to rely on your memory alone. The second benefit is that it will reduce the planning effort required. You will just look at each sub-task in your procedure, decide if it is relevant to the current situation and if so, perform it. The third benefit is that your procedure will keep you focused and on track. If you enhance your procedure with every iteration of your task, you get the fourth benefit, which is improving execution ability. You will get the fifth benefit when you share your procedure with your team members. Your team members will improve their execution ability by benefitting from your procedure. In turn, they are likely to give you feedback that will help you enhance your procedure even more. Your procedure will also be a good means to transfer execution knowledge to new team members.

If you are excited about creating your own procedures in order to excel at tasks, you should take a few pre-cautions:

1. Do not get over-ambitious and try to create procedures for every task that you perform. If you do, your work will slow down to a crawl and you may be overwhelmed quickly.

2. Choose to write the procedures for only regular AND non-trivial tasks. Do not spend hours writing a procedure for a task that you will perform once in six months (and the project situation may be quite different at that time). Do not write a procedure with obvious steps e.g. you know that you have to fill up each relevant field in the bug report form before you submit a bug report.

3. Once you have a procedure ready, do not delete a sub-task even if you find that it is not required in the current task iteration. This sub-task may very well turn out to be important in a subsequent iteration.

If you work with a process-oriented organization, you will find that documented procedures are available for only the major software testing tasks. In other organizations, you will find that you only have high-level industry guidelines and standards to follow. In both cases, you will find your own procedures very helpful. How else do you think high performers are able to produce substantial results in half the time that you take?

Why you shouldn't be too nice?

Let us say that you are starting out in a project. You know that "people like to work with nice people". Therefore, you decide to be nice with everyone in the project team. You get these benefits:

a. The team members share their knowledge with you.

b. They help you understand the software application and the process they use.

c. They introduce you to the people related to the project.

d. They invite you to project meetings.

e. They explain and share their project work with you.

So far, so good. But what happens when you have decided to be so "nice" that you have forgotten how to say no?

1. You are given responsibilities loosely related to your role that nobody else wants to take because they are "busy". Examples could be completing some old documentation, preparing the conference room for the team meeting and arranging the team lunch.

2. When you approach someone, you are advised to fix up a meeting but you are constantly interrupted yourself. The team members feel free to walk up to you or call you and discuss whatever it is they want to discuss.

3. Your schedule is modified constantly. Here you were working on a task but suddenly something else has come up and you need to attend to the new task. While you were busy completing the new task, your old task has been cancelled or re-assigned to someone else so now you need to discard your work.

4. You always work based on someone else's estimates. Examples could be that you may estimate a task taking you 8 hours but your manager wants you to do it in less than 4 hours. Or, you may want to prepare for a task and then do it but your teammate suggests that you do it directly.

Do you think that being "too nice" will affect your performance on the job? You bet it is. Just consider the four effects above:

1. You are spending your precious time on busy work that just about anyone could perform. Worse, this work may not be required at all.

2. Your concentration is being broken repeatedly. Coupled with the loss of your productive time, you end up work superficially.

3. You cannot plan ahead of time because your schedule keeps changing. You may not get good ideas immediately when faced with an urgent task.

4. You are tired or confused because you are working according to someone else' work style or speed.

The sad thing is that you may be thinking that you are working well trying to please everyone in your team even when in reality you are putting up a mediocre performance. Worse, you are positioning yourself as a "nice" person in the eyes of your team members more and more with the passage of time.

I can say these things from personal experience. Because, I too have been the prey to my "be a nice guy" approach from time to time.

The question is what should we do? Should we suddenly stiffen up and become very demanding from others? No, we should continue to behave cordially with our team members. However, we can ask ourselves the following questions:

a. What is my role in the project?

b. What actions do I need to take to fulfill my role best?

c. What actions do I need to refuse to fulfill my role best?

d. How do I guard my own productive time best (and still be respectful of others' time)?

e. How can I create or at least influence the approaches and estimates for my own work?

The only thing left for us to do is to make the changes according to our responses.

Good job performance requires confidence in our actions. This is especially true of software testing. After all, software testing is about generating confidence.

Test Strategy - How to define and implement it?

On this October 14, I attended a web talk by Alan Page along with several others. The topic of Alan's session was Test Strategy. I would like to list the points that I saw and heard Alan make before making my own observations:

1. Consider the context before creating your test strategy. It is useful to consider your own situation in terms of your team's composition, their current skills, their desired skills and other goals. For example, it may be okay communicating the test strategy verbally within a small team of say up to 20 people. However, when you have a large team, it becomes useful to document the test strategy and distribute it so that everyone is on the same page.
2. After considering your context, the next step in the process is your fact-finding and assessment. This helps you answer questions like how is testing at present, how would it be different in the future, would other parameters change and how could the team change to meet the future requirements.
3. A useful way of clarifying your thoughts is to map your facts to goals. What is your current state (fact) and what is your desired state (goal)?
4. The journey from your Current state to Desired state may not be a straight jump but a series of steps. However, each step should aid the transition away from the Current state and towards the Desired state.
5. Once the strategy is in place, just take the desired actions. Track and review the progress and adjust course if required.

It was a clear and thought-out presentation. You can view the talk here. It should take you about 30 minutes to listen to it. Now my questions and comments.

1. Each action (even the tiniest one) taken in an organization should contribute to the organization's objectives positively. How does the test strategist ensure that each step outlined in the test strategy maps to the organization's objectives and ultimately to its vision? A test strategist should be keenly aware of their organization's business objectives. Further, the test strategist should be aware of other factors such as the current customer experience, competition and the direction the industry is moving.
2. Implementing a test strategy in a sizeable team is no mean task. Other than piloting actions and showing supporting data to other team members, what are the ways to smoothen the implementation of a test strategy? It may require sessions to explain the test strategy to each team member, arranging and executing any training they may need and providing the supporting processes and tools to the team help take action to move to the Desired state. Explaining what is in it for them, recognition of good performers and championing the test strategy may also help attain buy-in from the team members.
3. How does the test strategist know that they have arrived and it is time for the next strategy? By ascertaining if the desired state is institutionalized (data consistently points to the desired state, team members discuss about the Desired state as the Current state and team members have become a little complacent).

Why software testing should be like good journalism?

Don't you just love news? News is an important part of our lives. It keeps us informed about the happenings in the world around us. Further, news helps us update our mental model of the world so that our understanding matures from that time onwards. Now, news are gathered and communicated to us by journalists. Let us see what can we apply from the world of journalism to software testing?

Similarities between journalists and software testers
A journalist has a network of sources to inform her of interesting events.	A tester has a bunch of tests to inform her of interesting facts about the system under test.
In order to stay on top of events, the journalist stays in constant touch with her contacts.	In order to stay updated about the current quality of the system, a tester executes her tests regularly.
The journalist seeks to strengthen her network by adding new contacts or replacing her contacts with better ones.	The tester seeks to strengthen her test suite by adding new tests or enhancing her existing tests.
As soon as the journalist comes to know about an interesting event, she starts working to gather all possible information on it.	As soon as the tester comes to know about an interesting bug, she starts working to gather all information about it and isolate it.
A busy journalist has more than one story to work upon at a time. She follows all of them as they develop but focuses her attention on the ones most critical to her readers/ viewers.	A busy tester has more than one bug to work upon at a time. She follows each of her bugs but focuses her attention on the ones most critical to the system's stakeholders.
A journalist does not work alone but seeks help from others to create the best possible news story.	A tester also relies on her team to provide her insights into areas requiring more testing, re-usable tests and better testing techniques.

Now let us see what we can learn from not-so-good news stories.
A late new story: Nobody likes stale news. Stale news makes us miss opportunities and disappoints us.	Our tests should be freshly executed. Our bug reports should be promptly reported giving timely information to our stakeholders to understand, digest and decide actions based on our bug reports.
A poorly labeled news story: We decide to read/ view a news story based on its headline. It wastes time if the headline is not a true representation of the news story and we stop reading/ viewing the news mid-way.	Each of our bug reports should contain a true summary of the bug. This would enable our stakeholder effectively decide whether they want to read it it or not.
An incomplete news story: We don't feel good when we have a number of open questions after reading/ viewing a news story. It requires additional effort on our part to seek missing information from elsewhere or follow the story further.	Our bug reports should contain each required information item e.g. the steps to reproduce the problem, the actual result, the expected result, the test data used and the test environment in which the bug was discovered.
A repetitious news story: We don't want to waste our time on reading/ viewing details that we already know about.	Each of our bug reports should contain unique information and not duplicate information that is already known via other bug reports.

I am confident that the next time you read or watch news, you would think about the things that you could apply or avoid in your own software testing. Let me know if you find other lessons for us to learn from good journalism.

How fast would you progress in your software testing career?

If you are a software testing professional and wonder about your career growth, take the short quiz below. Select just one answer, A or B, for each question. Add up the number of As and Bs in your answers.

1. What is the most rewarding effect of your software testing career?

A. Money

B. Job satisfaction

2. How do you plan your testing tasks?

A. You prefer your tasks to be planned by someone else and told to you.

B. You analyze your tasks, prioritize them and try to provide the most value in each task.

3. What is your driving thought when you test software?

A. Finish the tests that you have been assigned and go home

B. Test carefully to not miss any problem

4. What do you worry about the most before submitting a bug report?

A. That it is not an invalid or duplicate bug report

B. That it contains enough information to help identify a real problem

5. How do you handle free time (say, between projects or assignments) at work?

A. Socialize/ catch up on personal tasks/ take it easy

B. Analyze own performance and prepare to deliver increased contributions

6. Do you think about software testing in your personal time?

A. Never, what is the need?

B. Of course, it is an important part of my life

What kind of progress should you expect for yourself?

Excellent: 0 As and 6 Bs

Good: 1 or 2 As and 4 or 5 Bs

Average: 3 As and 3 Bs

Below average: 4 or more As, 2 or less Bs

Notes: 1. Money can only motivate you to a limited extent; the intrinsic job satisfaction is what drives you in your career constantly.

2. In order to contribute the most, you need to identify your most important tasks and perform them to the best of your abilities.

3. Each test that you perform is an opportunity for you to excel. Do not squander such opportunities.

4. Always focus on the positives. Instead of worrying too much about making mistakes, focus on your real responsibility.

5. You should always be planning and working towards progress in your career.

6. If software testing is a part of your personality, you cannot help thinking about it from time to time.

How to create new test ideas quickly?

Test design is an important task for software testers. However, even "solid" requirements do not cover all aspects of a software product or application. As testers, we should be creative in designing tests that cover each and every system characteristic that is of importance to our clients.

In order to learn more about test design, I decided to run an experiment last month. I wanted to see the test cases that could be designed for testing a common object of everyday use, a tea cup. I posted a discussion on this topic in the Software Testing Space group. See my short video, How to Design Test Scenarios or read on...

The experiment was a success. The group members came up with more than 75 test ideas. I too participated actively in the discussion and came up with more than 75 other test ideas on my own. I learnt a lot from this experiment. In this post, I will share one learning with you.

To begin with, I just had some basic test ideas. Ideas like does the tea cup hold an acceptable quantity of the beverage, does it prevent the loss of heat while the tea is being consumed, is it possible to operate the tea cup without burning one's digits or mouth and whether is it possible to prepare (i.e. wash and wipe) the tea cup for the next use.

Other STS group members added more test ideas related to the physical characteristics of the tea cup (e.g. its weight, leaklessness, its looks, the properties of the material used in its construction and its inter-operability with other objects such as its plate). Now, the physical characteristics category is a gold mine of test ideas. I came up with more test ideas now on

Operation

• Does not get caught with other objects e.g. other utensils or garments while handling
• Does not lose material, shape or any other physical characteristic when washed
• Does not have any hard to reach areas (difficult to wash zones)

Inter-operability

• With a kettle or tea vending machine

Safety

• Stability (with respect to its height, weight and center of gravity) while lifting a filled tea cup and placing it down
• "Unbreakability" during use e.g. when dropped on the floor or when squeezed by hand
• Size and shape of pieces (e.g. small and pointed versus large and smooth) that it breaks into

Looks

• Has a good shape design, symmetrical or otherwise
• Has visible logo
• Handles extreme temperatures without physical distortion

At this stage in the discussion, I found myself thinking hard to get fresh ideas. Sure, I would come up with a few fresh test ideas. But I also found myself coming up with several test ideas same as or similar to the ones already on the table. I felt that there were a lot more tests that I had not considered yet. But how to get at them quickly?

It was at this stage that my fellow STS group member, Freddy Gustavsson added to the discussion. Freddy suggested more test ideas but the thing that struck me about his response were the categories he listed. Things like Changeability (modify the tea cup) and Replaceabiltiy (repair a broken tea cup).

I found a sizable list of system quality attributes on Wikipedia. After looking at these attributes, I could then think up with a number of fresh tests including, for instance,

• Material free from harmful (reactive or radioactive) chemicals
• Material does not conduct electricity
• Tea cup operates well with accompanying items like cup cover and coaster

What is even more important is that you may use the list of system quality attributes to quickly design tests for any system, including a software product or application. Like I did, you could select the quality attributes applicable to your system. Add sub-attributes as desired by you. Create a hierarchy of attributes if you want. Thinking about test ideas for your system one attribute at a time gives you focus. This could enable you to come up with a number of test ideas more quickly.
A final note: Out of all the test ideas that you collect, remember to select and prioritize your tests based on the objectives and needs of your clients. The importance of a test depends on its alignment to the objectives and needs of your clients.

Why you must know your product's competitors?

Why does a customer purchase (a license) of your product? More likely than not, the primary reason for doing so may boil down to

1. Getting something new e.g. increased productivity or increased efficiency or increased resources

2. Overcoming a risk e.g. miscommunication or failing to meet statutory requirements

However, your product may not be the only solution available in the market to satisfy the customer's primary requirement. If your product is not so well-known, it has to compete with leading products in the market in the particular category. If your product is the market leader, it may have to compete with products catering to specific niche markets. Even if yours is a one of a kind product, there may be a proven manual system that it has to compete with.

When the customer evaluates or first uses your product, it is no leap of imagination to think that s/he would be actively comparing it with its competitors. If you test software, you can ill-afford to ignore your product's competitors. Software testing should include not only testing with respect to your organization's or customer's requirements but also testing to check how the product functions with respect to its competitors.

Knowing the product's competitors is not the prerogative of product managers alone. As software testers, we pretend to be customers using the product. Therefore, just like customers, we should be aware of the alternative products. Only then would we come to know about how our product functions on its own and how it functions with respect to its peers.

Find a Bug

Scenario: You are a competent tester who has just joined a company and is testing on the first project there. The application you are testing is a financial web application. During test execution, you make the following observations. Rate each observation on a scale of 1 to 10, 1 being definitely not a bug and 10 being certainly a bug.

1. The logo on the home page and other pages of the application is not the client's. For example, if the client's name were 1, the logo is that of another company, say 2. The logo in the previous version of the application is your client's.

2. There is a group of links on the pages of the application. When you click any link in this group, it opens a page with the "Not Found" error.

3. You log on as a new user into the application. You make a deposit of $ 1,000 into your account. When you visit the Transactions page, it shows you your transaction of $ 1,000. However, when you visit the Balance page, it shows your available balance as $ 2,000.

Should you go ahead and report these observations as bug reports pronto?
.
.
.
.
.
.
.
.
.
.

My advice is No. All your observations mean is that you should investigate further. For all you know, there might be perfectly reasonable explanations for these observations. For example,

1. Your client is getting this application developed for a partner organization. Or, their parent organization. Hence, the different logo. The change request is already under construction and you would get it soon.

2. The group of links will be supported by an external entity. During your test, you should just have checked if each link is correct. The external entity would populate these links before the test finish date and then all the links in the group would work.

3. There is indeed a requirement which states that when a new user makes the first deposit between $ 1,000 and $ 2,000, the client organization doubles the balance by making an equal deposit into the user's account. However, you are not aware of this requirement.

The objective of this post was to help you realize how using Heuristics may lead you along a wrong path. However, I did not state this objective at the beginning of the post because I did not want to bias you.

Testing is an investigative process. We should observe the application carefully, formulate theories if what we see is not in line with our mental model, gather more information from multiple sources and analyze and test our theories before pronouncing a discrepancy or a bug in the application.

P.S. The idea to write this post came after reading, ICICI Bank ATM bug … Try it!............. by Amit Jain, a member of the Software Testing Space group.

As you wish!

Once upon a time, there was a tester who had just joined a large end-user company. He had a good profile and was promptly inducted into an ongoing project to develop an application for internal use across offices of the company. Things started moving slowly for this person.

Though nobody in his team realized at the time, this tester was quite capable. He was also quite talented, hardworking and methodical in his working style. He quickly introduced himself to each of the team members (but in his hesitant way). During his initial days in the project, he made it a point to read (and re-read) all the documentation related to the project. Whenever he had questions, he made the effort to approach the relevant team member and clarify his thoughts.

Some time passed and now he was assigned some modules to test in the project. Since the tester was quite knowledgeable about the requirements by this time, he could understand the existing test cases quite well. He was also able to see the short-comings in these test cases and made refinements to his own copy of the test cases before executing them. He found defects. In fact, he found a lot of defects. This led to the problem.

The Development Lead on the project was an influential person. He was always "in the know". He was also widely recognized in the company as a competent developer and business domain expert. But somehow, he did not like so many defects being logged by our tester against "his" application and "his" team. He called the tester for a one-on-one meeting and questioned his work. Did the tester really understand the business objectives of the application? Should the tester have been spending more time validating the application? Were his defects really valid at this point in time?

Our tester did not like confrontation. So, when the Development Lead changed the following rules, our tester said "As you wish" and smiled meekly:

1. The tester would now only test the modules specifically assigned to him and not anything else.

2. If the tester thought he found a bug, he was to approach the Development Lead, take an appointment and present his bug. Only when the Dev Lead had analyzed and agreed to the bug was the tester required to report it in the bug tracking system.

3. The tester was not to approach any team members directly. If he had questions, he was to take permission from the Dev Lead and only then meet the team members.

The Development Lead did not however stop at that. During his status reporting meetings with the management, he took the time about how he thought of our tester as a somewhat loose cannon. He said that the tester needed to be monitored closely but assured the management that he had put the tester on an "improvement plan".

Life had become tougher for our tester. While testing, he could see bugs in many areas of the application but he had to keep them to himself. When he attended the meetings with the team, his mind would be full of ideas. However, many times he hesitated to share those ideas. Other times, when he would get the courage of speaking them, he was quickly interrupted by the Dev Lead, "We will talk about it later". The tester would just smile weakly and say "As you wish". Many other team members too started taking little notice of the things the tester had to say. When the tester found bugs in the modules assigned to him, he would make careful notes and take them to the Dev Lead for discussion. The Dev Lead rejected most of the bugs he thought of as "not realistic enough", "too early to fix" or "doubtful". The result was that he allowed the tester to report the most obvious bugs only. But our tester kept on plodding without regrets.

Time passed. A number of releases were made to downstream teams. Finally, the application was deployed to production. The Dev Lead was also now the in-charge of supporting the application in production. In the first few months, internal customers reported several issues in the application. These were promptly fixed. Six months after the go-live date, the Lead happened to think about the issues reported in the go-live period. He listed the issues and started analyzing them. Just out of curiosity, he picked up our testers submitted notes from the previous year to see whether he had put forward any one of the real issues. He was amazed. All save one issue reported in production against the tested modules was discussed by the tester, while the application was still in development. Now, the Lead was very ashamed of how he had treated the capable tester.

He promptly called the tester for a meeting. He hurriedly explained his pre-occupations at the time and how he now realized the good work done by the tester. The tester was now free to discuss his ideas with others and report bugs as he saw fit. Then he asked the tester if this was okay? All our tester had to say was "As you wish", again with a meek smile.

Let us treat each team member with respect. Who knows how much a team member may be able to contribute to our success?

Equivalence Partitioning - Why you should NOT use it AS IS in black box testing?

Equivalence Partitioning is an interesting test design technique. You can learn it from my video, Equivalence Partitioning and Boundary Value Analysis tutorial.

Put simply, EP involves dividing the input test data into partitions, valid and invalid. It promises to reduce the number of input test data values that must be used by suggesting that only one test data value be used from each partition to determine the behavior of the application for each partition.

Let us consider an example of the input, day of the week. The valid partition is 0..6 (or Sunday to Saturday). marked in green. There would be two invalid partitions, <0 and >6, which are marked in red.

-------------------------------------------------------------------------------------------

...  -3   -2   -1      0    1    2    3    4    5    6    7    8    9  ...

-------------------------------------------------------------------------------------------

Therefore, you decide to execute your test case with three distinct values, say -3, 3 and 9 (a value each from the first invalid partition, the valid partition and the second invalid partition). Correct?

Wrong decision. The technique assumes that the application treats any value within a particular partition identically. Well, may be NOT. Unless you are privy to the source code and can confirm that indeed each value in each partition is handled exactly the same.

Partitioning is fine. I disagree with the "Equivalence" part of "Equivalence Partitioning" term. I will mention why. Let us say that the programmer wrote separate "Case" or "Switch" statement(s) for each value from 0 to 6. If you only ever execute your test case for the input value 3, you would never test the application's code for the other values in the valid partition (0,1,2,4,5 and 6).

At this point, I can anticipate questions. How about the invalid partition? Should you execute your test case with multiple values in the invalid partition? How far back should you go? Obviously, you cannot use each value in a large partition. However, you may consider the following:

a. Use at least one or two values in the beginning of the partition e.g. -1 and -2.

b. Use at least another value deeper in the partition e.g. -100.

c. Use a value outside the range of the data type (integer in this case) e.g. -12345678

In short, when you have to test without looking at the source code, test using each input value in a small partition. And, test using spread out sample values in a large partition.

Future of software testing

We don't know the future. Nobody does. However, I have been involved with software testing since 1998 and I have seen changes taking place. It used to be simple earlier. We received the requirements and designed simple test cases based on these requirements. Then we received the latest build of the application, execute our test cases and report discrepancies in bug reports. We did all of this as carefully and as fast as we could. As I experienced software testing first hand, I began to learn it. There were multiple approaches available to perform testing tasks. Each approach had its own pros and cons. There were multiple types of testing that we could do. Each of my team members had a different set of skills, strengths and weaknesses. It was not simple anymore. 3 or 4 years ago, I started following the online software testing communities. I read a lot of material and comments on hundreds of topics in software testing. I saw thought leaders in software testing repeatedly pointing us test practitioners to the basics. Over time, I have begun to consider software testing as quite complex and challenging. The good news is that software testing still has a long way to go before it truly matures.

Here is the list of my predictions. These are not revolutionary changes that are going to catch you all of a sudden. In fact, you can see some of these changes today. But, if you are aware that these changes could speed up or intensify in the coming future, then you have a better chance to prepare yourself to take advantage of them.

Prediction #1. Companies will demand more value for the testing resources they put in.

The recent downturn has shaken everyone. We have been forced to become savvier with our investments. The same is true for companies. Companies will demand a better testing service from their resources (in-house testing team or a vendor providing testing services). The companies will now demand:

a. Faster turnaround time

b. Greater coverage of specified and implied requirements

c. Testing in more perspectives (functional, performance, security, usability and so on)

d. Increased collaboration with all other teams involved in sales/ product development, software development, deployment and support

e. Lower costs (of test infrastructure (test environment), test tools and testing personnel)

f. More transparency of the test process

Prediction #2. Software testing will become more complex.

Keeping in mind the increased expectations of clients, the increasing complexity of applications and the increasing knowledge of test practitioners, software testing will become more complex. In future, testers will need to find answers to the following questions among others:

a. What are the most important business objectives of the application that I am testing?

b. What technologies does my application employ? How do I test each of those?

c. What test infrastructure will I need to test my application? How can I set those up with the least cost (of setting it up, using it, maintaining it and tearing it down)?

d. What tests would provide the best value against the cost of creating them?

e. How is my application integrated with other systems? How do I test various aspects of each integration?

f. What is the best test methodology that I can use?

f. Which of my communication provides the best value to other stakeholders?

g. How do I utilize my natural strengths in testing? How do I circumvent my natural weaknesses?

Prediction # 3. Crowd-sourcing will continue to become popular.

uTest is becoming more popular by the day. Today, uTest has more than 20,000 testers and a client list that includes Google and Microsoft. The clients of crowd-sourcing companies can buy just the testing services they need when they need them and even select the individual testers for the test. No wonder, many companies consider crowd-sourced testing services as viable alternatives to large in-house testing teams or inflexible testing services vendors.

Prediction # 4. In order to get hired and stay hired, testers will need to distinguish themselves from the crowd.

Today, there are masses of software testers. Their profiles and resumes look similar. If I were going to hire someone for my team, I would not like to just go for someone with the basic knowledge and skills. I would like to get the details. And, I would probably like to interview someone with substantial achievements. Someone who has "walked the extra mile". Someone who has achieved more than their counterparts at the same level. Be it extra-ordinary knowledge, uncommon or advanced skills or a solid recognition from testing experts.

Prediction # 5. Social skills and working style will become important.

Other than software testing knowledge and skills, testers will be required to be socially adept. They will be required not only to plan and test well, but also communicate well. They will be required to establish themselves as part of a team, support the team, speak up when required and influence others when required. In future, just testing won't do for the testers. They will also be required to collaborate effectively and strive to maintain long-term relationships with their extended teams. Further, testers will be required to show align themselves to the (stable or changing) business objectives and the team.

What do you feel? Do you think that you are ready for these changes? Are you going to take advantage of them? What other changes do you see on the horizon?

The Ultimate Machine: How would you test it?

As many of you know, we now have our Software Testing Space group in LinkedIn. A lot of exciting discussions are taking place there. If you have not joined it, you should consider doing so.

My friend, Freddy Gustavsson from our STS group posted an interesting challenge on testing the Ultimate Machine. Well, the Ultimate Machine is attributed to Claude Shannon (1916 to 2001). It consists of a simple box with a single switch on its top surface and a closed lid. If you flip the switch on, the lid opens, a mechanical hand arises from it and the hand flips the switch off. Thereafter, the hand goes back into the box and the lid closes. Freddy's challenge was that if he asked me to test this Ultimate Machine, which tests would I perform? Here are the questions that I thought of. I would like to design tests based on these questions.

Positive tests

a. If the tester flips the switch on, does the hand (or an arm in certain implementations) switch it off?

b. If the tester does not touch the switch, does the machine just sit there and do nothing?

Negative tests

a. What happens when the tester flips the switch on and switches it off before the hand can reach it?

b. Is it possible to flip the switch somewhere between the on and off positions? What does the machine do in such a case?

Non functional tests

a. Can the tester operate the machine as it is or does it need to be installed? If installed, what does it take to install it?

b. Once the machine is switched on, how long does it take to switch itself off?

c. How many times can be machine be operated  before it stops working (due to battery discharge, wearing off of mechanical parts and so on)? Does it slow down after a while or show operational problems (make hitherto unknown noise for instance)?

d. Does the machine operate correctly if the ambient conditions are changed?

   i. The machine is vibrated e.g. during travel or a minor tremor.

   ii. The machine is operated outdoors (e.g. during a dust storm or in rain/ sleet/ snow).

   iii. The machine is operated in a strong magnetic field (e.g. certain places on a factory floor or in a hospital).

   iv. The machine is operated in different light conditions (e.g. direct sunlight, in the office daytime with blinds open/ blinds closed, at dusk or in total darkness).

   v. The machine is operated in different temperatures (e.g. at room temperature, in a freezer or near a furnace).

Usability tests

a. Is it easy for the tester to locate the switch?

b. Is the switch easy to flip (works smoothly, clicks to indicate it has flipped)?

c. Is the switch safe for the tester to operate (no rough surfaces or pointed end)?

d. Is the box pleasing to look at? How much space does it occupy on the tester's desk?

White box tests

We could open the box. Then, we can try to understand the mechanism inside and create more tests based on our understanding. For e.g. I would like to know if the time it takes to switch off is configurable and is the machine connected to any external system.

I am sure that you can think of more questions to help test the machine. Did you notice that I used the various types of testing to think about the above questions? What approach would you have used to design tests for the Ultimate Machine?

Do developers hate testing?

Having recently read a post on the UTest blog, I decided to think back about my developer days. What challenges did I remember from my experience as a Developer? Did I test my code or not?

1. Sometimes, it required a huge effort on my part just to know the correct set of requirements. Sometimes, the requirements would be given by a business person who would be focused on the promises already made out to the customers. The product manager/ business analyst would rarely verify the technical feasibility of implementing the requirements before committing to the customers. In such a situation, it became a matter of identifying the design alternatives available and exploring the promising ones in detail. As a developer, I used to take such situations as intellectual challenges. This resulted in me saying Yes, even when a simple No would save me a lot of work.

2. At other times, I was handed over source code that had been written, changed and enhanced (all these in different orders) by at least 3 or 4 developers before me. These developers were now either busy with other projects or no longer available in the company. I found this source code riddled with problems. There would be sections of the code that were incomplete, the sections would work with some input values but not with others, were partial duplicates of other sections or had logical problems. Getting such code to work was challenging. It involved plowing through the code (reading a section, unit testing it, resolving the problems, unit testing it again, refactoring it to make it more understandable, unit testing it and so on).

3. The other thing I recall is the sheer number of problems I had to face in order to implement a single requirement. Examples of these problems were:
a. The design was either non-existent or did not cover the particular requirement. This meant that my task doubled in scope. I first had to create a good design and then implement it.
b. The base components were not present or had defects. So, I had to decide either to re-write the base components from scratch or debug them before using them.
c. A similar requirement was already implemented in the application. The trouble was that I was either not able to understand that implementation or suspected hidden defects in that implementation.
d. The underlying development or run-time environment had issues (meaning defects or constraints) in certain conditions. This meant that I had to either somehow circumvent those limitations or break down my implementation into multiple parts in such a way that I did not run into these issues.

4. The next thing that I remember is how tight the schedules were. There were two reasons for this. The first reason was that the development effort was routinely under-estimated. Maybe my project manager (who estimated the development effort) wanted to increase my productivity constantly. Or maybe s/he estimated the effort considering the simplest development possible. The second reason was that I wanted my code to be perfect (in some cases, more than perfect). This meant that I would write the code implementing a requirement and run it repeatedly looking for problems. Once I had code running without problems, I would refactor it to make it leaner and strictly according to the coding standards (for example, naming the variables according to the specified nomenclature, adding comments every few lines and so on). If time permitted, I would even attempt to enhance the design or add extra functionality (though I stopped adding any extra functionality quite early on). My worries about how my code may not work under specific conditions led me to test it, modify it and again test it repeatedly. Given the tight schedule and my worries about the quality of my code meant that I was under stress.

It is not that as a Developer, I hated testing. Quite the reverse actually, I always wanted my code to be perfect and tested constantly. It was the sheer number of problems that I had to solve in a tight schedule that allowed some defects to fall through the cracks. And the defects discovered by the testers were only small fraction of all the defects that originally existed in the code.

Though I tested my code constantly looking for defects, there was only so much I could do given the tight schedule. In fact, I found that in internal projects (where the delivery deadlines were relaxed), I was able to submit code in which the testers could hardly find any defects.

Software testing involves a lot of work. The tight schedules do not help because it is very common for the development scope to increase during development. If the schedules are more realistic, I am confident that developers would test their code better and there would be a lot less defects in their applications.

Team Competition - How to compete against other software testing teams and win?

There may be occasions when you or your software testing team is pitted (compared from a business point of view) against another individual or another team. Examples include:

1. You are a senior tester and the management has just hired a junior person. Now, some tests have been assigned to the junior tester. The idea is to see if there is a discernible difference in the outputs of the two of you.

2. Your management or client has decided to off-shore (OR bring on-site) some of the testing work. Some work is now being done in parallel in both locations. The idea is to see which team provides more value with respect to the cost it incurs.

3. An experienced person with the business background has been added to the team. The idea is to see if business knowledge or software testing knowledge provides greater value in testing.

Before I go on, let me clarify that healthy competition is a fast way to grow your capabilities. Otherwise, things tend to stagnate. And quite often, the competing teams end up collaborating with and supporting each other the other side of the tunnel.

But, in the meantime, you have to think about at least maintaining your position. If you do NOT take any additional action, your role may be diminished or change into something else regardless of your preference. How can you maintain (and subsequently grow) your position?

1. Study the other team.
When sports team prepare for competitions, they actively study the other team. You should do the same. You should find out the following information about the other team:
 a. The number of members in the team
 b. Their names and location
 c. Their general background, experience, knowledge, achievements and struggles
 d. Their prior exposure to your company's specific applications, tools and processes
 e. Their working style/ culture
 f. Any natural advantages they have over you

2. Follow their work and deliveries.
You should actively follow their work and the deliveries they produce. Use all channels (official and informal) to keep you updated about their progress.

3. Analyze the other team's strengths and weaknesses.
Your team should now be able to have a fair idea of the other team's strengths and weaknesses. Be ready to update their image in your mind as you follow their progress regularly.

4. Identify your own strengths and weaknesses.
This is a good time to be more aware about your own team. What things is your team good at? What tasks is it not so good at? In what respects does your team absolutely struggle?

5. Change your approach appropriately.
If are keenly aware of the other team and your own team, it should be easy for you to identify the ways in which you can out-perform them. Some examples are given below but you should find out your own ways to out-perform the other team. And, implement the changes quickly.
 a. If the other team only executes the predefined test cases, your team may want to additionally invest time in enhancing and then executing the available test cases. Or perform exploratory testing in addition.
 b. If the other team focuses on functional bugs, your team may want additionally focus on performance bugs, usability bugs and look and feel bugs.
 c. Get work done faster. If their team members watch the clock (come in at time, work and leave on time), your team can shorten your breaks or concentrate more on the tasks or stay on the task longer.
 d. If the other team has individual performers, your team may want to harness the power of team work.
 e. If their team works in a silo, your team may have a good rapport with the other engineering teams.

6. Inform the decision makers yourself.

You can be sure that the decision makers who initiated this change would be actively following its effects. You should inform your own achievements in a positive light to them. Do NOT rely on someone else to do this for you. If so, they may tone down your achievements according to their own biases, opinions and agenda.

7. Finally, help your NEW team.
When the dust settles, your team will have a better assessment of their strengths and weaknesses. You will also be more mature. The other team will also share the same benefits. After all, everyone wants to grow.

If the decision makers take a professional decision, the work will be more aligned according to the strong areas of the either team. The teams may even be re-distributed or merged into a single unit. It is a WIN-WIN situation. Now is the time to help yourself and your new team to the best of your abilities.

Why you need to articulate more?

You need to communicate your ideas, thoughts and progress whether you are a tester, a manager or the CEO of your company.

What is the benefit of articulating your thoughts? When people hear from you, they come to know where you are coming from, what your approach is and what are the actions that you are going to take? Once they understand your position, they tend to support you. Why is this? This is because your communication makes them think in a way similar to yours.

A person with the same knowledge as you but who does not articulate their thoughts receives none of these benefits. If you don't believe this, go back to your school days. Think of the popular students. Were they the ones who always stayed silent or were they the ones who had interesting things to say to the teachers and in your friend circle?

But, what happens when you articulate more? You influence more people and in a deeper way.

1. Tester: A tester who speaks of new test ideas in team meetings and writes informative bug reports and test reports is perceived well by his colleagues and manager. The team and the manager are impressed by the tester and increasing responsibilities/ authority come his way.

2. Manager: A manager who clearly conveys the objectives of the project to his team members and updates the management effectively runs a more successful project. The management is eager to assign bigger and more important projects to him.

3. CEO: A CEO who pitches the strengths of his organization well in front of the clients tends to win their confidence (and more business for the company). When the same CEO outlines the company strategy clearly to the employees, he aligns the employees to the company objectives well.

When you articulate more, you:

a. Force yourself to think about more topics of interest.

b. You study/ research these new topics. You learn.

c. You plan according to the objectives of your communication.

d. You design what you are going to say in structure and words suitable to your recipients.

e. You overcome shyness when you actually communicate.

f. You become mentally agile to answer your recipients' questions well.

g. You become faster and more effective in each step of the communication process.

So, seize every opportunity to articulate. And, articulate better than you have ever done before. Get more and more benefits.

How to review better?

We often get artifacts such as test plans, test cases, test results or bug reports to review. This is especially true for those of us in the leading or senior positions. Do you wish to be a good reviewer? If so, try NOT to fall into the following categories as others have in the past.

1. The Silent Reviewer

You submit your material for review. There is NO response from the reviewer. You decide to follow-up a bit later. Still, there is NO response. What the Silent Reviewer is not telling you is the reason they are not able to perform the review. Often times, the Silent Reviewer assumes that you know everything that you need to provide them to do the review. Diplomatically coaxing the reviewer to share the reason can be helpful. The trouble is that not many authors think of this approach or take the necessary time to ease the review along.

A dangerous version of this type of reviewer is the Silent and Angry Reviewer. They do not perform the review but tend to form a poor opinion about you.

2. The To-and-Fro Reviewer

You submit your material for review and look forward to completing other work. Little do you realize that you are going to be spending a lot of time with this particular reviewer. The To-and-Fro Reviewer takes one look at the material and shoots off a message e.g. You have not used the correct template OR You have not provided a specific piece of information. Your reply results in request for still more information or maybe, a review comment. You feel confused and exhausted after a long chain of communication with this reviewer. The trouble is the To-and-Fro Reviewer is performing the review on their whims and fancies.

3. The Opinionated Reviewer

You request for a review and what do you receive? A personal comment on your lack of knowledge, lack of competence or something basic that you have missed or done incorrectly. You feel bad after hearing from the Opinionated Reviewer because they are not focusing on the material but rather on you. You may also find the Opinionated Reviewer transform into another category after blaming you personally.

4. The Insensitive Copier

The Insensitive Copier wants to look good in the eyes of others. Even when they do a thorough and useful review, you find that they have copied their review comments to your manager, their manager, colleagues and the Head of the unit. Their perception of the quality of your work is now visible at the high levels. Worse, they may ask you to address their review comments immediately. If you do not address the review comments promptly, you risk looking lazy in the eyes of the management. So, you have to re-schedule your other (important) work and tackle the review comments pronto.

5. The Skimpy Reviewer

This reviewer provides you little value. Maybe, it took them less than two minutes to review your work. You get comments like:

a. It seems alright at first glance.

b. The formatting seems to be off in places.

c. I am sure that you have done a thorough job. Don't have any review comments as of now.

6. The "Busy" Reviewer

This reviewer performs the review, even to a high standard, but in their own time. What good are review comments on your test cases when testing is mid-way and there is little or no time to update the test cases? In extreme cases, you receive their review comments after the event is over e.g. the release has been deployed in production. There is little use for the review comments except as learning for the future.

If you do not agree with the above, try to remember the time when you were at the receiving end of one of the above types of reviewers? How did you feel after the review? Drained, exhausted, bitter?

If the review is not too important or you are too busy to do it well, you should politely decline it giving the genuine reason. However, if a review is important, you should do it well. Schedule an available time for your review. Make sure that you have all the required material, do the review and pen your review comments using your knowledge and wisdom. Go through your review comments and make sure that they are professional, factual and focus on the material (and not on the author). And please, communicate your review comments promptly giving sufficient time to the author to address them correctly.

GUI Test Automation with RoutineBot

Recently, I came across a simple and effective GUI Test Automation tool. It is named RoutineBot. RoutineBot works by searching and performing actions on image patterns. Other than that, it can emulate keystrokes and mouse movements and clicks.

A few salient points about RoutineBot are:

1. It works with both Windows applications and Web applications.

2. It supports Pascal, Basic and JScript scripting languages.

3. It provides warning and error messages to help debugging, returns results of the test and closes the test on timeout.

4. It provides Environment options (e.g. snapshot interval i.e. time during which you should navigate to the image, location of the log file etc.)

5. It currently comes with a free unlimited 30-day trial version.

6. The full version is priced quite economically when compared to other tools with similar features.

Here is my experience when I decided to try out RoutineBot.

Installation

The installer is in a single file, routinebot.exe of a small size (2.2 MB). On running the installer, the installer shows the standard wizard (confirmation to install RoutineBot, License Agreement, selecting destination folder, selecting start menu folder, creating desktop icon, selected settings so far and the complete setup screen). The installation was done in a matter of seconds on my machine.

Applications tested

Notepad

Since the example mentioned on RoutineBot website used a Windows application (Calculator), I decided to use RoutineBot to automate few test steps on a Windows application. However, I used the Notepad application instead. The steps that I decided to automate were:

a. Open Notepad.

b. Type some text in it.

c. Save the text in a file.

Opening an application is very simple in RoutineBot. The Execute command did that for me. Next, I needed to enter some text. The command to do so is EnterKeys. Note that EnterKeys can be used not only to type text but also other keystrokes like Ctrl, Alt, Enter, Function Keys and so on. The next part is where I had to learn using the RoutineBot approach of using image patterns. I needed to click the File menu item. Therefore, I changed the tab to Select Test Image. Then, I clicked on the Make snapshot button. It starts a countdown of 5 seconds during which I had to move the mouse pointer near the File menu item. Next, I used the Select and crop button to select just the File menu item text. Then, I saved the selected image (of the File menu item text) as a .bmp file (I could have chosen the .jpg or .gif format instead) using the Save sample button. Next, I selected the action of MouseFocuse (the default action). Now, I switched to the Script tab and placed a MouseClick command after the MouseFocuse command. Similarly, I automated the click on the Save menu item (under the File main menu item), typed a filename and clicked on the Save button. Every time I added something to the script, I clicked the Run script button to ensure that it worked just as I wanted it to work.

My final script looked like:

Execute('C:\WINDOWS\NOTEPAD.EXE');

EnterKeys('Hello world!');

MouseFocuse('FileMenuItem.bmp',10000);

MouseClick;

MouseFocuse('SaveMenuItem.bmp',10000);

MouseClick;

EnterKeys('abc');

MouseFocuse('SaveButton.bmp',10000);

MouseClick;

Firefox browser

Next, I chose to automate the following test steps of a Web application:

a. Open Firefox browser.

b. Navigate to Google search engine.

c. Search for "RoutineBot".

d. Click on the first result (expected as the RoutineBot website's home page).

I tried the Record option but, as expected, it generated too many lines in the script. Therefore, I chose to create my own script by using the Add Action button. The working script looked like:

Execute('D:\Program Files\Mozilla Firefox\firefox.exe');

Wait(5);

EnterKeys('www.google.co.in~'); //Note that the ~ stands for the Enter key

Wait(5);

EnterKeys('RoutineBot~');

MouseFocuse('RoutineBot.bmp',10000);

MouseClick();

Licensing and Price

1. I found the price of RoutineBot reasonable. You can see the pricing information here.

2. Note the important current licensing approach here, "One registered copy of RoutineBot may either be used by a single person who uses the software personally on one or more computers, or installed on a single workstation used non-simultaneously by multiple people, but not both."

3. It currently comes with free updates (minor version changes) but paid upgrades (major version changes).

Other tips

1. RoutineBot did not display complete UI on my screen that had the resolution set to 800X600. I found that when I increased my screen resolution to 1024X768 or higher, there was no display problem.

2. If you add actions from the buttons (Add Action or Select Action) as well as write commands in the script yourself, you should look out for formatting errors. Anyway, RoutineBot points the exact location where the syntax is incorrect.

3. When you Hide RoutineBot, it not only becomes invisible but also disappears from the list of open applications (meaning, for example, that you cannot use Alt-Tab key combination to open it). On hiding, RoutineBot displays as an icon in the taskbar. You can click this icon to unhide it.

4. When you execute your script, you should ensure (programmatically or otherwise) that the RoutineBot Interpreter toolbar (with Stop, Pause and Hide buttons) does not overlap an image of interest. In other words, the image to be searched should be visible. Otherwise, RoutineBot will not be able to find the image and perform actions on it.

5. If the image pattern changes in the application, then your script may not work correctly. Therefore, for images likely to change, it is better to use smaller images (that stay constant) or to use the button's caption to click it.

Summary

This is my overall view of RoutineBot. I was able to learn building test automation scripts using RoutineBot within a few minutes. Then, I read the documentation that is available on the tool website (see links below). After reading the documentation and trying simple examples, I became confident that I had mastered the basics of the tool. Since, I the trial period of the tool is far from over, I plan to automate test cases of a web application with it and see for myself how well RoutineBot is able to automate them.

Important links

RoutineBot website
FAQ

Screenshots

Test automation samples

Recording test automation scripts

Supported commands

Ordering

Support

Disclaimer: I have reviewed RoutineBot as a potential user. I do not represent the tool vendor (AKS-Labs). If you want to evaluate RoutineBot for your needs, you should use your own judgment and contact the tool vendor directly.

What have I learnt after blogging for a year?

The timing of this post is almost correct. I have been blogging for a little over a year now. Software Testing Space has now over 50 articles. Here are the top lessons that I learnt while blogging about topics in software testing. You will find these tips handy if you blog or plan to blog in the future.

1. Getting ideas for posts is critical.

In the beginning, I spent a lot of effort of listing and evaluating ideas to blog about. Then, I would select a topic that was interesting to me. That was a mistake. Your post is helpful only if the content is useful to your readers. Off late, I have found that a good source of ideas is the questions posed by readers. Of course, the response to the question should provide value and be interesting. You can also write on topics on which there is little, misleading or no information available online.

2. The title of the post is its most important part.

A reader is more likely to read the post if your title is interesting. A short title is better than a longer one. If you can frame the title as a question, even better.

3. Posts that draw on personal experience are more popular.

Posts should be interesting. A post based on personal experience captures a reader's attention more than one that just deals with a topic in a theoretical fashion. If you have no personal experience to draw upon, then you should provide the data supporting what you write. At least, you should explain the logic of your thoughts on the subject.

4. The post itself should not be too short or too long.

The post should cover the subject well. For example, if you are writing about how to create a good test strategy, you should first define what you mean by a test strategy. Then go on to point out the benefits of a good test strategy and finally outline the method by which you can create a powerful test strategy.

If your post is too long, a reader may just skim the post. However, this is not always true. I have had readers write to me and sometimes they remember even a point made in passing one of the earlier posts.

5. Grouping and linking information makes it easy to find it.

Earlier, I just managed with a chronological listing of all the posts. If a reader had to find a related post, they would need to look up the title of each prior post. Grouping your posts by category makes it easier for all. Further, linking to other resources (including previous posts) within the post is even better.

6. Add content regularly.

I have seen blogs that only have a handful (say, 2 or 3) posts or haven't been updated for a year or more. It is sad. If a reader visits your blog again, they expect to find some new useful or interesting content. These days, I aim to create at least 10 to 15 new posts every month.

7. Use the power of humor.

Writing with humor is an art. To be honest, I find writing with humor while being sensitive and respectful to all concerned rather challenging. However, I have written one humorous post and plan to write more in the future.

8. Finally, take help from others.

You should remember that there are many other experts in your field. They may be happy to share their knowledge with you. I found that interviewing other experts is a good way to way to gain knowledge and broaden your mind. I have started interviewing experts and soon more interviews should follow. I, too, write on other sites. If you would like me to write for you, you are welcome to let me know :}.