Category Archives: Fourth Edition

Domain Knowledge – Is it important to Testers?

In today’s market testing has become essential entity across any domain like Banking, Financial Services and Insurance (BFSI), Retail, Health Care, Transportation and so on. As the testing industry grows, a tester with basic skill is not sufficient to meet the market needs. Market now demands domain and subject experience. Having said that doesn’t mean they don’t need software testing knowledge. Domain knowledge is used to derive business use cases and software testing knowledge is used to derive ideas to test the limits of the technology.


Majority of the testers would agree that it is unfair to not hire a tester just because he/she does not have prior domain knowledge. This could be justified by the testers who had to start somewhere at some point where they didn’t have testing experience or testing skills. They learnt on the job and added value to the projects they worked on. But can these testers test an application without knowing how a particular business works? What about the risk involved with hiring a poor domain knowledge tester?

Let’s understand this:

1. Online Banking – Tester has to test online banking flows few of which include login, transfers, bill payment. To login a tester might need basic testing knowledge but to do modules like transfers and bill payment, a tester needs to be a subject matter expert. One should understand the business logic on money flows.

2.  Health Care systems may not consider testers without prior knowledge, as it would risk some- one’s life.

3.  Retail: Retail domain In Store Solutions, Enter- prise management, and Warehouse manage- ment. One needs to understand the basic flow at every level for the service to run successfully. Ex: If I were to test POS, I need to know about POS before I can actually test it.

With this being said, a tester also has to understand the ground reality. It is quite a challenging task to build and maintain a team rich in testing and domain knowledge

How can testers gain domain knowledge without prior experience in the domain?

1. Plan
To increase domain knowledge is to come up with a plan of attack. Knowledge is vast and one cannot gain all in just a day. You need to filter down the amount of knowledge you are trying to absorb into pieces and attack it gradually.

For example: if you may say you want to become a domain expert in banking. But which area of banking, specifically? Retail banking, investment banking or private banking? Or it doesn’t matter to you?

2. Ask Questions

Ws Asking questions is an art in itself and if you want to build up knowl- edge, you need to know WHO to ask, WHAT quest ions to ask and WHEN to ask them. Then you also need to record the answers from others so you build up knowledge base for yourself.

3. Internet one of your best friends to pick up domain knowledge. There are so many websites which showcase the knowledge and yes you have online courses too. So start your search, register, read and gain as much knowledge as you can.

4. Find a Mentormentoring

Finding a mentor who has years of domain knowledge acquired kills two birds with one stone – you get guidance on your career and you ALSO get to strength- en the domain knowledge.

Wrapping Up
Now we know why domain knowledge is important and some tips on how to increase the domain knowl- edge. As with all learning, the most important aspect of increasing domain knowledge is your DESIRE to learn. If you have the desire, no hurdle will be great enough to block you from gaining anything.

Always desire to learn something useful – Sophocles

That’s all I have for now. Stay positive and have fun picking up domain knowledge in your projects.

About the Author

Ajitha Mannem is a senior test engineer with 9 years of experience in software testing and is currently working for a banking institute. You can learn more about Ajitha at

Design Patterns in Test Automation World

Software development has lot of methodologies and standardized approaches to make the development process efficient such as object oriented programming, domain-driven design, test-driven design and behaviour driven design etc. Automation testing, since the very beginning, has been relatively new when it comes to processes and standards. But now it has gained lot of exposure in terms of standardization and has been under the process of continuous improvement and evolvement through design patterns. Automation testing is a process of developing software to test software. Hence, the test patterns are loosely similar to design patterns that are used in software development.

Design patterns show how to design the test automation testware so that it will be efficient and easy to maintain. The most challenging part in test automation has always been the code maintenance. A lot of test automation projects have drowned or were scrapped due to the inability of the frameworks to cope up with the growing codebases. In order to keep the maintenance cost low, the automation engineers should strive to minimize the code that they reinvent or create from scratch by using existing functionality for common, generic, or repeated operations.


What are the types of Design Patterns in test automation?

1. Design Patterns in Test implementation
From the test implementation perspective, different design patterns can be understood as types of automation frameworks (illustrated in Figure 1):

Patterns2. Architectural Design Patterns




3. Functional Design Patterns




What are the advantages of using Design Patterns?

The use of design patterns offers below advantages:
– Low maintenance effort and time
– Low maintenance cost
– Enhanced code reusability
– Enhanced reliability
– Structured codebase which is easy to fix and extend
–  Improved communication


The design patterns contribute to a major chunk in defining the test automation best practices. The bene- fits of test automation cannot be reaped effectively without implementing the required design patterns specific to a test automation project.

About the Author

Divya Madaan is a test automation specialist with 11 years of experience in quality control. She has extensive experience in various automation tools, frameworks and latest technology. She is currently working with Aspire Systems.

Make Excellence Your Norm

It used to be that you would find a job and stay there for 10 years or 20 years or even until retirement. Those days are gone—as is the idea of job security. You may exceed your performance goals and still be laid off—in a turbulent and changing economy. Nonetheless, you can develop career security, which has many of the same benefits, with the addition of personal control.

Job security is the likelihood that you will keep your job over a long period. In other words, your job is secure if there is precious little chance that you will become unemployed. Assuming you have been a consistently good tester, your job security is largely controlled by factors outside of your control.

Career security is something you can establish for yourself. Career security means you are the one who makes the decisions about where you work and when. When you do what it takes to establish career security, you are in the driver’s seat. You set your own career goals, choose your own path—and then you work to get there. You don’t depend on someone else for your ability to stay employed.

I am not suggesting that you job-hop or plan to abandon your current employer—that is certainly not the case. The truth is that everything you do to enhance your career security will also help you be the best you can be at your current job. If your dream is stay with your current employer forever—the following practices will only enhance you as an employee.

How can you develop career security?

Hustle: Be the best at what you do where you are doing it now. Learn all you can. Volunteer for the hard stuff or the new stuff or the stuff no one wants and make it the envy of everyone else. If you see a problem, develop a solution—and share it. Finding a problem and solving it is your best method for developing the skills you have and gaining others—while demonstrating leadership. Make excellence your norm.

Learn: You have heard about BBST courses, Certified Software Tester (CSTE) or ASTQB certifications, and other learning opportunities. Take a course. Get a certification. Participate in learning activities like, where you gain practical experience while you explore different aspects of testing. I believe in the BBST courses and other experiential learning, but I also work with some rocking good testers who have certifications.

Choose whatever suits your interests and career goals. The point is: keep learning. Stretch yourself. Grow as a tester. Stephen Covey calls that “Sharpening Your Saw.” If you haven’t read The Seven Habits of Highly Effective People, do so immediately. It will change your life. By constantly honing your testing skills, you will be more valuable to your current employer—and you will also be prepared for whatever comes next.

Try something new: You have heard of testing dojos: start one at your workplace. You learned about some new technique? Why not try it? Ask your co-workers and testing friends how they run their tests—and what they look for—and then try it. You might find an exciting new path to success. You may have seen one of the many testing mnemonics (for example, HICCUPPS, which stands for History, Image, Claims, Comparable products, User expectations, Product, Purpose, and Statutes). You can find bunches of heuristics models, mnemonics, and checklists on the Internet. Choose one you haven’t used before—it may inspire you to test in a new and exciting way. You may even develop one of your own. Share it with others. You will grow and help them grow too.

Read: Read blogs by newbie testers and by long-time experts. Read testing magazines and discussion boards for Testing interest groups. You will learn a lot and have new techniques to talk about and try. When someone mentions Miagi-do belts or discusses context-driven or risk-based testing, you will be able to chime in. Reading will give you strong foundational knowledge on which to build and expand your skill set.

Join: User groups, Meetups, Software Quality societies and associations. Volunteer—and you will get noticed— and this will only enhance your learning. You will sometimes get opportunities through a volunteer effort that will help you get to the next rung on your career ladder. Plus, the people you get to know through these groups will think of you when there is an opening at their company. Conversely, you may meet someone who would make an ideal addition to the company where you are now.

Ask: Question everything and find the answers to the questions you can’t answer. Curiosity is what separates a good tester from a great one. Take 10 minutes and answer the question “What if…” as it applies to your current testing project. Asking questions will increase your knowledge and may help you find creative solutions to problems—as well as new ways of testing what you have already tested.

Network: Open an account on and update your profile regularly. In fact, update your resume at least once a year and attach it to your profile. If you keep that updated, not only are you always ready for the next opportunity, you will be prepared if the company you are working for considers you for another internal position (or, alternatively, lays you off). You will be ready—which puts you worlds ahead of other people in your field. Plus, it feels good to have a place to track your career growth.

Write: a blog, an article, a comment on subject in your field (QA, testing) via social media. A recruiter once told me that she was looking for the 1%-ers, which she explained thusly: 90% of people lurk on social media and contribute nothing. Another 9% occasionally contribute a little something. 1% drive the discussions. She said she only wanted to hire the 1%. What that means to you is active (and consistent) participation on key media channels for your industry (or specialty). If you want some ideas, visit here:

Listen: Find podcasts and listen to them during your commute. Ask more experienced testers and managers and leaders in the field—and listen to what they say. If someone you trust gives you feedback, listen and heed their advice. This is an area where finding a mentor can take you a long way. Find a woman (or man) in your field who has the kind of career you would like to emulate and ask them to mentor you. Mentorship can be a transformational experience. When I took the BBST Foundations course—my mentor helped me understand the depth and breadth of some of the new material I learned in the course.

Attend lectures and seminars. If you get one good idea you can take back to work and apply—you will learn and grow.

Share: As you expand your foundational knowledge and grow as a tester, share what you are learning with others. You will find after a while you will become the “go-to” person. If other people know they can come to you for help and advice, it will help you practice leadership and grow contacts and trusted advocates throughout your career.

Putting it all together
Only you know what your goals are, how much money you want to make, what roles you want to play, what kinds of testing and work environments you enjoy. You know your own strengths and your own weaknesses. Develop a plan and try a few of the suggestions above— or add your own. If you do, you will not only increase your job security—more importantly, you will have career security.

About the Author

Karen O’Keefe is a Senior Quality Assurance Analyst with UTi Worldwide, a transportation logistics company. Karen is also an instructor for the BBST Foundations course.

When Bugs Bug You

In my testing career, I have seen testers being pessimistic about the unaddressed bugs. I have heard sometimes “What is the use, even if I file it?”, “they will never fix it”, or “Leave it, they will not be able to reproduce it”. Sounds true!? Such reactions should not be the criteria to stop logging low priority bugs. The perception of a bug differs as we move from department to department or start climbing the management ladder.

The same “hey, it works as designed” bugs sometimes becomes one of the important bug which has to be fixed as soon as possible, and from corner-of-the eye I can see, once disappointed tester now smiling.

It is natural to get disappointed if the bugs are marked as “INVALID”,”WONTFIX” or “WORKSFORME”, but at the same time it provides ample opportunity to the individuals to learn, understand and grow as experienced professionals by analysing the root causes of it.

A bug as defined by dictionary is “A fault or defect in a computer program, system, or machine” but when taken in verb form it means to “Annoy persistently”. The bugs if not handled properly, will keep annoying us. To understand bugs we have to understand their stories. And to stop them from annoying us we have to understand the difference between Ego vs. self-respect and creating vs. existing.

Bugs have Stories
Every bug has its own story and tester is the story-teller. If the story is not told properly, the audience cannot understand it and they will start asking questions. Try watching a movie with Kids, they have lots of questions to ask and you have to answer each question patiently or explain them the story thus far and they will continue to watch it happily without bothering you. In the same way, if the bug story is clearly explained starting from how it looks like, when it occurred, in which way it occurs every-time, in which scenario it’s not observed and when we have captured the intricate details of it then it will not bother us.

Once the story is told to the audience, the work of the story-teller is finished. Now the response of the audience will be decided by the type of story (severity of the bug) and how well it is presented.

Even if initially the bug could be rejected (as it may be not reproducible) but if you present it in a different way and make the developers and the involved team understand, you could as well win a bug bounty of 12,500$ as one of the individual got from Facebook even though initially his bug got rejected. He made a proper video and showed Facebook Inc that it’s a security flaw, and he was awarded. There should be synergy between developer and testers, if testers can make developers understand the criticality of the bug it becomes imperative and it will be fixed.

Ego versus Self Respect
Ego comes when we start thinking that we are the best, and when we start comparing ourselves with others. In this process if we come across some bugs which were rejected, it hurts our EGO and we feel hurt. But if we know that we did our best work and the issue we filed is valid, then that boosts our confidence and self-respect. When we respect ourselves, nobody can hurt us. We should not fall in trap of EGO; it has tremendous power to make self-inflicting wounds.

Self-respect also comes when you have domain knowledge. Question each and everything that causes doubt in your mind. ”Why apple falls? “A simple question resulted in discovery of gravitational force. Issues can be seen from outside but when you know the internals of the system then you can find real issues in the system and log bugs efficiently. When we identify the real issues then certainly it can be fixed.

Ego comes from comparing ourselves with others and self-respect comes when we compare our past to present. For becoming better we have to learn, enhance our skills and be better than yesterday.

Creation versus Existence
When we create something we get emotionally attached to it. We want to protect it; we seek appreciation for our work. The things which are already into existence, we use it and move on to next thing. Bugs are not the tester’s creations but were part of system even before it was discovered. When a tester finds a bug, he/she is only discovering which was in existence even if it was never discovered.

Once we understand that bugs always existed, and we are merely a keen observer whose job is to find it and help the team to fix it, life becomes much easier for a tester and a developer. Defend your bug to a point where you don’t take it personally nor hurt anyone professionally. If still there is no result, it’s still fine, analyze it and understand ways in which it could be presented well or ways in which we could have found a higher priority bug in the same feature or functionality and move on to next issue.

Kill the bug not the relation
We should not write bug reports which reflect the problem of an individual developer, but it should be specific to the feature. Let them understand we are doing our job to make the product better. Maintaining healthy relationship with the developer causes many small but important bugs to be fixed fast.

Every bug like humans has a complete life-cycle. Filing bugs is equally important as having them fixed in the product. We should always file the bugs even if it seems very trivial, but we should not get annoyed or disappointed if it’s not fixed. Every feature and every product poses new challenges, once bug is filed its time to move on and keep hunting. Life is made up of many events and each disappointing event offers opportunity and assists us to turn stronger and better. Don’t let any bug, bug you instead analyze it, report it and let it go. Happy Hunting!

About the Author

Sujata Verma has over 14 years of experience in Software industry and is working in Proxim Wireless as QA manager. She is responsible for complete system level product validation. Prior to joining Proxim, she worked in Analog Devices and Ikanos Communication and has extensive experience in Embedded and network domain device testing.

Show the Way, Then Get Out of the Way

First Steps Through a Coding and Testing Journey

As I drove up to the glass and steel office building in our town, I figured I would pick up my daughter, like I had from so many other school sponsored events. I’d ask her how her night was, she’d say it was “good” and then we’d have a little bit of small talk about her day. On this day, however, the response was not at all what I had expected. On this day, she had gone to a presentation being sponsored by Google and YouTube called “Made with Code”. It was meant to be an introduction to how computers control so many parts of our lives, from conducting traffic, managing trains and helping airliners take off and land, to business functions and fun things as well, including computer games, favorite applications, and the social media tools so many of the kids were familiar with. As she hopped in the car and I asked how her time was, this time, she answered back “it was amazing. There are so many things you can do!” She described a variety of the projects they demonstrated for her. Her breathless enthusiasm made me smile, but it also made me think. In this world that requires so much technical acumen, why shouldn’t I encourage her to learn as much as she wanted to about code and software?

Having been in the software testing world for twenty- four years, twenty one of those years officially holding a job title that had some connection to testing, I felt I’d be a great person to teach her about what it took to learn more about software testing. What struck me as an important perspective to focus on was to help Amber get excited about how computers work, not from a “users” perspective, but from a “makers” perspective.

Perhaps there might be some interesting “discoveries” and reactions from our two perspectives. We both decided to put some practice times into our days, and see if the concepts that I have been learning over the years are easily teachable, or if I might learn more from her interactions than she would from me. That process has had its fits and starts. We discovered that streaks are wonderful when they are established, and they can be motivating when they get going or build up a substantial amount of time. We also discovered that streaks can be big let downs when you find you have to break them, or if something forces you to shift gears. Sometimes, getting back into the swing of regular practice is as difficult as starting over.

For a young person looking to learn to code, frankly now is probably the best time in history, because so much free material can be accessed, played with, reviewed and used in real time, and much of it completely free or very close to free. Sites like Codecademy and Khan Academy have proven to be excellent for this purpose, especially when it comes to basic syntax and general details of languages. Together, we have chosen to focus on three areas; HTML/CSS, JavaScript and Python. Why those three? Well, pretty much any web interface today that allows someone to write or create something to post and share allows for editing documents in HTML, so knowing the markup tags for HTML and CSS felt like a logical first step. Since most modern web pages utilize a lot of JavaScript, which likewise made sense to be a next step. Why Python? Truthfully, I picked Python because it was the programming language I have to date had the least amount of experience working with that’s readily available and in use in many places. It felt reasonable to say “we could learn this together. I could help with broader concepts, but the syntax would be as new to me as it would be for her.

Through the past few months, we’ve learned a lot about each other’s work styles and approaches to solving problems. Additionally, we’ve learned what it feels like to approach an interest together that goes beyond a general hobby and resides outside of mandatory school work. Rather than have me explain all of this, I figured it might make sense to get Amber’s perspective and how she felt about taking this journey.

Make it Real, and Make it Fun
AL: Codecademy was helpful in that it had whole lessons on the basics and how to get started. I appreciated that each segment blended into the next, so that you could work on one step at a time. Several of the projects allowed me to make changes to what looked to be very advanced sites. My dad explained to me after I finished these sections that they were showing me frameworks (the one we worked on that I most remember right now is Bootstrap.JS). The ideas that were being taught were easy to grasp and I felt like I could progress fairly rapidly through a few of the projects, but I felt it was a bit too streamlined to use the framework. I’d make changes that would have dramatic effect on the look and feel of the site, and I didn’t think that would be possible with just a line of code being edited. My dad pointed out to me that a lot is happening under the surface to make it so a simple one line change would have such a dramatic impact, but yes, it was possible to have one line of code made such dramatic changes. The important part was to make sure that I understood exactly how much help I was getting from the system itself. Overall, it made what I was working on feel a lot more real than just writing up a text box and making sure I could put text in it. Feeling like I was actually editing AirBnB was pretty cool.’

Guide Me to Guide Myself
AL: One of the things my Dad tends to do that can be a little off putting is when he sits next to me and “helps” me with some of the assignments and examples. I like the fact that he can help me understand what is happening, but sometimes the “Dad Card” gets played too much. He can be a little to quick to tell me when I am doing something wrong. That gets frustrating. It makes me feel like I am not learning as well as i could. When the going gets hard, that’s when you really start to figure stuff out, but if my dad is too quick to help me, then I don’t really learn what I want to. We finally made an agreement that I would work on my own computer and that I would call him over only when I felt stuck or confused. While I appreciate his input, I told him I was not going to learn anything with him always hovering over me and telling me what to do.

Strive to be Consistent, But Don’t Beat Yourself up if You Can’t Always Be
AL: I will admit that keeping a streak running can show dedication or progress, but it can also give you a false idea of what you’re learning. I have several friends that have expressed interest in learning how to code, and some of my friends have said they’re interested, but haven’t really stepped up to do it yet. By keeping a streak going, I can help motivate them and encourage them to do some of the exercises with me. It’s also possible to do just one exercise a day, and keep a streak going forever, but move really slow. There needs to be a balance between getting points for what you do and learning enough to actually get what I am doing. The other challenge is that, at least with Codecademy, I feel like I am learning a lot about how to use the terms and tags, but I’m not learning enough about where I can actually use it. My Dad pointed out that tools like WordPress, Blogger and Tumbler allow him to have a public place he can show off stuff if he chooses to, and that many of the elements are completely adjustable using HTML, CSS and JavaScript. That availability gives me an opportunity to interact with tools I already know about and work on code in a real place. Doing rather than just reading is the critical part.

I’ve greatly enjoyed these past few months and watching my daughter learn about the various aspects needed to set up a site, use code to make pages or apps that she can use (mostly rudimentary at the moment, but that’s where we all started at some point), and carry on from there. I think she makes some good points that will help other young programmers get the most out of what they are learning. As Amber sums it up “Keep it simple, make it fun, and do a little at a time as often as you can”. That’s great advice, both for an Intermediate school girl and for her twenty-four year veteran Dad.


About the Authors:

Amber Larsen is winding down her Intermediate School years and getting ready to enter High School in the San Francisco Bay Area. When she’s not playing around with web pages and figuring out code syntax, she enjoys Japanese Manga and Anime, music from both Japan and South Korea, watching K-Dramas and having fun with cosplay and attending events where she can meet other creative people.

Michael Larsen is a Senior Quality Assurance Engineer with Socialtext in Palo Alto, California, USA. Over the past two decades, he has been involved in software testing for a range of products and industries, including network routers & switches, virtual machines, capacitance touch devices, video games, and client/server, distributed database & web applications. He is a Black Belt in the Miagi-Do School of Software Testing, President of the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and a founder and facilitator of the Americas chapter of Weekend Testing. Michael writes the TESTHEAD blog ( and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at