воскресенье, 31 марта 2013 г.

Полезный и интересный Quiz из книги Software Testing Рона Паттона

       Дочитал наконец я книгу "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?



Комментариев нет:

Отправить комментарий