Category Archives: Second Edition

Thinking Differently While Testing

Looking at a product or an application from a different perspective and understanding the end user requirements makes a lot of difference to any tester.

If anyone can test the application by just reading the requirements specified, then what makes you different and how can you stand out?

One of the simpler definitions of a tester that I have come across is:

“A tester is someone who knows that things can be different, who thinks creatively and out of the box”

Let us understand together, how we can think differently while testing.

Customers’ Perspective

Viewing your company’s service through customer’s eyes provides valuable feedback on how to improve and enhance your testing experience. How do you know customer’s view point? The answer is simple – You have to be a customer. However this can be tricky too, not all customers think alike.

Let’s understand this with a simple example.

    1. The purpose of iPod is to listen to music, but how customer listens to this music (headphone, dock) varies between individuals.
    2. The purpose of paper towel is cleaning, but how customer likes to use the towel for cleaning matters. He can use for wiping his face or cleaning the table.

Understanding the customer and the wide range of their expectations should be a prerequisite for testing software.

Test to Break Attitude

The minds of the people working on the development of an application are bound to think in the direction which will cover more positive testing. But, testers should never limit their testing to what a requirement says. You should always think “what if I do this?” while testing.

When you put on your thinking like a user cap, you may discover screens that are not intuitive which could cause potential confusion or frustration, perform processes in a different order than intended causing errors to be revealed, or even find broken links/images/functionality.

“Testing is questioning a product in order to evaluate it”

Let’s understand this with few examples on how we can think different

1. The requirement says “user can upload up to 1MB file”. What’s your approach in testing this? This is a good example for boundary value analysis and which can be a part of such test scenarios.

●   Upload a file less than 1MB ( Positive testing)
●   Upload greater than 1 MB( Negative Testing)
●   Exact 1MB (Boundary Testing)
●   Upload the 0KB file (Boundary testing) and so on.

2. The requirement says “input field cannot accept special characters”. What’s your approach to test this?

●   What if I enter only special character?
●   What if I enter special characters in combination with alpha
numeric?
●   What if I copy and paste the special characters?
●   What if I drag and drop the page URL to the input box?

The example I illustrated above might be difficult to believe but this is what would happen if I put the application into the hands of a 5 year old who wants to see the pretty flashy things show up on mommy’s/daddy’s laptop screen because he/she forgot to log off. In the testing world there is no place for the word’ invalid’. If the system lets you do something, this implies that the customer can do the same.

Working Together in New Ways

Developers and Testers act like Tom & Jerry. But what qualifies you to be a good tester is when you closely work together with developers. By looking at the application through the eyes of the developers, testers can learn more about the application.

If you find a bug and are not able to reproduce it, what do you do?

●  Do you just log defect and leave it to the developer to work on it?
or

●  Do you sit with the developer and try understanding why the issue exists and work on it together?

Software testers are always the bearers of bad news. They have to tell the programmers that their baby is ugly. Good software testers know how to do so tactfully and professionally and know how to work with programmers who aren’t always tactful and diplomatic.

Creative and Smart

Software testing is the most creative profession. Do you disagree? OK let me rephrase it this way, which takes more creativity: creating the error or finding the error?

The comparison is a bit strange, but the essence:

– it is difficult to find errors you don’t know about

– is more or less valid regardless of which type of project you are working on.

A creative and a smart tester can and will find important bugs a lot faster, especially if uses this knowledge to prioritize tasks. But we should not see creative testing as something that you do because you are in a hurry, even though it sometimes might be the fastest way to reach your goals. It is about reaching beyond the standard tests. Creativity in testing is a luxury you have to afford.

Compare and Suggest​

As a tester you are not just limited to testing the application. While testing did you ever get a thought on improvising current functionality and provide suggestions?

If not, than it is high time you think beyond to improve the functionality you are working upon. Sometimes looking into our competitor products helps boost our thoughts.

Let’s understand this with an example:

1. Why is that we try our dress on before wearing and check with our partner or friend if it suits us? Because we like to know what they think.

When you test, you are actually playing the role of an end user. Any suggestion on improvising the functionality by a tester/you is equivalent to how the end user might feel as well. Hence do share your suggestions to improve the application with your team.

Conclusion

Ending this post here, knowing it is an ongoing learning. Testing too requires a lot of hard work and constant learning. Knowledge is not static, especially not in the technical domain. Constant learning is essential in order to become better at what we do.

About the Author

Ajitha Mannem is a Sr. Test Engineer with over 8 years of experience in software testing and is currently working for a banking institute. Yes, she is a women Tester who believes in women power and is proud. You can learn more about Ajitha at www.linkedin.com/in/ajithamannem

Problem Solving and Logical Thinking

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

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

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

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

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

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

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

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

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

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

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

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

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

a. Requirement Analysis
b. Defining Test Strategy

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

          c. Defect Analysis

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

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

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

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

Some basic queries to post are as follows:

Table1

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

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

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

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

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

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

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

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

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

Flowchart

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

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

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

About the Author

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

Behaviour Driven Testing – An Introduction

What is Behaviour Driven Testing (BDT)?

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

Why BDT originated?

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

model1

 

 

 

 

 

 

 

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

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

How is BDT implemented?

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

Advantages and challenges of BDT

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

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

Conclusion

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

About the Author

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

Women Participation at Let’s Test Oz 2014

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

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

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

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

We’re both incredibly proud of what we achieved.

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

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

I think the following reasons may contribute.

1) Female Co-Organiser

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

2) Program Choice

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

Lets Test 2012 = 5/ 29

Lets Test 2013 = 5/ 32

Lets Test 2014 = 6/ 30

Lets Test Oz = 7/22

CAST2013 = 10/37

CAST2014 = 20/51

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

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

3) Community

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

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

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

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

 

About the Author

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

Logo Design Contest Result

Women Testers Logo Design

Dear Readers,

Here is the winning logo submission designed by Maria Kedemo

WomenTestersLogo_MariaKedemo

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

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

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

Learn more about the contest here: http://www.womentesters.com/women- testers-launching-logo-designing-contest/

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

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.

Customer

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

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.

Team

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

Whiteboard:

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:

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.

Applications:

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 shwetamagazine@gmail.com 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.