February 28, 2024 • 38 mins
In this insightful episode of Testing Experts with Opinions, we examine the shifting landscape of software testing roles and qualifications expected by 2024. We talk about the integration of automation into traditional roles, the increasing demand for quality engineers, and the rise of 'full-stack engineers'. We also venture into the fascinating realm of AI in testing, discuss various training paths for testers, and consider the future significance of manual testers.
Explore with us, the different facets of non-functional testing types and discover potential career avenues like observability testing and test data management. Learn why adaptability is key in this transformation and how platforms like Test Automation University and Udemy can aid in acquiring these new skills.
Our panel emphasises the growing importance of continuous learning in software testing. We highlight the shift from manual to automated testing and performance testing, and discuss the skills upgrade and mindset change necessary to tackle these evolutions in the field. We delve into the importance of exploratory and user experience testing and cover continuous testing — anticipated to be a major trend in 2024.
Fully immerse as we discuss the practices and concepts of continuous testing in both Waterfall and Agile models. We bring into focus UX testing, the user perspective in testing, and the need for expansive test coverage. We also consider the prominence of IoT in the current testing landscape, and debate over the relative emphasis given to desktop and mobile testing by organisations. Listen, as we round off this episode with a focus on striking a balance between methodologies, available tools, and project-specific needs.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Welcome to Testing Experts with Opinions, an inspired testing podcast aimed
at creating conversations about trends, tools, and technology in the software testing space.
Prediction for 2024 is there's going to be a shift in terms of testing roles
and the qualifications are also going to be tested and tried.
(00:21):
For example, the conventional manual testing role is going to be required to
be coupled with a bit of automation.
The manual testers or the traditional software test analysts may be required
to write a little bit of code in there to be able to execute already written scripts.
Likewise, there's also going to be a demand for automation engineers who can
(00:45):
step up into quality engineers in the sense that they have got a quality head.
They're true quality gatekeepers, and they can write code, and they can think,
or their thought process is shift-left kind of focused.
And again, there's likely to be a demand for more of estates,
our software developers in tests.
(01:08):
And these are automation engineers who have got a very strong development background,
but have also good understanding of software testing. testing.
So career wise, there's going to be a shift. Recently, there are quite a number
of training certifications for AI in testing.
And my prediction is testers who are going to remain on the same level with
(01:33):
the same knowledge are going to become irrelevant,
and will be surely faced of other companies already in South Africa,
they're now aiming for what they're calling full-stack engineers,
full-stack quality engineers.
They should be able to do functional testing on web and API.
They should also be able to write tests in for mobile, both APM and Android.
(01:56):
They should also be able to do performance testing using any of the open-source
tools like JMeter and other commercial tools like Neolord.
So the conventional qualifications and roles or responsibility of testers,
I foresee them changing in 2024.
Matt, you've just said about four things there which can make a podcast on its own.
(02:18):
I'm going to have to, I will have to decide which of those I talk about.
I was part of a conversation this morning, and it was around manual testers
and manual testers that only have manual testing skills.
And obviously, the natural thing always is, oh, we need to turn them into automation
engineers, or they need to learn automation.
(02:41):
But I guess there are other things that you can do as well as a manual tester these days.
And we can touch on the low-code automation tools in a second,
which is still automation.
Automation but in terms of things like
test data engineers so so we know at
inspired testing there's test data management and there's test
environments management there's data testing etc you can you can probably transition
(03:04):
quite a bit easier from being a manual tester to maybe a test data engineer
as opposed to automation or potentially and this is more on the more in on the automation side,
maybe learning something like Robot Framework or Tricentis, maybe Tosca,
(03:25):
those tools which don't need the deep-rooted automation coding knowledge.
Then again, not every manual tester wants to do automation. Not every manual
tester wants to go down the automation route.
But if we're saying that the market and the trend seems to be that quality engineering
role where you need to be able to do, I guess all aspects to some level.
(03:49):
What advice would you give to a manual tester today which don't,
well, they either don't or they haven't had the opportunity to go down the automation route.
What other, I guess, avenues are there for them to upskill or reskill themselves?
Now, it's not just a question for you, Matt, it's for everyone. Stefan?
(04:13):
So I just understand your question. where you're saying if automation isn't
necessarily something that they've had opportunity or would be uncomfortable
with, are there other avenues in testing that they could maybe look at?
Yeah, so let's – I mean, the obvious ones are, okay, you're a manual tester
today. That's the thing you've always done.
Okay, become a test manager or become a test lead.
(04:36):
Now, that's another contentious issue for me because if all companies are going
towards agile, what's a test manager's role within agile? but that we can discuss another day.
But if you're a manual tester and you don't necessarily want to go down the
automation route, I guess what other avenues are there for you?
(04:56):
It's interesting you asked that i was reading a few
articles this morning and listening to something from joe calentonia
as well and he touched on observability testing sorry
that's a tongue twister for me all of a sudden observability testing
so i mean that just opened up
my thoughts in terms of thinking about non-functional testing
types that i think there's a whole untapped level of testing that not a lot
(05:20):
of people are dabbling with i mean if you talk about observability observability
testing i mean it's something i personally haven't played around with a lot
in my career and i don't know if if you just in terms of the concept it's it's focusing on,
how well a system can be monitored and understood and debugged in
real time particularly in production environments so if
(05:41):
that system goes to production and something goes wrong how
easily can the devops or the prod support guys look at
the events the metrics the logs and alerts and that's
something you can start to implement quite left in this
you know as an and push that as a non-functional requirement
and test that and take that all the way through i think there's
lots of areas that people can focus on that's not
(06:01):
necessarily coding specific but yeah maybe that's just one of the areas of non-functional
testing but i think that's something to look at is across the moving more shifting
testing left and far right i think there's a lot of non-functional areas somebody
can become an expert in without having to even touch a piece of code.
So I want to think about what you just said, Leon, around people who don't want to. Can they?
(06:26):
Absolutely, right? So you can always change your career focus if you want to,
right? And no one can stop you from doing that.
But I think if you want to stay in software quality assurance,
then unfortunately you will have to touch on these things.
Now, I know that we are scared and a lot of thesis out there are scared to embark
(06:51):
on these journeys, but it's not as scary as you might think, right?
So I see it, this quality engineering role as being able to help yourself when
you need to help yourself, right?
So we are not saying, I'm not necessarily saying be an automation expert,
be a performance expert, be a security expert, right?
I'm saying that have the attitude that will get you to a GP place.
(07:14):
So if you go to a GP, the GP can diagnose something and he or she will help
you. But they're not an expert, a specialist.
They will send you to a specialist when they need to send you to a specialist.
But they still understand everything in the medical field well enough to at
least start helping you.
And I think from a testing perspective, if you are a manual tester today and
(07:34):
you say, well, I absolutely categorically don't want to get involved in anything
else, then maybe your only option is to look at.
Being a test data manager or moving into something else.
But if you want to stay in the – and when I say being a test or software quality
engineer, that is someone that can work in an agile testing team,
(07:54):
also Waterfall, but an agile testing team.
And if you want to contribute in that agile testing team, these are the skills,
especially around automation and some of the non-functional testing types that you will have to learn.
And again, I've had many conversations with potential clients that says,
well, my people can't go to automation.
(08:16):
I say, well, just start contributing to the automation effort.
Don't become an expert developer overnight, but understand if we're using BDD,
our feature file fits into the framework and start writing those things.
So there are pragmatic ways for you as a manual test that can get involved in
the automation effort, for example, right? Right. The same with performance testing.
(08:37):
If you analyze a user story and you see, well, I think there's a performance impact there.
Write it down and get the experts in to come validate what you thought and learn
from them. And next time you'll know a little bit more.
So it's not being an expert from a GP to being an expert in everything tomorrow.
But it's having that attitude to listen out for certain things when I'm analyzing
(08:58):
stories and requirements to see, oh, maybe this accessibility thing or,
wow, this sounds to me like this security risk.
Score this sounds to me like this performance impact and then getting people
so you're still entrenching into that quality engineering mindset although you're
not an expert in everything but i think that's a must from my perspective.
Just to concur with what you said, so basically it's all in the mind,
(09:21):
and it also starts with you as an individual to understand what is it that you
want to do to stay relevant.
For example, there are so many free sites like Test Automation University where
you can learn coding from scratch.
There are steps which are set there step by step to say, if you want to be an
automation engineer who focuses on Java or C Sharp, this is the route that you
(09:44):
have to take. This is the path that you have to take.
So there is a whole lot of open source sites that you can use.
And again, Udemy is there.
For a 200 grand, you can buy a course that can teach you how to learn a new
programming language. There are some exercises there.
And once one is done that, it's also important to get hands-on exposure.
(10:06):
For example, for those in companies where they are already implementing.
Shouldering is the best way to learn.
You go and get paired with someone who is already doing something in the project.
Not something theoretical but you
you get your hands dirty into the project start observing
watch while they're debugging take notes and you
learn from there so anybody who is a manual tester today
(10:28):
if your attitude is right and you can literally do anything it's only last week
where we're looking at certain profiles where we discover that some of the best
it guys really did not start study computer science they started something completely
different so it's all in the the mind, and the attitude.
For anybody who is coming from a manual testing background, if you tell yourself
(10:50):
that you can do it, you can definitely do it.
We also at some point carried an experiment with one business analyst.
We wanted to see how that person was going to learn robot framework automation.
We just said, okay, these are the keywords that you use. If you want to do this,
you just type these commands. Can you do it?
The business analyst within a matter of four days was able to just go through
(11:13):
the robot framework training and was able to write some robot framework scripts.
So it's all in the mind. Start by just telling yourself that you can do it and
then you can follow all the steps to get your hands dirty with the code.
Okay, so say all the manual testers all over the world listen to us and they
(11:34):
transition to the roles you have recommended.
Who is going to do manual testing unless you say manual testing is going to be eradicated?
I think the manual testing aspect becomes part of the quality engineer.
So we're not saying manual testing has no place in testing. That's actually the complete opposite.
(11:58):
The fact is just if you look at companies today or employers,
they're looking for someone that can do both.
Well, not both because both suggests only two.
There's actually more than that. They want people that can do manual testing
and automation and potentially some basic level of maybe performance testing,
security testing, accessibility testing, etc. et cetera.
(12:21):
So I think it's just, and Matt just alluded to mindset.
I think it's a mindset shift within maybe the whole testing community where
you need to realize that even if you're an automation engineer and that's your
passion, some days you're going to have to do manual testing.
Maybe it's every day, but there's no, oh, I'm only an automation engineer,
(12:43):
therefore that's the only thing I'm going to do, or I'm just doing manual testing.
So I think the manual testing testing aspect doesn't lose any of its value at all.
It's just why do I need to pay for two people doing two separate,
I guess, roles where actually I can combine those into two, sorry, into one.
(13:05):
And it's a similar thing that we're seeing with the whole move towards estates
and developers and testers are getting closer and closer together.
If we think about it, developers are now expected to do more testing and testers
are expected to do more development in that scenario of estates.
And in a similar way, I think it's similar in manual and automation and performance testing.
(13:31):
Within the testing competency, those things are expected to all be done by a
single person as opposed to three different people.
I don't know whether anyone else wants to add on to that.
I totally agree. I agree. I
don't think it takes away any of the testing disciplines or phases, right?
It just, you need to, as a tester, enhance the one that's needed for the job
(13:54):
today, right? And I agree with you, Mahatla.
Manual testing and the art of testing and test analysis and design,
that's even more important than ever, right?
And we're not taking away from that. That is just saying that do that more effectively
and then look out for other things as well or non-functional requirements for,
oh, yes, I've written the test as I've executed it.
(14:17):
Let me automate it and add it to a pipeline. So absolutely, I think that skill
will always stay the most important part for any testing, right?
There's a saying out there that all testing is manual, right?
So if you're not actually trying to interrogate the system and finding issues,
then you are not really testing. And that will always be a manual effort,
and that will always be any taster's main skill.
(14:38):
I mean, it's not replacing a tool in our tool belt, it's just adding more tools
and then selecting the one best fit for the job.
But I think there's, again, I'm just going to go back to Matt's point about mindset.
So I think a lot of manual testers, and we're getting slightly stuck on this,
but a lot of manual testers feel that there's a massive mountain that they have
(15:00):
to climb to get towards maybe being able to do automation.
But if you know a basic level of code, it doesn't take you very much to get to that level.
And then if you're working with an established automation framework,
we're not expecting you to build an automation framework from day one.
(15:21):
If you're working in a fairly established automation framework,
it's not difficult writing automation tests, especially if you're just having
to add additional tests, et cetera.
So I would say that that needs to be sort of almost the first goal.
Just get yourself to understand whatever, maybe Python, maybe Python is the
best example the best choice because it's one of the easier languages to learn.
(15:46):
But understand the basics of Python, which isn't difficult to grasp.
It's not going to take you long.
And then work with an established framework where initially you're just adding tests.
And if you're working in a company where there is an automation team and you're
the manual tester, actually start pairing with them. Sit next to them and just
(16:06):
watch what they're doing.
And gradually you start taking on on more and more.
But that starting point is always, in my mind, the starting point is always
having that basic understanding of a language, a programming language because
otherwise it's going to be Greek to you.
It's like trying to read French when you're English or Afrikaans.
(16:26):
But also, you know,
Just to add to that, we all find ourselves in the technology world.
And the one constant with technology is it's fast moving and it's always changing.
Now, I think one of the things that you have to accept when you're in this space
is you're going to constantly have to keep up to speed with what's happening.
(16:47):
And you're always going to have to keep learning.
This is not the type of job where you can stop learning at any point because
we've used the word irrelevant, and it's maybe a very strong word,
but to some degree, that is what will happen.
Your skills will become irrelevant if you don't keep up to speed in terms of changes.
(17:10):
So I think with AI, to me, it just feels like everything is moving much quicker than before.
So maybe we're giving away our age, but maybe 20, 25 years ago,
you could be a manual tester and maybe you could sustain that,
I guess, career for 20 or 30 years.
(17:33):
It doesn't feel to me today, sorry, but without learning any additional skills.
So you start doing manual testing at the start of your career,
20 years later, you're still doing manual testing.
You've not really invested in yourself to upskill yourself.
It doesn't feel to me like a 20-year-old today is going to be able to learn
one skill and then for the next 20 years,
(17:55):
not do anything and still be irrelevant in 20 years time because things are
just moving too quickly and also just my last point because i'm talking too much.
Testing has also evolved massively over the last 10 or 15 years.
So in the past, testing was almost a bit of a side hustle for many where there
(18:16):
wasn't so many companies specializing in testing.
There wasn't so many opinions and, I guess, innovators around testing and changes
to tools and tool vendors, et cetera, et cetera.
So that's also contributed to
this market moving quicker than it did 20 years ago, 15 or 10 years ago.
Because there's so many more people invested in changing it and making it more
(18:42):
efficient, et cetera. Any opinions on that?
Yeah, I think I'll go after you.
Yeah, Leon, so I actually agree with you, particularly when you said some time
back, others would take testing as a side hustle.
Go to any company, any other profession, or any other person can tell you that
(19:03):
I also can test. Talk to a product owner.
They will tell you that I also can test. A business analyst,
they will tell you I also can test.
Even developers, they will tell you that I also can test.
So back then, testing was just something that can be done when other important
things in courts, when other important things are done.
But with the way things are moving we're
(19:24):
shifting left we're shifting right we cannot afford
to remain with the same knowledge testing with the same knowledge or using the
same test cases to to test the same thing so basically we have to keep up learning
upskilling ourselves because that's the only way we can be good testers picking
the relevant bugs but otherwise if we remain with with the same knowledge,
(19:47):
same test cases. We don't change anything.
We'll have test cases which are always passing, but defects will always be picked in production.
Okay, I think that's a good point, a good time to move to the next point.
Jan, what's your prediction? It's actually good that we had this conversation,
(20:08):
Matt, because it feeds into what I want to say and what I want to talk about, right?
So why now is quality engineering a thing?
Why are we expecting people to do more, right? Why are we shifting left and
have we shifted left for the last 10 years?
Why are we moving down pyramids to do things earlier, right?
(20:29):
And why is AI important, as we just established, in the test is to make ourselves
more efficient and more effective.
So there must be a reason for all of these things.
And one of the things that I'm seeing is this whole continuous testing principle.
So we are doing all of these things to enable us to provide information and
(20:50):
testing-related information quicker, faster, so that deployment cycles can get shorter.
Right and we've all heard about ci
and cd and those things are great and we even went
as far as integrating automation frameworks in that but it goes
beyond that it's moved it's the
the movement of getting rid of testing as
a phase and introducing introducing testing as
(21:13):
a process right so no longer do we
want testing to be a phase somewhere in the stlc we're doing
all of these things that we just spoke about to make
testing part of the process so this whole continuous
testing cycle especially in 2024
because for all the things we said is now there we've been
hearing about it for a long time but we are now there where testing needs to
(21:35):
be continuous we want to make changes we want to deploy continuously right and
that's why automation is there and that's why all of these things are there
now because we are doing all of this and mamata to your point and i'm I'm actually
saying two things and not one.
But so continuous testing, absolutely, I think it's a big trend.
And part of that is this whole concept of exploratory testing.
(21:56):
Now, because we are spending so much time automating things and continuously
testing things, it's extremely important that we hone our exploratory testing
skills as testers, right?
Because you don't have the luxury of writing extensive test cases anymore.
You don't have the time to do all of these things. You need to have that testing
(22:17):
mindset and start exploring the application beyond the boundaries of just a test case.
Now, we all know exploratory testing is still a planned testing activity, right?
I'm not saying just go wild west on the application, but plan your sessions
and start exploring the system more to get a lot of these defects out of the
way very quickly, right?
Start understanding what the system will do when we do unpredictable things
(22:43):
to it as users would, right? So two things, continuous tasting,
I think, is the one thing.
And in the back of that is, what do we do and how do we find the defects still and taste the system?
It's by placing a big emphasis on exploratory tasting and doing more in the
exploratory testing world that we've ever done before.
Thank you, Jan. I really like the way you introduced the topic.
(23:06):
Basically, you said, why are testers required to do more?
So, in my opinion, testers are required to do more because I think this is more
like feeding onto the previous topic where we're saying we have to upskill and
we have to remain relevant. event.
We're expected to do more because a whole lot of these repetitive tasks should
be done by tools, should be automated, and that's where technology kicks in.
(23:32):
Basically, we need to take away any task that can be done repetitively.
We can use a tool, we can schedule it, it can be run after hours.
Instead of it being done by 10 people, one person can do it.
The shift now is is testers should mainly focus on the complexity of work, not the volume.
Forget about the volumes. Let the tool do that repetitive task.
(23:54):
The tester now, to your point, needs to focus more on more of exploratory testing
and more of user experience testing.
So these are some of the things which the tool cannot intuitively say,
okay, this is very easy to use.
Some of the things needs human opinions and the other external factors that
may influence an opinion about usability of a tool or a system.
(24:16):
So basically, this topic is kind of tied to what you're talking about earlier,
where if we are not relevant, we may discover that we feel, oh,
testers are doing a lot of work.
They're doing too many tasks at the same time.
And the feeling maybe will become jack of all trades, but master of none.
But it all goes to let's upskill and let's be relevant.
(24:41):
A lot of what we often talk about is all the examples we cite are often related
to companies following Agile or doing something within an Agile type of model.
But how does what you've said, Jan, so continuous testing, how do you see that
actually working in a company not following Agile?
(25:02):
So we often laugh when we hear about people still talking about waterfall,
but actually companies are still following waterfall.
And often companies that say they're doing agile are actually doing more waterfall.
So does that still hold true for, I guess, companies that aren't fully agile?
(25:22):
So that all continuous testing thing and also companies that haven't actually
adopted automation yet and gone down that route.
How do you see continuous testing playing out in those scenarios?
Well, continuous testing will be very difficult if you don't embrace automation, right?
So I think it doesn't matter the methodology you follow.
(25:45):
If you are not embracing automation throughout your SDLC, you're never going
to reach continuous testing.
You're going to continuously taste, but that's going to be a big effort for
you, but you're not going to get to continuous tasting.
I think when you look at Waterfall itself, the concept of continuous tasting
is not necessarily going to work because you don't have the same….
(26:09):
Short cycles where you need to deploy, right? If I was a test manager in a Waterfall project,
I would still try and aim for that because you still want to get the testing
out of the way and get to the definition of done, although that's not official
thing in Waterfall, but get to the definition of done for the piece of testing as soon as possible
because then you need to move to the next piece that's on your list, right?
(26:31):
So if you look at Waterfall versus Agile, it's not to say that we can't follow
the same practices. is, the last
part of it in the deployment part is not necessarily going to be there.
But from a testing efficiency perspective, surely you'd still want to do things
as effective and efficient as possible that enables you to do more of the testing
in a shorter period of time.
(26:52):
Like I said, we're giving away our age, but when we started testing,
it was not an hurdle for a test cycle to be six months.
It was a fairly typical test cycle, right? But I would still say in today's
world, there are tools and technologies out there to help you to do more in those six months.
And then mitigate more of the risk and focus on expanding your test coverage.
The exploratory testing, and Matt, I'm glad you mentioned the UX testing as
(27:15):
well, right? But those two aspects are all true. It doesn't matter the methodology.
You want to explore. You want to get testers to think more like a user would.
Back in the day, again, we labeled testers as super users of a system.
When you said that in the interview, people hired you on the spot, right?
But that's really what we kind of forgot throughout the way,
(27:36):
that the tester should also look at it from the user perspective,
from a user experience, and then from exploratory tasting perspective about
how users on any level would actually operate the system.
Any other opinions or comments?
Okay. I think we've got time for one more. and
(27:58):
anyone want to discuss anything specific any specific
ones that you want to highlight or should we go to my matla
again i i just wanted to or stefan sorry stefan was first sorry something that
stefan said so maybe we are going to back to stefan again but you mentioned
around iot i think we've we've heard about iot the last couple years some people
(28:21):
embraced it some people said it's not not really a thing to test.
But I really think in today, in 2024, IoT is here, right?
Whether you like to know about it, whether you like to accept the fact or not that it is there.
Is it completely different than API testing? I suppose in its core, it's pretty much that.
But there are a lot of nuances around IoT, the environment that the IoT device
(28:44):
lives in that we have to consider.
So I think IoT is definitely something we can't forget about in 2024.
And if you're going to do so as an organization, at least, will slowly become
irrelevant in that space.
Agreed. I think you've just prompted a thought in my mind in terms of mobile testing as well.
(29:04):
So we know that more and more people are using mobile devices for shopping and, well, everything.
As much as you can do on your phone as possible, that's what you'll do.
But it feels to me like often the first consideration is still desktop and browser on a computer.
(29:25):
Instead of thinking about mobile. So what I'm trying to, I guess,
say or suggest is, if you look at a project and it's an automation project,
often the first thought is, how are we going to automate this on the browser, on a desktop site?
Mobile always feels to me like it's a secondary thought.
(29:47):
It's not always front and center in terms of that automation strategy.
Strategy but with with i
guess mobile becoming more and more and more prominent every year
do you guys and girl feel that
anything is going to change around i guess mobile testing
mobile test strategies we know
(30:10):
there are there are cloud-based cloud-based solutions out there which which
many companies are going to now do you feel that they need to expand on their
service offerings and and start doing other things to maybe keep ahead of where
mobile is going. Any thoughts on that?
(30:30):
Yeah, I think mobile is getting more and more complex as the days go on, as you said, Leon.
And the amount of devices grows by the day as well.
So definitely from a cloud provider perspective, I think there's a lot more they can do.
And I've seen a lot of them starting to delve into how can we couple providing
(30:51):
you the device with testing the device.
So I think that's really where you want to go from a software testing organization
perspective. perspective, you don't really just want to use a mobile provider
to provide the mobile phone, but you also want these providers to help you with
the testing effort they're on.
Now, a lot of the organizations out there providing these devices have started
(31:12):
getting into the automation world, starting to help you to write test cases
with an AI perspective on that device and the app you put on the device.
So I'm seeing because it's getting more and more complicated,
these providers are now bringing more and more to the table to enable us to
actually get the coverage that we need.
Fair point. Yeah, in addition to what you said, Jan, what I've also observed
(31:34):
is, you know, looking at the traditional way of testing mobile applications
where you need a physical device,
there are a number of providers who are now coming up with some cloud-based
virtual environments and also some virtual images where you can literally spin
up any container and run as many tests as you want without necessarily being
(31:56):
limited by the number of physical devices You can connect at the same time.
You can get an image in the cloud
for whatever version or model of mobile device which you want to test.
So these are some of the trends which we have observed that are also picking up lately.
And also some low-code, no-code organizations are now offering quite a number
(32:18):
of images for anyone to test on mobile devices.
Is and and in terms of the skill set do you feel that there's a is there a change
in skill set is there is a upskilling that needs to be done so if if you i i
don't know maybe maybe you've,
you've worked in a company that that's only had a website and there's been no
(32:39):
mobile presence i can't imagine that but let's assume that you've only you're
only used to to doing testing on on a web browser, on a desktop.
Is there a different skill set that you require to do mobile automation?
Is there a focus that needs to come into certain people's, I guess, upskilling?
(33:01):
So in most cases, I've observed that the main automation which is being done
is mainly based on the APM framework.
And this can then be written in the C-sharp or Java.
But the cloud aspect is just maybe some external third-party vendors will provide some virtual devices.
(33:21):
So skill-wise, I've not really seen so much of a huge shift besides the conventional
C-sharp and Java using APM.
But the integration with the third-part tools where they provide the platform
for you to be able to create your test cases faster for the mobile devices.
I think that's the technical skill.
Okay, more of a tooling skill that is to be learned. But programming language-wise,
(33:44):
it's mainly C Sharp and Java.
Python is coming in though, but C Sharp and Java are still the main programming languages.
Okay. Yeah.
Amatla? Okay, so Leon, And I wanted to understand where you are coming from
with mobile testing, because most organizations are already adopting the mobile first strategy.
(34:06):
And with the design for their web pages, they want them to be responsive.
You know, if you are on a desktop and then you transition to mobile,
so the pages scale according to the resolution.
So, I wanted to understand where you were coming from with the search in mobile applications in 2024.
(34:32):
So, I think for every example of a company that's going mobile first,
there's probably another company that's not.
And I'm not talking about the company so much as from a testing perspective.
So, if we know that there's a mobile site that needs to work on both,
(34:58):
it's adaptive and it works on the browser as well as your mobile browser,
are we giving enough, I guess, are we giving equal importance to making sure
it works on the mobile as we are?
Just historically, we've always tested on desktops and it feels like that's
always still the default thought.
Are we giving enough consideration?
(35:19):
And then if it's a native app on iOS or Android or wherever,
are we critically thinking about what's required for that?
Is that at the forefront of our minds or is it still a bit of an afterthought?
If you know I need to test this on 15 different devices.
What is your strategy and are you giving importance to that?
(35:41):
Are you going to go a physical device route or are you going to go a device
farm in the cloud somewhere?
Also, if you don't have a framework, what sort of framework are you going to
adopt? Are you doing automation on mobile?
I mean, there's a client that we spoke to recently and they're not doing any mobile automation.
(36:02):
Automation they they they automating the heck out of their website but mobile
automation has never happened and and that just made me think that maybe that's
a not a common thing but we kind of live in this i guess false sense of security
where we feel or we think everyone is is giving.
(36:22):
Equal importance to desktop or mobile or
whatever but but maybe that's not always at the
forefront front of people's minds maybe maybe the feeling is
that well if it works on desktop and and
it's sharing the same code base etc we don't actually have
to test on mobile the risk is lower i don't
know so it was just from that perspective okay i think i think let's wrap it
(36:45):
up there because even my mom's not going to listen this long our one listener
we've already lost uh stefan did you want to say something stefan as a as a
closing thought no pressure having to put on the closing Now,
I just wanted to mention in the mobile testing, I think there's lots we can do.
I think even companies that are looking at mobile testing and realizing the
(37:05):
importance, I think there are a lot we can say about standardizing the approach
that we should look at when we talk about mobile testing.
There's definitely a specific set of checklists or items that we should look
at, like staggering the network, rendering, turning the phone around, battery consumption.
There's things very specific and niche to that. And I think there's definitely.
(37:27):
Places or things that we should consider specific to that area of testing.
And I mean, we've seen that with clients recently as well, where we've helped
them standardize their approach.
So I think there's definitely a niche approach and companies should make an
effort to look at what are the special considerations they should take when
looking at the mobile testing.
(37:49):
Even silly things like per application, understanding what the demographics
are of your various applications and making sure that, you know,
what kind of phones to certain areas,
what phones are more popular in the bulk of your user base and making sure those
ones are being tested first. You know, there's a lot of things to consider.
(38:11):
Yeah, so maybe that's just my final thought. Okay, awesome.
All right, thank you very much for your time. I think it was a good discussion.
We touched on quite a few things, but I think a lot of the opinions It's actually
given me some ideas for maybe some focused discussions going forward where some
(38:31):
of these aspects we can delve deeper into and dive deeper into and maybe have
a dedicated podcast for it.
But, yeah, thanks a lot. Until next time.
This has been an episode of Testing Experts with Opinions, an inspired testing podcast.
Find us on LinkedIn, Twitter, Facebook, Instagram, YouTube, and TikTok,
(38:52):
where we're driving conversations. Thank you.
Welcome to Testing Experts with Opinions, an inspired testing podcast aimed
at creating conversations about trends, tools, and technology in the software testing space.
Prediction for 2024 is there's going to be a shift in terms of testing roles
and the qualifications are also going to be tested and tried.
(00:21):
For example, the conventional manual testing role is going to be required to
be coupled with a bit of automation.
The manual testers or the traditional software test analysts may be required
to write a little bit of code in there to be able to execute already written scripts.
Likewise, there's also going to be a demand for automation engineers who can
(00:45):
step up into quality engineers in the sense that they have got a quality head.
They're true quality gatekeepers, and they can write code, and they can think,
or their thought process is shift-left kind of focused.
And again, there's likely to be a demand for more of estates,
our software developers in tests.
(01:08):
And these are automation engineers who have got a very strong development background,
but have also good understanding of software testing. testing.
So career wise, there's going to be a shift. Recently, there are quite a number
of training certifications for AI in testing.
And my prediction is testers who are going to remain on the same level with
(01:33):
the same knowledge are going to become irrelevant,
and will be surely faced of other companies already in South Africa,
they're now aiming for what they're calling full-stack engineers,
full-stack quality engineers.
They should be able to do functional testing on web and API.
They should also be able to write tests in for mobile, both APM and Android.
(01:56):
They should also be able to do performance testing using any of the open-source
tools like JMeter and other commercial tools like Neolord.
So the conventional qualifications and roles or responsibility of testers,
I foresee them changing in 2024.
Matt, you've just said about four things there which can make a podcast on its own.
(02:18):
I'm going to have to, I will have to decide which of those I talk about.
I was part of a conversation this morning, and it was around manual testers
and manual testers that only have manual testing skills.
And obviously, the natural thing always is, oh, we need to turn them into automation
engineers, or they need to learn automation.
(02:41):
But I guess there are other things that you can do as well as a manual tester these days.
And we can touch on the low-code automation tools in a second,
which is still automation.
Automation but in terms of things like
test data engineers so so we know at
inspired testing there's test data management and there's test
environments management there's data testing etc you can you can probably transition
(03:04):
quite a bit easier from being a manual tester to maybe a test data engineer
as opposed to automation or potentially and this is more on the more in on the automation side,
maybe learning something like Robot Framework or Tricentis, maybe Tosca,
(03:25):
those tools which don't need the deep-rooted automation coding knowledge.
Then again, not every manual tester wants to do automation. Not every manual
tester wants to go down the automation route.
But if we're saying that the market and the trend seems to be that quality engineering
role where you need to be able to do, I guess all aspects to some level.
(03:49):
What advice would you give to a manual tester today which don't,
well, they either don't or they haven't had the opportunity to go down the automation route.
What other, I guess, avenues are there for them to upskill or reskill themselves?
Now, it's not just a question for you, Matt, it's for everyone. Stefan?
(04:13):
So I just understand your question. where you're saying if automation isn't
necessarily something that they've had opportunity or would be uncomfortable
with, are there other avenues in testing that they could maybe look at?
Yeah, so let's – I mean, the obvious ones are, okay, you're a manual tester
today. That's the thing you've always done.
Okay, become a test manager or become a test lead.
(04:36):
Now, that's another contentious issue for me because if all companies are going
towards agile, what's a test manager's role within agile? but that we can discuss another day.
But if you're a manual tester and you don't necessarily want to go down the
automation route, I guess what other avenues are there for you?
(04:56):
It's interesting you asked that i was reading a few
articles this morning and listening to something from joe calentonia
as well and he touched on observability testing sorry
that's a tongue twister for me all of a sudden observability testing
so i mean that just opened up
my thoughts in terms of thinking about non-functional testing
types that i think there's a whole untapped level of testing that not a lot
(05:20):
of people are dabbling with i mean if you talk about observability observability
testing i mean it's something i personally haven't played around with a lot
in my career and i don't know if if you just in terms of the concept it's it's focusing on,
how well a system can be monitored and understood and debugged in
real time particularly in production environments so if
(05:41):
that system goes to production and something goes wrong how
easily can the devops or the prod support guys look at
the events the metrics the logs and alerts and that's
something you can start to implement quite left in this
you know as an and push that as a non-functional requirement
and test that and take that all the way through i think there's
lots of areas that people can focus on that's not
(06:01):
necessarily coding specific but yeah maybe that's just one of the areas of non-functional
testing but i think that's something to look at is across the moving more shifting
testing left and far right i think there's a lot of non-functional areas somebody
can become an expert in without having to even touch a piece of code.
So I want to think about what you just said, Leon, around people who don't want to. Can they?
(06:26):
Absolutely, right? So you can always change your career focus if you want to,
right? And no one can stop you from doing that.
But I think if you want to stay in software quality assurance,
then unfortunately you will have to touch on these things.
Now, I know that we are scared and a lot of thesis out there are scared to embark
(06:51):
on these journeys, but it's not as scary as you might think, right?
So I see it, this quality engineering role as being able to help yourself when
you need to help yourself, right?
So we are not saying, I'm not necessarily saying be an automation expert,
be a performance expert, be a security expert, right?
I'm saying that have the attitude that will get you to a GP place.
(07:14):
So if you go to a GP, the GP can diagnose something and he or she will help
you. But they're not an expert, a specialist.
They will send you to a specialist when they need to send you to a specialist.
But they still understand everything in the medical field well enough to at
least start helping you.
And I think from a testing perspective, if you are a manual tester today and
(07:34):
you say, well, I absolutely categorically don't want to get involved in anything
else, then maybe your only option is to look at.
Being a test data manager or moving into something else.
But if you want to stay in the – and when I say being a test or software quality
engineer, that is someone that can work in an agile testing team,
(07:54):
also Waterfall, but an agile testing team.
And if you want to contribute in that agile testing team, these are the skills,
especially around automation and some of the non-functional testing types that you will have to learn.
And again, I've had many conversations with potential clients that says,
well, my people can't go to automation.
(08:16):
I say, well, just start contributing to the automation effort.
Don't become an expert developer overnight, but understand if we're using BDD,
our feature file fits into the framework and start writing those things.
So there are pragmatic ways for you as a manual test that can get involved in
the automation effort, for example, right? Right. The same with performance testing.
(08:37):
If you analyze a user story and you see, well, I think there's a performance impact there.
Write it down and get the experts in to come validate what you thought and learn
from them. And next time you'll know a little bit more.
So it's not being an expert from a GP to being an expert in everything tomorrow.
But it's having that attitude to listen out for certain things when I'm analyzing
(08:58):
stories and requirements to see, oh, maybe this accessibility thing or,
wow, this sounds to me like this security risk.
Score this sounds to me like this performance impact and then getting people
so you're still entrenching into that quality engineering mindset although you're
not an expert in everything but i think that's a must from my perspective.
Just to concur with what you said, so basically it's all in the mind,
(09:21):
and it also starts with you as an individual to understand what is it that you
want to do to stay relevant.
For example, there are so many free sites like Test Automation University where
you can learn coding from scratch.
There are steps which are set there step by step to say, if you want to be an
automation engineer who focuses on Java or C Sharp, this is the route that you
(09:44):
have to take. This is the path that you have to take.
So there is a whole lot of open source sites that you can use.
And again, Udemy is there.
For a 200 grand, you can buy a course that can teach you how to learn a new
programming language. There are some exercises there.
And once one is done that, it's also important to get hands-on exposure.
(10:06):
For example, for those in companies where they are already implementing.
Shouldering is the best way to learn.
You go and get paired with someone who is already doing something in the project.
Not something theoretical but you
you get your hands dirty into the project start observing
watch while they're debugging take notes and you
learn from there so anybody who is a manual tester today
(10:28):
if your attitude is right and you can literally do anything it's only last week
where we're looking at certain profiles where we discover that some of the best
it guys really did not start study computer science they started something completely
different so it's all in the the mind, and the attitude.
For anybody who is coming from a manual testing background, if you tell yourself
(10:50):
that you can do it, you can definitely do it.
We also at some point carried an experiment with one business analyst.
We wanted to see how that person was going to learn robot framework automation.
We just said, okay, these are the keywords that you use. If you want to do this,
you just type these commands. Can you do it?
The business analyst within a matter of four days was able to just go through
(11:13):
the robot framework training and was able to write some robot framework scripts.
So it's all in the mind. Start by just telling yourself that you can do it and
then you can follow all the steps to get your hands dirty with the code.
Okay, so say all the manual testers all over the world listen to us and they
(11:34):
transition to the roles you have recommended.
Who is going to do manual testing unless you say manual testing is going to be eradicated?
I think the manual testing aspect becomes part of the quality engineer.
So we're not saying manual testing has no place in testing. That's actually the complete opposite.
(11:58):
The fact is just if you look at companies today or employers,
they're looking for someone that can do both.
Well, not both because both suggests only two.
There's actually more than that. They want people that can do manual testing
and automation and potentially some basic level of maybe performance testing,
security testing, accessibility testing, etc. et cetera.
(12:21):
So I think it's just, and Matt just alluded to mindset.
I think it's a mindset shift within maybe the whole testing community where
you need to realize that even if you're an automation engineer and that's your
passion, some days you're going to have to do manual testing.
Maybe it's every day, but there's no, oh, I'm only an automation engineer,
(12:43):
therefore that's the only thing I'm going to do, or I'm just doing manual testing.
So I think the manual testing testing aspect doesn't lose any of its value at all.
It's just why do I need to pay for two people doing two separate,
I guess, roles where actually I can combine those into two, sorry, into one.
(13:05):
And it's a similar thing that we're seeing with the whole move towards estates
and developers and testers are getting closer and closer together.
If we think about it, developers are now expected to do more testing and testers
are expected to do more development in that scenario of estates.
And in a similar way, I think it's similar in manual and automation and performance testing.
(13:31):
Within the testing competency, those things are expected to all be done by a
single person as opposed to three different people.
I don't know whether anyone else wants to add on to that.
I totally agree. I agree. I
don't think it takes away any of the testing disciplines or phases, right?
It just, you need to, as a tester, enhance the one that's needed for the job
(13:54):
today, right? And I agree with you, Mahatla.
Manual testing and the art of testing and test analysis and design,
that's even more important than ever, right?
And we're not taking away from that. That is just saying that do that more effectively
and then look out for other things as well or non-functional requirements for,
oh, yes, I've written the test as I've executed it.
(14:17):
Let me automate it and add it to a pipeline. So absolutely, I think that skill
will always stay the most important part for any testing, right?
There's a saying out there that all testing is manual, right?
So if you're not actually trying to interrogate the system and finding issues,
then you are not really testing. And that will always be a manual effort,
and that will always be any taster's main skill.
(14:38):
I mean, it's not replacing a tool in our tool belt, it's just adding more tools
and then selecting the one best fit for the job.
But I think there's, again, I'm just going to go back to Matt's point about mindset.
So I think a lot of manual testers, and we're getting slightly stuck on this,
but a lot of manual testers feel that there's a massive mountain that they have
(15:00):
to climb to get towards maybe being able to do automation.
But if you know a basic level of code, it doesn't take you very much to get to that level.
And then if you're working with an established automation framework,
we're not expecting you to build an automation framework from day one.
(15:21):
If you're working in a fairly established automation framework,
it's not difficult writing automation tests, especially if you're just having
to add additional tests, et cetera.
So I would say that that needs to be sort of almost the first goal.
Just get yourself to understand whatever, maybe Python, maybe Python is the
best example the best choice because it's one of the easier languages to learn.
(15:46):
But understand the basics of Python, which isn't difficult to grasp.
It's not going to take you long.
And then work with an established framework where initially you're just adding tests.
And if you're working in a company where there is an automation team and you're
the manual tester, actually start pairing with them. Sit next to them and just
(16:06):
watch what they're doing.
And gradually you start taking on on more and more.
But that starting point is always, in my mind, the starting point is always
having that basic understanding of a language, a programming language because
otherwise it's going to be Greek to you.
It's like trying to read French when you're English or Afrikaans.
(16:26):
But also, you know,
Just to add to that, we all find ourselves in the technology world.
And the one constant with technology is it's fast moving and it's always changing.
Now, I think one of the things that you have to accept when you're in this space
is you're going to constantly have to keep up to speed with what's happening.
(16:47):
And you're always going to have to keep learning.
This is not the type of job where you can stop learning at any point because
we've used the word irrelevant, and it's maybe a very strong word,
but to some degree, that is what will happen.
Your skills will become irrelevant if you don't keep up to speed in terms of changes.
(17:10):
So I think with AI, to me, it just feels like everything is moving much quicker than before.
So maybe we're giving away our age, but maybe 20, 25 years ago,
you could be a manual tester and maybe you could sustain that,
I guess, career for 20 or 30 years.
(17:33):
It doesn't feel to me today, sorry, but without learning any additional skills.
So you start doing manual testing at the start of your career,
20 years later, you're still doing manual testing.
You've not really invested in yourself to upskill yourself.
It doesn't feel to me like a 20-year-old today is going to be able to learn
one skill and then for the next 20 years,
(17:55):
not do anything and still be irrelevant in 20 years time because things are
just moving too quickly and also just my last point because i'm talking too much.
Testing has also evolved massively over the last 10 or 15 years.
So in the past, testing was almost a bit of a side hustle for many where there
(18:16):
wasn't so many companies specializing in testing.
There wasn't so many opinions and, I guess, innovators around testing and changes
to tools and tool vendors, et cetera, et cetera.
So that's also contributed to
this market moving quicker than it did 20 years ago, 15 or 10 years ago.
Because there's so many more people invested in changing it and making it more
(18:42):
efficient, et cetera. Any opinions on that?
Yeah, I think I'll go after you.
Yeah, Leon, so I actually agree with you, particularly when you said some time
back, others would take testing as a side hustle.
Go to any company, any other profession, or any other person can tell you that
(19:03):
I also can test. Talk to a product owner.
They will tell you that I also can test. A business analyst,
they will tell you I also can test.
Even developers, they will tell you that I also can test.
So back then, testing was just something that can be done when other important
things in courts, when other important things are done.
But with the way things are moving we're
(19:24):
shifting left we're shifting right we cannot afford
to remain with the same knowledge testing with the same knowledge or using the
same test cases to to test the same thing so basically we have to keep up learning
upskilling ourselves because that's the only way we can be good testers picking
the relevant bugs but otherwise if we remain with with the same knowledge,
(19:47):
same test cases. We don't change anything.
We'll have test cases which are always passing, but defects will always be picked in production.
Okay, I think that's a good point, a good time to move to the next point.
Jan, what's your prediction? It's actually good that we had this conversation,
(20:08):
Matt, because it feeds into what I want to say and what I want to talk about, right?
So why now is quality engineering a thing?
Why are we expecting people to do more, right? Why are we shifting left and
have we shifted left for the last 10 years?
Why are we moving down pyramids to do things earlier, right?
(20:29):
And why is AI important, as we just established, in the test is to make ourselves
more efficient and more effective.
So there must be a reason for all of these things.
And one of the things that I'm seeing is this whole continuous testing principle.
So we are doing all of these things to enable us to provide information and
(20:50):
testing-related information quicker, faster, so that deployment cycles can get shorter.
Right and we've all heard about ci
and cd and those things are great and we even went
as far as integrating automation frameworks in that but it goes
beyond that it's moved it's the
the movement of getting rid of testing as
a phase and introducing introducing testing as
(21:13):
a process right so no longer do we
want testing to be a phase somewhere in the stlc we're doing
all of these things that we just spoke about to make
testing part of the process so this whole continuous
testing cycle especially in 2024
because for all the things we said is now there we've been
hearing about it for a long time but we are now there where testing needs to
(21:35):
be continuous we want to make changes we want to deploy continuously right and
that's why automation is there and that's why all of these things are there
now because we are doing all of this and mamata to your point and i'm I'm actually
saying two things and not one.
But so continuous testing, absolutely, I think it's a big trend.
And part of that is this whole concept of exploratory testing.
(21:56):
Now, because we are spending so much time automating things and continuously
testing things, it's extremely important that we hone our exploratory testing
skills as testers, right?
Because you don't have the luxury of writing extensive test cases anymore.
You don't have the time to do all of these things. You need to have that testing
(22:17):
mindset and start exploring the application beyond the boundaries of just a test case.
Now, we all know exploratory testing is still a planned testing activity, right?
I'm not saying just go wild west on the application, but plan your sessions
and start exploring the system more to get a lot of these defects out of the
way very quickly, right?
Start understanding what the system will do when we do unpredictable things
(22:43):
to it as users would, right? So two things, continuous tasting,
I think, is the one thing.
And in the back of that is, what do we do and how do we find the defects still and taste the system?
It's by placing a big emphasis on exploratory tasting and doing more in the
exploratory testing world that we've ever done before.
Thank you, Jan. I really like the way you introduced the topic.
(23:06):
Basically, you said, why are testers required to do more?
So, in my opinion, testers are required to do more because I think this is more
like feeding onto the previous topic where we're saying we have to upskill and
we have to remain relevant. event.
We're expected to do more because a whole lot of these repetitive tasks should
be done by tools, should be automated, and that's where technology kicks in.
(23:32):
Basically, we need to take away any task that can be done repetitively.
We can use a tool, we can schedule it, it can be run after hours.
Instead of it being done by 10 people, one person can do it.
The shift now is is testers should mainly focus on the complexity of work, not the volume.
Forget about the volumes. Let the tool do that repetitive task.
(23:54):
The tester now, to your point, needs to focus more on more of exploratory testing
and more of user experience testing.
So these are some of the things which the tool cannot intuitively say,
okay, this is very easy to use.
Some of the things needs human opinions and the other external factors that
may influence an opinion about usability of a tool or a system.
(24:16):
So basically, this topic is kind of tied to what you're talking about earlier,
where if we are not relevant, we may discover that we feel, oh,
testers are doing a lot of work.
They're doing too many tasks at the same time.
And the feeling maybe will become jack of all trades, but master of none.
But it all goes to let's upskill and let's be relevant.
(24:41):
A lot of what we often talk about is all the examples we cite are often related
to companies following Agile or doing something within an Agile type of model.
But how does what you've said, Jan, so continuous testing, how do you see that
actually working in a company not following Agile?
(25:02):
So we often laugh when we hear about people still talking about waterfall,
but actually companies are still following waterfall.
And often companies that say they're doing agile are actually doing more waterfall.
So does that still hold true for, I guess, companies that aren't fully agile?
(25:22):
So that all continuous testing thing and also companies that haven't actually
adopted automation yet and gone down that route.
How do you see continuous testing playing out in those scenarios?
Well, continuous testing will be very difficult if you don't embrace automation, right?
So I think it doesn't matter the methodology you follow.
(25:45):
If you are not embracing automation throughout your SDLC, you're never going
to reach continuous testing.
You're going to continuously taste, but that's going to be a big effort for
you, but you're not going to get to continuous tasting.
I think when you look at Waterfall itself, the concept of continuous tasting
is not necessarily going to work because you don't have the same….
(26:09):
Short cycles where you need to deploy, right? If I was a test manager in a Waterfall project,
I would still try and aim for that because you still want to get the testing
out of the way and get to the definition of done, although that's not official
thing in Waterfall, but get to the definition of done for the piece of testing as soon as possible
because then you need to move to the next piece that's on your list, right?
(26:31):
So if you look at Waterfall versus Agile, it's not to say that we can't follow
the same practices. is, the last
part of it in the deployment part is not necessarily going to be there.
But from a testing efficiency perspective, surely you'd still want to do things
as effective and efficient as possible that enables you to do more of the testing
in a shorter period of time.
(26:52):
Like I said, we're giving away our age, but when we started testing,
it was not an hurdle for a test cycle to be six months.
It was a fairly typical test cycle, right? But I would still say in today's
world, there are tools and technologies out there to help you to do more in those six months.
And then mitigate more of the risk and focus on expanding your test coverage.
The exploratory testing, and Matt, I'm glad you mentioned the UX testing as
(27:15):
well, right? But those two aspects are all true. It doesn't matter the methodology.
You want to explore. You want to get testers to think more like a user would.
Back in the day, again, we labeled testers as super users of a system.
When you said that in the interview, people hired you on the spot, right?
But that's really what we kind of forgot throughout the way,
(27:36):
that the tester should also look at it from the user perspective,
from a user experience, and then from exploratory tasting perspective about
how users on any level would actually operate the system.
Any other opinions or comments?
Okay. I think we've got time for one more. and
(27:58):
anyone want to discuss anything specific any specific
ones that you want to highlight or should we go to my matla
again i i just wanted to or stefan sorry stefan was first sorry something that
stefan said so maybe we are going to back to stefan again but you mentioned
around iot i think we've we've heard about iot the last couple years some people
(28:21):
embraced it some people said it's not not really a thing to test.
But I really think in today, in 2024, IoT is here, right?
Whether you like to know about it, whether you like to accept the fact or not that it is there.
Is it completely different than API testing? I suppose in its core, it's pretty much that.
But there are a lot of nuances around IoT, the environment that the IoT device
(28:44):
lives in that we have to consider.
So I think IoT is definitely something we can't forget about in 2024.
And if you're going to do so as an organization, at least, will slowly become
irrelevant in that space.
Agreed. I think you've just prompted a thought in my mind in terms of mobile testing as well.
(29:04):
So we know that more and more people are using mobile devices for shopping and, well, everything.
As much as you can do on your phone as possible, that's what you'll do.
But it feels to me like often the first consideration is still desktop and browser on a computer.
(29:25):
Instead of thinking about mobile. So what I'm trying to, I guess,
say or suggest is, if you look at a project and it's an automation project,
often the first thought is, how are we going to automate this on the browser, on a desktop site?
Mobile always feels to me like it's a secondary thought.
(29:47):
It's not always front and center in terms of that automation strategy.
Strategy but with with i
guess mobile becoming more and more and more prominent every year
do you guys and girl feel that
anything is going to change around i guess mobile testing
mobile test strategies we know
(30:10):
there are there are cloud-based cloud-based solutions out there which which
many companies are going to now do you feel that they need to expand on their
service offerings and and start doing other things to maybe keep ahead of where
mobile is going. Any thoughts on that?
(30:30):
Yeah, I think mobile is getting more and more complex as the days go on, as you said, Leon.
And the amount of devices grows by the day as well.
So definitely from a cloud provider perspective, I think there's a lot more they can do.
And I've seen a lot of them starting to delve into how can we couple providing
(30:51):
you the device with testing the device.
So I think that's really where you want to go from a software testing organization
perspective. perspective, you don't really just want to use a mobile provider
to provide the mobile phone, but you also want these providers to help you with
the testing effort they're on.
Now, a lot of the organizations out there providing these devices have started
(31:12):
getting into the automation world, starting to help you to write test cases
with an AI perspective on that device and the app you put on the device.
So I'm seeing because it's getting more and more complicated,
these providers are now bringing more and more to the table to enable us to
actually get the coverage that we need.
Fair point. Yeah, in addition to what you said, Jan, what I've also observed
(31:34):
is, you know, looking at the traditional way of testing mobile applications
where you need a physical device,
there are a number of providers who are now coming up with some cloud-based
virtual environments and also some virtual images where you can literally spin
up any container and run as many tests as you want without necessarily being
(31:56):
limited by the number of physical devices You can connect at the same time.
You can get an image in the cloud
for whatever version or model of mobile device which you want to test.
So these are some of the trends which we have observed that are also picking up lately.
And also some low-code, no-code organizations are now offering quite a number
(32:18):
of images for anyone to test on mobile devices.
Is and and in terms of the skill set do you feel that there's a is there a change
in skill set is there is a upskilling that needs to be done so if if you i i
don't know maybe maybe you've,
you've worked in a company that that's only had a website and there's been no
(32:39):
mobile presence i can't imagine that but let's assume that you've only you're
only used to to doing testing on on a web browser, on a desktop.
Is there a different skill set that you require to do mobile automation?
Is there a focus that needs to come into certain people's, I guess, upskilling?
(33:01):
So in most cases, I've observed that the main automation which is being done
is mainly based on the APM framework.
And this can then be written in the C-sharp or Java.
But the cloud aspect is just maybe some external third-party vendors will provide some virtual devices.
(33:21):
So skill-wise, I've not really seen so much of a huge shift besides the conventional
C-sharp and Java using APM.
But the integration with the third-part tools where they provide the platform
for you to be able to create your test cases faster for the mobile devices.
I think that's the technical skill.
Okay, more of a tooling skill that is to be learned. But programming language-wise,
(33:44):
it's mainly C Sharp and Java.
Python is coming in though, but C Sharp and Java are still the main programming languages.
Okay. Yeah.
Amatla? Okay, so Leon, And I wanted to understand where you are coming from
with mobile testing, because most organizations are already adopting the mobile first strategy.
(34:06):
And with the design for their web pages, they want them to be responsive.
You know, if you are on a desktop and then you transition to mobile,
so the pages scale according to the resolution.
So, I wanted to understand where you were coming from with the search in mobile applications in 2024.
(34:32):
So, I think for every example of a company that's going mobile first,
there's probably another company that's not.
And I'm not talking about the company so much as from a testing perspective.
So, if we know that there's a mobile site that needs to work on both,
(34:58):
it's adaptive and it works on the browser as well as your mobile browser,
are we giving enough, I guess, are we giving equal importance to making sure
it works on the mobile as we are?
Just historically, we've always tested on desktops and it feels like that's
always still the default thought.
Are we giving enough consideration?
(35:19):
And then if it's a native app on iOS or Android or wherever,
are we critically thinking about what's required for that?
Is that at the forefront of our minds or is it still a bit of an afterthought?
If you know I need to test this on 15 different devices.
What is your strategy and are you giving importance to that?
(35:41):
Are you going to go a physical device route or are you going to go a device
farm in the cloud somewhere?
Also, if you don't have a framework, what sort of framework are you going to
adopt? Are you doing automation on mobile?
I mean, there's a client that we spoke to recently and they're not doing any mobile automation.
(36:02):
Automation they they they automating the heck out of their website but mobile
automation has never happened and and that just made me think that maybe that's
a not a common thing but we kind of live in this i guess false sense of security
where we feel or we think everyone is is giving.
(36:22):
Equal importance to desktop or mobile or
whatever but but maybe that's not always at the
forefront front of people's minds maybe maybe the feeling is
that well if it works on desktop and and
it's sharing the same code base etc we don't actually have
to test on mobile the risk is lower i don't
know so it was just from that perspective okay i think i think let's wrap it
(36:45):
up there because even my mom's not going to listen this long our one listener
we've already lost uh stefan did you want to say something stefan as a as a
closing thought no pressure having to put on the closing Now,
I just wanted to mention in the mobile testing, I think there's lots we can do.
I think even companies that are looking at mobile testing and realizing the
(37:05):
importance, I think there are a lot we can say about standardizing the approach
that we should look at when we talk about mobile testing.
There's definitely a specific set of checklists or items that we should look
at, like staggering the network, rendering, turning the phone around, battery consumption.
There's things very specific and niche to that. And I think there's definitely.
(37:27):
Places or things that we should consider specific to that area of testing.
And I mean, we've seen that with clients recently as well, where we've helped
them standardize their approach.
So I think there's definitely a niche approach and companies should make an
effort to look at what are the special considerations they should take when
looking at the mobile testing.
(37:49):
Even silly things like per application, understanding what the demographics
are of your various applications and making sure that, you know,
what kind of phones to certain areas,
what phones are more popular in the bulk of your user base and making sure those
ones are being tested first. You know, there's a lot of things to consider.
(38:11):
Yeah, so maybe that's just my final thought. Okay, awesome.
All right, thank you very much for your time. I think it was a good discussion.
We touched on quite a few things, but I think a lot of the opinions It's actually
given me some ideas for maybe some focused discussions going forward where some
(38:31):
of these aspects we can delve deeper into and dive deeper into and maybe have
a dedicated podcast for it.
But, yeah, thanks a lot. Until next time.
This has been an episode of Testing Experts with Opinions, an inspired testing podcast.
Find us on LinkedIn, Twitter, Facebook, Instagram, YouTube, and TikTok,
(38:52):
where we're driving conversations. Thank you.
Popular Podcasts
Are You A Charlotte?
In 1997, actress Kristin Davis’ life was forever changed when she took on the role of Charlotte York in Sex and the City. As we watched Carrie, Samantha, Miranda and Charlotte navigate relationships in NYC, the show helped push once unacceptable conversation topics out of the shadows and altered the narrative around women and sex. We all saw ourselves in them as they searched for fulfillment in life, sex and friendships. Now, Kristin Davis wants to connect with you, the fans, and share untold stories and all the behind the scenes. Together, with Kristin and special guests, what will begin with Sex and the City will evolve into talks about themes that are still so relevant today. "Are you a Charlotte?" is much more than just rewatching this beloved show, it brings the past and the present together as we talk with heart, humor and of course some optimism.
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com