Тестирование программного обеспечения. Базовый курс

К недостаткам водопадной модели принято относить тот факт, что участие пользователей ПО в ней либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований. С точки зрения же тести-рования эта модель плоха тем, что тестирование в явном виде появляется здесь лишь с середины развития проекта, достигая своего максимума в самом конце.

Если вы пишете требования на русском, то пишите «нажать» вместо «нажмите», «ввести» вместо «введите», «пе-рейти» вместо «перейдите» и т.д. В технической документации вообще не рекомен-дуется «переходить на личности», а также существует мнение, что личная форма глаголов подсознательно воспринимается как «чужие бессмысленные команды» и приводит к повышенной утомляемости и раздражительности.

Помните, что в основе тестирования лежит цель. Если вы не можете быстро и просто сформулировать цель созданного вами тест-кейса, вы создали пло-хой тест-кейс.

Обязательно пишите чек-листы. Если вам кажется, что вы сможете запом-нить все идеи и потом легко их воспроизвести, вы ошибаетесь. Исключений не бывает.

Ещё одним аргументом в пользу тестирования требований является то, что, по разным оценкам, в них зарождается от ½ до ¾ всех проблем с программным обеспечением.

Мало просто обнаружить некий единичный случай неверного поведения при-ложения, нужно понять закономерность такого поведения и его источник.

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

Если же выразить все преимущества и недостатки автоматизации тестиро-вания одной фразой, то получается, что автоматизация позволяет ощутимо увели-чить тестовое покрытие (test coverage126), но при этом столь же ощутимо увеличи-вает риски.

Методы белого и чёрного ящика не являются конкурирующими или взаимо-исключающими — напротив, они гармонично дополняют друг друга, компенсируя таким образом имеющиеся недостатки.

Сэм Канер определяет361 исследовательское тестирование как стиль, осно-ванный на свободе и ответственности тестировщика в непрерывной оптимизации своей работы за счёт выполняемых параллельно на протяжении всего проекта и взаимодополняющих изучения, планирования, выполнения проверок и оценки их результатов. Если сказать короче, исследовательское тестирование — это одно-временное изучение, планирование и тестирование.

Корень проблемы состоит в том, что планированию и отчётности в школах и университетах учат достаточно поверхностно, при этом (увы) на практике часто вы-холащивая эти понятия до пустой формальности (планов, на которые никто не смотрит, и отчётов, которые никто не читает; опять же, кому-то повезло увидеть строго обратную ситуацию, но явно немногим).

Тестирование удобства использования (usability174 testing) и тестирование интерфейса пользователя (GUI testing183) — не одно и то же! Например, корректно работающий интерфейс может быть неудобным, а удобный может работать некорректно.

Фредерик Брукс в своей книге «Мифиче-ский человеко-месяц»166 писал: «Фундаментальная проблема при сопровож-дении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечёт появление новой».

Если вас интересует некая «эталонная классификация», то… её не суще-ствует. Можно сказать, что в материалах113 ISTQB приведён наиболее обобщённый и общепринятый взгляд на этот вопрос, но и там нет единой схемы, которая объединяла бы все варианты классификации.
Так что, если вас просят рассказать о классификации тестирования, стоит уточнить, согласно какому автору или источнику спрашивающий ожидает услышать ваш ответ.

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

Очень частая ошибка! Негативные тесты НЕ пред-полагают возникновения в приложении ошибки. Напротив — они предполагают, что верно работающее приложение даже в критической ситуации поведёт себя правильным образом (в примере с делением на ноль, например, отобразит сообще-ние «Делить на ноль запрещено»).

Тестирование можно классифицировать по очень большому количеству при-знаков, и практически в каждой серьёзной книге о тестировании автор показывает свой (безусловно имеющий право на существование) взгляд на этот вопрос.

личностные качества, позволяющие тестировщику быстрее стать отличным специалистом:
1) повышенная ответственность и исполнительность;
2) хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли;
3) терпение, усидчивость, внимательность к деталям, наблюдательность;
4) хорошее абстрактное и аналитическое мышление;
5) способность ставить нестандартные эксперименты, склонность к исследовательской деятельности.

Если выразить образно главную цель тестировщика, то она будет звучать
так: «понимать, что в настоящий момент необходимо проекту, получает ли проект
это необходимое в должной мере, и, если нет, как изменить ситуацию к лучшему».
Звучит похоже на цель руководителя проекта, верно? Верно. Начиная с некоторого
уровня развития, IT-специалисты, по большому счёту, различаются лишь наборами
технических навыков и основной областью приложения этих навыков