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

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

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

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

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

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

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

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

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

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

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