Advocate With Confidence

As testers, we are the champions of bugs. However, how often than not have we had to convince developers and other project stakeholders that a bug is a bug!! There are courses, books and blogs that teach us how to write effective bug reports and tactfully convey defects to stakeholders. Bug advocacy is a persuasive exercise where we have to sell our findings, sometimes in the form of an unwelcome news or at the expense of pointing out someone else’s mistake. As professional skilled testers, we know to stick to the facts and keep it neutral. However, sometimes the challenge is in having the courage and confidence to stand by our reasoning. A lot of the time, it’s the loudest and most opinionated people that get heard even though they may not necessarily have the right or only solution. When working with dominant personalities, it can be easy to start doubting our own voice which stands in the way of it being heard.

If we arm ourselves with the confidence to trust our instincts and believe our abilities, we are better equipped at standing a firm ground and not let others sway us easily. After all, in the case of bug advocacy, we have tested the system thoroughly and we know we are one of the most knowledgeable person in that area. However, to have that firm belief in ourselves requires a deep self-awareness and being truly comfortable with who we are.

We’ve all heard of the quote, ‘fake it till you make it” which is a wise old saying advising people to exude feigned confidence until they start to become it. Unfortunately, pretending to be something that we’re not is difficult and takes up a lot of our energy. We are at risk of coming across as disingenuous as we’re not allowed be our authentic self. Building and maintaining credibility is important in bug advocacy. To have credibility, we need to first have trust, and to have trust, not only do we need to prove that we’re capable, we also need to display genuineness so that others feel confident to rely on us. So instead of putting our energy into pretending, why not shift our focus and transfer that energy into developing and growing our confidence. In this article, we’d look at three ways that will help increase our confidence, whether it’s for advocating bugs or advocating for other worthy causes.

1) Surround yourself with good people and be one of them

How we feel about ourselves should come from within. Unfortunately, that’s harder said than done and external triggers tend to have a stronger influence on the way we feel. We seek validations from people around us and the media tells us who we should be. We feel the pressure to be someone else and when we don’t meet that expectation, it can feel like we have failed, knocking away at our confidence.

We might not have much control over what the media portrays to us but fortunately, we can choose the people that have an influence over us. So be selective and smart in who you let into your inner circle. Find the right people around you that allows you to be yourself. Think about who are these people at work, in your social group, your friends and family and find support and guidance in this group of people. There is a lot of people in the world. Statistically speaking, there will always be people out there ready to criticize your every action but equally there will also be people out there wanting and willing to support you. So if you arm yourself with a strong network of supportive friends, it is harder for the other half of the population to knock you down.

Humans are reciprocal creatures and if you let go of your own judgments and start to get to know people, you’d find there’s a whole web of interesting people outside your network. Don’t limit yourself to your existing group of friends, try something different and be open to meeting new people. As you weave and welcome more diversity into your inner circle, you’d find there’s less pressure to conform and you’d feel more confident in your own skin.

2) Learn, up-skill and work on your weaknesses

This really is a no-brainer. Without a doubt competency is closely correlated to our confidence. As a person gains more experience and becomes more skilled in a particular area, their level of confidence also increases in that area. The only catch is that experience requires time and up-skilling requires a lot of effort – and there is no short-cut.

The good news is that it does get easier. Once we learn and gain expertise in an area, the next time we learn a new thing in another related area, it would require less effort. Remember your very first testing project where everything was new! The subject matter, the business processes, the testing principles and not to forget, learning the names of all the people on the project. In your second project, there would have been new learning’s but you would have learned a lot faster as many of the skills would have been transferable from your last project. This applies to everything you do and as you collect more experience and skills, you have more tools and tricks to recall upon the next time you are faced with a new learning opportunity.

So learn as much as you can and master everything that you do, be it the system you’re testing or a skill that you’re wanting to develop. Be open to opportunities that allow you to up-skill or allow you to add something new and different into your special skills tool-kit; whether it’s attending training’s and conferences, attending local meet-ups or joining a new club. Even attending your own company’s social events could help you learn new skills or open you up to new experiences – You never know when or what could be just around the corner. The internet too hosts information at your fingertips, all you have to do is look and learn.

It’s a universal truth that we’re different. When we’re all different, we also have different areas of strengths and unfortunately different areas of weaknesses. Strengths make us stronger but weaknesses breed insecurities. So ask yourself what they are and work at it. When we get better at a skill that we’re already good at, it’s easy to become arrogant. But if we master a skill that we’re not so good at, we have to put in more work. We feel a greater sense of achievement and this increases our confidence to set and meet the next un-achievable goal.

3) Say yes and don’t be afraid to own up to mistakes

We’ve established that new experiences give us the opportunity to hone new skills and make us more confident individuals. However, we often miss out on the opportunities because we feel we don’t have the right skills or think the task is insurmountable. This is tragic because we’ll never find out if we don’t try and we may lose out on developing new set of skills and meeting new people who can help us learn.

There’s a few things that we can do to help us put our hands up for new opportunities. Firstly, don’t over analyze and just do it. When we over-think, it’s easy to talk ourselves out of doing something as we start thinking about the consequences of when things go wrong. We see the possibility of failure and lose our courage to pursue the task.

Secondly, it’s important to know that nothing ever goes according to plan. More than likely, something is bound to go wrong and tell yourself that this is not a failure. It’s how we handle the unexpected that dictates how successful we are. It’s also very easy to magnify a mistake in our eyes when most of the time, it goes unnoticed.

Additionally, not being afraid to own up to our mistakes if/when things do go terribly wrong will give us the courage to embrace challenges. Next time when there is a bug that requires to be advocated, be confident and stand your ground. If the result turns out to be an error on our part, own up to it with confidence! There is no shame in making an error.

However, it doesn’t matter whether we’re testing or doing something different, confidence can dictate our actions. So pick the right people in your life that can boost your self-confidence and give you the sense of security to let your personality shine through. Continuously work on developing and up-skilling so that we always have a pool of shiny tools to pull from. Lastly, open yourself up to opportunities so that we can develop the skills and be the confident person that we want to be.

There’s a saying ‘The rich become richer’ and just like confidence, the more challenges we overcome, the more confident we become to try out new opportunities. Happy learning.

About the Author

Alice Chu graduated with a degree in Engineering and landed her first job in testing. She has found the skills she gained from her training very beneficial to her role – a desire to understand how things work and asking why. Passionate about continuous improvement, Alice is interested in all areas of testing which can help projects run better and empower testers. You can find her tweets @ecilauhc.

Agile Tester – from Novice to Intermediate

I started out as the only tester on an agile team without any former knowledge of testing, experience with agile development or other testers to learn from. I evolved from novice to intermediate by falling into every possible pitfall on my way and learning from my mistakes. This is the story about those pitfalls and what I learned from them.

As many testers before me, I came into the testing business by coincidence. The only thing I had in my baggage was a couple of years working experience as a web developer and a Bachelor’s degree in Computer Science. I hadn’t learned much about testing during my studies, only a bit about the difference between white box and black box testing and something about usability testing.

The reasons for the company I work with now to hire a tester was a wish to increase the quality of their deliveries and to have less regressions. They had no past experience having a tester on the team and no knowledge of what exactly was needed. My job was therefore to begin mainly with manually testing new features and to look into the possibilities of doing automatic regression testing. For this of course my background in programming was a bonus, but my lack of testing skills and knowledge of how testing fits in the process – and especially an agile one – slowly showed its impact.

I’m telling this story because I have the idea, that others like me fall into the testing business by accident and have to figure things out by themselves. My hope is that some of the pitfalls I have encountered will amuse you and enlighten you.

The Gatekeeper
In the beginning I was assigned the responsibility of testing every single feature in the project. In the issue tracking system I had a “Ready for test” column, where the developers could hand over features they regarded complete and I would start testing. The problem with this approach soon appeared. Features piled up, the burn-down chart looked terrible because very few features moved fast enough to the “Done” column and the project leader got frustrated. I had turned into a bottleneck.

The problem with gate-keeping was that I got the role as “law enforcer”. Instead of collaborating with the developers – being a team – I had heated discussions about what was right and what was not. Now I know that neither of us had the right answers. The right person to judge would of course be the customer. My role should not be to guard – but to guide, inform and support.

Test it all
I also learned another important lesson. Everything was not equally important. I had to prioritize my testing. It didn’t make sense to test every single bit, it made testing expensive, my teams hair turn grey and the customers lost faith. Instead I had to ask the customers what mattered the most and use my time on that. Of course with input from the developers as well about which features constituted the biggest risks.

In love with the tool
My project manager had found a framework for doing automated functional testing and sent it my way for further exploration. With a background in programming I found it exciting to play with the tool and since it was easy to quickly automate a lot of manual flows, that’s what I did.
But soon the nightmare began and I learned some hard earned lessons. Just as it doesn’t make sense to test it all manually, it doesn’t make sense to automate it all. Not all tests are suitable for automation. Or put in another way – the benefits are not commensurate with the cost. I also learned that it’s not the start-up cost of automation that matters – but the cost of maintaining the tests in the long run. I had to think of return on investment and not just about making good tests.

Even though it felt safe and comfortable to rely on a tool it also became very clear that it’s not mastering a tool that makes you a good tester, but your experience and skills in test that do.

You can quickly automate a lot. But the value depends on how you write the tests. Automatic tests are code and should be treated as such. That means the same high standards to the quality of the code should apply to the test code as to the production code. The tests should be readable and understandable – even for the customers. And that brought me to Behavior Driven Development (BDD).

First things first
To ensure that we build the best possible product that satisfy the customer’s needs it’s not enough to just test that we build the things right but also to test that we build the right things.
After a while I discovered that some issues kept turning up again and again. Issues we thought were completed had to be discussed again. The customer was not quite satisfied with the solution, we had missed some important requirements. We could easily start a blame game about who had failed to deliver or collect the required information, but that would not be constructive. In agile development there’s a balance of not over-specifying things up front and still get the right information in time. Things change on the way in the project and there should always be room for that.
The problem of some small issues reappearing after a sprint is done might not be as big an issues in agile development as in a traditional approach, but it still breaks the flow, forcing you to halt. The way we gathered requirements could be improved.

Instead of just being a tester that did checks when a feature was complete, I started being involved from the beginning of the projects. Until now our approach to BDD was mostly focused on the benefits of automating the business requirements as tests, so we could have living documentation and regression tests. We found out that the real value of BDD was not the automation but having the conversations with the customers and discussing and gathering examples. The power of examples is that it forces you to ask questions, leading to rules, edge cases and a common knowledge.

Member of a team
From being a tester that measured my success in how many bugs I could find, I now define myself successful when I have helped the customers and the team to avoid misunderstandings and having the requirements fleshed out.
Being an agile tester is about collaboration and helping the team. The value you add is not about your individual contribution but about the success of the product. It takes courage to involve yourself and not just sit in the corner doing checks and validation. But it’s worth it, you grow as a human being and your value to the project rises.
Still being far from an expert on the field, I would love to hear your opinions. Feel free to contact me in any way.


About the Author

Rikke Simonsen works as a technical tester at Reload! A/S. Reload is a danish consultancy specialized in complex websites based on Drupal, an open source Content Management System. Rikke is passionate about BDD and is the organizer of the “Copenhagen BDD Meetup” . She is @vanilleDK on Twitter and can be contacted at [email protected]

Being Fearless

There has been some recent discussion in the testing industry about women in testing and in particular, the ‘voice’ of women in testing. There are thousands of talented and dedicated female testers across our testing communities, however it seems to me we are less likely to share our stories and experiences in public forums. This is something I feel strongly about: that there need to be amazing women for those who are new to the industry to see and aspire to be in testing, and in tech in general.

I have been one of the quiet ones up until now. In my day-to-day life I constantly push boundaries, and am more than happy to raise my voice when needed. I also play a lot of football (soccer), predominantly as a goalkeeper. In some of the competitions in my city there are no women’s leagues, so I play in the men’s ones, because that is where I get a game and where most of my football friends play. I don’t ask permission to join these leagues, generally, and while I do occasionally get kicked out of some, I love that I see more and more women playing in these leagues and playing well. I don’t claim to be a great player or leader by any stretch, but feel that by just playing and holding my own, I have helped encourage others. The other bonus from this is that my game improves dramatically as I get new challenges and face different styles of play that I wouldn’t if I just stuck to my regular leagues.

Why then is it so hard for me to make myself more visible in the testing world, when testing is something I really enjoy and am passionate about? For those that have met me, you probably know that I am always happy to have a chat about testing in person. I join in testing conversations at the events I attend, but living at the bottom of the South Island of New Zealand makes it difficult to attend more. So we come to writing about my experiences. This is an area I have shied away from up until now. There are a few reasons for this but the major one for me is Imposter Syndrome.

When I have previously considered writing about my experiences with testing, I have started to think I am not as good as other testers who will read what I write, that I don’t have anything worth to sharing, and if I did share, I would be exposed as an incompetent tester. I tell myself that I am not technically skilled, have nothing new to share that hasn’t already been shared, or in the case of Twitter, often feel that I am too late to the conversation, or won’t offer anything that hasn’t already been said. I even suffer from this at my work sometimes, where although I am told I do great testing and feel confident that I have done my best, I worry that I have missed a serious bug that will affect my company or that someone will come along and ‘out’ my work as majorly sub-standard.

Well no more! I made a commitment to myself this summer to be more fearless as a goalkeeper, to challenge harder and push myself to improve, and I realized that I should extend this to my testing. I need to be more fearless and that will encourage others to be more fearless. Even if my experiences and insights are old hat to some people, they will be new to someone else. If I say something wrong and am challenged, that is ok, I will be learning and improving my craft. I will build my technical skills as I ask the questions that I need answered and in turn that will help someone else. Most importantly, I will be the voice I want to hear, one that is confident and growing, and adding to an ever growing list of other talented women. Expect to hear more from me soon.


About the Author

Rachel Carson is a context-driven tester from Dunedin, New Zealand. Rachel got her testing role after originally applying for the role of a scientific writer at her current company. They offered her a testing role as they thought it suited her better, and she has never looked back. Getting to test desktop apps, cloud based systems and hardware, as well as using domain knowledge has ensured that her role is ever changing and challenging. Rachel is @akiwitester on Twitter.

Career Advice From One Tester To Another

When I was asked to write an article for Women Testers magazine, I thought about what I can contribute in the context of the mission behind Women Testers: “to bring out the best in YOU”. I’d like to share some things that I feel helped my career as a woman tester. I learn best by example, so here are my own examples!

Network for improvement

I had an advantage when I started in the software industry: at the time, there were plenty of women programmers and analysts. I had many role models and mentors. For example, when I was a programmer with the University of Texas Libraries, the team leader was a librarian who was also good at code design. She taught me the importance of domain knowledge: once I learned library science, I could contribute much more value. I learned to collaborate closely with the librarians so we could build the right circulation system and online catalog. I feel these are still my main strengths as a tester: learning the business domain quickly, and working together with the business experts to help them identify valuable features and articulate their requirements.
Since the late 1990s, however, I’ve often been the only woman on my software delivery team, so if you started out during this period, it’s hard to find that kind of support. Fortunately, you can join communities such as Women Testers, Women Who Code, and Systers to find your own mentors and role models. Local testing user groups and meetups are another great place to build your supportive network.
One of the best ways to learn is to help others learn. When I was a programmer trainee, I was offered the job of “education coordinator”, and I gladly took it. I had to oversee a program of training classes that we programmers offered for our customers, so that they could learn to code their own reports in the 4GL we used. I also found that pairing with newer trainees to help them learn reinforced my own skills. Share your experiences by presenting at local user group meetings and conferences. Having a conference session accepted is also a great way to get to a conference more affordably!

Find your courage

People who have met me at conferences may not think it, but I’ve always been quite shy. I enjoy working with people and facilitating learning, but the experience leaves me exhausted. My first job after MBA School involved going to local governments and doing research and surveys. Having to cold call city managers (I have a phone phobia, too) was terrifying. My manager built up my courage. He told me, “Go bite ‘em on the leg, Lisa!” He didn’t mean I should be unpleasant, but just that if I got scared, I was capable of defending myself! And it made me laugh, so it made me brave.
When I subsequently joined a software delivery team as a programmer trainee, I forced myself to speak up at meetings if I had a question or an idea. I found that others often had the same questions but were too shy to ask. Getting people to explain things helped me learn and was rewarding.
One of my early managers (who was male) taught me a valuable lesson: communicating the contributions you and your team have made to management and people outside the team is part of leadership. I find that women are often reluctant to “toot their own horn”; I certainly am. But making our accomplishments visible helps us lead by example. I believe this advice is a major reason that my career has been rewarding.

We testers need lots of courage. Don’t be afraid to ask questions. In standups, say what you contributed yesterday. Keep track of your accomplishments, and communicate them. When I was a test team manager, I wrote a short summary to the company management each week listing ways my team had added value. Experiment to see what’s most effective for you and your team.

Look for the opportunities

One of my mantras is “If you can’t be smart, be lucky”. But we often make our own luck. Early in my career, I worked for what was at the time a sizeable software company. However, that company failed to perceive industry trends and was getting left behind, with their products seen as outdated. And all I knew was their hierarchical database, their proprietary 4GL, and so on. How would I find a new job if nobody used my employer’s products anymore?
In an attempt to build business, the company branched out into supporting many operating systems, including VAX/VMS, Wang, and all flavors of Unix. By this time I was a tester, and I volunteered to learn these other operating systems and do the testing. A whole new world opened up! I received training in system administration skills for these various platforms.
The company also started supporting relational databases, and I raised my hand right away to go to a

SQL course and start testing our products with Oracle and Sybase. OK, learning Wang didn’t help much in the long run, but my Unix knowledge and SQL skills got me a great new opportunity with a growing software company.

If you enjoy learning, and seize every opportunity to learn something new, you’re going to have a rewarding career. New skills can help in unexpected ways. And being good at learning is a skill in itself, which you should practice as much as you can!

How to find the time?

This sounds like a lot of work! I’m often asked how I have the time to write books, learn new things, and prepare conference sessions, on top of my full time job. If you love what you do, then you make time to do it. To excel at any profession, you have to practice. Think of Malcolm Gladwell’s 10,000 hour rule in Blink. Successful musicians, craftspeople, physicists, they all spend years practicing, learning, improving.
If you’re working a stressful job 60 hours per week, or you’re a single parent, of course this is going to be a lot harder. But try scheduling a bit of time every day to learn and practice. I’ve written three books by spending at least five minutes a day writing them. Five minutes isn’t much, but look at the size of those books!
If you’ve built a supportive professional network, you find your courage, and you seize unexpected or unlikely opportunities, you’ll learn ways you can improve, and grow your career. It’s trite to say “follow your passion”, but I think that’s what we have to do!


About the Author

Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014), Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 2009). Lisa was honored by her peers by being voted the Most Influential Agile Testing Professional Person at Agile Testing Days 2012. Lisa enjoys working as a tester with an awesome agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world. For more about Lisa’s work, visit, and follow @lisacrispin on Twitter.

Answering the call for proposals

Lack of female speakers at technology conferences. A common topic of discussion, particularly among women who want to see more of their peers take the stage. I think that a first step to improving the current state would be to have more women responding to Call for Proposals (CFP) issued by conference organizers. Writing a proposal can feel like a prohibitive hurdle to those who are new to speaking at conferences. A proposal does require some effort to compose, while offering no guarantee that the effort will be rewarded with a speaking engagement. Having written a few proposals, I’ve come to realize that there is a common expectation in what they should contain, and that writing a proposal is not nearly as onerous as I originally imagined.

The purpose of a proposal is to pitch an idea to the organizers of the conference. You do not need to have an existing presentation prepared before proposing. Instead you imagine how you might communicate your experiences or knowledge to others, then describe this vision.

In my experience, a conference proposal usually has four key parts, which are:

● Format
● Title
● Abstract
● Learning Objectives

How I tackle these when writing a proposal differs from how they are requested when submitting a proposal. When I write a proposal I begin with the abstract, which might also be referred to as the presentation description. A simple abstract has two paragraphs, where the first states some problem or opportunity then the second describes what the presenter will talk about. With this structure in mind, I roughly note down my ideas, often in bullet point format or sentence fragments dumped into a document.

From this skeleton, I work to create polished prose. An abstract is a marketing tool, so I aim to tell a compelling story that will make people want to attend my talk. I try to keep my language simple, easy to understand and persuasive.

Usually I only know the format that I want to adopt once I have completed the abstract. The available formats will differ between conferences, but may include a short or long presentation, half or full day tutorials, or hands on workshops. Consider how much you want to communicate to your audience, and which format the material is best suited to. Most new presenters will stick to a familiar method of delivery and choose to present from a set of slides.

Next I consider the learning objectives, which may also be described as the learning outcomes or key takeaways. This is generally the point where I determine whether a proposal has merit for submission. I like to aim for five succinct bullet points that explain what I feel people may learn from my session, where each begins with a different descriptive word. Bloom’s Taxonomy is a really helpful reference for giving me the correct language to express where I imagine people will find value.

Once my idea is defined with an abstract, format and learning objectives, then I attempt to label it with a title. This is my least favorite part about writing a proposal; I find it quite difficult to summarize my message into a catchy one-liner.

When writing a proposal, I place a one hour time limit on this entire process. In my experience this is enough time to determine whether I have an idea with merit, then write a proposal that describes it to others. Remember that a minimum output is two paragraphs and five bullet points, which is not much at all!

Before submitting a proposal to organizers, I seek feedback from my peers. I am lucky to be part of a strong community of testers in Wellington who are happy to complete proposal reviews. If you can’t think of someone to ask to review your proposal, there are people with an interest in improving gender diversity in technology that will be willing to assist you:

Speak Easy – a new initiative from Anne-Marie Charrett and Fiona Charles.

A Line at the Ladies Room – a mentoring programme co-ordinated by Lorinda Brandon.

Proposal feedback will usually include phrasing, spelling and grammar; it’s amazing how many errors slip through the gap between what you meant and what you actually said. The reviewer should also highlight any areas of the proposal that are unclear. If your reviewer needs to ask a lot of questions to understand your proposal, then attempt to include your answers to their questions in the proposal itself. This will make it much clearer when you submit to the organizers.

Updating the proposal after feedback and submitting it can take as long as writing the proposal itself. Some conferences request a proposal via email while others enforce a standard submission format through an online form. Altogether, I usually spend about two hours pulling a proposal together.

You may be wondering, is this worth it if I don’t get accepted to a conference?
Even though my proposals are not always selected, I find the process of writing them to be valuable. A call for proposals is a worthy excuse to spend a relatively short amount of time reflecting on my work and considering which experiences and ideas I could share with others. Though I find it challenging to articulate what I want to present, writing a proposal prepares me for a number of other conversations. Having thought about how to frame my work to others, I can eloquently explain myself in meetings with senior stakeholders, client managers, and my own boss.

A Call for Proposals is an opportunity to have your voice heard by speaking at a conference. It is also a platform through which you can find your voice by practicing writing proposals. The review process may also help you create new connections with testers in the wider community, or strengthen relationships in your existing networks.

I believe the benefits of responding to a call for proposals far outweigh the investment. I hope that many of you will consider responding to the next call for proposals that interests you.


About the Author

Katrina is an active contributor to the international software testing community. She is the Editor of Testing Trapeze magazine, a co-founder and organiser of WeTest Workshops, an international speaker, frequent blogger and tweeter – @katrina_tester.

Katrina works for Assurity in Wellington, New Zealand. She is the Practice Lead for Lean Testing, the lead trainer for the Agile Testing course, and the content owner of the Assurity graduate programme.

The False Security of Compliance

With the primary focus of an organization being “the bottom line”, it’s easy to see why compliance is at the forefront and more businesses, especially multinational corporations, are making it a priority. In heavily regulated verticals like healthcare and banking, being non-compliant is costly. For organizations that provide goods or services, being compliant can impact whether or not an entire market area is available or change the outcome of a sale. Even though compliance is essential in many cases, having “blind faith” in compliance is bad news for organizations.

Let’s look at compliance from the perspective of a new motorcyclist. In order to attain a motorcycle license in the state of Ohio (USA), riders take a written test to demonstrate knowledge of the law and a driving test to demonstrate ability to safely operate the motorcycle. Once both tests are passed, a license is issued and they can operate the motorcycle within the boundaries of the law. If at any point the law is violated, the riders risk fines or license revocation. At predefined intervals of time after licensure, the license must be renewed to continue operation of the motorcycle.

Sound familiar?

Compliance, in technology, refers to the need for an organization to have controls for processes in place for things like how data is stored or retrieved. Gaining compliance works in a similar fashion as licensure. A regulation is studied, written documentation and a demo are created to prove adherence to the regulation, product is assessed to determine if it is certifiable and is issued a certification, and, once certified, the certification must be renewed at predefined intervals. While certified, if the product fails to meet the regulations the organization faces fines or loss of certification. Of course compliance has its place in our organizations and in some verticals is mandatory. Just as a motorcyclist should not be able to drive without laws for proper use, regulations should be in place to govern how businesses receive, access, share, or store personal data. However, complying with regulations is not enough. After all, having a license to operate a motorcycle does not make you a safe motorcyclist.

So what about security?

A compliant organization must be secure, right? No; in fact, compliant organizations may still face breaches and costs related to non-compliance. Solution: shift the focus to security. In technology, security refers to the protection of data focusing on three elements known as CIA: Confidentiality (C) which prevents unauthorized access to data by implementing the “Need to Know” principle; Integrity (I) which prevents modification to a record that is in storage, being processed, or in transit; Availability (A) which prevents against denial of service to authorized users. Protecting data can be accomplished in a variety of ways from strong password policies to entire network designs but each protective layer serves its purpose.

In the state of Ohio, there are no laws that regulate what a motorcyclist wears; even helmets are not mandatory. It could be inferred that as long as the riders follow all of the laws, they will be safe; however, not all circumstances can be predicted. Even if they follow all of the laws, a risk that someone else may not still exists and without proper attire, injury will likely occur. On the other hand, if the riders wear non-required protective gear they will be more prepared for the unexpected and will lower their risk of injury. In technology, security refers to the protection of data.

Secure systems are unique to each organization. Although costly at inception, the return on investment (ROI) is greater when secure systems are in place. It is evident that being compliant does not equate to being secure.

According to research completed by the Ponemon Institute, it costs an average of $3.5 million to comply with mandated and optional standards. According to a study completed by Nelnet Business Solutions, initial costs for complying with PCI range from $50,000 to $250,000 depending on the size of the organization not including annual costs to maintain the compliance or gain the certification. From the standpoint of a ledger or numbers only, it is easy to see why organizations that are mandated to comply with specific standards choose compliance as the focus.

Implementing security can also be very costly, especially for small businesses (organizations with fewer than 100 employees). The SANS Institute estimates that implementing a basic security structure for a small business would cost approximately $15,000 for software and hardware alone. If the business is serious about security and hires an IT person to monitor the system, the cost grows to include salary and benefits. After the secured system is in place, the company still has to pay for whichever standards are required in order to operate.

If switching the focus to security is going to increase the overall initial cost, why should any organization do it? For the same reasons that a motorcyclist should wear the proper gear. Purchasing all of the protective gear upfront will be costly; however, it will greatly reduce the risk of injury and costs if an accident occurs.

●Ditch the flip-flops and buy boots.

Obsolete and New Technologies – Technology is constantly changing and for some companies and verticals it is very difficult to keep up with this technology sprint. Obsolete technologies in use increase vulnerabilities and implementing new technologies without thoroughly testing the change first can also cause vulnerabilities. In many organizations upgrading to new technologies is completed in phases creating environments where obsolete and new technologies are used in conjunction increasing risk. The race to stay current while keeping data secure can be accomplished with a strong security focus.

Ditch the shorts and buy pants that will protect you on any

Evolving Security Landscape – Standards and regulations are often too far behind the ever- changing technology and security landscape to be relevant. The security landscape is volatile; changing with each new technological advancement or newfound exploitation in small bursts of time. Although most standards have a review and update process, more often than not the deadlines are pushed back and changes come years later practically nullifying any parts related to security at conception. Shifting the focus of an organization to security safeguards the organization and decreases the likelihood that vulnerabilities will be found and exploited.

Cover that holy tee-shirt with a new jacket. 

Perform Risk Analysisor Security Audits– Only a few standards, for example HIPAA (Health Insurance Portability and Accountability Act), actually require a risk assessment to be completed before attaining compliance. The Ponemon Institute’s research shows that 28% of companies do not perform security audits. Organizations should realize that vulnerabilities exist; if they are not the ones finding them, someone else is finding the vulnerabilities and exploiting them on behalf of the organization. Performing regular security audits and risk analysis of the organization’s systems is a necessity.

●Hands are important too so buy some gloves. 

Reduce Risks of a Breach by Training Employees – Being compliant is, essentially, adding a checkmark to an item in a checklist to indicate the criterion is met. As mentioned before, having a secure infrastructure with updated technologies that undergoes regular security audits can reduce a risk of a breach. Proper training of employees is essential to reducing risk. Most standards do not require a subject matter expert or that any particular group is trained on the criterion. If an employee does not have knowledge of basic security, such as do not write down network passwords, or an organization does not have a security policy in place, the risk of a breach increases. Reduce this risk by properly training employees and creating, if one does not exist, a policy for security practices.

Protect your livelihood and buy a full-face helmet.

Prevent Costs  to the Organization- With lax security, a breach may occur. Although being compliant may reduce the organization’s accountability, it will not prevent all costs. Monetarily an organization may face fines if found to be non-compliant, costs for purchasing new technologies or making repairs, or even lawyer fees if any lawsuits arise. Other than monetary costs, the organization faces loss of customer loyalty, brand repair, and declines in new business. By focusing on security, the risks of a breach decline and organizations will likely never endure the process of recovering from a data breach.

Once properly suited, the motorcyclist can safely take to roads and enjoy the ride. Similarly, once properly secure, organizations can focus on preventative actions and reduce the likelihood of a breach; avoiding the aftermath of costs and brand damage.

Remember, when data breaches occur it is unlikely due to a lack of compliance and more likely due to lax security. It is evident that being compliant does not equate to security. Despite the initial cost, security will have a better ROI for the company. In order to not be the next organization breached and reported on the news, companies need to switch the focus from a compliance perspective to a security perspective. Just as the adage “Better safe than sorry” states, it’s better to be secure than to just be compliant.


About the Author

Rachelle Below is new to software testing but has a real passion for the craft and for learning about testing. As an avid learner she spends time reading (blogs, magazines, books, and Twitter) and conversing about testing when possible. Currently, she works as a compliance analyst and looks for ways to meld compliance, security, and testing into projects. Follow her on Twitter @achelleRay.

Problem Solving and Logical Thinking

Testing teams are considered as problem identifier and testing profession as mediocre job suitable for persons who have lesser analytical and logical thinking. Tester has to in cult logical and problem solving quality to change the perception of the dev team. Primary users/reviewer of product or project being developed is none other than testers. Throughout the project testers feedbacks are extremely valuable to build robust, reliable and scalable applications. To provoke healthy arguments or discussions for value addition to the application, testers should exhibit their logical and problem solving quality.

Let us see, in detail of building Logical thinking and Problem solving.

What is critical thinking/Problem solving?
The simplest definition is offered by Beyer (1995): “Critical thinking… means making reasoned judgments” (p. 8). Basically, Beyer sees critical thinking as using criteria to judge the quality of something, from cooking to a conclusion of a research paper. In essence, critical thinking is a disciplined manner of thought that a person uses to assess the validity of something (statements, news stories, arguments, research, etc).
Critical thinking in our context is defined as thought process of testers involved in the project or product in assessing the validity or quality of application and their related artifacts (input documents to client deliverables).

Levels of Critical Thinking
Benjamin bloom in 1956 identified six levels of critical thinking; in this article let us see how the six levels are applied to software testing discipline.

Level 1: Knowledge
“Exhibits previously learned materials by recalling facts, terms, basic concepts and answers.”
Key Words: Who, What, How, Where, When etc

Level 2: Comprehension
“Understanding facts and ideas by organizing, comparing, translating, interpreting, giving description, and stating main idea”
Key Words: compare, relate, illustrate, classify, explain, infer, outline etc

Level 3: Application
“Solving problem by applying acquired knowledge, facts, techniques and rules”
Key Words: apply, use, build, interview, make use of etc.

Level 4: Analysis
“Examining and breaking information into parts by identifying motives or causes. Making interference and finding evidence to support”
Key Words: analyze, categorize, classify, compare, contrast etc

Level 5: Synthesis
“Compiling information together in a different way by combining elements in new pattern or proposing alternate solution”
Key Words: compile, build, invent, make up, original, minimize, maximize, improve, change, test etc

Level 6: Evaluation
“Presenting and defending opinions by making judgments about information, validity of ideas or quality of work based on a set of criteria”
Key Words: conclude, determine, evaluate, measure, recommend, appraise, estimate etc

From Level 2 to Level 6 apply the Level1 keywords to generate output related to each stage of problem solving. Example in level 2 following question shall be posted to identify the solution:

a. What to compare?
b. How to compare?
c. What do you infer?
d. How do you outline?

What Makes difference – in Tester
Software testers are required to apply strong imaginations, creativity and intelligence to gain empirical information about the application or product under investigation. Testing requires information analysis and using logic to address the work related issues. In addition it also requires creativity and alternative thinking to develop new ideas for and solution for work related problems.
Let us see some of the critical testing related activities were the critical thinking could benefit us.

a. Requirement Analysis
b. Defining Test Strategy

a.Risk Analysis and Mitigation
b. Designing Test Case in complex domain

          c. Defect Analysis

Testers are sole proprietor for activities listed above. The success of the activities unveils our ability and capability to our cross functional co-workers, that would change their perspective on testing discipline.

Implementation of logical and problem solving by tester in their day to day activities is detailed here:

Requirement Analysis
Requirement serves as base upon which the project or product built in future. Testers are the authorized personnel to certify whether the application is working as intended as per the derived requirement. Primary responsibility of tester is to validate the requirement for consistency against business domain.

Proceeding with “Requirement Assumptions” is like sailing in the ship without compass. Testers are required to “Question their Assumptions” based on their earlier experience or by knowledge acquired by any means or domain to clarify the requirement. This would help all the stakeholders in identifying ambiguous, unclear, missed and uncertain functional validations. This would add credibility to the testers because finding defects earlier in life cycle saves cost, as study reveals more than 50% of the defects are from requirements.
Down the line as things headway testers should be positioned as master of requirements in guiding other stakeholders. To gain comprehension on requirements one should pursue “What, How, When, Why, Who, Where” key words defined by Benjamin critical thinking. A query would probe others to unveils hidden information, ambiguity and develop a robust questionnaire.

Some basic queries to post are as follows:


The queries should be tracked to closure, to identify the benefits attained by pursuing the skill, as well as would help PL/PM to construct metrics on quality of requirements and analyze the skill level of testing team in understanding business requirements.

Test Strategy
“Test Strategy” speaks about testing objective, methods of testing, new functions, resources and effort required for the project and test environment, risk and mitigation at the test level, types of test to be executed, and entry and exit criteria for testing”. Test Strategy is the mother document of testing team which demonstrates the stakeholders on testing solution provided by the team.
Here comes the question, what forms the basis or input to the test strategy. Yes, the queries solution and our knowledge on application act as source for Test Strategy.
Following activities are to be carried to plan test strategy.

a. Break the application into logical parts
b. Model the app using the logical parts
c. Brain storm along with the team to

a. Identify applicable test objectives
b. Identify feasible and impractical features of testing
c. Identify appropriate tools and techniques to be implemented
d. Identify the risk involved in testing
e. Attain mitigate plan for the risk
f. Different approach of testing the app by

i.       Previous experience
ii.      Shared knowledge from team
Iii.    Identify the levels and types testing
Iv.    Entry and Exit criteria of testing
v.      Finalizing the approach by discussion both the sides of
the coin
vi.    Identification of critical test cases of the domain

Group involvement enables to attain more than one solution, which are to be brain stormed closely examining positive and negative part of implementation. The solution with more positives is finalized. Success of this activity depends on the team involved in brain storming. Criticizing ones view or idea should be strictly prohibited; otherwise it would inhibit the individuals to exhibit their thinking/talent.
Devised “Test Strategy “is adhered by the testing team with open mind and with comprehensionWhat are we doing?

a. Why are we doing?
b. Why are we doing?
c. When particular task has to be executed?
d. How to execute a task?
e. Who has to execute?
f. Whom to escalate or report to?
g. What is the criticality of the task?
h. What are the tools to be used? etc.

Defect Analysis
Defect analysis itself is a very big ocean; here I am going to deal with certain scenario the testers would undergo in their day to day activities.
Primary outcome of test execution are defects against the application under investigation. Testers know-how to report a defect, but to add credibility and to enhance their knowledge on application they have to drill down further by examining the log files or data base or any other resources to unveil the cause of the defect. This would help them in assisting non- technical people like business analyst and validate the implementation of application functionality throughout the project life cycle. Certain defects arise due to changes in baseline, data base, code; environment settings etc. in these situation logical thinking and problem solving skill would be very useful. To be an outstanding performer and add value to project one should enhance their logical and problem solving skill.

Defect analysis does not end here, activities preventing issue occurrence are valued more because cost incurred by bug found at execution phase are multifold when compared to defects found at earlier stage of project. The exercise given in the flow chart is suggested to be executes to prevent common defects.


In addition to prevention of occurrence of valid defects, common invalid defects should be analyzed. The reason for invalid defects should be identified such as

a. Requirements not clear
b. Requirement misunderstood
c. Implicit Requirement
d. Technical Constraint
We have to classify the issues based on the above categorization, high priority should be given to the category with max no. of issues and then subsequent categories. Based on the analysis, corrective action should be taken to prevent similar defects.
On sharing this information with the Project Manager, would enhance their confidence over the testing team. The Testing team along with the Dev team conducts bug triage and brain storm over the issues to identify the solutions to prevent defects in future.

Apart from testing and filing issues, testing team hold other responsibility to enhance the quality of the project/product, cost and effort. They should employ their problem solving and logical thinking in their work on daily basis, and exhibit difference in their work; this would make the world to turn towards them.

About the Author

Maha Lakshmi is working as project lead at Aspire Systems Ltd, Chennai. Her knowledge spreads across various domain manufacturing, semiconductor, document management system, and application right from desktop to current mobile apps.

Behaviour Driven Testing – An Introduction

What is Behaviour Driven Testing (BDT)?

Behaviour Driven Tests focuses on the behaviour rather than the technical implementation of the software. If you want to emphasize on business point of view and requirements then BDT is the way to go. BDT are Given-when-then style tests written in natural language which are easily understandable to non-technical individuals. Hence these tests allow business analysts and management people to actively participate in test creation and review process.

Why BDT originated?

Since the time test automation started, it has evolved tremendously with new concepts, framework design and tools. The low usability, rigidity and high maintenance cost has been the reason of evolution of automation frameworks.









The one common disadvantage of using any of these frameworks is the difficulty in understanding the automated test cases by the non-technical people such as business analysts and management.

BDT has helped to plug-in this gap. It has helped to bridge the communication gap by writing human readable test cases. It is a relatively new agile software development approach that focuses on communication; encouraging collaboration between developers, QA and business participants; to help bridge the Business-IT alignment gap. The scenarios are written to build up a clear understanding of the desired behaviour and this happens through discussion with stakeholders.

How is BDT implemented?

There is a plethora of open source BDT frameworks available in many programming languages and supporting different platforms. For instance, Cucumber (preferably with Ruby), JBehave for Java, NBehave and specflow for .Net, Behat for PHP and Twist for Groovy etc. The BDT layer is implemented on top of customized framework so it’s about building up layer upon layer only. The behaviour driven tests are given- when-then style steps written in natural language. Ofcourse, the implementation of these steps has to be done in a programming language of one’s choice.

Advantages and challenges of BDT

•  Collaboration: It engages product teams, business analysts,
QA   team and developers onto the same page and provides a
platform to resolve the differences in point of view. Thus,
ensuring that all stakeholders have the same expectations.
This co- operation between stakeholders in-turn results in
good and clear set of Acceptance Criteria

    • Easy Review and Feedback: No development skills are required for creating tests as tests are written in ubiquitous language. Business Analysts can actively participate in automated test cases review process and give their feedback to enhance them.
    • Right Focus: BDT helps to focus on the user’s needs and the system’s expected behaviour rather than focusing too much on testing the implementation.
    • Greater ROI: It has been observed that the behavior of the software stays for longer than the implementation. So, behavior driven tests are easier to modify and hence results in greater ROI. Also, the BDT tools are open source which further reduces the investment.
    • Easy Maintenance: With BDT code redundancy can be minimized due to ‘step reusability’ feature. Hence, these tests are less costly to maintain.
    • Availability of skilled resources: The BDT tools and framework development approach are different from other popular automation tools in the market like QTP, SilkTest, TestComplete. So, skilled resources are required to build and maintain the BDT framework.
    • Re-engineering: In some cases, the tests written by the manual tester/client/ business analysts are not good enough for automation. So, some rework may be required to make them suitable for automation.
    • Support Community – The concept of BDT is relatively new that is why the support community is yet not large enough. So currently, it might take a little longer to resolve the technical issues or queries.


BDT is gaining momentum as lot of organizations are looking at it as a solution to their automation and collaboration challenges. BDT framework has been successfully implemented by various QA teams in various domains. Implementing BDT with automation best practices and integrating it with CI & test case management tool produces all the benefits of automation. BDT for sure is here to stay

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.

Women Participation at Let’s Test Oz 2014

How Let’s Test Oz came about is well explained in David Greenlees’s blog post. David is one of the co-organisers along with Henrik Andersson.

For me, Let’s Test Oz wasn’t only a conference, it was a journey. Let me explain.

It’s no exaggeration to say that David Greenlees and I worked incredibly hard over the entire year to get Let’s Test Oz to the point where things appeared to work seamlessly. We agonised over venues, we deliberated over content. We tirelessly promoted the conference forming partnerships to help spread the word.

When day one of the conference arrived, I felt surprisingly zen. My work was done. Myself and David had created a space for a wonderful community to get together and learn and discuss context driven testing. The enormity of what we had done began to sink in.

We’re both incredibly proud of what we achieved.

We also had personal goals for the conference. Something that I’m particularly proud of is the significant number of women speaking and participating in the conference.

At the closing keynote I asked all attending women to identify themselves, 35% of the audience stood up, not bad for a tech conference and really it surpassed my expectations. Now the conference is over, I’ve had time to reflect why we had a significantly higher female participation.

I think the following reasons may contribute.

1) Female Co-Organiser

I think one of the major reasons why there was a high number of women at the conference was because of me. Greater diversity in the committee meant that greater diversity was implicitly considered. It’s not that having women at the conference was a ‘key metric’ or a goal, but it flowed intrinsically from me being there.

2) Program Choice

33% of our speakers were female with CAST2014 (with also a female program chair Anna Royzman) topping the ratio at a fantastic 38%. (rough and ready figures are below).

Lets Test 2012 = 5/ 29

Lets Test 2013 = 5/ 32

Lets Test 2014 = 6/ 30

Lets Test Oz = 7/22

CAST2013 = 10/37

CAST2014 = 20/51

One reason I think is I have a great network of female testers that I could naturally call upon to speak. These were a mix of highly experienced speakers such as Fiona Charles, Anna Royzman, Ale Moreissa, Katrina Clokie and Beth Skurrie but also those who had not spoken at a conference, but I knew had powerful stories to tell. Women like Margaret Dineen who stole the show with her story about working on difficult projects.

Does having a greater diversity in speakers encourage greater diversity in attendees? I’m not sure. Anecdotally, this seemed to be true, but it’s hard to tell. If there are any attendees reading this, let me know what you think.

3) Community

We have a fantastic and strong testing community down under, both in New Zealand and Australia. Many prominent women are actively involved in running meetups. I ran the Sydney Testers meetup – started by Trish Khoo for 4 years before handing it over to Richard Robinson earlier this year. Katrina Clokie runs the WeTest Meetup in Wellington. The Auckland WeTest Meetup is organised by Shirley Tricker, Nicola Owen, Jennifer Hurrell, Erin Donnell and Kim Engle. Having women visible in prominent positions encourages others who wish to speak and play a similar role.

There’s more work to be done. I believe women do an exceptional amount of work behind the scenes but are not so good a muscling into the limelight. Their philosophy often is, “as long as I do exceptional work, people will recognise that”.

Women need to understand the importance of being recognised for the exceptional work they do. Somehow we seem to think tooting our horn is unladylike, that doing good work is sufficient reward. It’s important to be recognised for our work. Hiding it under a bushel does no-one any favours.

So let me complete this article by congratulating myself, the women speakers and all the women participants at Let’s Test Oz. We rock, now let’s rock the testing community!


About the Author

Anne-Marie Charrett is a testing coach and trainer with a passion for helping testers discover their testing strengths and become the testers they aspire to be. Anne-Marie offers free IM Coaching to testers and developers on Skype (id charretts) and is is working on a book with James Bach on coaching testers. An electronic engineer by trade, testing discovered Anne-Marie when she started conformance testing to ETSI standards. She was hooked and has been involved in software testing ever since. She runs her own company, Testing Times offering coaching and software testing services with an emphasis on Context Driven Testing. Anne-Marie can be found on twitter at @charrett and also blogs at

Logo Design Contest Result

Women Testers Logo Design

Dear Readers,

Here is the winning logo submission designed by Maria Kedemo


Maria Kedemo has worked within software development since 2000. Her experience ranges from developer, test lead, tester and coach in different domains such as Telecom, Retail and Security. Today she is working as a coach and manager of a test department, working to spread the values of the context-driven school of software testing. With a passion for helping and providing the opportunity for people to learn and develop she is engaged in various testing communities often behind the curtains. Sporadically you can find her speaking at software testing events or writing on her blog.

This is Maria’s explanation for the idea behind the design.

As at tester I look for information and clues, there are similarities to the job of a researcher or a detective, thus the magnifier. The woman part is represented by the magnifier that is formed as the symbol for woman.

Learn more about the contest here: testers-launching-logo-designing-contest/

Readers / Women Testers you can continue to submit your designs to us and we will select a winning entry, every quarter. Thank you for all the submissions.