К основному контенту

"The Ongoing Revolution in Software Testing" by Cem Kaner (2004) - разбор общепринятых утверждений о тестировании/тестировщиках

Благодаря давнишнему твиту Alan Page узнал про чудесную статью Cem Kaner, который еще в 2004 году разобрал популярные утверждения (мифы?) про тестирование и роль тестировщиков.

Что именно так разбирается:

The Role of Testers
• The primary reason to test is to find bugs?
• The primary reason to test is to prove the program works correctly?
• Testers are THE advocates of quality on a project.
• Test groups should evolve into quality assurance groups.
• The test group should have the power to block release if product quality is too low.
• Testers and programmers have conflicting interests.
• The test group should work independently of the programmers.
• Testers should push their project teams to follow "appropriately professional
development models," like the Waterfall, that require people to THINK before they act.
• Testers should base test cases on documented characteristics of the program. If the software documentation is inadequate for this, testers should assert a quality control function and demand better specification and requirements documentation. 
• The primary reason to test is to find bugs. 
• The primary reason to test is to prove the program works correctly.

Test Planning and Documentation
• Testers should specify the expected result of every test, in advance.
• Exploratory testing, if done at all, should be done only by experts.
• There should be at least one thoroughly documented test for every requirement item or
specification item.
• Testers should design most or all tests early in development.
• Testers should design all tests for reuse as regression tests.
• Testers should document manual tests in great procedural detail so that they can be
handed down to less experienced or less skilled testers.
• Testers should document each test case individually, ideally storing them in a test case
management system that describes the preconditions, procedural details, postconditions,
and basis (such as trace to requirements) of each individual test.

The Practice of Testing
• Testers should assume that the programmers did a light job of testing and so should
extensively cover the basics (such as boundary cases for every field).
• Testers should develop automated tests at the user interface level.
• Testers should design tests without knowledge of the underlying code.
• Testers should design the build verification tests, even the ones to be run by
programmers.
• Most testers don't need to be programmers, because they only have to specify how the
external program will behave in their tests. Testing tools will allow business experts to
develop automated tests without having to program.
• The pool of tests should cover every line and branch in the program, or perhaps every
basis path.
• All failures must be reported into a bug tracking system and carefully counted.
• We can measure the individual effectiveness of software testers by counting how many
bugs they find, perhaps with an adjustment for bug severity.
• We can tell how close we are to release of the product by examining the bug curve that
shows bug finds per week.

Все тут обсуждать/переводить не буду, оставлю только то, что очень зацепило. Но вы обязательно почитайте все остальное тоже, если интересуетесь организацией процесса тестирования или вашем местом в этом процессе.

QA - точно про assurance?
Попробуйте ответить на эти вопросы и еще раз подумать действительно ли вы сейчас QA-инженер?
• Do testers have the authority and cash to provide training for programmers who need it?
• Do testers have the authority to settle customer complaints? Or to drive the handling of
customer complaints?
• Do testers have the ability and authority to fix bugs?
• Do testers have the ability and authority to either write or rewrite the user manuals?
• Do testers have the ability to study customer needs and design the product accordingly?

"Каждый тест должен иметь ожидаемый результат"
One fundamental problem with this idea is that it is misguided. Every test has many results. No one specifies them all. An "expected result" points the tester at one or a few of these results, but away from the others.

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе