To become a better software tester, one must move beyond the misconception that testing is easy and instead cultivate a deep understanding of the product, adopt a critical and analytical mindset, and maintain meticulous documentation and professional communication.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
hello friends and greetings for the day
welcome back to our channel tm square
where we look forward to give you the
best knowledge on software testing
concepts and related certifications and
today again we are bringing back to you
another episode of technical talks with
neeraj where we are going to talk about
what makes you a better tester day by
day now a very common understanding
which we presume when starting a career
of being a qa given by a lot of people
that qa is something which is pretty
easy and it can be performed by any
individual you may not need a lot of
detailed knowledge a lot of
understanding of the technical traits
like programming languages architecture
etc to get started i would like to share
some of the thoughts of mine again here
to give you some good building
understanding on the foundation level
that what basically makes you a perfect
tester to continue your journey not just
to start and stop on the way and uh the
very first point i would like to talk
about is
what exactly a tester needs to know
right what are the responsibilities what
are the soft and hard skills a tester
should be aware of which would be pretty
much helpful for a lot of you who are
preparing for their interviews
getting into has a qa role number one
thing do not underestimate testing
testing is not an easy job at all right
a lot of people have created this myth
across the world considering that they
are not a tester they thought that
testing is all about uh just writing
test cases and executing them in a very
simple way and reporting some defects
which is
could be anomaly from the requirement
deviations but the point is in order to
just create that test case we need a lot
of skill set number one thing you need
to have a good understanding of what
exactly is the product
now assume that you are trying to test
something which you have never seen
before right now people say that testing
is pretty easy
just like using something for example
you have been using a phone and if i ask
you that hey do you know how to test a
phone you would say of course i've been
using a phone for a long time and i know
how to test it i know how to take
pictures i know how to make calls i know
how to change the settings and transform
a phone to something different
right of course that's true but the
point is
it's just because you have been using
phone for years together and you have
probably like 10 years of experience of
testing a smartphone
right but still if you go ahead and talk
to a mobile application tester or if you
go ahead and talk to a hardcore mobile
tester they will have completely
different thought process than you
because you have been using the product
like a user but there are a lot of
technical parameters behind the screen
which i think you've never seen before
now that is where i wanted to clarify
that the myth
that testing is easy is not correct okay
it's difficult
yes i'm not trying to scare you here but
i'm just trying to make sure that you do
not underestimate testing this thing is
not an easy job you need to know the
bits and pieces of the product the
technology the platform which you are
going to test
if you are a good tester why don't you
go ahead and test automotive systems
because you need automotive skills you
need to understand on what principles
what factors does automotive
application works
and there are different ways of testing
the same thing following one of our
principles of testing that testing is
context dependent
testing is even performed differently
for different products it's not exactly
the same for the same product right so
testing again is not so easy
so to get started with that simple
activity which people say that hey a
tester is just responsible for writing
some test cases and that's it he's
pretty much done and he probably he or
she has to run those test cases when the
application gets delivered the point is no
no
in order to write those test cases we
have to spend a lot of time so make sure
that you have been through the
requirements make sure that you have
understood what architecture is being
built again understood right you don't
you're not requested to create the
architectures or make yourself as an
architect more importantly you need to
understand what kind of design is being
built behind the screen whether this
design is going to support this or not
you can relate these examples with very
layman level examples like construction
of house
you do understand that you are not a
masonry you are not a
architect of building a house but you
understand the concept of structure of a
house that hey if i have to build four
floor or four-story building then how
many pillars would be supporting that an
architect designs it says that hey this
is the positioning of my different
pillars and this is the count of the
pillars which you may need in order to
construct a four floor house
now the point is here that a masonry has
to understand what would be the
positioning of the pillars so that they
can let you know about the layout of the
rooms and the walls that how they will
cover up those pillars that does not obstruct
obstruct your
your
engagement while entering the house
right so the journey is not just limited
to writing some test cases we are
talking about we are insisting on
writing efficient test cases
writing test cases is not a big deal and
you can call yourself as a tester for
sure but the point is are you a good
tester is the question here and making
yourself as a good tester you should be
able to think from a destructive
approach from a negative mindset that
what could
basically go wrong here
what is that that may not support
the platform may not support the
functionality what is that which is
contradicting with the expectations of
the user and thinking from that
perspective allows you to create
different set of test cases and that too
not just limited to writing some test
cases making efficient test cases so
going through the requirement
understanding the architecture of
understanding the platform what you're
going to test on is all a part of
preparatory work for a test engineer to
write some efficient test cases without which
which
your test cases may not result into or
yield great number of defects or great
defects at all
right so being a tester it does not does
not just mean that you look at the
requirements frame some test cases but
you also need to think from the angle of
a user that where all a user can find issues
issues
more importantly if you have some good
understanding of the domain
it builds better coverage on your confidence
confidence
given that you have been working with a
particular application platform like
java python or maybe some particular
database you know the anomalies the
limitations the drawbacks of that platform
platform
and you would be certainly hitting your
test cases in that those corners those
edges for sure to make sure that hey
isn't it this side is working fine
because it could be possible but we have
seen that database has limitation on
this part and the customer has one of
the expectations at this point to do
some functionality in this corner too so
we just want to make sure that whether
this is happening or not right so that's
one thing the technical traits is about
your platform about your technology
about your requirements what the
customer is asking you to and given that
you have you possess all these knowledge
would lead you to write great test cases
to find more defects don't forget team
testing is not about
validating a product
we did this mistake once we don't want
to do it again testing is just not about
testing a software product or hardware
product testing is to prove
that the system doesn't work
okay you have to do and die prove that
this piece of code is not going to
function and you need to find different
ways to prove that statement
you have to find failures
it was never said okay none of the
objectives nowhere it mentions that
testing is about testing a product
there are objectives like finding
defects conducting failures preventing
defects gaining confidence about the
quality of the product you know
mitigating risk a number of things are
objectives of testing but none of the
objectives says that
testing is about testing your product
okay because testing consists of all
these objectives we have to find failures
failures
anyhow no matter your test cases are
about interfaces systems protocols
the right platform or technical
abilities no matter what your test cases
are about that we cover in different
levels you can talk about security
portability accessibility usability
right performance but the point is prove
me this piece of code doesn't work
that's the objective of a tester and
that makes you a better tester and
that's one of the you know parameter of
making yourself as a better tester the
more you have the knowledge about the
product being tested the better you will
be in finding defects in turn making
yourself more better tester day by day
the second important thing here is your psychology
psychology
you don't have to do friendship
with your developers professionally
professionally
okay professionally you're just
colleagues having different
responsibilities to be delivered towards
the quality goals of the product
you don't have to understand that hey he
is one of my friend given that he's a
developer how can i just
you know go ahead and publish 10 defects
on his or her name
the point here is your psychology is
completely different
you have been hired
to prove
that this person would have done so many mistakes
mistakes
and we don't bring our personal emotions here
here
we don't bring any kind of relationship
here that okay considering that he is
one of my colleagues who has been
traveling with me for so many
organizations let me just you know tell
him unofficially that got these defects
can you fix it
that would probably maintain a healthy
relationship for sure probably
probably
right but the point is
it will not build up a better quality
system because you found some defects
and you unofficially told him to fix it
but what about the modules which were
tested by another tester and what if you
could not figure out those defects
you are responsible for leaking defects
to the production because you excused it right
right
there is a professional way of thinking
politely talking to people and making
sure that your psychology is different
from that of the developer and that's
the reason you have been hired for
a tester is hired for their psychology
their perception their mindset towards
the product that hey
we don't love you we don't treat you as
our baby
we are just having a victimized product
and we need to make sure that we find
any number of defects on top of it
right a teacher certainly
certainly
one way loves their students but when it
comes to examination
you might have seen a transformation in them
them
the transformation is to make sure that today
today
i don't know you as simple as that
today i just know that who has done
better preparation
will get better scores
no no leniency no kind of you know
easiness in the in vigilation of the
examination they pretty much try to
behave straight so that come on this is
the time where you have to justify your
knowledge this is the time where you
have to justify your hard work which is
going to help you i may be a very
friendly teacher to you but i could help
you now but what about your future what
about your lifetime well what about your
career will i be there to give you marks
there or scores or performance rating
not at all right so same way here a
tester has no leniency in what kind of
module what kind of
developers module is being tested
irrespective of who has built it
irrespective of what functionality it
has a tester's mindset should always be
concentrating towards proving that the
system will fail
trying in different angles
okay you are just there to destroy the
product at any cost
so that that cost can be saved in the
production see again each and every word
has a deep meaning if you deep dive
right you're trying to invest some cost
here internally to reduce the cost of
failure in the external environment
and that's where you have been hired
your salaries are being paid just to
make sure that these defects are not leaked
leaked
now people say that white testers are
getting blamed for
releases or delays in release the point
is that yes if we leak the defects
we are responsible for it
if we don't find the defects on time we
are responsible for it
right a tester has to think from a
perception of justifying that the system
will not work in production at any point
we should always be
contradicting what the assumptions made
with the solutions provided with the
workaround being produced all that
we should be contradicting from a user
perception that what if
what if this could happen what if that
would happen what if a user performs
this now i understand your perception
could be very very vile sometime could
be very very different
and you may be rejected with your
perception sometime but yes we want that
confirmation for us that rejection
becomes a confirmation that for an
example i told them that what if people
try to post videos on facebook
then the customer says hey okay you know
what this is a platform where we don't
post videos we are only restricted to
pictures and emojis etc all right thank you
you
right because you just got a clarity on
your requirement that videos are not in
scope but at least you raise that
terminology you raise that functionality
so that you've got a clarity because the
requirement did not had it
right so you always think from so weird
angles that either you get clarity or
you get sure that what is the
expectation what is the ask from the business
business
right but at the same time
being so negative at some point of time
being negative for
a long period of time for example me
where i've been doing testing for more
than a decade
it certainly becomes at some point of
time that you start finding out
negativity in your day-to-day work as well
well
for example today if i'm watching a
movie if i'm
watching an advertisement if i'm looking
forward to have some kind of you know uh
interactive banners multimedia posters
etc i'm more than getting the message
from the poster or advertisements i look
forward to find mistakes
why because i'm a good test manager i
have been a good tester myself and my
mindset now after 10 years or 13 years
of time has become very very negative
towards proving that the given thing is
not correct
point but is that what we expect in reality
reality no
no
given that your job invites you to be
negative you should not be negative to
the people you're working with
mind your language mind your statements
mind your words when you talk to them
when you report something when you write
emails or when you chat with your colleagues
colleagues
remember one thing being a good tester
it requires you to control your emotions
towards the people you should only be
negative you should only be destructive
to the product
there are some examples to understand
this right number one example here is
uh for example if i say when you talk
about saying a statement about a defect
to the developer that hey developer you
have done a mistake in this code okay
okay
another way around you say hey developer
your code has one of the mistake
did you just realize the difference
between them
the number one says hey developer you
have done a mistake in the code that
means you're pointing that finger on
that person
proving that this person is good for
nothing which is incorrect
and the second statement you're saying
hey developer your code has a mistake
that means it's pointing the finger on
the work product not on the person
now at any point you should mind this
particular language of pointing the
finger on an individual because that can
hurt him but pointing a finger on the
chord pointing the finger on the work
products or the chord
will not hurt the chord at all people
will remain
with those statements those words till
you work with them they will always remember
remember
it's just like a kind of wound
it would retain for some time for sure
or maybe forever
but we testers we need to maintain the
eco relationship the respect for the
other people working along with you that
hey you are not wrong
mistakes can happen by human okay humans
are error prone we all agree to that and
being a tester no matter a good tester
you are not someone who is robot
right and cannot do mistakes you are 100
accurate every time
humans are error prone and mistakes can happen
happen
but the point is we are not pointing at
pointing out to you that you are not
good for anything
we are pointing those mistakes back on
the work work product or the code or the
application which is being built
so nobody will feel bad
why do we say that people have
contradictions between testers and developers
developers
and the reason is
the the way we talk to them the way we
inform them
about problem nobody likes
nobody likes listening bad about
themselves no matter you can raise your
hand and say come on mirrors i'm very
polite and i love listening about how to
improve i improvise myself thank you
but the point is
more than 90 people do not agree to this
that i feel happy about listening
about myself as a bad part
or a bad person or maybe someone trying
to question my professional right
so point here is think it on yourself
when you have been putting a lot of
efforts working 12 hours a day producing
you know optimum level of test cases
giving great number of defects and your
manager steps in and says what are you
doing here
what kind of contribution are you making
doesn't doesn't it feel bad for a moment
you may put your papers the right moment
if you're very very aggressive
or maybe if you're slightly polite you
may take three to four days search for a
job and when you have an offer letter in
your hand and then you throw your papers
right pointers everyone feels bad about
it so being a tester we do not
do that
though our job is inviting us to be
negative destructive
but only to the application only to the
product we are being testing
not to the people who are building it
we always maintain healthy relationship
with our developers in terms of having
the communications being provided
in terms of getting the bugs resolved
getting the defects resolved
that relationship is has has to be healthy
healthy
that okay when i talk to a developer
developer smiles and says oh come on man
thank you for letting me know i'll just
fix it up and let you know
this is what you're talking about having
a relationship not being kind enough to
excuse their bugs and not being so kind
enough that you directly put that you
know finger pointing on them that hey
you're good for nothing you know what we
are the testers we are doing everything
here and we don't need developers never
never
right so psychology is another important
thing which we need to take care of that
when you mention your defect reports
when you write an email when you are
chatting with another you know colleague
of yours especially when you're talking
with developers or architects you never
put that straight forward to them
talk to them in a very fact focused
neutral way without criticizing them
okay just how much ever you want you can
criticize the work products or the
application which is being built but not
the people
because think why they behave as they do right
right
take it on yourself and you would
understand that too
now further making it is like having all
that information the third parameter
which i wanted to talk quickly is the documentation
documentation
the information which you capture
a lot of time a tester
ignores some critical information about
a defect
writing or updating the status of the
test execution
coverage measurements of those with the
requirement or with any other test
spaces and the point is a tester can
misinterpret information which could
misguide the whole management or project managers
managers
where we are what we are doing right now
how much we have tested how much more to
test and a lot many other things like that
that
so gathering the information capturing
the information because you are the one
as a tester who are individually
interacting with work products at points
just for an example if i'm talking about
a defect
defect report
as a tester you were performing a test
case complete alone right and something
failed now you know what happened why
you think this test case has failed and
you are just worried about sharing this
information with every other stakeholder
because you want this to be resolved now
the point is how will you let them know
because they were not there when this
happened so you write a defect report
now now you understand that how critical
your defect report becomes
in terms of letting someone know who was
not there
when this failure happened
so capturing the information capturing
the details capturing those mining
information like taking a screenshot
creating a video on the screen
right or capturing all that critical
information that hey when a user clicks
only on this button this is what happens
if not it works good so giving those
concrete information in the description
of a defect report would be important
sometimes you report a defect and the
developer rejects it
could be a possibility due to
environment issues
developer never sees that defect at all
but you are getting it the reason could
be your environment because your
environment is different than that of a developer
developer
so capturing the environment details
becomes again important similarly there
could be build versions which are also crucial
crucial
for example today you're working on 4.5
of a build and you got an effect and you
reported to the developer and developer said
said
for me it's working fine because he's
working on 4.6 and accidentally the
defect is already resolved and he says
come on come and see i'll show you here
that in my version it is working fine so
this conflict results into disputes
right contradictions until unless you
capture the right information hey
can we just cross check what version you
are testing it in and what i found it in
okay you found it in 4.5 but i am
working on 4.6 so this is an assumption
that the 4.6 has already resolved this defect
defect
makes sense right
so everything whatever i just mentioned
brings back to one conclusion that your
information plays a vital role
to let the other stakeholders know that
how crucial
is your status update
right if you provide misinterpretation
in your testing information
if you don't capture the details
appropriately it could misguide the
whole project management or project schedule
schedule
so right from defect report test case
execution details test summaries uh you
know all that test case details
everything what you manage
has to be appropriate has to be complete
clear concise so that other stakeholders
understand what you're doing
all alone
is very transparent to everyone
right so i hope that gives you a very
clear picture of what exactly is
is
going to make you a better tester i'm
not saying perfect tester okay a better
tester day by day which may at some
point result into a perfect tester right
so today we were just talking about how
to make yourself better tester day by
day we'll continue these kind of
discussions in our upcoming episodes
weekly ones look forward to them and uh
feel free to drop your comment drop your
queries stop your questions
contradictions with what we are talking
about here because i'm looking forward
to hear from you and we would love to
talk about that and respond back to you
right so that's all from this particular
video team should you have anything else
feel free to comment below i'm always
there to answer your queries and respond
to them well till then keep learning
keep exploring keep understanding the
context thanks for watching the video
team and happy learning [Music]
[Music] you
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
