What to Learn on a New Project

One of my blog readers recently wrote to me that she moved to a complex project and is finding it hard to learn quickly. She suggested I write an article that might help many first timers like her.

Getting placed on a new project is like your first day at school after a long and lovely vacation. You just don’t want to return, but you have to. New work, new team, new manager, new processes, new culture…. too many “new” variables and nowhere to escape.

On day 1 on the new project team, testers are mostly goaded with scores of documents to go through for next two weeks if they are lucky. If they are luckier, they start testing from day 1 and learn on the job. Where to start and how to start learning is a gigantic task.


Learning about the customer is the first and foremost task that any tester must undertake while starting to work on a new project. Understanding who the customer is, what their context is, what are their business goals, what is their main line of business, who are their customers, what is their history/legacy, what is their vision for the future and how they are making money are critical questions to ask. Many testers I worked with used to ask, “I am a tester, not a business owner. Why should I bother about these things?” Testers need to know these as it helps them understand the product better.


Product or application under test is one of the important factors to learn about on a new project.

General Information

What problems or unmet needs is the product solving, how is it solving the problem, is the product sticky enough for users to try out, what kind of users use this product – consumers or enterprises, what is the revenue model for the product.

Testing Information
From a testing perspective, it is important to identify why the product owners need testing in the first place.

Understanding this reason is very important as it helps testers’ fine tune testing processes to be in sync with stakeholders’ goals. Testers need to ask questions on what needs to be tested, reasons for testing them, known risks and issues, which features/areas are of higher priority compared to others, what are the release goals for the product, what technologies need to be learned, what part of products can be tested versus which ones can be checked using automated checking and so forth.


Knowing the team is a key factor for any project to succeed or fail.

Internal Project Team

Knowing the team not just includes getting introduced to testing team, but corresponding programming team, data setup team, inventory/content management team, business team, technical support team, sales/marketing team, leadership team and others as appropriate. Why know about so many people while testers work only with fellow testers, one may ask. Knowing as many people on the project puts testers in quick contact with many people who can help you learn quickly on the project. In much high risk, high tension projects, networking with other teams helps you gather important information that sets you apart as a new tester on the project.

I once worked on a project where testers had to work with seven other teams to get their test environment setup. Since many testers did not look outside testing team for help, they would be stuck for weeks. With me onboard, I reduced the ‘Got Stuck’ time to fewer hours just with smart communication with cross-functional teams.

Customer Team

Some customers would like to be in direct touch with development teams which may requires testers to interact with customers especially during critical releases, customer escalation meetings, bug triages and others. In such scenarios, it is important to keep a record of customers contact details including email address, contact numbers and their role on the project.

A cohesive project team is like marriage. Everyone involved has to work harder towards making it work. This can happen if and only if everyone is working towards a common end goal – of building a great product.

Technical and Soft Skills

Every project demands select set of technical and soft skills. Many testers take it for granted that testing is a common skill that is applicable on any project or domain. This assumption drives them to think that they have already arrived with all skills. It is important to draw a simple map of what skills may be needed – like new domains, technologies, tools and spend at least 20 minutes a day on learning them. There are scores of free courses on Udemy, Coursera and Khan Academy that can help. Even stalwarts like Satya Nadella spend some time every month learning a new concept. Learning is a lifelong journey and a critical one at that.

Some projects may need testers to interact with customers on a regular basis which in turn demands them to be aware of additional skills like client communication, email etiquette, presentation skills amongst others.

Work Protocol

New projects bring new guidelines/rules with them. Working style, timings, processes, body language of team member and culture followed on a new project may be completely different from those on previous projects. Testers need to be skilled to adapt to changing environment not just on technical front, but also on the culture front. Different people come with different perspectives. The objective must be to work in an elliptical model where everyone in the team works in a complementary way where everyone’s strengths are magnified and weaknesses are minimized. Many testers will have the biggest challenge here as humans, by tendency don’t like changes at a personal level. Since this directly deals with changing their interests and thought process, working on a new project can be taxing. Approaching changes with empathy helps cope with the change and also adapt quickly. In a very short time testers, might start to contribute positively to the project.

Note Taking Skill

Always carry a note book and pen with you all the time! We have limited memory and remember too few things. Capturing important information at all times helps not just in

getting things done quickly, but also helps you plan and organize tasks better. Critical information like setting up a cluster machine or configuring a server or reproducing a crash requires meticulous detail that can be supported by great note taking skill. Adding a visual touch to it by drawing visuals / sketches is more powerful and interesting way to capture notes.

Seeking Help

Knowing that you need help and seeking the help you need is a very important aspect of learning. If testers intend to solve all problems by themselves or spend several days before approaching someone for help, then they are setting themselves up for failure. If testers need help, they must SHOUT.

Here is a simple heuristic to ask for help. When you hit upon a problem, understand the problem deeply, come up with a few solutions and apply those solutions. Give it your best. If it still doesn’t work, reach out for help. When you ask for help, state the problem, emphasize on the steps you took to solve the problem and tell them how you failed. This will demonstrate to the problem solver that you care about the problem. From thereon, any person will be interested to solve your problem unless it’s your bad day or the person on the other side is a maniac.

Emotional Labor

According to Seth Godin, “Emotional Labor is doing the difficult work of bringing your very best self to each interaction braving pain.” It is to do the work even when you don’t feel like it. Expending emotional labor is a quality that is expected of everyone because they no longer do what they love most. People with a gift for emotional labor are called Linchpins.

Linchpins hope for a better world. They already live in the world that they are about to create. They slog it out, not knowing that they’ll become indispensable. Linchpins make changes happen. Every tester must ask them, “Am I a Linchpin? Am I capable of expending emotional labor?” What does it take for a tester to succeed on a new testing project? A combination of all factors mentioned above + Drive to accomplish personal goals which are tied to this project. It takes a lot of hard work, patience and perseverance to build credibility on the new team.

About the Author

Parimala Hariprasad has worked as a tester for close to 12 years in domains like CRM, Security, e-Commerce and Healthcare. Her expertise lies in test coaching, test delivery excellence and creating great teams which ultimately fired her as the teams became self-sufficient. She has experienced the transition from Web to Mobile and emphasizes the need for Design Thinking in testing. She frequently rants on her blog, Curious Tester (http://curioustester.blogspot.com). She tweets at @CuriousTester and can be found on Linked In at http://in.linkedin.com/in/parimalahariprasad. She currently serves as Delivery Director at PASS Technologies AG.

How to Keep Yourself Organized

At some point in our careers, we may get into a situation where we feel overwhelmed by the sheer volume of projects and tasks that need to be completed. We might be juggling testing tasks (such as writing test strategies, reviewing testing approaches), recruiting and training new Testers, writing performance reviews, planning for upcoming releases, and working on special projects.The focus of this article is to discuss methods to identify important tasks and to organize them in order to stay focused on important priorities. Finding a manageable system can help you make decisions on where to allocate available time wisely when the workload outweigh the time available.

Take an Inventory of What You Think Needs to be Done

Create an inventory list of everything you believe needs to be completed. This can be projects, a listing of tasks, or a combination of both. At this point it is not necessary to get too granular such as a project plan instead this is an initial start to understand what needs to be completed.

What Are Your “Real” Priorities and Timelines?

A laundry list of projects and tasks can be overwhelming. Review the initial inventory list to determine what really needs to be accomplished and associated timelines. A few questions to get started in understanding the priorities.

What projects and tasks:
  •  are associated with hard‐deadlines?
  •  must be completed in the short‐term?
  • can be re‐negotiated to provide more time for the most critical
    or  time sensitive projects and tasks?
  •  have longer term deadlines that do not require immediate
    attention?   (Move them to a different list leaving a
    placeholder  in your laundry  list of projects so you do not
    forget about them.)
  • are nice to do but if not addressed will not have a big impact?          (Move them to a different list for future projects so they are
    not part of your daily review.)

Organize What Needs to be Completed


Using a whiteboard is a low-tech solution that is helpful when you prefer to have the tasks visible without needing to open a notebook or electronic organizer. The downfall of this system is you cannot take it with you; however you can always take a picture with your mobile as a work around. Start with first understanding how you want to logically group the tasks to allocate space for each category. The categories can be based upon the type of tasks to logically keep them together or by priorities or due dates. Another approach is to list all the tasks vertically and then along the top of the whiteboard indicate the timelines (such as September, October, or Quarter 1, Quarter 2) based upon the deadlines. For each task place an “x” under the appropriate time to indicate when it is due. Using symbols, acronyms, and different color markers can help track the progress and priorities of those tasks.


Spreadsheets are a great way to organize tasks with the ability to add columns and sort the data based upon any of the columns. Using Google Drive Spreadsheets is great to access that information from most any device or operating system. It is easy to add and remove tasks, then re-sort the spreadsheet to keep tasks organized by priority or category. Columns that can be helpful include:●  Status (Not started, In Progress, On Hold, Blocked, Completed)

●  Deadline

●  Priority

●  Category (such as administrative, testing, special projects)

●  Effort

●  Task Description

●  Notes (Add the date before each note to keep track of the progress)

Moleskin Notebook and Bullet Journal:

There are different types of notebooks that typically come with their own planning system. These are great systems for those who prefer paper systems and like the ability to take them wherever they go and not be reliant on technology.


There are a lot of apps that can help organize tasks. iPad has a nice app called “Everyday” that has a “To Do” list that you electronically cross off a task and any tasks not completed automatically moves to the next day. This is nice for immediate priorities but it is a listing of tasks with no organization.

OneNote is a digital notebook that can be used for many purposes from organizing tasks, capturing notes including using a camera, voice, drawings, while providing storage in the cloud for easy access to the information across devices.

There are a lot of “To Do” apps that range from simple to complex with many of them being free. Download a few of them to find out which one works for your needs. Consider if you want the information stored in the cloud to make it easier to access across operating systems and devices.

Symbols, Acronyms, and Color Scheme:

Use different symbols, acronyms, and colors to visually see your priorities and progress. For example, start each task with a small box and when that task is completed place a checkmark in the box to indicate it is done. A star might indicate the task is top priority; a question mark might indicate additional research or questions need to be addressed; a triangle indicates a change has happened with the task; and so on. Incorporating color can be a quick way to understand if a task is on track (green); slightly off schedule (orange); or is in trouble (red). The color scheme can be used to identify the tasks priority as an example red might indicate a top priority. Acronyms can be used such as:

IP – the task is currently in progress
BL – the task is blocked
CL – the task has been closed

Immediate Priorities

When there is a lot of demands on your time, keep your immediate priorities visible to ensure they do not get missed, which is easy to do when you are busy. Every day either in the morning or at the end of the day, re-review the top priorities for any changes. Understand any upfront work that needs to be completed for a future deliverable to reduce the last minute rush. For example, if in two-weeks you are facilitating a meeting, what do you need to do now to prepare for that meeting.

Best Use of Time

Utilizing your time wisely is important as a general rule; however when you are juggling a heavy workload, this rule becomes critical. Understanding the tasks’ effort is helpful for when you have a small chunk of time available – you can easily select a small task to complete. For example, a meeting is cancelled freeing up an hour, which is not enough time to work on a larger project but might provide time to complete a smaller task.

Meetings can be scattered throughout the day. If possible, organize meetings in a manner to provide a larger block of working time. Scheduling time to get work done is helpful, which might be accomplished by allocating uninterrupted time by closing an office door, putting out a Do Not Disturb sign unless it is an emergency, and working from home (based upon the company’s HR policy). Often people do not want to go to these extremes, but protecting time will help with utilizing time wisely. This also includes not constantly checking email and your mobile that breaks your concentration. Review your typical work day to determine where else you can make changes to protect time.

Different approaches can be effective based upon the type of workload and deadlines. Test out different approaches to determine what works best for you based upon the situation.

About the Author

Bernice Niel Ruhland is a Director of Quality Management Programs for a privately-owned software development company. She provides strategic oversight and leadership of a Software Testing Department using context-driven and agile approaches and techniques. She participates in company-wide quality initiatives and programs. The opinions of this article are her own and not reflective of the company she is employed. You can connect with Bernice at: LinkedIn; Twitter: bruhland2000; or her blog: TheTestersEdge.com

What Testers can Learn from My Wife

Let me start by guessing what you might be thinking looking at the title. Some guesses-
1. This must be an emotional piece from someone who adore his better half.
2. This must be a sort of self/family achievements boasting exercise.
3. This must be something about a next generation test innovation.

If you are thinking on the above lines then i only have one word for you- Sorry, your assumptions here are misplaced. It might take me rest of the article to explain about my stand here but let me clear some things upfront-

1. My wife is not a software tester.
2. In fact, her job profile has nothing remotely to do with Information Technology.
3. She is an engineer by qualification and professional experience.

As a family, we have been brought-up in a culture that values humility to the core. As a result of this foundational nature, we are probably low key about the way we are and about our humble achievements, if any. Being low key usually have a negative connotation to it especially in the cultures and sub-cultures that value extroversion. But to me, being low key does not mean being anti-social as we are sufficiently social and thriving in the space that we operate in.

With this background, i can say that what i am attempting to share here is probably something that does not come very naturally to me. But in the spirit of sharing for the betterment of our profession, i thought it is a risk worth taking. So my words my stumble, grammar may get shaky, the full stops may seem too far away but still here i attempt to narrate the lessons that i learned from my wife that helped me become a better professional.

A bit more about my wife:
Being engrossed in the everyday challenges of Information Technology profession, we sometimes get too blinded in our world. So much so that we don’t recognize that any other profession or job that can be as challenging, if not more. If i just say that my wife is in automobile engineering profession, it may not give perspective on what she actually does- so let me narrate a bit more.
1. A very mention of the word “automobile” should give a sense that it’s a profession that is dominated by a certain gender. No prizes for guessing which one. One could argue that even IT is dominated by male bastion, which i don’t deny. But difference lies in the extent. If, for example, IT has male/female ratio as say 3/10- take automobile world as 0.25/10 or even less.
2. Her job role is at managerial level and she belongs to a core engineering role, by which i mean- as a part of her role she knows each and every part of two-wheeler (her area of expertise). Every now and then, she gets to open each and every part of a two-wheeler and assemble it back. As a part of Quality role that she played, she knows quality assessment and parameters of each and every part involved in making a bike. As a part of her Service engineering profile, she gets to train managers, engineers to workshop workers on the technical nuances of her area of work. And much more.
3. She thoroughly enjoys her job and is passionate about it.

Professional lessons that i learned from her:
With this background, i will attempt to share some worthy lessons that i imbibed from her.

1. Be hands-on not because of your position but despite of your position
Few days back, my wife told me that she needs to go to work wearing the sports shoes. No, they didn’t have any sports event in the organization but on the contrary, it was the strike period. For those unfamiliar, strike happens in manufacturing plant when the workers usually have some unmet demands and they decide to abandon work. So why did she need sports shoes? On a lighter note, it was not to “run” away from work but rather run towards it. Let me explain- Given that it was a strike, the management had requested people from the organization to help with meeting production targets. She willingly volunteered for the same and was required to work and deliver Compressor internal assembly. She needed shoes (than the usual sandals) as a protection towards accidental oil spillage or heavy parts getting dropped.

Crises situations are not new to Software testing profession. We are faced with many uncertain situations during the life cycle of a release, including but not limited to- build breakages, late arrival of requirements, blocker bugs, and new changes at the end of the release, people attrition, and possibly many more. That truly is our world in Software testing. From the above incident that i narrated, the core question for me is- How often do we see Managers and Executives contribute hands-on when the crisis situation arises? Of course, there is guidance, words of encouragement and motivation from higher-ups but hands- on involvement?

I am sure we have seen some instances but does it happen often?
So, the core lesson she taught me is- Be proud to be hands- on, not because of your position but despite it.

2. Work for your passion irrespective of not getting the credit

I am sure most of the current generation Software testers are passionate about what they do. As i have experienced in my career, the extent of our passion towards our craft really gets tested at many times. One of the crucial such phase is when we go through a lean phase in our career.

The work culture in automobile profession is quite different from that in software industry. It’s a task oriented culture to the core. It means that if you do the task, then usually there is no response from your manager but if by any chance, you miss to do that you were asked to, then all hell can break loose. Of course, it is a person-dependent thing but higher- ups in that culture are quick to spot when you are wrong (even if you are really not) than really take efforts to appreciate the right deeds of an employee. Usually, the rebuke for mistakes is public deploying the choicest words. My wife usually a lone female in such meetings have been subject to uncomfortable situations mostly for no fault or mistake of hers as she is usually always ready with data- bound explanations. The bigger point here is how one gathers the motivation to continue one’s job if you are subjected to such situations almost daily, either happening to you or your colleagues. This is where I have seen her exhibit tremendous maturity to focus on task (not on people) and deliver great work despite not been given credit and accolades she deserves.

In Software testing world too, there are many difficult situations where our passion gets tested but you would agree that they are largely at a much lesser extent than what i described above.

From her i learnt to respond to unfair situations with the same élan as any other work situation. Treat every day at work as experience. Don’t leave seemingly bad bosses at once, as there is much more fun and fulfillment in winning such people over by your passion, focus and hard-work. And don’t keep bad experiences sulking within you, speak to your close ones, have mentor and routinely clear your mind off the negative thoughts.

3. Get better at job even if it means learning and mastering the local language.
No, the language here does not mean programming language, it’s the one that we use to interact with other human beings. Somehow, the people at the job my wife was doing spoke to each other mostly in the local language of Bangalore i.e. Kannada. Being the only non-Bangalore person, she realized that she will need to adapt to local culture sooner than later. Such adaptation would need her to learn and converse in the local language. With her will and determination, she picked-up the individual words, then small sentences and eventually became fluent in Kannada. From a non-starter in the language to achieving fluency good enough to train the people technically in local language in a matter of few months was nothing short of transformational to me.

Is learning local language important for Software professionals? Whenever i have asked this question to people, the response has always been skewed towards a resounding No. And that’s because people feel that writing and testing code majorly requires us to know English or English-like syntax’s. To me that’s a very narrow way to look at one’s job. Broadly speaking, every job has two aspects to it. The core job itself (development, testing etc.) and the people relationship aspect. Even if we write or test code, the work cannot be accomplished without teaming up with others and in certain cases, without approval of others. Now, one can argue that every organization has a business language and that must be followed to get the business done. There is no problem, in general, with this argument but it misses a larger point about complexity of human relationships. Such relationships, including at work, are never linear -as an example, even though English is a preferred business language, often people feel more connectedness with those who embrace local cultures. I would be missing a point if you are feeling that knowing local language would amount to favoritism, that’s not at all what i mean. But all I am trying to stress is the subtle nuances of human nature and why a seemingly unrelated thing like mastering a local language can enable us to work better than without having that knowledge.

4. Have a child like curiosity towards embracing newness

Newness, in essence means change.In automobile world, which arguably follows sort of fixed production process, newness opportunities may be thought of as limited. But automobiles are also invested a great deal in R&D and that is seen in the capability of organization to come up with new models. New model launches bring in a great sense of anticipation in the organization and for the techies post production, it is an opportunity to explore. That is what i have seen my wife do with almost a childlike questioning, exploration and figuring out each and every detail of what has changed not only at the exterior but also going a step ahead and opening the vehicle up and intricately checking the details.

Software testing profession also sees such situations when the new versions of the software gets released. Often testers deploy the build and observe what has changed. What i have not seen as often is the curiosity to see the code and understand what has changed and design tests. This is what i have learned from my wife’s experiments with the newer models of the vehicles. If you are really a curious software tester, then you shouldn’t be restricting your curiosity to what happens on the exterior but rather go a level down and see how raw code is designed.

5. Thinking out of the box is fine but not at the expense of making the box dirty
Most of the jobs in automobile engineering profession would require following a process to ensure conformity. This is done to ensure that physical parts that millions of automobiles use should behave the same way across. To ensure the sameness of such high-degree, it requires that the process that goes into making the part and later assembling the same is identical, and fool-proof. So while there are part of jobs that deal with R&D, a good chunk of jobs are related to ensuring consistency and less variance, and this is where process orientation is a key virtue. Following the process for certain things is taken as a given expectation.

Coming to Software engineering world, I have seen certain fascination by many people in believing that following a process is not right or something similar. Agreed that a good portion of software engineering requires a Research and Development mindset, but does it mean that all the tasks in testing or development are research based? I guess the answer is- No.

Can the various release phases exist amicably without well- defined entry and exit criterias? Can all the testing be only Exploratory? Does all the test-ware need to be created new (based on Research) always or do we reuse pre-existing test-ware? Does the test-reports not, in some cases, need to be standardized based on stake-holder needs? Doesn’t the role of testing changes based on the phase of release you are in i.e. towards the close to release, the role changes more from finding bugs to confirming there are no ship-critical bugs?

If you look at these and many such instances in software testing world, you would realize that we are talking about situations where we would expect less variations and more conformity. This is exactly what a well-designed process help us achieve. It ensures repeatability of results wherever it is desired and needed. And as you can think now, there are some situations in software testing where this is needed. So before you bash the process, think that processes are here to serve a need. There can be cases where process isn’t designed well and it causes irritation to the impacted people but that doesn’t mean all processes are bad in essence, on the contrary they may be unsuitably designed. The need to embrace innovation (out-of-box thinking) is well understood but processes should also be embraced with same vigor wherever they are needed, otherwise it can potentially impact the project deliverables and overall scalability of the organization.

As I come to the epilogue of this story, I must convey that some advice here may be offbeat, some orthodox but to me, the life really lies between these two extremes. That’s why probably i value my wife’s professional journey. In life one needs reference points to help us walk past difficult phases. To me, she is one of my professional reference points. If i hit a trough, i think of her day-to-day struggles and capability to overcome them and then choosing to celebrate small victories of the day rather than choosing to stay buried in the past.

If you like what i said here and learned even a single thing, i would hugely appreciate if you can drop a note to my wife at [email protected] and express what you felt after reading this (she doesn’t know that I have written this and would surely be surprised).

About the Author

Anuj Magazine is a software testing and general management professional at Citrix Inc. He regularly share his knowledge and experiences as a conference speaker and writes frequently on diverse topics like software testing, management, sports, and handwriting analysis. Anuj tweets at @anujmagazine.

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.”






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


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

Crossword on Testing Types

A new year gift to all our readers in the form of this Crossword puzzle.


Image Courtesy – Google

About Crossword – A word which is cross, yes literally 😉
Makes you stretch your imagination,  flex the grey matter and scribble / doodle away thinking about the solution. If crossword solving interests you, then take a look at the crossword grid and the clues below.

Crossword Theme is based on different testing types. This holiday season, entertain yourself by solving this crossword,  constructed by Jay Philips. Thank you Jay for your effort in constructing this puzzle.

Crossword Grid



The clues are below:Crossword_1_TT


Send in your solution to [email protected] by the 26th of January 2015. The solution will be published on 30th January 2015.

The Mother of All Testers

The Mother of All Testers

We live in a world where things that are precious to us are labeled with a feminine title.  Mother Earth.  Mother Nature.  People refer to their cars as “she”.  Why do we do this?  Because there is something genuine, tender, caring, and special about the female aspect when it comes to our lives.

We are witnessing a change in the world we live in.  Women are taking more leadership positions in government, corporations, and within various other communities.  The right person is being selected for the positions, regardless of whether they are male or female.

Women have paved the way through the years for others to follow and build upon.  Imagine what life would be like without these influential Women:

  • Mother Teresa – she led a cause to the orphaned, sick, and dying among the poorest worldwide and became an inspiration to so many who followed in her servant leadership.
  • Diana, Princess of Wales – she chose not to just live in royalty, but to lead many causes (such as acceptance of AIDS victims, and a campaign against land mines). She inspired the world with her life.
  • Marie Curie – first woman to win a Nobel Prize in two areas. She coined the term “radioactivity” and was one of the first to suggest radiation to treat cancer.
  • Mary Kay Ash – she founded Mary Kay Cosmetics, and gave jobs to thousands of women, along with the chance for each to earn a “pink Cadillac” car to drive.
  • Maya Angelou – during the writing of this article, Maya passed away. Of all the many great things she did, one of her quotes that stood with me for so many years has been “People will forget what you said, people will forget what you did, but people will never forget how you made them feel“.  Never forget this quote.  Make it something you live by.
  • Grace Hopper – how could we have a software testing discussion related to women in testing without talking about this lady? This Navy admiral was also a math genius and founding mother of computer languages, which led to the development of COBOL.  She is credited with the term “debugging”  One notable quote from Grace was “The most important thing that I’ve accomplished, other than building the compiler, is training young people.  They come to me, you know, and say ‘Do you think we can do this?’ and I say ‘Try it’.  And I back them up.  They need that.  I keep track of them as they get older and I stir them up at intervals so they don’t forget to take chances.”  What an inspirational quote to live by.

In the testing profession today, being a test practitioner is nothing like years ago.  The dynamic nature of the industry, combined with the exponential growth of new technologies gives so many great, new, and interesting areas for the thinking tester.  We are seeing the ratio of male to female in the practice changing.  And with this change comes a new group of women testers that are providing new insights and inputs to the testing community.  I am encouraged by the articles, presentations, and teachings of many of the women in testing.

My challenge to the community is this: let’s bring on testers who want to change the world.  Let’s encourage them to expand and help others grow along the way.  Let’s get more women testers in our communities, and let’s encourage them to be seen and heard and to lead major changes as we face the future.  We have no idea what the next 10 years will bring us.  In the 1980’s, we had not even heard about the internet or mobile phones in everyone’s pocket.  Now these two things are responsible for so many testing efforts conducted today.

Congratulations to Women Testers magazine and Testing Circus on this effort.  I look forward to the many articles that will rise up from writers around the globe.  You have my support and following!

About the author


Mike Lyles is a  Sr. QA Architect with over 21 years of IT experience. He has led various aspects of testing: functional testing, Test Environments, SCM, Test Data Management, Performance Testing, Test Automation, and Service Virtualization.  In his current role, he is responsible for defining and implementing tools, processes, and methodologies to support the QA teams.  Mike is an international/keynote speaker at multiple conferences, and is regularly published in testing publications. Mike’s passion to help others improve and grow in the field of testing, leadership, and management is his key motivation.  He is available for mentoring and coaching on testing via Skype (mikewlyles).  You can learn more about Mike at http://www.linkedin.com/in/mikewlyles, www.MikeWLyles.com or http://about.me/mikelyles

From A to Z; 26 ways Testers can work with UX designers

The team needs to build a product. The team readily recognizes the testers need to work with the developers but the same team often doesn’t consider that the testers need to work with the UX staff. Often the UX staff is tucked away in a different part of the office, working with multiple teams and yet, rarely working directly with the testers. Why? How can testers review a product without a good understanding of the design? Testers need closer access to UX and UX designers would benefit from working directly with the testers. Following are 26 ways a tester can work more closely with UX designers – from A to Z. 

Accessibility Testing

Accessibility testing is a growing need as more websites and apps are becoming ADA compliant.  While ADA compliance can be included on the design, it is only through testing that compliance can be checked. In addition to “checklist” testing, the W3C has an accessibility guide mentions the concept of using a persona with disabilities which inspires a more holistic way to test for accessibility than testing solely with a checklist. Offer to work with your UX designer on the persona and execute testing through a different perspective.


As designers layout web pages, they might not be aware of the nuances of page rendering from browser to browser and this is an opportunity for testers to share their experience at the concept phase to ward off issues, as well as to offer access to testing during development.

Be fluent in browser settings and coach your UX designers when they introduce ideas that require specific browser settings or when they make browser assumptions. Browser assumptions – meaning the designer is assuming users are using Chrome with cookies enabled but you know from watching browser stats that your user audience is different – and may prefer Firefox with privacy settings turned on. In fact, you could be reviewing browser stats on an intermittent basis with your designer to make sure you are both aware of the production reality of your site usage.


The expression “content is king” may bring to mind the stark reality that many websites and mobile apps are free but the money is made in charging customers for access to content. While website and app designers are focused on the end user experience, it is in the testing of permission and user roles that we can ensure who can access what (and for that matter – when).

A second well used expression: “content is everywhere” refers to the separation of content and the form being used to display content.  Think mobile device versus tablet versus website; think about your site’s content and whether that content is ready to render as it should based on the viewing device and layout. Designers and writers can “tag” content but ultimately, it is in the testing to see how it all really comes together (or not.)


My data, your data, whose data? What can you see? What can you access? Like content, data is what makes a website or app really matter to the user. Screen mockups often show personal information but without test data or occasional production spot checks, how do you know what data is visible? Or how it looks?

Error Handling

While the “works as designed” scenarios may be more fun to design, UX designers (like developers) need to think about troubled situations that may arise and how those conditions will be handled. Have you ever used a graceful application only to face a hideous error message? Offer to preview error messages with your UX designer and to test software such that you see the error conditions evoked.


So many forms! From shopping carts whether on ecommerce or mcommerce payment is the most essential transaction on many websites and apps. The experience might be well designed but someone has to make sure the financial aspects and the forms of the site or app work and work well.


Websites and apps need to function well in addition to the look and feel. Learn what gestures are available and offer to test gestures in collaborations with a UX designer.


With security problems being displayed on the front of the news, everyone on a software development team needs to think like a hacker. Be aware of security flaws and help guide your UX designers to be mindful of potential security issues.


Installation testing is back in the forefront of concerns with mobile and tablet apps. Upgrading one app or many apps at the same time, as well as testing an upgrade to the operating system is needed. Work with UX designers to identify moments during installation for messages to users and like error messages, offer to preview messages.

Jail Broken Devices

Clean and pristine devices might be the ideal used during design but most users’ cell phones are jail broken or rooted and contain a multitude of apps. Testing on a more realistic device is helpful. Perhaps BYOD can help you achieve realistic testing? Help your UX designer by offering BYOD sessions for testing.


If you can navigate your site with just a keyboard – and not the use of a mouse, your site is ADA compliant (that is the only checkpoint). You can test for ADA compliance together.


Is your site or app suitable for international use? Do you need to test with international keyboards? Does content need to be adapted for global usage? Coordinate with your UX designer to address multi-lingual checks.

Multi-Device Experience

The multi-device experience promised by Apple computer ‘s TV ads shows a person moving from home to office, to the local coffee shop and back again but data synchronization, Wi-Fi access and retrieving information from the cloud is all just a magical promise without testing. A UX designer can dream and design but a tester can road test concepts best.


In design, the flow through a shopping e-commerce experience, an e-learning system or even the login process is often designed with the “happy path” in mind and while it is important to think of the “typical” path, it is the tester on the team that can highlight alternate or problem flows that also need to be designed.

Open Lab Time

As the team’s tester you might have access to multiple computers and devices, you can offer to your UX designer open lab times for them to come and view and use software for themselves.


It is easy to think about personalization through the mental lens of a single user but what happens to web pages like My Account and My Order History when the user is a longtime customer with pages and pages of history? A tester with access to the database can build account history and then review web pages with a UX designer to do a sanity check of how personalization pages look with deep order history and a variety of interesting past orders.

Quirky scenarios

UX designers may focus on more typical user scenarios but as the team’s tester, you may be able to envision more gnarly or quirky scenarios.  Sharing your ideas early on about twists in typical usage paths helps designers plan for the less expected scenarios.

Responsive Web Design

RWD – responsive web design – building in the ability to resize, pan, and scroll all while auto-detecting the way a device is being held or rotated and having that instant fluid presentation takes planning and testing. Work with your UX designer to test on an array of devices to ensure a smooth user experience.


Search engine optimization and the continual change in search order ranking is an ongoing “art” in the quest for companies and their websites and apps to be “findable.” From glass box testing of the HTML to black box testing of search results, testers can help UX designers.

Target Users

Marketing efforts often rely on A/B testing – providing two different looks of a website to see which is more successful. UX designers design those two layouts and while testing the success of the marketing efforts is a different form of testing, checkpoints workflows and shopping carts regardless of which entry point is used is something testers can coordinate with UX designers.


Offer to help host and attend UAT sessions your UX designer may host. Once you have a chance to see the software through the user’s perspective, your own testing approach may change.


Version control and compatibility especially when web services and APIs are in the background and being updated at a variety of times and not always updated and released at the same time. Coordinate with your UX designer to ensure compatibility.

Web Services

Testing what cannot be seen such as web services and APIs is a challenge for people who don’t know how to test what they cannot immediately and directly “see.” Testers can work more closely with developers to provoke or stimulate services that are down or disrupted to test challenge scenarios that designers are dependent on.


Extensible Markup Language defines precise formatting for information and while designers plan for data and information to be available, testers can test those dependencies on data.

Y2K and other dates

Y is a reminder to test with sensitive dates and date formatting that may otherwise “quietly” appear on web pages and confirmation emails.

Zip Files

Browse to file, upload file, drag and drop file and other ways to navigate to files to include, attach and upload files is not the most exciting part of a website but the end result is important to users. Zip files are not the only file types to test with but compressed hefty zip files do provide a reminder to consider boundary conditions.

About the Author


Karen N. Johnson is a software test consultant. She is frequent speaker at conferences. Karen is a contributing author to the book, Beautiful Testing by O’Reilly publishers. She has published numerous articles and blogs about her experiences with software testing. She is the co-founder of the WREST workshop, more information on WREST can be found at: http://www.wrestworkshop.com/Home.html Visit her website at: http://www.karennjohnson.com

Foundations of Ticket Writing

For web development test engineers, one of the most common tasks is lowly defect ticket creation.  Each ticket is a valuable nugget of feedback provided to the development team, but the caveat is that it is provided at the end of a project. Nerves become frazzled while timelines get tighter.

Key Ticket Concepts

A vital requirement for each ticket is that it is clear, concise, and distilled as much as possible. I try my best to use an editing eye with my ticket, knowing that the developer may look at hundreds of tickets. I highly recommend using a tool like Hemingway for a few tickets, which dissects the text readability levels. When I write a ticket, I try to keep the non-technical language at an 8th grade reading level – this distills the information to the developer diagnosing the issue.

While working on each ticket, I do my best to give feedback in a neutral manner. It may seem obvious to not include negative commentary in each ticket, but I also try my best to not include positive commentary (smiley faces and similar). Both can cause strife and imbalance on the development team – a developer dealing with a difficult ticket may feel slighted when another developer receives a positive comment. Using neutral language helps a developer simply diagnose an issue without emotion.

Additionally, being careful of language that presumes is one lesson I learned as well. It was pointed out to me that the small word “should” added to a behavior expectation I never thought would irk a developer. For example, “Expected Behavior: The site should include a favicon.” adds presumption with the word ‘should’. It never occurred to me, this simple word, would rankle a developer. Instead, it’s better to simply provide straightforward language: “Expected Behavior: the style guide shows a favicon is added to the site.”. It also references a precise location in the documentation that defines a defect.

Constructing a Ticket

One thing that I believe helps the developer quickly diagnose a defect is a very clear title: “Global – Favicon Missing from Site”. The location ‘Global’ helps define its greater location (or, for example, “Careers”). For the title of the headline itself, I try use MLA Style headline casing, and try my best to keep it as short as possible. I’m dorkily pleased if I can get it under 60 characters. If the defect only occurs in one environment, I display an abbreviated version before the location: “[IE7] Global – Favicon Missing from Site”. More information is provided in the ticket of the specific detail, but the abbreviated environment also helps the developer eliminate possible issues.

Within the body of the ticket, I provide an Issue Description, an Expected Behavior description, affected URL(s), an Environment reference, and a screenshot or short video. If the defect is triggered by a process more than two steps (generally a UI issue not related to CSS), I will also provide Steps to Reproduce.

The Issue Description is a short sentence or two describing an issue, and its converse, the Expected Behavior, notates what is defined as being necessary to the project. These seem obvious, but it is imperative to be clear for the developer’s sake. If a developer sends back the ticket for clarification, they have taken the time to open it, read it, attempt to understand it, potentially switch their train of thought, but then send it back for clarification. This means the developer has wasted time simply comprehending the problem – which I will have to clarify anyway. For me, my personal acceptable rate of clarification is 1-3% of tickets written may need further information.

Environment references are essential for the developer. Providing a simple ‘Google Chrome’ isn’t enough – I also am sure to provide the operating system, as well as the version number. For example, today I’m using the Chrome version “Mac OSX 10.8.5, Chrome 35.0.1916.114”. It’s essential for the developer (and is one of the first reasons the developer requests information from the tester), but there are many times defects that only occur in specific environments.

The screenshot (or video, if appropriate) gives a developer a visual cue of the defect. There are many tools that can gather screenshots, but I use the simplest method of Command+Shift+4 on my Mac computer. Research methods that work best, and the developer will be appreciative and will be able to comprehend the ticket even faster.

I personally do not include Steps to Reproduce if it is a simple CSS issue, or one that can be quickly understood when landing on the page – if there is a button that has an incorrect color, or if a login form is not present on the page. Otherwise, the Steps to Reproduce are the final chance for the developer to understand the problem. I try to make them detailed and almost nauseatingly step-by-step, so that nothing is missed.

But You Test, And You Might Know Some/Most/All of This Topic

Well, I’m really pleased. This makes development easier for everyone, and you’re able to give iterative feedback in a more constructive manner. Perhaps you’ve taken this template and tweak it to your own for your group’s projects – this is definitely the just the basics of a ticket.

When I first started with testing, I learned a bit of this from a fantastic tester, and the rest was picked up along the way. I’m hoping this goes out to someone just starting out, or making the leap to Quality Assurance from another career path. I also find it helpful for trusted folks who aren’t testers that contribute to a project provide feedback to the development team. I think that providing clear feedback throughout any project will amplify your project’s quality, and the basics gets your team started on the right track.

About the Author

Sara Tabor is a NYC-based Director of Quality Assurance for Noise, a marketing and analytics agency focused on the millennial market. She has been testing for 6+ years, having prior worked in quality assurance at The Nerdery and Magenic. Her focus is manual testing, with additional background in auditing, accessibility testing, and localization testing, and works to foster quality assurance standards throughout the agency development experience. When not breaking code, she can be found playing hockey, waterskiing, knitting, or unhooking her cat’s claws from her clothing.