QA (rus)

Вопросы после прочтения книг по тестированию

Вопросы и ответы, которые появились после прочтения книг:

  • В какой момент девелоперы должны делать юнит-тестирование?
    Я просмотрел множество ссылок в поисках наиболее простого ответа, везде примерно одно и то же. Юнит тесты – это тесты, которые можно запустить на этапе компиляции программы. Их задача – тестирование функций и классов, а не работающей программы. Фактически, юнит тесты полностью описывают и проверяют минимальные блоки из которых строится программа. Соответственно, не так важно, какой методологии мы следуем в проекте. При изменении, например, класса, мы начинаем запускать тест.
  • Должен ли аналитик или PM участвовать в организации юнит тестирования? Этот вопрос для меня оказался самым сложным.. Вопрос в степени участия. Аналитик, как мне кажется, не должен участвовать на данном этапе. Тут должны работать скрипты, логика работы проявляется на уровне интеграционного тестирования, но аналитикам вообще важнее системный. На всякий случай, задал вопрос на uml2.ru. Руководитель проектов должен санкционировать данный вид тестирования, на этом его роль в этом процессе, видимо, заканчивается.
  • Может ли юнит-тестирование быть вместе с интеграционным тестированием? Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию. Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования. Как аналитик, я  занимался системным тестированием.
  • Для каких видов тестирования делается Regression Routine? Я могу ошибаться, но кажется, что это совпадает с Регрессионным тестированием. Регрессионное тестированиесобирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ.regression bugs). Это из Википедии, приведу ещё раз виды тестирования (тут очень удобные ссылки):

По объекту тестирования:

По знанию системы:

По степени автоматизации:

По степени изолированности компонентов:

По времени проведения тестирования:

По признаку позитивности сценариев:

  • Позитивное тестирование (positive testing)
  • Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

  • Тестирование по документации (formal testing)
  • Тестирование ad hoc или интуитивное тестирование (ad hoc testing)

Комментарии

Эдуард Гелиаскаров на форуме uml2.ru ответил мне следующее (на второй вопрос):

Мой ответ.  Я думаю, что не должен. Хотя если следовать Майерсу. Тестировщик – человек с особым типом мышления, и не должен быть аналитиком или кем-то еще кроме тестировщика Улыбающийся

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

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

И продолжение:

Алексей. Вы не поверите, у нас такая стратегия, что все повально автоматизируем. Я бы даже сказал, что, возможно, мы попали в ловушку автоматизации. Это когда и тест уже устарел и выбросить жалко. Спасает пока постоянный рефакторинг всего тестового плана.
Нет, конечно, доля ручного тестирования велика. Более того я бы сказал, что ее практикуют аналитики – хотя не всегда системно и всегда фрагментарно. Опять же наша любезная армия пользователей. Ну и, конечно, мы специалисты по качеству Улыбающийся Да всегда все новые функции заявленные в релизе тестируются вручную по плану и без плана в свободной исследовательской манере. В ходе такого тестирования кристаллизируется сценарий тестового случая (чаще всего это сложные тестовые цепочки – ну не на два часа, но близко к смыслу), немедленно автоматизируются отчеты. Такие тесты реализовать очень просто, а тестовая сила у них большая. Частенько применяем такой прием: масса тестовых сценариев проверяют какие-то свои тестовые случая, но и постепенно готовят массовые изменения, которые потом проверяются созданием некоторого отчета – все проблемы высвечиваются как прожектором. правда не всегда сразу ясна проблема, но ошибку фиксирует. Правда при условии, что полученный эталон – действительно эталон. Частенько эталоны существуют с ошибками месяцами, прежде чем их обнаруживаешь. Но постепенно учимся делать эталоны сразу качественные.
Кроме того, стараемся многие цепочки минимизировать, ведь каждая цепочка – это приведение базы в определенное состояние, по этому мы часть шагов (наиболее долгих и трудоемких) делаем один раз и сохраняем в эталонной базе.

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

Advertisements
Standard

One thought on “Вопросы после прочтения книг по тестированию

  1. Pingback: QA terms and questions | Alexey Kiselev

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s