Escolar Documentos
Profissional Documentos
Cultura Documentos
A: Each of the followings represents a different testing approach: black box testing, white box
testing, unit testing, incremental testing, integration testing, functional testing, system testing,
end-to-end testing, sanity testing, regression testing, acceptance testing, load testing,
performance testing, usability testing, install/uninstall testing, recovery testing, security testing,
compatibility testing, exploratory testing, ad-hoc testing, user acceptance testing, comparison
testing, alpha testing, beta testing, and mutation testing.
For example, when a web server is stress tested, testing aims to find out how many users can be
on-line, at the same time, without crashing the server. Stress testing tests the stability of a given
system or entity.
Stress testing tests something beyond its normal operational capacity, in order to observe any
negative results. For example, a web server is stress tested, using scripts, bots, and various
denial of service tools.
Q: What is load testing?
A: Load testing simulates the expected usage of a software program, by simulating multiple users
that access the program's services concurrently. Load testing is most useful and most relevant for
multi-user systems, client/server models, including web servers.
For example, the load placed on the system is increased above normal usage patterns, in order
to test the system's response at peak loads.
During stress testing, the load is so great that the expected results are errors, though there is
gray area in between stress testing and load testing.
Load testing is a blanket term that is used in many different ways across the professional
software testing community.
The term, load testing, is often used synonymously with stress testing, performance testing,
reliability testing, and volume testing.
Then, (and this is called second stage of alpha testing), the software is handed over to software
QA staff for additional testing in an environment that is similar to the intended use.
Q: What is beta testing?
A: Following alpha testing, "beta versions" of the software are released to a group of people, and
limited public tests are performed, so that further testing can ensure the product has few bugs.
Other times, beta versions are made available to the general public, in order to receive as much
feedback as possible. The goal is to benefit the maximum number of future users.
A: Closed box testing is the same as black box testing. Black box
testing a type of testing that considers only externally visible
behavior. Black box testing considers neither the code itself, nor
the "inner workings" of the software.
Q: What is a QA engineer?
A: QA engineers are test engineer, but they do more than just testing. Good QA engineers
understand the entire software development process and how it fits into the business approach
and the goals of the organization.
Communication skills and the ability to understand various sides of issues are important. A QA
engineer is successful if people listen to him, if people use his tests, if people think that he's
useful, and if he's happy doing his work.
I would love to see QA departments staffed with experienced software developers who coach
development teams to write better code. But I've never seen it. Instead of coaching, QA engineers
tend to be process people.
A software test case template is, for example, a 6-column table, where column 1 is the "Test case
ID number", column 2 is the "Test case name", column 3 is the "Test objective", column 4 is the
"Test conditions/setup", column 5 is the "Input data requirements/steps", and column 6 is the
"Expected results".
All documents should be written to a certain standard and template. Standards and templates
maintain document uniformity. It also helps in learning where information is located, making it
easier for a user to find what they want. Lastly, with standards and templates, information will not
be accidentally omitted from a document.
Once Rob Davis has learned and reviewed your standards and templates, he will use them. He
will also recommend improvements and/or additions.
A: Metrics that can be used for bug tracking include the total
number of bugs, total number of bugs that have been fixed, number
of new bugs per week, and number of fixes per week.
Once Rob Davis has learned and reviewed your standards and
templates, he will use them. He will also recommend improvements
and/or additions.
The completed document will help people outside the test group
understand the why and how of product validation. It should be
thorough enough to be useful, but not so thorough that no one
outside the test group will be able to read it.
A: This ratio is not a fixed one, but depends on what phase of the
software development life cycle the project is in. When a product
is first conceived, organized, and developed, this ratio tends to
be 10:1, 5:1, or 3:1, i.e. heavily in favor of developers. In
sharp contrast, when the software is near the end of alpha
testing, this ratio tends to be 1:1 or 1:2, in favor of testers.
A: I suggest you read all you can, and that includes reading
product description pamphlets, manuals, books, information on the
Internet, and whatever information you can lay your hands on. Then
the next step is actual practice, the gathering of hands-on
experience on how to use WinRunner.
If there is a will, there is a way. You CAN do it, if you put your
mind to it. You CAN learn to use WinRunner, with little or no
outside help.
SCM is the control, and the recording of, changes that are made to
the software and documentation throughout the software development
life cycle (SDLC).
SCM covers the tools and processes used to control, coordinate and
track code, requirements, documentation, problems, change
requests, designs, tools, compilers, libraries, patches, and
changes made to them, and to keep track of who makes the changes.
Depending on the project, one person can and often wear more than
one hat. For instance, we Test Engineers often wear the hat of
Technical Analyst, Test Build Manager and Test Configuration
Manager as well.
Rob Davis has had experience with a full range of CM tools and
concepts. Rob Davis can easily adapt to your software tool and
process needs.
Q: What is up time?
For example, if, out of 168 hours, a system has been busy for 50
hours, idle for 110 hours, and down for 8 hours, then the busy
time is 50 hours, idle time is 110 hours, and up time is (110 + 50
=) 160 hours.
A: Usability means ease of use; the ease with which a user can
learn to operate, prepare inputs for, and interpret outputs of a
software product.
Q: What is a utility?
Q: What is utilization?
Q: What is V&V?
Q: What is a variable?
A: Variables are data items whose values can change. One example
is a variable we've named "capacitor_voltage_10000", where
"capacitor_value_10000" can be any whole number between -10000 and
+10000.
Q: What is a variant?
Q: What is VDD?
Q: What is a waiver?
Q: What is SDLC?
For integration testing, test cases are developed with the express
purpose of exercising the interfaces between the components.
A: Here is what you can do. You can visit my web site, and on
robdavispe.com/free and robdavispe.com/free2 you will find answers
to the vast majority of others' questions on testing, from a
tester's point of view.
I also suggest you get a job in software testing. Why? Because you
can get additional, free education, on the job, by an employer,
while you are being paid to do software testing. On the job, you
will be able to use some of the more popular software tools,
including WinRunner, LoadRunner, LabView, and the Rational
Toolset. The tools you use will depend on the end client, their
needs and preferences.
Other terms, e.g. software defect and software failure, are more
specific.
A: Invest in your skills! Learn all you can! Visit my web site,
and on http://robdavispe.com/free and http://robdavispe.com/free2,
you will find answers to the vast majority of questions on
testing, from software QA/testers' point of view.
The test team analyzes the requirements, writes the test strategy
and reviews the plan with the project team.
The test plan may include test cases, conditions, the test
environment, and a list of related tasks, pass/fail criteria and
risk assessment.
A: Number one: I suggest you read all you can, and that includes
reading product description pamphlets, manuals, books, information
on the Internet, and whatever information you can lay your hands
on.
If there is a will, there is a way! You CAN do it, if you put your
mind to it! You CAN learn to use WinRunner, and many other
automated testing tools, with little or no outside help. Click on
a link!
"Smart monkeys" are valuable for load and stress testing, and will
find a significant number of bugs, but they're also very expensive
to develop.
"Monkey testing" can be valuable, but they should not be your only
testing.
The software under test typically passes the individual tests, but
our goal is to see if it can pass a large series of the individual
tests.
Our test case is inadequate, if both the original software and all
mutant software generate the same output.
Our test case is adequate, if our test case detects faults, or,
if, at least one mutant software generates a different output than
does the original software for our test case.
Q: What is PDR?
A: PDR is an acronym. In the world of software QA/testing, it
stands for "peer design review", or "peer review".
Your end client requires you to have a PDR, because when you
organize a PDR, you invite and assemble the end client's best
experts and encourage them to voice their concerns as to what
should or should not go into the design and documentation, and
why.
Therefore you want to embrace the idea of the PDR, because holding
a PDR gives you a significant opportunity to invite and assemble
the end client's best experts and make them work for you for one
hour, for your own benefit.
Remember, PDRs are not about you, but about design and
documentation. Please don't be negative; please do not assume your
company is finding fault with your work, or distrusting you in any
way. There is a 90+ per cent probability your company wants you,
likes you and trust you, because you're a specialist, and because
your company hired you after a long and careful selection process.
A: Number 1: PDRs are easy, because all your meeting attendees are
your co-workers and friends.
Number 4: It's technical expertise that counts the most, but many
times you can influence your group just as much, or even more so,
if you're dominant or have good acting skills.
Number 5: PDRs are easy, because, even at the best and biggest
companies, you can dominate the meeting by being either very
negative, or very bright and wise.
Number 10: At PDRs, your meeting attendees are the very best
experts anyone can find, and they work for you, for FREE!
Q: What is the Exit criteria?
Using these checklists, before the start of the peer review, the
developer, tester and facilitator can determine if all the
documents, reports, code blocks or software products are ready to
be reviewed, and if the peer review's attendees are prepared to
inspect them. The facilitator can ask the peer review's attendees
if they have been able to prepare for the peer review, and if
they're not well prepared, the facilitator can send them back to
their desks, and even ask the task lead to reschedule the peer
review.
The attendance of these four people are usually required for the
approval of the PDR. According to company policy, depending on
your company, other participants are often invited, but generally
not required for approval.
In my experience, the most useful peer reviews are the ones where
you're the author of something. Why? Because when you're the
author, then it's you who decides what to do and how, and it's you
who receives all the free help.
When you're an author, developer, or task lead, many times you can
relax, because during your peer review your facilitator and test
lead are unlikely to ask any tough questions from you. Why?
Because, the facilitator is too busy taking notes, and the test
lead is kind of bored (because he had already asked his toughest
questions before the PDR).
Number four, I suggest you read all you can, and that includes
reading product pamphlets, manuals, books, information on the
Internet, and whatever information you can lay your hands on! If
there is a will, there is a way! You CAN do it, if you put your
mind to it! You CAN learn to do QA work, with little or no outside
help! Click on a link!
Number four, I suggest you read all you can, and that includes
reading product pamphlets, manuals, books, information on the
Internet, and whatever information you can lay your hands on!
If there is a will, there is a way! You CAN do it, if you put your
mind to it! You CAN learn to do QA work, with little or no outside
help! Click on a link!
Q: What is CMM?
There are not many Level 5 companies; most hardly need to be.
Within the United States, fewer than 8% of software companies are
rated CMM Level 4, or higher. The U.S. government requires that
all companies with federal government contracts to maintain a
minimum of a CMM Level 3 assessment.
In gray box testing, just as in black box testing, you test from
the outside of a product, just as you do with black box, but you
make better-informed testing choices because you're better
informed; because you know how the underlying software components
operate and interact.
The two terms, version and release, are similar (i.e. mean pretty
much the same thing), but there are minor differences between
them.
1. Verify that you can create, modify, and delete any data in
tables.
Data validity errors are probably the most common, and the most
difficult to detect, data-related errors.
How can you reduce data validity errors? Use simple field
validation rules.
Difference number two: Data validity errors are more common, while
data integrity errors are less common.
Q: What is TestDirector?
On the job, oftentimes you can use some of the world's best
software tools, including the Rational Toolset, and there are many
others. If your immediate manager is reluctant to train you on the
job, in order to do your job, then quietly find another banker,
i.e. another employer, whose needs and preferences are similar to
yours.
Number four: Invest in your skills! Learn all you can! Visit my
web site! On robdavispe.com/free and robdavispe.com/free2 you will
find answers to most questions on testing, from a Software Test
Engineer's point of view. Read the free information! Click on a
link!
Difference number 11: Static testing can find all of the following
that dynamic testing cannot find: syntax errors, code that is hard
to maintain, code that is hard to test, code that does not conform
to coding standards, and ANSI violations.
A: Ideally, you should use both static and dynamic testing tools.
To maximize software reliability, you should use both static and
dynamic techniques, supported by appropriate static and dynamic
testing tools.
All this static testing (i.e. testing for syntax errors, testing
for code that is hard to maintain, testing for code that is hard
to test, testing for code that does not conform to coding
standards, and testing for ANSI violations) takes place before
compilation. Static testing takes roughly as long as compilation
and checks every statement you have written.
If you use neither static nor dynamic test tools, the static tools
offer greater marginal benefits.
Possibility number 2: Know someone, and you WILL get your first
job!
In other words, top down design starts the design process with the
main module or system, then progresses down to lower level modules
and subsystems.
Test every page of the site for left and right justifications,
every shortcut key, each control, each push button, every radio
button, and each item on every drop-down menu. Test each list box,
and each help menu item. Also check, if the command buttons are
grayed out when they're not in use.
For instance, our mythical web designer decides that the fun of
using Javascript and Flash is more important than backward
compatible design, or, he decides that he doesn't have the
resources to maintain multiple styles of backward compatible web
design.
On the other hand, if the same mythical web designer decides that
backward compatibility is more important than fun, or, if he
decides that he has the resources to maintain multiple styles of
backward compatible code, then no user will be inconvenienced.
Top down design is most often used in designing brand new systems,
while bottom up design is sometimes used when one is reverse
engineering a design; i.e. when one is trying to figure out what
somebody else designed in an existing system.
Bottom up design begins the design with the lowest level modules
or subsystems, and progresses upward to the main program, module,
or subsystem.
Top down design, on the other hand, begins the design with the
main or top-level module, and progresses downward to the lowest
level modules or subsystems.
Once you abstract out the parts which are merely utilities, what
is left is much shorter program. The higher you build up the
language, the less distance you will have to travel down to it,
from the top. Bottom up design makes it easy to reuse code blocks.
For example, many of the utilities you write for one program are
also useful for programs you have to write later. Bottom up design
also makes programs easier to read.
You should add revisions to the build only when it makes sense to
do so. You should to establish a Build Group, and build *daily*;
set your *own standard* for what constitutes "breaking the build",
and create a penalty for breaking the build, and check for broken
builds *every day*.
In addition to the daily builds, you should smoke test the builds,
and smoke test them Daily. You should make the smoke test Evolve,
as the system evolves. You should build and smoke test Daily, even
when the project is under pressure.
If you build and smoke test *daily*, success will come, even when
you're working on large projects!
A: There are many who might say, "I need experience to get a job.
But, how can I get the experience, if I cannot get a job?"
The good thing is, when you want a QA Tester job, there are MANY
possibilities!
If there is a will, there is a way! You CAN do it, if you put your
mind to it! You CAN learn to use WinRunner and many other
automated testing tools, with little or no outside help. Click on
a link!
Documentation is critical.
Why? Because I believe it's NOT wise to put any fake experience in
one's resume. Putting fake experience would not be professional,
would not be ethical, could hurt my career, and I would be found
out.
A: If there is a "magic bullet", i.e. the one test case that has a
good possibility to catch ALL the bugs, or at least the most
important bugs, it is a challenge to find it, because test cases
depend on requirements; requirements depend on what customers
need; and customers can have great many different needs.
Q: Give me one test case that catches all the bugs! (Cont'd...)
Often the lack of enough time for testing is the reason for bugs
to occur in the field.
However, even with ample time to catch the "most important bugs",
bugs still surface with amazing spontaneity.
A: The terms "test scenario" and "test case" are often used
synonymously.
Test scenarios are test cases, or test scripts, and the sequence
in which they are to be executed.
Test scenarios are test cases that ensure that business process
flows are tested from end to end.
Test case number 101: "Inputs: The headlights are on. The brake
pedal is depressed. Expected result: The brake lights are on.
Verify that the brake lights are on, when the brake pedal is
depressed."
Test case number 102: "Inputs: The left turn lights are on. The
brake pedal is depressed. Expected result: The brake lights are
on. Verify that the brake lights are on, when the brake pedal is
depressed."
Test case number 103: "Inputs: The right turn lights are on. The
brake pedal is depressed. Expected result: The brake lights are
on. Verify that the brake lights are on, when the brake pedal is
depressed."
To make the test case complete, I also add particulars e.g. test
case identifiers, test case names, objectives, test conditions (or
setups), input data requirements (or steps), and expected results.
Q: What is a parameter?
Q: What is a constant?
Keep in mind that, unlike variables which can be read from and
written to, constants are read-only variables.
How do you create one? You can create a requirements test matrix
template in the following six steps:
Step 4: Focus on the the first column of your table. One by one,
copy all your 90 requirement numbers, and paste them into rows 2
through 91 of your table.
Step 5: Focus on the the first row of your table. One by one, copy
all your 360 test case numbers, and paste them into columns 2
through 361 of your table.
Step 6: Examine each of your 360 test cases, and, one by one,
determine which of the 90 requirements they satisfy. If, for the
sake of this example, test case 64 satisfies requirement 12, then
put a large "X" into cell 13-65 of your table... and then you have
it; you have just created a requirements test matrix template that
you can use for cross-referencing purposes.
Q: What is validation?
Q: What is a walk-through?
Q: What is an inspection?
Q: What is quality?
One problem with such tools is that if there are continual changes
to the product being tested, the recordings have to be changed so
often that it becomes a very time-consuming task to continuously
update the scripts.
"Well, I read a book and it said you should have a one page
resume."
"I can't really go into what I really did because if I did, it'd
take more than one page on my resume."
"Gosh, I wish I could put my job at IBM on my resume but if I did
it'd make my resume more than one page, and I was told to never
make the resume more than one page long."
"I'm confused, should my resume be more than one page? I feel like
it should, but I don't want to break the rules."
Or, here's another comment, "People just don't read resumes that
are longer than one page." I have heard some more, but we can
start with these.
The biggest mistake you can make on your resume is to make it hard
to read. Why? Because, for...
One, scanners don't like odd resumes. Small fonts can make your
resume harder to read. Some candidates use a 7-point font so they
can get the resume onto one page. Big mistake.
Two, resume readers do not like eye strain either. If the resume
is mechanically challenging, they just throw it aside for one that
is easier on the eyes.
Three, there are lots of resumes out there these days, and that is
also part of the problem.
Five, resume readers don't like to guess and most won't call you
to clarify what is on your resume.
A: The same qualities a good test engineer has are useful for a QA
engineer. Additionally, Rob Davis understands the entire software
development process and how it fits into the business approach and
the goals of the organization. Rob Davis' communication skills and
the ability to understand various sides of issues are important.
Good QA engineers understand the entire software development
process and how it fits into the business approach and the goals
of the organization. Communication skills and the ability to
understand various sides of issues are important.
Once Rob Davis has learned and reviewed your standards and
templates, he will use them. He will also recommend improvements
and/or additions.
Unit testing is performed after the expected test results are met
or differences are explainable/acceptable.
You CAN learn system testing, with little or no outside help. Get
CAN get free information. Click on a link!
Depending on the project, one person may wear more than one hat.
For instance, Test Engineers may also wear the hat of Technical
Analyst, Test Build Manager and Test Configuration Manager.
Depending on the project, one person may wear more than one hat.
For instance, a Test Engineer may also wear the hat of a Test
Build Manager.
Depending on the project, one person may wear more than one hat.
For instance, a Test Engineer may also wear the hat of a System
Administrator.
A: Your need clearance whenever you work in a job where you have a
potential to cause damage to national security, or in a job where
you can gain access to classified information. You need clearance
because of executive order 10450, signed by President Dwight
Eisenhower on April 17, 1953. Executive order 10450 gives the
government the authority to require clearances of employees who
request access to national security or sensitive information.
A: First you have to find the right job, apply for the job, and
get a conditional offer of employment. Then you can apply for
clearance, by filling out multi-page forms (e.g. federal form
SF-86, National Security Questionnaire), giving the government
lots of background and identification information on yourself,
your relatives, and others. Then you're fingerprinted,
interviewed, and then, in due time, investigators working for the
government (i.e. DSS) will put you and your lifestyle under a
microscope.
A: Surely they can! We don't know how the government decides, but
my educated guess is, if you're not the stereotype all-American
good guy the government investigators have in mind, then, chances
are, your application for clearance will be rejected.
They can reject you for hundreds of reasons, including sabotage,
espionage, treason, terrorism, sedition; for wanting to overthrow
the government; for friendship or sympathy with anyone who
attempts to commit these crimes; act of force or violence; lack of
American citizenship, non-citizen spouses, family members,
relatives, cohabitants, or friends; failing to report associations
with foreigners; association with suspected foreign spies;
financial or business interests in a foreign country; dual
citizenship, foreign passport, accepting educational, medical,
retirement or welfare benefits from a foreign country, residence
in a foreign country, seeking or holding political office in a
foreign country, voting in a foreign election, serving the
interests of a foreign government, military service in a foreign
country; compulsive or addictive behavior, self-destructive or
high-risk behavior, personality disorder, any sexual behavior that
makes you vulnerable, lack of discretion or judgment;
uncooperative attitude, incomplete forms or releases, lack of
full, frank and truthful answers, opinions of neighbors,
associates, employers, or coworkers; omission, concealment, or
falsification of facts; providing false or misleading information,
concealment of information, any activity that makes you
susceptible to blackmail, dishonesty, violation of rules or
written agreements, association with criminals; too much money,
too little money, not paying your debts, fraud, embezzlement,
theft, income tax evasion, deceptive loan statements, breach of
trust, addiction to gambling, drugs, or alcohol; driving while
under the influence, fighting, child or spouse abuse, reporting
for work drunk, drinking on the job, diagnosis of alcohol
dependence, habitual consumption of alcohol, impaired judgment;
drug use, possession, cultivation, processing, manufacture,
purchase, sale, or distribution, diagnosis of drug abuse or drug
dependence, unsuccessful drug treatment program; defect in
judgment, reliability, or stability, failure to take prescribed
medication; high-risk, irresponsible, aggressive, anti-social or
emotionally unstable behavior; allegations of criminal conduct;
disclosure of classified information, negligence; job a foreign
country, service to a foreign national, foreign intelligence agent
or organization; computer crimes, including unauthorized entry,
modification, destruction, manipulation, denial of access to
information, removal or introduction of hardware, software or
media, and illegal downloading of files.
One, you will likely loose your job as soon as your access to
classified information is terminated.
Five, you might face large expenses. Why? Because your hearing
will be conducted like a federal district court bench trial.
Therefore you want an attorney on your side, to make an opening
statement, closing argument, to do a direct examination of
yourself and your other witnesses, and to cross examine government
witnesses. And, attorneys usually cost a lot of money!
Knock off personal pronouns, such as "I", "me" and "my". The
reader already knows your resume is about you. Resumes should not
contain any unnecessary words. Your resume is not a memoir, but a
concise summary of your skills and experience.
Words such as "a", "an", "also", "because", "the" and "very" are
sometimes necessary, but, nevertheless, in one's resume, one needs
to keep them to a minimum.
In your resume, avoid any words you can't define. If you use them
incorrectly, they can kill your chances of landing the job. The
damage they bring will be permanent.
Q: What is a QA engineer?
A: Software failure occurs when the software does not do what the
user expects to see. Software fault, on the other hand, is a
hidden programming error.
_________________________________
Depending on the project, one person can and often will wear more
than one hat. For instance, we, Test Engineers, often wear the hat
of Technical Analyst, Test Build Manager and Test Configuration
Manager as well.
As to "best" roles, the best ones are the ones that make YOU
happy. The best job is the one that works for YOU, using the
skills, resources, and the talents YOU have.
Rob Davis has had experience with a full range of CM tools and
concepts. Rob Davis can easily adapt to your software tool and
process needs.
Q: What is up time?
Q: What is usability?
A: "Usability" means ease of use; the ease with which a user can
learn to operate, prepare inputs for, and interpret the outputs of
a software product.
Q: What is VDD?
Q: What is a waiver?
A: In software QA, a waiver is an authorization to accept software
that has been submitted for inspection, found to depart from
specified requirements, but is nevertheless considered suitable
for use "as is", or after rework by an approved method.