Q and A with Joep Schuurkes

Learning what other alternate science(s) helps me become a better tester?

As a general answer I don’t think it matters that much which science(s) you’d learn, but rather how you relate them to testing. How much effort do you put into finding and exploring those relations? If the area of science is close to IT, it will probably take some effort to find interesting over trivial relations. If it’s farther away, finding meaningful relations will take effort, because they will be somewhat more abstract.

If I needed to make the case for one field of study inparticular, it would be philosophy, since that’s what I studied before becoming a tester. One skill I picked up is being able to (partially) construct someone’s worldview based on what they say, since that’s what you do when reading philosophy. It also taught me to reason on a more abstract level – allowing me to think about the information structures involved next to thinking about the specifics involved. Thirdly, since there’s more and more discussion about ethics in software engineering, studying philosophy will help you participate in those discussions.

I am new to API testing, what tools and guidelines are recommended for API testing?

There are a lot of different tools for API testing. A general recommendation is difficult, because it will depend on the kind of API and the kind of testing you want to do.

Postman is a good tool for exploring REST and SOAP APIs. You can do that with the free version. It’s also quite popular, so you can easily find information online about how to do particular things.

When you start working with bigger test suites, more complicated requests (e.g. polling), or want to run the tests in a pipeline, I would recommend moving to a programmed solution like RestAssured for Java or pytest and requests for Python. This does mean you need to learn some programming and that may sound like a big step, but I don’t think it is. APIs are meant to be consumed by other software, so every language has several libraries to make that quite easy. Moreover, tools like Postman and SoapUI require JavaScript and Groovy respectively for more complicated tests anyway. The only way to avoid programming is to use a framework with a domain-specific language for API testing. However, then my question is: if you are going to learn a domain-specific language, why not learn the sub-set of Python, Java, JavaScript, … you need to do the API testing? That way, once you want to start doing other things with code, you have a foundation to build on.

I am planning to learn programming to assist my testing, where do I begin? And will programming skills assist me to become a better tester?

The best place to start is the place you can continue from. There are so many books and online courses, that it’s rather easy to learn the basics of programming. But then what? Contributing to an open source-project can still feel quite intimidating. You can start your own project, but how do you build a community around it? So my advice would be to start by learning a language you can use to solve a problem you have right now. Ideally, you also have some people close to you (colleagues, testing community, …) you can ask questions. Solve that first problem (it’s fine if it’s a small problem that is solved with 20 lines of code), then move on to the next one, and the next one, etc.

Personally, I started by creating a simple templating tool in Perl, because I got tired of copying and editing xml to test SOAP services. Then I built a tool in VBA for Excel that could compare values across different reports, because I didn’t even want to think of doing that manually. After which I did some stuff with Selenium WebDriver in Java. In the end, I started using Python in which I have now done a bunch of things, so it seems that I finally can call something my “main language”. So two lessons from my experiences: build things that are useful to you right now and don’t get hung up on picking a language.

As to their usefulness, I think programming skills can help you in several ways. You’ll have a better understanding of the thought processes and the challenges of programming. You’ll be able to better read the code of the product you’re testing. And you will be able to build tools to help you with your testing.

I intend to work as a test consultant with over a decade of experience in testing, where do I begin to learn about test consultation? And what are my chances as a consultant outside India?

Jerry Weinberg has written two great books about consulting: “The Secrets of Consulting” and “More Secrets of Consulting”. For something more concrete, there’s Bill Matthews’ talk “Get Out Of The Testing Game” from TestBash 3, in which he talks about a test process improvement job he did as a consultant.

On a more practical level, what consultancy can you do right now in your current job? Not that you should be giving unrequested consultancy, because that is almost never well-received, but you could do some smaller things. Where you work currently, how does testing fit in the overall software delivery process? And how does that fit in the overall business processes? What are the three biggest pain points with regards to testing? What are the three biggest strengths? If you would address the pain points, what small experiments would you design? How would you decide if these experiments initiate the desired change?

Whom do you talk to at work with? Do they have different roles, like testers, developers, project managers, department managers, …? As a consultant, you will deal with people in these different roles. Can you explain what it is they do all day? What are their goals? Their challenges?

So to summarise, two questions: what are the core skills of a consultant and can you practice these in some form at your current job?

As to your chances as a consultant outside India, I can’t offer much advice there, since I’ve only worked in the Netherlands. I haven’t come across many consultants. There are however a lot of contractors, i.e. people who are hired for a specific project. This gives companies flexibility, as it is difficult to fire an actual hire, but contractors usually require to be given only one month notice.

How to deal with time consuming meetings amidst testing, and learning to test?

This question reminds me of something I became very aware of recently: people making the distinction between working and being in meetings. They should be no different. If you’re not working by participating in the meeting in some form, that’s a problem. This also means that being good at meetings is a crucial skill.

As to the question itself – although I have no idea if the person asking is making this distinction – my answer is along similar lines. I assume that you’re participating in these meetings in your role as a tester. This means you should be testing or at least perform testing-related activities during these meetings. Which means you can use these meetings to practice your testing. So my advice would be to start with the question: what does a tester who successfully participates in these meetings look like? What do they do? And what do they not do? One thing that good testers might do is spot shallow understanding in a meeting and start asking questions to get to an actual shared understanding. Then before a meeting, pick one of these things that a successful tester does and focus on that one thing. Put it into practice and observe how/if others put it into practice to.

Apart from the meetings, the only way to learn is to take time for learning. In practice that often means blocking time in your calendar and finding a place away from your desk to do the learning. Communicate this clearly to your team and be consistent: learning time means learning time.

What books do you recommend that a tester read, in 2018 and 2019?

For a recent book I would recommend “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” by Nicole Forsgren, Jez Humble and Gene Kim.

Next to that I would recommend reading books from the previous century. IT seems to be such a fast-moving field that it’s easy to forget many of the great truths in software engineering (e.g. Conway’s Law) were already known in the 1960s. Some excellent books from the previous century are:

– Code: The Hidden Language of Computer Hardware and Software (Charles Petzold, 2000)

– The Mythical Man-Month (Frederick Brooks Jr., 1975)

– Peopleware, Productive Projects and Teams (Tom DeMarco & Timothy Lister, 1st edition 1987, 2nd edition 1997)

– Quality Software Management series (Jerry Weinberg, 1991 to 1997)

– The Design of Everyday Things (Donald Norma, originally 1988, revised edition 2013)

I am a beginner and need to know by having no formal training in testing, how can I contribute to testing?

The obvious and not very helpful answer is: learn how to test. It is rather weird and more importantly unfair to the person in question that people seem to expect someone to do testing without giving them much opportunity to actually learn about testing.

Which makes me rephrase the question to: how can someone learn testing on-the-job?

My first piece of advice would be to set time aside for learning and to stick to it. Create a program beforehand: a list of topics and resources you want to work through. This way, you’ll never get stuck on the question what to do during your learning time – or use it as a reason to skip it.

Secondly, take some time every day to reflect. Grab a notebook and write at least one page per day about that day. Don’t worry about what to write. Start with the first thing that comes to mind when you think about what you did that day. Observations and thoughts will follow and before you know it, you’ll be continuing on a second page on most days, because you’re not done yet.

Finally, you can ask your colleague testers (assuming you have these) if they would like to debrief their testing to you. So once they’re done testing something, they summarise and explain what they did to you in maximum 10 minutes. For them it’s great practice in reporting and you will get insight into how different testers test different things in different ways. An additional benefit is that debriefs are a great way to come up with more and improved test ideas.

What other roles can a tester take apart from the lead and manager, as they progress in their career?

Ideally, you work at a company that allows you to progress to an expert tester role. Strictly speaking, that’s the only real progression from a tester role. Although in an org chart becoming a lead or manager looks like a progression upwards, in my opinion you’re switching to a parallel track. The responsibilities and required skills change significantly, so they are different jobs altogether, not progressions from a tester role. Looking at it that way, there are several parallel tracks you could switch to – the most common ones are probably developers, scrum master or the product owner. The latter two seem to work especially well for testers. Testers who tend to get involved with how the team does their work, can move into a scrum master role. Testers who have a good feel for the product as product instead of ‘just’ software, can move into a product owner role.

Smart devices are programmed to send user information to the product/owner. But some of the user manuals/guides do not upfront say this. In this context, what type of testing can be performed?

I don’t have any practical experience in this area, so this will be a high-level answer. What you want to do is the perform a man-in-the-middle attack (MITM) on the device, i.e. capture the traffic to read it. There are two parts to that: the capturing and the reading. If the device connects to the Internet over wifi, capturing is fairly straightforward. Turn your computer or laptop in a wifi hotspot and make the device connect to that hotspot. If the device connects over the mobile phone network, the same idea applies, but the practicalities are more difficult. You’ll need to set up a mobile network antenna to which the device will connect. Getting the right equipment and finding out how to do that, might be a bit of a challenge, though.

Once you can eavesdrop on the traffic, the question is how to capture and read it. Tools like WireShark (a network protocol analyzer) or the OWASP Zed Attack Proxy (a security testing tool) will let you see the captured traffic, but hopefully it is encrypted. It’s impossible to give general advice on how to decrypt the traffic, as that depends greatly on the level of security implemented by the device. If you can’t decrypt the traffic, there is one thing you can do. Track how much data is being sent when. You won’t be able to draw any hard conclusions, but you can ask: considering the functionality of device, are the traffic patterns I see reasonable?

On the similar lines, can the tester ask for and test for claims – Claims testing?

What is the future of testing in the age of AI, ML/DL, IoT, Devops, Testops?

I don’t think any of these fundamentally change testing. Agile didn’t change testing in a fundamental way either.

Of course, a lot about testing has actually changed and will continue to change. And it is hard to see through all those changes – with people shifting left and shifting right, new tools and technologies emerging, the pressure to automate everything, testing being declared dead yet again, etc. However, if you take a few steps back, you’ll notice that the fundamentals of testing, the basic principles have not changed at all.

That’s actually one of the secrets in the practice of any skill. I’ve heard this from both my music and my martial arts teachers: you’re never done with the basics, you have to keep revisiting them. Refine them, deepen them, return to them to regain your balance.

For the changes coming with AI and ML/DP, I think they will add an interesting set of tools to our existing toolkit. There is one thing I’d like to see mentioned more in this context: decisions made by AI are not auditable afterwards. It’s not possible to determine how the AI came to its conclusion. It will be interesting to see to what degree we will find this acceptable when it comes to testing.

For IoT the main challenge there seems to be security, so I’d think that any tester active in that area should have some basic knowledge and skills in security testing.

Another interesting aspect of IoT is that as we turn more and more things into computers with an Internet connection, testing needs to widen its scope as well. As these devices become more and more integrated into our daily activities, we will need to take their effect on those activities into account more and more. Not just on a user-level, but also on a social and ethical level. Back in the day, most software was used by someone sitting at a desk, performing a task related to the software. That’s a significantly simpler context than the context (and actually: contexts) of the present-day smartphone user. And that’s not even a cutting-edge example.

Finally, about Devops and TestOps I can only be happy. The more collaboration between all people involved in the product’s lifecycle (conception, development, operation, disposal), the better.

___________________________________________________________________________

Author bio

Author Joep

Joep wandered into testing in 2006. Two years later he discovered context-driven and realized that testing is actually not that bad a fit for a philosopher. In 2015 he joined Mendix, because he wanted to increase his technical skills. Since then he’s become more and more involved in automation, while also taking on the roles of scrum master, then team lead, and as of October 2018 tech lead testing. Somewhere along his journey (some say it was 2013) he started speaking at conferences and joined DEWT. Outside of work, his thoughts tend to revolve around coffee, fountain pens and bouldering.

@j19sch | https://testingcurve.wordpress.com/ | https://www.fourhourtester.net/

Specification By Example and Product Quality

Target audience: Product People, Testers, Developers

I’m sure that in your workday with software development you’ve heard words like BDDATDD, and Specification By Example. Most of us link these terms to just the test portion of an application but do not observe how powerful the practices are.

Rather than just contributing to the test of what your team is developing, they help ensure that it is actually doing the thing — what your customer needs!

To try to clarify a little better where these words came from and how we got here, I set up a timeline based on several different authors. These authors have written books covering the breadth of software testing and its principles. In the end they’re all basically saying the same thing, but they’re also presenting the theme according to their point of view.


A Little History

https://cdn-images-1.medium.com/max/1600/1*_-NRLWoFi2lkQYtGW88i5w.png

Figure 1

1999 — Kent Beck (Extreme Programming Explained: Embrace Change)

In this book, Kent Beck presents the values, practices, and principles of XP. Although he doesn’t talk about the term “Specification By Example”, he talks about continually specifying and refining during development, so that customer learning is reflected in the developed software.

In the cycle he proposes, the stories are specified immediately before they are implemented. After which, they become extracted tests of those specifications. In the cycle that follows —

  • The interface is designed to meet test needs
  • The code is written to match the tests and the interface
  • The design is refined to match the needs of the written code

This leads to a decision about which story to specify next. Meanwhile, the rest of the stories remain stationary, until they are chosen for implementation.

https://cdn-images-1.medium.com/max/1600/1*3E0JkiXfNSOwYjRvkRS7Ww.png

Figure 2

2004 — Martin Fowler — Specification by Example

In this article, Martin uses the phrase “Specification By Example” to refer to what Kent Beck had called specs in the XP part of testing. Instead of dealing only with behavioral specifications (thinking about preconditions and postconditions), the word example is added to make us think in a more humanized way in terms of actual use.

An important point that he raises is that Specification By Example alone does not solve all problems. You need to always have the support of more than one tool to achieve your goals and solve problems.

He also reinforces that this only works in collaborative environments — where all the people involved in software development are together building the best product.

“Always have the support of more than one tool to achieve your goals and solve problems”

2005 — Lisa Crispin — Customer Test-Driven Development

Communication and collaboration are two key words in this article by Lisa. For each story, she asked the client how he would know that the story was complete — in the form of tests and examples.

Just like in TDD, before writing any code, the tests are written first — and then if they pass, it means that the code meets the requirements. The tests should ideally be written in a way that can be understood by an automation tool. It should also be at a high level so that they can guide the exploratory tests.

“Write tests that can be understood by an automation tool”

2006 — Dan North — Introducing BDD

During his journey using TDD, Dan North noted some difficulties, such as — where to start, what to test and what not to test, how to call the tests, and how to understand why a test fails.

BDD is an agile practice that allows better communication between all technical and non-technical people involved during a software project. It describes a cycle of iterations with well-defined outputs and resulting in the delivery of tested and functioning software.

“BDD allows better communication between technical and non-technical people involved in a software project”

2008 — Elisabeth Hendrickson — Driving Development with Tests: ATDD and TDD

In this material, Elisabeth talks about executable requirements, where you create tests before coding. These tests represent the behavior that the software should have. It reminds you that it is very important that this work be done together with the stakeholders.

According to her, the specifications give feedback on how close the team is to the “done” of a story, giving even an idea of progress toward the goal.

2009 — Gojko Adzic — Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing

The most relevant point here in this Gojko publication is — specification is not a programming technique, but a communication technique. It brings people involved in software development closer to the project.

“Specification is not a programming technique, but a communication technique”

2010 — Lisa Crispin — ATDD X BDD X Specification By Example

At Agile 2010, during a workshop on Functional Testing, about 20 people from the international software community were discussing what ATDD really meant.

As you can see in the summaries of each of the sessions above, several people were saying the same thing but with different names and some particularities — (examples, acceptance tests, scenarios, user tests, behaviour, functional tests, executable specification …).

As a result of this workshop they came up with a definition of Specification By Example that would be described in 2011 in Gojko’s book of the same name.

https://cdn-images-1.medium.com/max/1600/1*6UKh2aYAar6swiN5PTmGMg.png

Figure 3

2010 — Craig Larman — Specification By Example

When Craig talks about Less, he devotes a part to techniques that help achieve technical excellence. And guess what — the Specification For Example is there (as well as Integration and Continuous Delivery, Clean Code, TDD and others).

According to him, tests should be regarded as requirements and requirements as tests. The book reminds you that if you have a test that describes the behavior, and at the end of development this test passes — it means that you have reached the goal of that functionality.

In addition, he cites other elements we have seen in previous blocks, such as — doing workshops to collaborate and discovering the requirements, working on short development cycles, and focusing on problem prevention rather than finding.

“Tests should be regarded as requirements, and requirements as tests”

https://cdn-images-1.medium.com/max/1600/1*MDzNFZbAaQIjq69giVVggA.png

Figure 4

2011 — Gojko Adzic — Specification by example: How successful teams deliver the right software

It was through this book that I came to know the subject. Two years ago as I entered Concrete, it was the first book I received as a reference on QA’s work.

In this book, Gojko brings together a series of standards that have been observed in several successful projects. He defines Specification by Example as a set of these standards that help to develop the right software.

Since then I have been using the references in this book by Gojko when talking about Specification By Example. But in doing the research for this post, I saw that his book is a summary of what many other people were talking about the world.

Get Down to Business

Going back to the beginning of this text, many people associate Specification Examples with only the testing part of the application. But they do not use all of their tool-ing to effectively build quality products — both in terms of meeting functional specifications, and actually being what the customer needs.

I consider Specification By Example as a very focused approach to discovery. Here collaboration between those involved in the development process (product and engineering) is extremely important in order to discover the requirements needed to meet the customer’s need. It helps to exemplify them in a way that all of these people can understand what is being said (so it uses a domain language) and using engineering support (with automated testing and Continuous Delivery and Integration practices). This ensures the delivery of quality software.

Applying SBE in Practice

For each of the practices of the Specification By Example, I have examples of how we can apply it:

#1 Derive the scope from the objectives

Find out what the customer really needs. Then, give the development team the freedom to suggest the best way to do it. This is simpler to implement, faster and even cheaper.

Our focus, then, should be to understand what problem the customer wants to solve, or the goal he wants to achieve. And from there, the whole team collaborates to arrive at the solution design.

#2 Business Objectives -> Derive the Scope -> Create the Stories

For example, if we aim to solve a problem of customers who want to pay an account quickly, we can derive the following scope:

The bank account holder will pay a ticket through the barcode. He can type the barcode, which is slow, or can use the camera of the mobile phone to capture the image of the barcode. The application must interpret this image and fill in the ticket data to be paid without the need for user intervention. The user can review the data and confirm the payment.

The faster option should be offered as the first option to the user, while the slower option should be offered as an option.

Story 1: I, as a checking account holder, want to use my cell phone camera and identify a barcode, so that my ticket data is filled up quickly.

Story 2: I, as a current account holder, want to manually fill in the barcode number of a ticket, to pay it even if the bar code is unreadable.

Story 3: I, as a current account holder, want to review the completed data of a ticket informed via barcode, to confirm them and to effect payment.

#3 Specify Collaboratively

Here is where some people who try to implement Specification By Example end up getting lost. Often only one person within the team (usually the one who plays the role of QA) writes the specs, and the rest of the team just looks. If this is what happens, we totally lose the sense of collaboration.

The idea is that — all involved should participate, and this can be through workshops, or writing and review. The important thing is that the specifications are written by the team including the client. Language has to be part of the business domain and be understood by everyone.

#4 Illustrate Using Examples

Human beings better understand practical examples. This helps avoid ambiguity and communicates accurately. It is important to use concrete business examples and think about expected outputs.

In addition, the examples help to generate discussion and eliminate doubts. Here’s one —

Functionality: Free Delivery
1: Offered to VIP customers, once they buy a certain number of books;
2: It is not offered for ordinary customers or for VIP clients who buy anything other than books;
3: The minimum number of books for free delivery is 5
Examples:

https://cdn-images-1.medium.com/max/1600/1*G5xu50Tox3_BvQ-uNdaFgA.png

Figure 5

What do good examples look like?

  • Must be precise: it helps to avoid ambiguity, it should clearly inform the context and how the system should behave in each case
  • Must be complete: it is important to combine different inputs and think about the expected results, as well as to experiment with data
  • Must be realistic: always think of real user situations (caution with sensitive information)
  • Easy to understand: everyone involved should read the examples and understand without much difficulty. You can use abstractions — for example, use “car” as an example instead of describing exhaustively the characteristics of the car: four-wheel car, two-door etc., unless these characteristics influence the final result.

You can also use examples for non-functional requirements.

  • Performance: “The system needs to import X records into Y minutes by consuming CPUs.”
  • UI: Screen prototypes are good examples as well.

#5 Automate Specifications

Today we have several tools available that allow you to automate specifications. The best known is Cucumber. Here, all the scenarios you wrote using the Gherkin format are interpreted and implemented from any other automation framework. Some examples are — Appium or Selenium.

With each new feature or change to an existing one, you can add or modify its specifications and ensure that the regressive continues to work.

#6 Validate Frequently

It’s no good getting several automated tests that do not run continuously. To ensure that your specification is alive once you have implemented them, you need to use mechanisms such as Continuous Integration for these tests.

It helps to remember that they are tests built from the specifications — they ensure that what has been developed meets the business needs. They need to be run frequently with each new change. This ensures that if there is a problem, the tests give you quick feedback and indicate what needs to be fixed. Here you can use tools like JenkinsBambooCircleCI, among others.


Conclusion

The purpose of this text was to show that developing from specifications is not new. We have been talking about this for a long time in software engineering.

But the most important point of the specification as we know it today is the constant discovery of requirements related to the product. It’s also about the use of that knowledge to generate a business domain language, which will be used in the writing of live and executable documentation.

Image Credits:

Figure 2: Extreme Programming Explained: Embrace Change — Kent Beck

Figure 3: Results from Workshop in Agile 2010

Figure 4: https://less.works/less/technical-excellence/specification-by-example.html

Figure 5: https://www.amazon.com.br/Specification-Example-Successful-Deliver-Software/dp/1617290084

References if any

https://martinfowler.com/bliki/SpecificationByExample.html
http://www.methodsandtools.com/archive/archive.php?id=23
https://less.works/less/technical-excellence/specification-by-example.html
http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
https://www.amazon.com.br/Specification-Example-Successful-Deliver-Software/dp/1617290084

Author bio:

Author's photo

Linkedin: https://www.linkedin.com/in/samantacici/

Twitter: https://twitter.com/samantacicilia

QA Manager at Concrete (an Accenture Company), helping teams to define quality strategies to create incredible digital products. Today I lead 40 QAs in the Rio de Janeiro, São Paulo, Recife, Belo Horizonte (Brazil) and Colombia offices.

I am passionate about agility. I believe in empiricism, continuous improvement and diversity.

Co-founder of the Carioca Testing Group that is now part of Ministry Of Testing (https://www.meetup.com/pt-BR/Ministry-of-Testing-Rio-de-Janeiro/)

Articles of QA published in https://medium.com/@samantacicilia/ and https://code.likeagirl.io/portugues/home

What is your upcoming strategy for Test Automation?

Implementing test automation is critical to build and deploy robust applications in quick time. However, the business should have a strategy in place to make test automation functional, cost effective and easy to maintain.

In an Agile and DevOps environment, the focus is on the quick detection of glitches in an application before its eventual deployment. This is due to the fact that a quality validated application stands a good chance in securing customer approval than the one devoid of it. It is better to have a robust and secure application with less number of features than having one with umpteen features but with glitches galore. To ensure this, the software must undergo a series of tests namely, unit, functionality, performance, usability, security, and regression test among others. However, should these battery of tests be conducted manually, the eventual outcome may not be to the satisfaction of everyone due to the inherent issues with manual testing.

Test automation provides the best way to validate an application in terms of quality and ensure its quick deployment. The automated tools can run scripts that test repetitive tasks to shorten the SDLC. This way, QA automation testing can achieve speed and reliability – important deliverables of the Agile-DevOps setup. Even though the test automation framework adopted by businesses has reduced the number of test cases, there are occasions where businesses have failed to implement their automated testing strategy like in regression testing. The reasons for the failure in implementing test automation can range from the difficulty in writing test scripts with a longer lifespan to maintaining them. Let us chart a robust automated testing strategy to achieve quality deliverables and ROI.

Strategy to implement test automation solutions

#1 Automating the right test cases: Since it is difficult to automate each and every component of the application, choose the ones that give the best test outcomes. Thus, it is better to run keyword based tests, for they are easy and quick to write. Moreover, they are best understood by the software as well. The challenge is to maintain these tests and keep them updated over time. The test cases to be automated should be of types such as large datasets, high risk, repetitive, and those covering a number of browsers, platforms and networks. The automation of such choicest test cases would help in identifying the glitches better, provide relevant dashboard reports for analysis and improving the processes, and free the test automation experts to explore other features thoroughly.

#2 Cover the development sprint: The Agile-DevOps ecosystem is about building a development sprint where writing and testing the codes are done concurrently. The goal of building a development sprint is to accomplish both the tasks of development and QA together and in the shortest possible time. This is not always feasible to achieve except with proper planning. For example, when new functionality is added, it should be subjected to unit testing. In other words, the functionality should be broken down into smaller units and tested based on keywords that correspond to your business requirements. This way, the business can derive the maximum benefit out of unit testing. The QA team can write automated scripts for various units while being a part of the sprint.

The test automation solutions can help the QA team to keep pace with the development team by quickly performing various unit tests. When the development and QA teams work in the same sprint, it significantly improves the quality of the code by a large measure.

#3 Making the automated scripts to last long: Among the many challenges of writing robust test cases is the fact that they can become irrelevant after a while. This can be pre-empted by writing smaller test cases in a sequence of steps to test a functionality. The advantage of writing smaller individual test cases is that they need not be rewritten once a new functionality is introduced. On the other hand, instead of rewriting the whole script from scratch, it will be easier to focus on a few test cases pertaining to the changes.

#4 Independent of UI: The flexibility of an automated test script can be ensured if the same is UI independent. The test cases should be written based on keywords that are duly supported by the backend. At the same time, should the test cases use the UI elements, it can spell trouble as the latter can undergo changes.  

Conclusion

The only way QA automation testing can succeed is by properly designing the QA build and devising a well thought out strategy. The focus should be to write test cases that remain relevant across processes and changes.

Author Bio

Komal Lopez

Komal Lopez works with Cigniti Technologies and is instrumental in helping enterprises make better decisions related to Quality Assurance products, tools, and services by leveraging research and content. She specializes in writing about technology trends, testing trends and has been in the Marketing and Communications industry for over a decade.

Q and A with Anuj Magazine – Part 1

We asked Anuj Magazine a mixed bag of questions about testing, career and skills required for a tester. Here shared in this quest for endless testing knowledge is his deep understanding of this science and brief answers.

Q) As a tester without dev/coding skills, how to become a technical tester with programming skills?

A) Let me first get the question right before getting to the answer.
To me, the phrase ‘Technical tester’ is an oxymoron.

In today’s day and age, everyone associated with software business are supposed to be sufficiently technical.

In my own career, I have interacted with professionals from spectrum of roles and functions. As example, one may argue that salespeople can escape with minimal technical skills. But the best sales people I have seen are the ones who are technically very articulate (among other skills)) and can strike rich conversations with customers. This, for a tester it’s a given that she has to be technically deep in the chosen area of expertise and technically broad in other related areas.

2. Second thing that I would like to correct in the question is the association of word ‘technical’ with only programming skills. Before you get me wrong, programming skills are without doubt important but they just aren’t the “only” technical skills out there. Right from your product architecture, APIs, underlying operating system, interactions with external systems, security, performance- there are innumerable ways to slice and dice technical skills. So I would encourage testers to have a holistic view of skills rather than looking at it from a narrow lens.

With this context established, I really see the problem expressed in this question as being mindset challenge and learning or learnability challenge. Allow me to explain it a bit:

A cursory glance at the way our society operates will reveal that as a humans, we are experts at categorizing ourselves in as many granular ways as possible. An example, we subconsciously categorize people based on city they come from, the way they speak, based on religion and so many ways. This thinking is just the byproduct of society we live in and I am not trying to be judgemental about it. It is what it is.

But professionally the problem happens when we start applying such thinking at work. We use the society imposed template to look at the jobs and start categorizing them. We start thinking I am a manual tester and programming is developers responsibility or managers job is to encourage the team unless she does it, I won’t show initiative. This is the mindset aspect of question that I was talking about. If we apply this template to our jobs, we give away control of situations to the forces beyond us. So the first thing to do to become a better at anything you want to do (in this case, programming) is to instill belief in self that it is my responsibility to become a better at a desired skill, it is my job, I am not doing a favor on myself by learning- my future paycheck depends upon how I learn. Would strongly urge to shun categorization mindset.

Secondly, I talked about it being a learnability challenge. What I mean by that it most of us want to learn skills but we don’t see “learning how to learn’ as a skill. That ‘i want to learn programming language’ is a skill based learning mindset. If you twist this question to ‘How quickly can I become a world class programmer” it will invariably force you to think through the learning methods you should apply to get to the goal in minimal possible time.
Most people like to learn via books, via internet sites, joining classes and that is fine. But the problem becomes if you continue leveraging just these means but remain underinvested in evolving other learning methods that can give you better investment from time. 70:20:10 model of learning addresses this challenge well. It simply states that 10% of all learning happens via formal education like classes, books, online tutorials. 30% of learning happens via modes called as social learning, which includes mentoring, spending active time with people who are great at what you aspire to become and 70% of learning happens on the job, when we work on live projects, take on challenges head on while working under time pressures etc.

The irony is that more often we spend 80% of time learning via formal education means, which really impacts 10% of learning surface. So there is a need to look at learning from fresh lens and invert the way we think about it.

Let me summarize the answer in 5 actionable tweets:
1. As a tester, you are expected to be technical. There is no ambiguity about it.
2. Being technical, doesn’t just include programming but a wide variety of skills based on context of your project/area.

3. Shun the categorization mindset. It is solely your responsibility to get better at your chosen area of expertise. Choose to stay in control of your learning.

4. Don’t just narrowly focus on what you wish to learn. Invest your time in learning how to learn effectively.
5. Don’t just learn from books, online/face to face trainings. Get a mentor. Spend ample time learning from experts. Pick a live project that is much beyond your current skills and persevere to execute it till the end.


Q) If I join as a SDET today, where should I see myself after 10 years?

A) In the next 10 years, you should see yourself as a CEO of an organization making immense impact on the company, employees and society.
What distinguishes us humans from other living species in the power to dream. Why waste this power by choosing to dream small. One promise we should make to ourselves is that whenever we think of future, it is bigger, bolder and better, much better than today.

There is one more perspective I would like to offer on this subject. When we think of ten year career horizons, we generally tend to think growing vertically i.e. if I am an SDET now, I would be Senior SDET in 2 years, then Staff SDET and so on. There is nothing wrong in thinking vertically except for the fact that vertical plans for careers tend to be self-limiting. What I mean by self-limiting is that designations trap you into thinking that reaching next level is the only goal you should have even if you are capable and are performing at much higher levels.
If you consider any industry leader you admire and look at their career profiles, I bet they wouldn’t have reached where they have reached by just following organization’s laid down career frameworks. They may have followed that a bit but more than that they would traversed horizontally and chartered their own unique paths.

In summary:
1. You are capable of reaching at unprecedented heights in your career in 10 years time provided you choose to aim higher at the first step.
2. Follow career paths laid down by organizations as a guidance at best but not the only way to grow. Successful people create their own paths however difficult it may be.
3. Like everything around you, within next 10 years the SDET role itself would have undergone transformation for good or bad. It’s best to have a pulse of what’s happening around you, have informed opinion about the future and change course as needed.

Q) For Women Testers, do you advice moving into technical role or management role as she moves forward in her career ?

A) Let me start by sharing 2 stories with you:

I recently ran Singapore full marathon. It was a gruelling course of 42.195 km with a very hot and humid conditions. In such a course, one seeks inspiration from fellow runners to keep at course and continue going. Many a times during the run, I looked up to female runners who were running better and strongly than I was.

A couple of years back a wrote this article: “What testers can learn from my wife” in Women testers website. In this story, I narrate how my wife inspires me professionally everyday. Being a woman in an extremely male dominated automobile industry, she managed to successfully carve a niche for herself, despite many odds facing her. She took-up and excelled in both management and technical path.

What I am trying to allude towards is that I don’t believe that gender should even be a factor in deciding or limiting yourself to choose any career path of your chose. Of course, there may be challenges in certain paths, but isn’t that true for anything worth doing in life.

One heuristic you can try choosing between technical and management role: If you like being with yourself more, try technical path. If you like being with people more, try management path. However, this heuristics is only valid for early stages in the career. As one grows towards more senior roles, even the technical roles need more and more social skills and management/leadership roles need more and more technical skills.

In summary, no career path is written in stone. Following 4 steps can help you reach your potential.

1.identify your strengths,

2.show appetite for experimentation,

3.if things don’t go as per your liking don’t hesitate to change course.

4.go to step#1.

https://www.womentesters.com/what-testers-can-learn-from-my-wife/

I don’t see career paths from the lens of gender.

In my world view women can excel in any chosen path- technical or management and so can men.

How concepts of feminism makes me a better tester – Part 2

Link to Part 1 of this article – https://www.womentesters.com/how-concepts-of-feminism-makes-me-a-better-tester-part-1/

Introduction

This article is based on Eeva Pursula’s talk at the Agile Testing Days (Potsdam, Nov. 13. 2018). It sums up her realizations on how feminist mindset supports the testers mindset, and how feminist concepts and feminist thinking can help us identify problems in the work environment and fix them to make our teams work better. At the end she will also share about what feminism can teach us about defining a testers role.

Target audience: Anyone

Cherish diversity

True collaboration requires some tolerance on people being different. We can have mutual goals and respect for one another even if there are issues where we do not share same views. You don’t have to win every argument, sometimes it’s enough just to listen, ask questions, and maybe tell why you disagree. It’s beneficial to learn why does the other think the way they think even if you never would agree with them. New ideas only emerge in environments where conflicting thoughts get to encounter, and new ideas are needed if we want to build better products and test better.  

The more diverse  are the backgrounds  and interests and views of people we design new features with  or have lunch with, the easier it is for us  to expand our thinking to areas we did not know  were not yet included in our plans.

But diversity does not come by itself. We have to actively work on it, realizing that some of the obstacles are invisible for the privileged. [4]

For example, democracy is good, but it does not guarantee that minorities get heard.

Have you ever been in a retro where the team gets to share their concerns and then they vote which problems will be discussed and solved? Imagine a team of let’s say three people, who’ve worked together for years and got to build their processes and tools as they like.

Suppose they need to hire  more people, and they manage to select two people who view things very differently than they do. These two will start figuring out how to adapt to the company culture and how to promote things they feel should be done differently. Then comes retro. Everyone gets to share their ideas, but when it comes the time to vote, the trio will pretty much agree on things and vote for each others ideas.  

The newbies don’t see things the same way, they probably don’t even understand each others struggles. The only way for them to get their unique ideas heard is if someone decides to unite with them on an issue. But who would do that, as the trio already feels that the most important issues are getting attention, and the other newbie is worried about their own issues?

Amplify small voices – actively find ways to promote minority thoughts

Some years ago women in Obama’s administration got tired of the common situation of their ideas being ignored unless a man would later present them as his own ideas. They discovered that they can change this by amplifying  each others voices. The idea is basically to repeat the message giving credits to the one who first introduced it and thus forcing others to notice it too. [5]

Similarly, we can amplify minority thoughts, if we just recognize that some voices are not heard,  and are willing to give some of our own space for their ideas. It just doesn’t happen if we don’t do it deliberately.

Of course retros are not the only ways to promote change within a team. You can have an impact through training, informal discussions, code reviews, pairing etc. But as we start in a new job, we already carry burdens of the role expectations from our previous jobs and gender stereotypes and so on. People often need active encouraging to become aware of these roles and to overcome their limitations to what they are. And sometimes the whole team needs to work together to achieve this.

For example, we intuitively expect men to be leaders and women to be followers, and that affects how we feel about a person when he or she makes a suggestion [6]. One way this is seen is that men interrupt more often than women do, and both men and women interrupt women more often than men [7] [8], and men are more easily forgiven that kind of behavior [9] [10].

So these kind of unconscious attitudes can form a barrier that blocks some of us from taking their ideas forward. That’s why we need to work together with these issues, because for an individual bumping into these obstacles, it can be a choice between wearing yourself out in never ending battles, or adapting yourself to the views of majority, or simply leaving.  

Psychological safety

When organizations go through changes, people generally don’t feel safe. Change often means that someone will be out of job. Now when we go through a change from a waterfall model into agile, many people will fear for their jobs. The roles offered in agile teams are quite different than in waterfall teams, and there may be no ready made job descriptions for people who do not identify themselves as programmers even though their work may still be very much needed. This is one reason why so many organizations ended up in a situation where the developers are allowed to “do agile” as long as it looks like waterfall for all others. If you want the whole organization to be agile you may need to help waterfall people find agile roles.

So sort of the starting point for people to feel safe at work, is that they can feel that they are useful. Some of us work on continuing to be useful by constantly trying to learn new things. Others hang on to an illusion of being irreplaceable. It is easier to believe that you are irreplaceable, and make it look like that for others too, if you concentrate on knowing things, not on learning things. So lack of safety blocks learning. We need safety to be able to do things that may fail, or to say out loud that we do not have all the answers that are needed. To do anything new.

And we need a sense of being listened to, to share our most precious thoughts.  

If we don’t feel safe, problems make us focus in covering up instead of speaking openly about the problems to get them solved.

Are we all really welcome here?

For decades already, there’s been discussion about how to get more women on male dominated fields of the society. We’ve seen many campaigns that encourage girls to study math and even computer sciences. Unfortunately the gender ratio in technology does not only suffer from young women not understanding that they could actually aim here, but also from experienced women leaving the field [11] [12].

Women leave because they don’t see that they had career prospects. They don’t feel appreciated nor supported. They are labeled emotional or difficult for demanding equal treatment compared to their male colleagues, and too many also report having been harassed in work environment.

But this does not concern just women. Ratio of women is rather easy to measure, ratio of people from oppressed subcultures is not, and they most probably experience similar difficulties.

So it seems that in tech we need to do something to our work culture to make it a less hostile environment.

There is no silver bullet for this. We need many changes, and we may not be able to do them all at once.

If we look at the problem strictly from the point of view of modern feminist discourse, it offers a couple of tools for creating a safer space for us.

Listen to understand

The problem with many normal conversation environments is that there is sort of a pecking order that allows the privileged to hijack every conversation and start explaining what the underprivileged actually think and why they think so, and how they should be thinking instead. Or what kind of problems they have and how they should be solved. Some forms of this behavior have been named as manterrupting, mansplaining and whitesplaining, but there are other forms as well, and you don’t have to be white nor male to end up doing that.

The problem is that we interpret the world from the point of view of our own emotions, attitudes and opinions, and they may block us from allowing space for minority thoughts. We should learn to concentrate more on listening than on giving our own interpretations. Asking questions more than giving answers. Let people tell themselves what they need.

But we should not listen politely just anything another person says. We should notice when the discussion is about defining “the others” and try to make it clear that it’s generally not ok. Some people seem to think that drawing lines between us and them brings us closer to each other. But we can never be sure that discriminating language would not hurt anyone who we consider to be one of us. You might not know if someone in your team is gay or has children with different skin color or ethnic background than you expect. And even if you do know your team well, if our culture encourages discriminating language, it forces us to seek for conformity, making it more difficult for people to stand out by expressing new thoughts or asking questions. That’s why we should not tolerate intolerance.

Choose your words wisely

Notice trigger words and avoid them. A trigger word means a word that gets someones attention more easily than others. In feminist context it means especially words that provoke strong negative feelings, making a person so upset and overwhelmed by emotions that it kind of overrides being rational. When someone is triggered, it will be really difficult for them to express themselves clearly, let alone understand opposing views. That’s why using language containing trigger words is not a way to promote freedom of speech, instead it’s an effective way to prevent discussion by creating hierarchies of power play and teasing.

It can be difficult to understand why another person is being triggered, but in the end, that is none of our business. Triggering can be caused by a word that reminds someone from lifelong experiences of constant fear and abuse, and most of us don’t really want to hear those kind of things explained. So we can be kind to others as well as towards ourselves by simply not using a word we know to be triggering for someone.

Words we choose to use also have a huge impact on what conclusions we are able to make, and often a word that triggers someone is also a word that will narrow your thoughts and contain some unconscious assumptions, so being aware of them is not just a question of being nice, it’s also a question of critical thinking.

When you realize what are the trigger words, you can also understand that nearly any subject can be discussed in a civilized manner as long as you avoid these words. If you can’t find a way for that, then you will need to do some more listening and learning before you can contribute to a conversation.

Admit failures and apologize

These rules are surprisingly difficult to follow. So apologize if you accidentally hurt someone. Show empathy and never undermine another person’s feelings. Learn from your mistakes instead of just trying to justify them.

This can feel strange, as many of us are used to some sort of a macho culture that promotes just the opposite behavior.

Feminism breaks limits forced from outside

The revolution of feminism started when women got tired of being defined by male opinions. Often the female views were dismissed as emotional and irrational, in contrast to the rational and science based views of the white male. Too bad that having balls and a position is not enough to make a person view the world correctly. Thanks to male doctors countless women have suffered unnecessary pain and agony as they’ve been forced to give birth laying down on their backs. There was a long period when small children did not get pain killers during anesthesia in surgery because male doctors had concluded that small children are not capable of feeling pain.

I’m not saying that women would not have done similar mistakes if they had been given similar positions in the society. We are humans,  and as we seek for new information and try new things, we often fail, and at times we don’t know that we are failing. And when in this insecure world we find a piece of authoritative truth to hold on to, it’s very tempting for us to build on it instead of questioning it, and that’s how harmful misunderstandings can become the cornerstones in the foundations of the systems we are building.  

Feminism fights for a world where the impression of an outsider does not define who we are.

Define your own role

I hear that at least in Finland, there is a constant demand on visionary talks that would reveal the future role of a tester. Many seem to have fear for the future, as they don’t feel that their work is understood nor appreciated. They hear ideas about replacing testers with cheaper people or automation.

I will tell you a secret. There is no future role of a tester. Well yes, there are trends that affect many of us, but the great testers I’ve met have all very different backgrounds and none of them have identical work roles. When a tester changes a team or changes a company, in many cases their role changes.

So nobody is ever going to be able to tell, what is a testers role. There are various roles for a tester, and it’s up to you to create your own. You are the only one who can define who you are and what you want to become.

We are not getting useless. Our tasks will become more complex, and with that it will be more and more important to understand your limitations and what kind of people we need around so that together we can conquer the quests. And this openness to admit that you are not perfect and still go proudly ahead,  is something we can learn from the feminist discourse.

More about feminism?

In case you got interested in feminism, there’s one last disclaimer. Don’t learn your feminism from white CIS-people. I’m not saying that our voices are not worth listening, I’m just saying that we should have stopped being in the spotlight at latest around the change of the millennium. There are other voices that are more relevant. Just remember that feminism is not supposed to be easy or consistent, it’s supposed to be thought provoking. It’s not supposed to be nice, but making pain visible and sharing it. And these things make it worth studying for us testers.

References

[4] Emerald Insight: A cultural feminist approach towards managing diversity in top management teams (Jawad Syed & Peter A. Murray, vol 27 issue 5) https://www.emeraldinsight.com/doi/abs/10.1108/02610150810882288

[5] The Washington Post: White House women want to be in the room where it happens (Juliet Eilperin, Sep 13 2016) https://www.washingtonpost.com/news/powerpost/wp/2016/09/13/white-house-women-are-now-in-the-room-where-it-happens/?utm_term=.04093738b462

[6] Forbes: The Price All Women Pay For Gender Bias (Kim Scott, Jan 31 2018) https://www.forbes.com/sites/break-the-future/2018/01/31/why-gender-bias-holds-us-all-back/#60d533174c5f

[7] aeon: How men continue to interrupt even the most powerful women (Tonja Jacobi, Dylan Schweers, May 26 2017) https://aeon.co/ideas/how-men-continue-to-interrupt-even-the-most-powerful-women

[8] Bustle: Research Confirms That — Excuse Me — Women Are Interrupted Way More Than Men (Morgan Brinlee, Jun 16 2017) https://www.bustle.com/p/research-confirms-that-excuse-me-women-are-interrupted-way-more-than-men-64732

[9] Pew Research Center: On Gender Differences, No Consensus on Nature vs. Nurture – Americans say society places a higher premium on masculinity than on femininity (Kim Parker, Juliana Menasce Horowitz, Renee Stepler, Dec 5 2017) http://www.pewsocialtrends.org/2017/12/05/on-gender-differences-no-consensus-on-nature-vs-nurture/

[10] A shorter read e.g. Forbes: New Research Reveals Society’s Attitude About Gender Differences (Bonnie Marcus, Dec 5 2017) https://www.forbes.com/sites/bonniemarcus/2017/12/05/new-research-reveals-societys-attitude-about-gender-differences/#7c5bf6fc67c5

[11] Kapor Center: The 2017 Tech Leavers Study – A first-of-its-kind analysis on why people voluntarily left jobs in tech (Allison Scott, Freada Kapor Klein, Uriridiakoghene Onovakpuri, Apr 27 2017) http://www.kaporcenter.org/wp-content/uploads/2017/08/TechLeavers2017.pdf

[12] A shorter read e.g. CIO opinion: Why are women leaving technology jobs? – A look at the possible reasons why women are moving away from STEM careers (Jamie Mercer, Sep 29 2017) https://www.cio.com/article/3229355/it-industry/why-are-women-leaving-technology-jobs.html

Author’s bio

Author's photo

Eeva Pursula has been in the software industry for 8 years, mostly doing exploratory testing. She has worked with many development teams practicing different blends of waterfall and agile, testing many kinds of browser-based solutions.

Eeva has a wide range of interests that have taken her to study topics from physics to philosophy to arts and social psychology. For her testing at its best is about questioning and opening eyes to avoided subjects. She is a storyteller who likes building collaboration instead of confrontation.

Twitter @EevaPursula

LinkedIn – https://bit.ly/2SgtRnz

How concepts of feminism makes me a better tester -Part 1

Introduction

This article is based on Eeva Pursula’s talk at the Agile Testing Days (Potsdam, Nov. 13. 2018). It sums up her realizations on how feminist mindset supports the testers mindset, and how feminist concepts and feminist thinking can help us identify problems in the work environment and fix them to make our teams work better. At the end she will also share about what feminism can teach us about defining a testers role.

Target audience: Anyone

Why a tester would relate to a feminist?

Testers and feminists have surprisingly much in common. We cherish a questioning mindset. We notice things that others don’t pay attention to. And sometimes we feel a need to do things that some people find disturbing. We may seem angry as we see a lot of structural problems and feel that we do not have power to change the things that need to be changed. And we meet resistance by people who don’t want to dig deeper into things.

Many things (like women’s right to vote) that were considered radical when the first feminists started to speak about them, are taken for granted today in many parts of the world. Some people have it difficult to understand that this does not mean that all relevant goals of feminism would already be achieved. Or they feel that since things are worse somewhere else, we shouldn’t point out problems at home.

Similarly, a tester may face pleas to stop finding new problems, as so much has already been done. But having fixed the worst bugs that were found on the first test rounds does not guarantee that we had a decent product in our hands.

The mindset of curiosity and suspicion

Feminism is about noticing what things are taken for granted and what is assumed, and questioning those things, the conventions and priorities and the frameworks of our thinking, to find out, which ones of them hurt us more than help us.

For example, I used to work in a smallish company where project managers were supposed to substitute the assistant when she wasn’t available. About 90% of the time it was a woman filling in for her even though about 90% of the project managers were men. Nobody meant it to be that way, but since we didn’t do anything to change this, we actually created a company culture where women’s work was less important than men’s work.

Similar situations are seen in many places, as women tend to do tasks for the common good just because these tasks need to be done, while men seem to be better at taking only tasks that benefit their personal careers [1]. If we want more women on leading positions, we have to notice these patterns and start valuing this work, or divide it more evenly, or hire someone for it.

Questioning is also the basis of a testers mindset. We get the best results if we are able to notice the hidden assumptions and forgotten points of view before any code is written, and communicate in a way that has a positive impact. But often times it would not (yet) pop into our minds at the whiteboard, or we fail to notice that our discussions leave people with different interpretations. So we bump into problems when we start testing.

I’ve seen many carelessly formulated requests that have lead into fixing wrong things. For example, when we want to get rid of some error messages, there can be confusion about whether the fix is about hiding the error message or about finding what caused it and fixing that. And sometimes the first suggestion for solving a problem only solves that one step, leaving the workflow unusable. Or the side effects of the fix make the product worse than what it was before.

There can be problems even if the functionality is able to do what it’s supposed to do. I’ve reopened features that could not be found by a user, or gave them false expectations. And I’ve seen a system freeze when the second user logged in.

Even if we try to think about an issue from all possible perspectives, some blind spots easily remain, so we should always be skeptical about whether all real workflows have really been thought through, and whether everything is done that needs to be done. If something seems trivial or avoided it’s probably good to look at it more thoroughly. And when we see risks or are confused over what has been done, we have to have courage to say it out-loud, even if we are not sure whether there really is a problem or not.

Making pain visible

Feminism is about making pain visible and sharing it so that it can be turned into a force that changes things. That’s what #MeToo campaign is about, as well as many human rights campaigns, sharing painful stories. It is not nice, but it seems to be necessary, because the ways we protect our minds from the threats around us, produce victim blaming. We easily close our eyes from the suffering of the others, whether they be refugees or transgenders or what ever group we alienate ourselves from, making up excuses why we should not care, and why they are to blame for their own despair. Nothing changes if we don’t see how much pain there really is, and how little power the victims have for avoiding it. Fixing things starts by seeing and understanding the problem.

As testers we also need to point out things that are sort of hidden below the surface. In a software project, there are many questions that need to be solved, and we need to find the ones that have been forgotten or given up with.

Once I was asked to test a product that had proven to be difficult to develop further without breaking old features. I read through the requirements, and in addition to simple user workflows, there were a bunch of small but important features with tricky time dependencies and other stuff that made them impossible to be tested by just using the software. So we had a meeting with the people responsible for the product and I asked how are these things tested. To one of my questions the answer from the developer was: “We don’t have  an environment where that could be tested, and it worries me.” Apparently nobody had ever before asked him about that, and he had never found time to raise this issue by himself. But once he got it out, he continued the discussion telling some other rather worrying things that I would not have known to point out. So sometimes the best testing is about finding the ways to make developers speak.

Breaking illusions to enable deliberate choices

Feminism is about breaking illusions. For example, in the University of Kansas, they created an exhibition named “What were you wearing?” to break the illusion of too sexy clothes causing women to be raped [2].

Testers also break illusions, mostly illusions related to the quality of the system under test, but it’s not just about finding bugs.

I used to test a rather old and big software that had three development teams that were responsible for different modules in it. But there were things that were common for all the modules, like some of the user roles. In that product, there was a tiny checkbox that gave superuser rights for a user. As I worked with different people in different projects, I found out that the meaning of this checkbox was seen quite differently in different teams and by different developers. Some seemed to think that no customer should ever be a superuser, while others coded customer requested features behind it. So I raised a question about this to allow us to make deliberate choices. That lead into some quite interesting discussions as well.

Making corner cases visible

Inter-sectional feminism raises awareness of corner cases that affect many lives of true, living people. The point is that our work for giving oppressed groups decent possibilities in life does not always help people who are at the intersections of these groups, marginalized in more than one way. We tend to see people from minority groups as solely representations of that particular minority group, so for example in Europe it’s easy to think that depressed muslims or black trans women would not exist. When we talk about European values, we often think about thinks like justice, equality and human rights. These can only be achieved if we give a voice also for the people who are normally neglected.

Similarly a tester sometimes needs to find stories to justify that a bug needs to be fixed even though the developer thinks that no real user would ever really encounter that problem. I’ve found it helpful to be able to name a particular customer, who would most probably see the situation from my perspective. Sometimes it’s of course difficult, and we may have to settle for waiting for user feedback. In those cases it would be good to make sure that we have a way to get some user feedback, because minor problems in software can become costly as they affect which services our customers choose to use.

Check your privilege

But if we talk about feminism, it’s not really enough to question things out loud.

What makes feminism unique as a philosophy, is that it also wants to make privilege and power structures behind the conventions visible. Privilege means things you don’t have to deal with, things you basically do not need to see nor understand [3]. It’s quite easy to see things where we are less privileged than others. If you are left handed or from a poor family, or you have any other disadvantage in your life, you probably see how most people around you are more privileged than you are. The challenge is to see, how I am privileged myself, and how my struggles are less than someone else’s. And we tend to make assumptions about the privileges of others, even though many of them we cannot see. We should be more aware of these assumptions and be able to question them. That can only happen if we learn about lives of different people.

From a testers point of view the concept of privilege is quite self evidently useful when we talk about accessibility. One reason why computers and robots are so great is because thanks to them physically disabled people can have normal jobs, but only if the digital tools that we build for our customers are accessible.

User roles are another point related to privilege. Many testers have heard a developer say “works on my machine” as they use administrator access rights when testing the feature, and the problems are only encountered with more limited access rights.

Tools are also a privilege. Many of us work with huge fancy screens our customers can only dream of. After the workday we may use just a phone or laptop for our personal needs. When my first child started school, for the first year we didn’t get any notifications from the schools electronic communication system. That was because I had filled our contact information to their web form using my laptop, and the check-boxes for giving permission for sending notifications did not fit onto my screen, so I didn’t know that they existed.

So there are quite many things where we have to remember that our users do not have all the information and tools and options that we have.

Leadership is about making people want to follow you

In addition to understanding our privileges compared to our customers, it’s also good to be aware of the power structures at work.

As testers, we are the ones who bring the bad news and spoil the joy of others by reminding them about inconvenient realities. Someone else has to worry about how difficult it is to fix the things we find. From a developers point of view that might feel like we use our power to be mean. So even as we need to be rather merciless in shedding light on problems, we also need to show some empathy and ability to evaluate the significance of our findings. Pick up your fights, and you will more likely be taken seriously when it’s time to fight.

And fighting generally is not the way I want my job to look like. I want to build collaboration, an environment where all roles support each other. It is important because there are many things where I really do not have a power. A tester does not get to decide what improvements are done and how the code is written, and this kind of things can cause frustration for us.

So we need to see, what are the things that we can change, who do we need  to convince in things that are not ours to decide, what is the information we need to give them to make them see the significance of the things that we see, and how to tell about our findings in a constructive way. Testing does not add quality to the product, quality is added by giving developers better possibilities to do their work well, and testing is one crucial tool for that. The way we communicate about problems, and how we are seen as humans, has a huge impact on how the problems are issued, and whether our work is seen as something that takes us towards the teams goals or not. 

References

[1] Harward Business Review: Why Women Volunteer for Tasks That Don’t Lead to Promotions (Linda Babcock, Maria P. Recalde, Lise Vesterlund, July 16 2018) https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions

[2] Huffington Post: Art Exhibit Powerfully Answers The Question ‘What Were You Wearing?’ – The installation proves that clothing has nothing to do with sexual assault. (Alanna Vagianos, Sep. 14 2017) https://www.huffingtonpost.com/entry/powerful-art-exhibitpowerfully-answers-the-question-what-were-you-wearing_us_59baddd2e4b02da0e1405d2a

[3] Everyday Feminism: What Privilege Really Means (And Doesn’t Mean) – To Clear Up Your Doubts Once and For All (Maisha Z. Johnson, Jul 21 2015) https://everydayfeminism.com/2015/07/what-privilege-really-means/

Author bio

Author's photo

Eeva Pursula has been in the software industry for 8 years, mostly doing exploratory testing. She has worked with many development teams practicing different blends of waterfall and agile, testing many kinds of browser-based solutions.

 

Eeva has a wide range of interests that have taken her to study topics from physics to philosophy to arts and social psychology. For her testing at its best is about questioning and opening eyes to avoided subjects. She is a storyteller who likes building collaboration instead of confrontation.

Twitter @EevaPursula

LinkedIn – https://bit.ly/2SgtRnz

30 Days of API Testing

MINISTRY OF TESTING is back with the 30 Days of Learning to Test API’s.

https://www.ministryoftesting.com/dojo/lessons/30-days-of-api-testing

30 Days of API Testing

The 30 Days of Testing Challenge is back!

The theme this time is API Testing and this challenge has been kindly sponsored by API Fortress – be sure to check out the free trial of their scalable and collaborative API testing suite for Testers and Developers.

These challenges are a great way to learn on your own, as a team effort or join in with the wonderful Ministry of Testing community online.

Below is a list of 30 challenges and a bonus challenge, one for each day of the month. Download the PDF below. Save it somewhere. Print it out. Stick it on your wall. Let’s do this!

What are the rules?

The goal is to tick off as many of the challenges as you can. You can do this in your own timeframe, or you can join us in our joint community effort throughout the month of November. We will be encouraging the community to share their progress on this challenge from the 1st of November 2018.

You may have an image to share, a blog post, a video, status update, whatever it is!  Come and participate!

Here is how you can share your progress:

30 days of testing

30_Days_of_API_Testing

ISO Multilingual Testers

ISO Multilingual Testers – How knowing to speak other “languages” leads to better testing.

ISO multilingual tester must be able to translate and interpret business requirements from Project Managers/Business Analysts in order to assist developers in creating software that End Users can use with little fuss and much gratitude.

Do you work with other business units/teams?  Have you gotten acceptance criteria from a Project Manager or Business Analyst and questioned its purpose?  Do you take time to explain to the developers why this certain feature needs to function in this way?  Do you ever have to sit with end users work through the development?  Wouldn’t it be more helpful if a QA/Software Tester’s job ad looked more like the one above?  In this article, we are going to explore the unique experience of speaking multiple “languages” and how that, in turn, leads to an improved testing experience.

Project Manager-ese – This language is part Sales manager, part developer speak and will occasionally include end user speech.   Project manager-ese shares roots with Sales in that the purpose is to sell the business unit and upper management that this particular feature is beneficial to the company and will be completed by the agreed upon time.  Bringing this to the development team runs the risk of things getting lost in translation, i.e. benefits to the company, timeline constraints, etc.  On some occasions, if the development team declares the timeline is too constrictive the project manager does not seem to have a way to translate that to the business unit.  This will cause a large language gap that is hard to bridge.  As a QA, knowing project manager-ese and cultivating the ability to recognize that certain project manager constraints are self-imposed rather than promised to the business unit will go far in the QA being able to work with the development team to create the best possible product within the project manager-ese constraints. This ability to translate helps the QA determine how and which items to test and an approximate timeline needed in order to complete testing.  Translating this back to the Project Manager will get slightly tricky, especially if the testing could push the timeline further than promised.  At this point, the QA should use any sales-ese they have at their disposal to start negotiations with the project manager to ensure that proper testing time will be taken in order to deliver a great quality product for the Project Manager and End User.  By speaking the Project Manager’s language, the QA can ensure good quality in a workable timeline.  In order to get the idea to translate into Project Manager-ese, however, you also have to know how to speak Developer.

Developer-ese – This language is built on highly technical terms, programming language and fandom for their favorite sci-fi/fantasy/etc. stories.  This language can occasionally be overly complicated and hard to follow.  When first learning developer-ese, one must work slowly and consistently.  It is an excellent idea for a QA just starting with developer-ese to utilize many of the resources available to learn technical terms and programming languages.  Getting a baseline knowledge of how the company’s chosen programming language works is helpful.  If you are still having issues, do not hesitate to ask a developer questions.  One finds that, though the speech feels out-of-reach, stopping to ask a developer for help will assist in bridging that knowledge gap.  If you still have trouble starting the conversation, listen to their conversations with other developers about the fandom that they follow.  If you can brush up on your fandom, you can open the door to starting that technical conversation.  Do not be afraid of developers or developer-ese.  Most developers are quite helpful and willing to teach a QA about what they are writing.  Their code is a point of pride and if you can follow it and comment on how well it is doing, or you are able to follow it and point out something they may want to look at, they will become more helpful.  Learning developer-ese will also create a symbiotic relationship where the developer, and other non-developer members of the team will look to you to get their point across to the other side.  So, because you have added both Project Manager and Developer to your language tool box, not only does your job as QA become easier, but you can speak their language to help them understand what you will need and/or expect going further into projects.  There is another language you will need to add to your tool belt as well – End User-ish.

End User-ish – This language is the language of the people.  It gets its roots in sarcasm, expectations and disappointment.  It can be found with the group of people that are the recipients of the software the QA has been testing.  You have spent time thinking like the end user, but there are things they know that you just will not know.  They will speak in terms of their job and how awful the software is to use. You will believe that, after all your hard work, the end user will be impressed and instantly fall in love with what your team has done.  They will not.  Do not be discouraged.  They simply speak this language.  They are unhappy with what they currently have but they are so used to it they do not want to change anything.  You will try everything you have to convince them that this new software is more efficient and will help them improve their work.  They will tell you that you are wrong.  Your next step is to engage them.  Ask them questions as to what they do in a day, how they use the system now, why they think your improvement will not help them.  Agree with them.  They are right; it is different and they do not know how to use it.  Show them.  Get down in the weeds with them and learn from them.  The more you know about the end user’s use of the system, the more of their language you will learn.  They are not trying to be negative on purpose; they feel unheard, left out, unappreciated.  Learn that their language does not mean to pick everything apart; they are just showing you what it is they do and what you are missing.  If you can master end user-ish, you will be able to communicate their needs, wants, uses into your tests and to the rest of the team.  You will be able to translate to the developer that, while they think putting this button over here will be better, it is better to leave that button right where it is because the issue that really needs solving is that modal opened by the button is too small.  You will be able to raise points in the meeting with the Project Manager about how the use will actually use the system.  When it comes time to meet with the end user again, you can use your end user-ish to explain that, in order to fix that modal, the button had to move, too.  There will be an amount of trust created with the end user because you took the time to learn end user-ish.  The rest of the team will appreciate that as well as the fact you took time to learn their languages as well.

Being multilingual as a QA is not about knowing French, German, Spanish, Cantonese, etc, though knowing another language is never a bad thing.  It is about knowing how to interact with your different team members.  It is about being able to tell the developer they did a great job but the end user really wants that button to do something else.  It is being able to tell the end user that the project manager designed that popover modal to look that way because it fits with the rest of the design of the site.  It is being able to communicate to the project manager that the workflow they created works great but the end user really uses the system like this.  It is about learning, communicating and getting the best product out the door, efficiently and on time with as few defects as possible.  Most of all, being multilingual makes you an incredibly beneficial member to have on the team.  My parting advice: do not be afraid to learn a new “language”; it could turn out to be helpful and fun!

Author bio

Author Photo

I am a Quality Analyst for FanThreeSixty, a sports fan engagement software company based in Kansas City.  I am always on the quest to learn something new, be it new testing techniques, how to better edit my photos, or how to raise my children to live up to their dreams.  I live with my husband, 2 children, a cat and a dog near Kansas City.

Feel free to contact me on LinkedIn: https://www.linkedin.com/in/amanda-perkins-bbaa3020

Reviewed by

Russell S. Perkins, M.S., M.A.

Registrar and Director of Institutional Research

University of Saint Mary

Leavenworth, Kansas

Benefits of Public Speaking

In the beginning, I wasn’t sure what would come of speaking at software testing conferences. Mostly, the thought of speaking at a conference evoked anxiety for weeks if not months beforehand. Now, a year later as I think about speaking at conferences my reactions and thoughts are quite different. Nowadays, I encourage other people to speak and I am happy to give tips on speaking when asked. But the most important question – or perhaps even more important is the answer to why speak at a conference? Here are a few of the benefits I’ve discovered from speaking at conferences.

Speaking helps solidify your thoughts

There is nothing like having a keynote scheduled on your calendar to make you realize that you need to collect your thoughts on a topic. By standing up in front of people, you might feel as if you need to do your “homework” which may entail reading related books and blogs, talking with others viewed as experts, research and finding influential quotes on a subject, Speaking at a conference really makes you and also to pull  your own thoughts together in a cohesive fashion. You might find you have conflicting opinions on a subject but realize that in your presentation unless you want to clearly identify more than one viewpoint, you need to find your viewpoint, your opinion and you want to be able to share those thoughts say it well.

Speaking gives you an opportunity to clearly share your ideas

Presenting, especially at a keynote level, where your talk might be recorded especially drives the feeling and desire to be able to say what you want and to say it well. You might feel you will be quoted or tweeted and you want your words to “come out right.” In the case of having people tweet about your talk, your thoughts will be reduced to a quip so it helps to have “quotable statements” so that you do not feel inaccurately quoted. When your talk is recorded, you feel your talk will last, be listened to possibly years after the recording is made. (Not to add to your speaking anxiety but recordings on YouTube due tend to last a long while.)

Speaking opens the door to meet other people

One (of several) unexpected bonuses of speaking is having the opportunity to meet people. Even though I am ultimately an introvert, there is a large (and growing) component of myself that is an extrovert – I enjoy meeting people and as I travel to speak, I find people want to come and talk to me after a presentation. It is a wonderful feeling to think that sharing my thoughts builds a connection to other people such that they want to talk with me and share their stories. On many occasions, I end up staying in touch and talking with people for – in some cases – years after meeting. I’ve had people help me find positions, I’ve hired people I’ve met and I’ve built solid professional relationships.

Speaking builds confidence

Interestingly, presenting originally was a source of anxiety and self-doubt but now years later, I find presenting a familiar setting.  Just like how some people may have a familiar office (as a consultant my workplace setting fluctuates continually), instead I find the speakers’ stand a familiar place. Getting to a place where I enjoy presenting even during presenting has been a pleasant surprise – I had thought I would always be so anxious I would never enjoy presenting. Don’t misunderstand – speaking is like playing golf or talking taking a photo – you might have great luck one day only to find the very next day that your performance does not go so smoothly. And just because I say I enjoying speaking does not mean I don’t get nervous beforehand or even during speaking – it’s ok though; I think all the energy – nervous or otherwise helps keep me on my toes. There is a balance between being ready and over-rehearsing. For a long while, I did not rehearse – to be honest – it had not occurred to me to rehearse until another speaker mentioned that he always rehearsed. So for a number of years, I would typically rehearse but I have to confess that I no longer rehearse. I’m comfortable “ad hoc” and sharing a story based on time available and not worrying too much about it. This more relaxed approach does not mean that I don’t know what I want to say, haven’t thought through my slides or gained some idea about the timing of my talk. (I’m oddly quite proud that I tend to finish without rushing and without going “short” on time but that I have timing figured out well.)

Speaking adds to a career

Presenting at conferences has also helped to show my passion and commitment to my career. Some of my clients watch my videos or listen to a webinar before hiring me. In the case of working as a solo consultant – it is difficult to distinguish what aspects of my “extracurricular” activities clients find interesting and helpful, instead, I believe they see my collective involvement and dedication to the field and to the professional community.  Another unexpected benefit of speaking at conferences is that when I need to speak onsite for a client, I’m less anxious, more familiar with speaking and as a result, I’m more comfortable speaking even under what could be more anxiety-provoking short notice situations (or groupings of people).

If you have a chance to speak at a conference, try to look past the understandable anxiety and consider the benefits. Present only on topics you know, talk about your own work experiences and you might discover you enjoy public speaking.

Author Bio

Karen's photo

Karen N. Johnson is a software test consultant. She is a 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