Дочитал наконец я книгу "Software Testing" Рона Паттона. Не могу сказать, что мне очень понравилось и она легко шла - не очень, из разряда книг для начинающих тестировщиков, Рекс Блек с его "Fundamentals of Software Testing, ISTQB Certification" и, само-собой Сэм Канер были прочтены с гораздо большим вдохновением и удовольствием.
Возможно, творение Рона Паттона мне было не очень интересно читать, потому что, все-таки это моя далеко не первая книга о тестировании, и большинство вещей являлись для меня чем-то само-собой разумеещимся; а так же различия в терминологии и толковании известных мне понятий - это конечно сбивало с толку и перестраиваться на мышление Рона не всегда хотелось..
Но, конечно же, Рон старался не зря - во-первых он все-таки знает предмет и повторить для себя истины никогда лишним не будет; во-вторых - неизвестных мне ранее идей, все же горсточка накопилась. Но остановиться я хочу на самой веселой и захватывающей части книги..:)
Книга имеет следующую структуру: в конце каждой главы приведен список вопросов к каждой из глав (называется Quiz), для, так сказать, закрепления знаний. А в конце книги приведены ответы на каждый из вопросов, возникавшие к каждой из глав. Так вот для своей заметки и не только делюсь вопросами/ответами заинтересовавшими меня:
What's
wrong with just testing that a program works as expected?
|
At
most, that's only half the testing problem. Users don't always follow the
rules, and testers need to prove out what happens when they don't. Also, if
testers don't approach their testing with a gotta-break-it attitude, they
will miss bugs
|
What's
the goal of a software tester?
|
The
goal of a software tester is to find bugs, find them as early as possible,
and make sure they get fixed
|
Why
can the waterfall development method be difficult to use?
|
Just
like with salmon, it's difficult to swim upstream. Each step is a discrete,
standalone process that follows the one before it. If you get to the end and
find that something should have happened further up, it's too late to go back
|
Why
would a software tester like the spiral model better than the others?
|
They're
involved very early in the development process and have the opportunity to
find problems early, saving the project time and money.
|
If you
were testing a feature of your software on Monday and finding a new bug every
hour, at what rate would you expect to find bugs on Tuesday?
|
Two
axioms come into play here. The firstthat the number of bugs remaining is
proportional to the number of bugs you've already foundmeans that you won't
come in on Tuesday and miraculously find the software to be perfect. The
pesticide paradox tells you that if you continue to run the same tests over
and over that you eventually won't find new and different bugs until you add
more tests. Given these two axioms, you will probably continue to find bugs
at the same rate or slightly less.
|
True
or False: You can perform dynamic black-box testing without a product
specification or requirements document
|
True.
The technique is called exploratory
testing, and you essentially use the software as though it's the product
spec. It's not an ideal process, but can work okay in a pinch. The largest
risk is that you won't know if a feature is missing
|
Why
does knowing how the software works influence how and what you should test?
|
If you
test only with a black-box view of the software, you won't know if your test
cases adequately cover all the parts of the software nor if some of the cases
are redundant. An experienced black-box tester can design a fairly efficient
suite of tests for a program but he can't know how good that suite is without
some white-box knowledge
|
What's
the difference between dynamic white-box testing and debugging?
|
Both
processes overlap, but the goal of dynamic white-box testing is to find bugs
and the goal of debugging is to fix them. The overlap occurs in the area of
isolating exactly where and why the bug occurs
|
What's
the difference between a test stub and a test driver?
|
A test
stub is used in top-down testing. It stubs out, or substitutes itself, for a
low-level module. It looks and acts to the higher-level code being tested
just like the original low-level module. A test driver is the opposite of a
stub and is used in bottom-up testing. It's test code that replaces
higher-level software to more efficiently exercise a low-level module
|
True
or False: Always design your black-box test cases first.
|
True.
Design your test cases based on what you believe the software is supposed to
do. Then use white-box techniques to check them and make them most efficient.
|
What's
the biggest problem of white-box testing, either static or dynamic?
|
You
can easily become biased. You might look at the code and say, "Oh, I
see, I don't need to test that case, the code handles it properly." In
reality, you were blinded by the light and eliminated necessary test cases.
Be careful!
|
If
there's no definitive right or wrong user interface, how can it be tested?
|
Software
testers should check that it meets seven important criteria: That it follows
standards and guidelines, that it's intuitive, consistent, flexible,
comfortable, correct, and useful
|
What
is gray-box testing?
|
Gray-box
testing is when you can take a peek at the underlying code and use that
information to help you test. You're not examining it to the same level of
detail as you would with white-box testing. It's helping you test, but you're
not basing all of your tests on it
|
Name a
few areas that you need to consider when performing configuration and
compatibility testing of a website
|
The
hardware platform, the operating system, the web browser, browser plug-ins,
browser options and settings, video resolution and color depth, text size,
and modem speeds
|
Name a
few benefits of using software test tools and automation.
|
They
can speed up the amount of time it takes to run your test cases. They can
make you more efficient by giving you more time for test planning and test
case development. They're precise and relentless.
|
What's
one of the simplest, but effective, types of test automation?
|
Recording
and replaying your test cases so that you only have to manually perform them
once is very effective. It frees you from the monotonous repetition and can
give you more time to hunt for those hard to find bugs.
|
Describe
the pesticide paradox and how bringing in new people to look at the software
helps solve it.
|
The
pesticide paradox is the situation that occurs if you continue to test
software with the same tests, or the same people. Eventually, the software
seems to build up an immunity to the tests because no new bugs are found. If
you change the tests or bring in new testers, you'll find new bugs. The bugs
were always there, it's just that the new approach made them visible.
|
Why is
it the process of creating the plan that matters, not the plan itself?
|
Because
all the issues and questions defined in a test plan either impact or are
influenced by other project functional groups or team members. Getting
everyone to understand and agree to the contents of the plan is what matters.
Privately creating a paper document and putting it on a shelf is not just a
waste of time, but also jeopardizes the project
|
What are
entrance and exit criteria?
|
These
requirements must be met to move from one testing phase to another. A phase
can't be left until its exit criteria are met. A new phase can't be entered
until its entrance criteria are met.
|
What
basic principles can you apply to your bug reports to give them the best chance
of getting the bug fixed?
|
Log
them as soon as possible. Effectively describe the bug, making sure it's
minimal, singular, obvious and general, and reproducible. Be nonjudgmental in
your approach. Follow the report through its life cycle
|
Why
would being called a QA Engineer be a difficult title to live up to?
|
Because
it implies that you are the one guaranteeing the product's quality. Are you
ready for that responsibility?
|
