Category Archives: Third edition

Point of Sale Testing

What is a POS?
A POS (point of sale) is a computer which is connected to a receipt printer, cash drawer, credit/debit card reader and a bar code scanner etc. Retailers use an automated retail system where
the store cash registers are linked to computer processing systems.
Merchandise is ticketed with colored bar code tags, which are read with wand readers at the checkout counter. The computer accumulates sales transaction information on magnetic tape for daily input into the computer memory bank or storage system. It is input into the sales journal, which is rolled up into the stock ledger.

Why is ensuring quality of POS system through rigorous testing so important?
In competitive business such as retail, a POS can be a key differentiator. Good POS software package increases efficiency by eliminating redundant, manual labour and can manage the entire business.

Listed below are a few concerns among others if testing is not in practice for POS.

  • More man power might be needed due to unreliability and slowness of checkouts.
  • Risks of incorrect inventory records and thefts by employees.
  • Erroneous Sales reports would not provide correct inventory levels and hence controlling cost would become a challenge.
  • Extremely difficult to track promotions, discounts, and coupons.
  • Incorrect loyalty member data and hence loss of business due to non-repeating customers

Clearly it is very important for POS applications to be reliable, scalable, easily maintainable, highly secure, and easily customizable by the customer and hence it demands a lot of focus on effectively testing the solution before it gets deployed.

How to test POS?
As mentioned earlier, to ensure quality of POS software, proper testing of the application is very crucial. Just like any other application, to test a POS a good test plan should be developed too. To test POS one has to focus on a lot of things, few are listed below:

  1. Cashier activity: This includes customer transactions such as the entry of items, tender, Store Value Cards, discounts and layaway. It also includes non-customer transactions such as cash drawer loans, petty cash, totals and closings.
  2. Store Server and Back Office Integration: Verification of POS interaction with store servers and back office systems. Register transactions can be verified against the Electronic Journal for accuracy.
  3. Platform check: If the POS supports multiple- platforms then verification of the functionality on the all the platforms should be part of testing
  4. Sales: Regular sale, Sale with credit/debit/gift card, return, exchange, loyalty member purchase, items, quantities and prices
  5. Manage return and exchange: Return and exchange of an item with different tenders (cash, credit etc), with and without receipt
  6. Discounts and Promotions: Item % discount, military discount (applicable in US), line item discount etc.
  7. Loyalty Members Data: The system keeps track of what your customers are buying and who they are. It keeps track of what’s selling, at what times of day or week, to which types of customers and by which sales people. The data collected from POS terminals is useful in planning of long term strategies. A good POS System will also have reminder dates for each customer so you can call or e-mail them prior to an anniversary or birthday.
  8. Ability to Read a Card: There are various types of cards in the industry today. (Magnetic Stripe, CAV, etc)
  9. Performance: Speed or the time taken to send a request (read) and receive response and applying the transaction based rules (ex Rebates/Discounts/Tax etc)
  10. Negative Scenarios: Various transaction declined scenarios (Invalid Card/PIN/Expired Card etc.)

Software testing can be broadly divided into manual and automation testing. Each of which has its own pros and cons, however software testers are becoming well versed with latest technical advancements and are up- skilling to test better both ways.

What are the challenges in manual testing of POS? Testing a POS software package manually can lead to many challenges:-

  1. Multiple Configurations: Testing a POS application with different settings and configurations is a cumbersome task. Test cases should be designed covering each and every scenario (positive or negative) in detail. Therefore significant budget should be put in testing of such applications to prevent any major issues at the customer end.
  2. Peripheral issues: The peripheral issues may be related to devices which are connected to POS like bar-code scanners, scales, printers, towers and cash drawers.
  3. Complex interfaces: Integration of POS System involves numerous interconnected systems and third party elements. Systematic test design techniques are followed to reduce the complexity of interfaces.
  4.  Test Lab Maintenance: As a significant amount of hardware is normally connected to POS, it thus requires a large amount of space to house this hardware. We also have to put some effort and expense in to keeping the hardware in good condition.
  5. Upgrades: Rapid technological advancements necessitate frequent hardware and software upgrades.
  6. PCI Compliance: Care must be taken to adopt PCI-compliant, tamper-proof infrastructure at all POS terminals to protect cardholder data and identity.

How can Automation Testing help?

To save manual testing time, a test automation strategy can be developed. Test automation frameworks reduce time to market and testing costs while increasing and improving test coverage, product quality, and end-user acceptance. Companies that increase the proportion of automated testing have a decisive advantage over their competitors. Automation testing provides enhanced test coverage, saves testing time and cost, gives objective testing evidence in the form of customized reports, easy defect tracking for faster troubleshooting.

Having said this, before proposing automation testing as a solution, it is important to carefully analyze the ROI on the whole effort. Test automation is a strategy to reduce timelines, cut costs and improve quality. But before we reap the benefits of automation we have to make significant investments. It is also possible to calculate the possible returns of the test automation investment. Based on the inputs (such as releases planned per year, number of regression test cases, size of manual testing team etc), an ROI report can be generated which:

  • Analyzes the cost involved in automation
  • Compares the effort and cost for both manual testing and test
    automation
  • Provides the break‐even period
  • Presents the saving in percentage

How to select an automation testing tool?

For automating the test cases of POS software, a test automation tool is required which can recognize the UI controls of the application. Selecting an appropriate automation testing tool for a given application involves a step-by-step process. Without a proper process being followed, one might end up with either wastage of effort or selecting an inappropriate tool for the application under test (AUT). There are plenty of commercial and open source automation test tools available in the market. A proof-of-concept (PoC) exercise should be performed to select the best-suited tool for the POS application. In a typical PoC, evaluation of two or three shortlisted tools is carried out to judge the capability and fitment of the tool for an AUT. Also, a framework design based upon the requirements is suggested. As a result of PoC, one is able to select the test automation tool along-with the test framework design.

What are the challenges in automation of POS?

We should consider the fact that 100% automation may not achievable. While developing test automation strategy for POS one might face few challenges:

1. Interaction with Peripheral devices: The scenarios covering scanning a bar-code, swiping a card, pin-pad-entry, opening and closing cash- drawer etc involve peripheral devices which require human intervention. Such scenarios are difficult to automate.

2. Custom UI Objects: The UI of POS applications might contain non-standard objects which are difficult to be recognized by an automation tool.

3. Dynamic UI: The UI is often highly dynamic to allow it to cater to the changing business needs. Also, business processes are frequently modified and the cost and time required maintaining an automated regression test suite increases and in some cases becomes difficult to maintain.

4. Multiple Configuration and Interaction with other interfaces: POS application generally interfaces with the external systems such as Sales Audit, CRM, E-Commerce etc. The test cases require interacting with such applications as well which increases the challenge and the complexity. Also, POS vendors might have multiple versions/formats of POS hardware and software. So, maintaining the scripts for different versions and configurations becomes difficult and needs prior planning.

However, these are not roadblocks, solution providers having good experience in automation testing have devised ways to overcome these known constraints. We can conclude by saying that for complicated and business critical system like POS, test strategy can be a combination of both automation and manual testing. Also one should understand that testing of POS systems is different from other software and requires in-depth understanding of POS-specific challenges. To overcome such challenges and mitigate risks, the subject matter expert should carefully design the test strategy and approach in order to achieve the quality goal.

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.

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” http://www.meetup.com/Copenhagen-BDD-Meetup/ . She is @vanilleDK on Twitter and can be contacted at rikke@reload.dk

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 www.lisacrispin.com, 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
terrain.

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.

Diversity in Tech – Making the Future Today

“The future belongs to those who believe in the beauty of their dreams.” ― Eleanor Roosevelt

I am a product of my environment. I have benefited from a lifelong positive model for diversity starting with my mother, to my wife, multiple bosses, friends, to my industry colleagues. Strong, intelligent men and women who inspire and challenge me, and make me think differently about who I am and how I see the world have surrounded me for as long as I can remember. I am grateful for that experience, but I realize that not everyone has had the advantages that I have enjoyed. As well, part of the social contract, as Elizabeth Warren says is to “take a hunk of that and pay forward for the next kid who comes along.”

Tweet1

 

 

 

 

Having spent twenty years in large, multi-national companies working on countless Human Resources exercises trying to work out why diversity is such a problem, I can tell you, Einstein’s view on “the same level of thinking” reins supreme. To crack a “problem” as large as the one that some of these organizations face, complete reinvention is required – something that most individuals, let alone 1000+ person workforces cannot easily accomplish.

Increasing diversity in technology has just about entered the phase of Corporate Social Responsibility (CSR) where everyone and their brother (pun intended) has started some initiative to increase their footprint with some underrepresented group. Looking to the future, this trend seems to be increasing with CSR commitments becoming the new standard to govern decisions from whom to do business to where we want to work.

Diversity versus inclusion…
In my experience, the trajectory for identifying, hiring, training, and developing people in large companies is so protracted; adding another source of candidate flow is nearly doomed from inception. Moving the needle on something so large and pervasive as the lack of diversity in technology requires a complete rethink of the issue at hand, and that means changing the game.

Unfortunately, the real problem with companies is not the lack of diversity but the lack of inclusion, regardless of what the workforce looks like. Inclusion according to the Harvard Business Review is how you “create an atmosphere in which all people feel valued and respected and have access to the same opportunities,” and inclusion is where the diversity rubber hits the road. I’ve sat on multiple senior executive boards discussing the progression towards our targets in a room comprised entirely of middle aged, white men. Worse than that, two and three layers deep into the org charts the demographics looked exactly the same – and no amount of target setting is going to change that fact.

So while setting targets to increase your diversity footprint may have some merit, in my opinion and experience, if that’s your approach – you’re doing it wrong.

You’re doing it wrong…

At the New York Tech Talent Summit last year, I was on a panel discussing workforce development and our work at Doran Jones with Per Scholas. During the Q&A I was asked what I thought could be done to increase the amount of women hired in technology. My answer: create new companies that make diversity an underpinning of their business model. There are clear benefits of a diverse workforce from marketing, to culture, and strategy, so as far as I’m concerned, the problem is not with the workforce – the problem is with the companies.

According to this Forbes article, that idea might not be as far off as it seems. The authors feel that building diversity and inclusion from the inception of a company is the quickest way to address the divide, as a “startup, short on history but long on seeking the best talent, provides a good platform for establishing an inclusive organization and work environment.” My view is that like everything else in the corporate world, when market scrutiny increases on CSR and potentially crosses into Federal regulation, companies that have a gap will come looking to “buy” a solution anyway.

There is a demographic sea change happening broadly across the workforce and technology is subject to the shift. In my opinion, companies that build diversity into their DNA and have inclusion as a principle instead of a target will have the best chance to be successful in the new economy. The beautiful part of my dream for the future is that you won’t have to worry about changing an organization to match reality – because those that don’t will no longer exist.

 

About the Author

Keith Klain is CEO of Doran Jones, a technology consulting company based in New York, With over 20 years of multinational experience in enterprise-wide testing programs, Keith has built global test teams for financial services and IT consulting firms in the US, UK, and Asia Pacific. Keith designed the Per Scholas STEP program, and has been instrumental in its growth and continued expansion. He is the Executive Vice President of the Association for Software Testing and was the recipient of the 2013 Software Test Professionals Luminary award. Twitter: @KeithKlain Blog: www.qualityremarks.com

WOMEN TESTERS – JANUARY 2015 EDITION

January2015January 2015 edition of Women Testers is brought to you by the team of Women Testers and in association with Testing Circus.

It was great being a part of this edition, we partnered with:

1) Speak Easy – An initiative by Anne-Marie Charrett and Fiona Charles to encourage diversity in speaking and at conferring and 2) NULLCON – an international software security conference. Inside this edition, all you Women Testers will find a gift, an opportunity to connect and learn from the software security gurus. Thank you NULLCON team for this sponsorship.  Hope these partnerships can help you to get on with your learning journey.

We have connected with constant learners and brought to you testing knowledge on diverse topics, in this edition. Thank you authors for timely submissions.

  • Advocate with Confidence by Alice Chu
  • Agile Tester – from Novice to Intermediate by Rikke Simonsen
  • Being Fearless by Rachel Carson
  • Career Advice From One Tester To Another by Lisa Crispin
  • Answering the call for proposals by Katrina Clokie
  • Point of Sale Testing by Divya Madaan
  • The False Security of Compliance by Rachelle Below
  • Guest Post: Diversity in Tech – Making the Future Today by Keith Klain

The winner of the Crossword on Testing Types – Congratulations Dharshini, a gift awaits you from TeamQualityPro.

Thanks for the inspiration and patronage Testing Circus.

Coordinator and Editor – Jyothi Rangaiah