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

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/