Тестирование — проверка соответствия между реальным и ожидаемым поведением программы.
При изменении вашего кода, вам необходимо проверить, как эти изменения повлияли на работу приложения. После этого вам нужно воспроизвести как можно больше различных случаев, как реальные пользователи будут пользоваться вашим приложением. Убедившись, что приложение работает, можно считать свою работу выполненой.
Вроде как очень простой и понятный процесс, но обычно разработчики не могут покрыть все возможные случаи и сам процесс проверки занимает слишком много времени (про лень разработчиков можно слагать легенды).
Чтобы не проверять все возможные случаи вручную и быть уверенным, что ваша «новая фича» не сломала часть вашего приложения, можно и необходимо использовать автоматические тесты.
Написание автоматических тестов:
- сократит время на проверку изменений;
- сократит кол-во багов;
- можно использовать многократно;
- при неудаче покажет в каком месте приложения изменилось поведение;
- является подтверждением того, что приложение работает как задумано.
Из этого следует, что тесты стоит писать в случае, если ваше приложение будет изменяться и развиваться.
Как убедить заказчика платить за тестирование?
Никак. Просто расчитайте время с учетом написания тестов и не говорите ему про это. Хотя если у вас способ, можете поделиться им в комментариях.
Виды тестирования для разработчиков
Существует огромное кол-во видов тестирования, но рассмотрим только те, которые используют разработчики в своих проектах.
Модульный тест (Unit test, Block test, Component test)
Модульный тест тестирует отдельный участок системы (функцию, процедуру, метод, класс или модуль) изолированый от внешних частей программы. Для изоляции модуля мы используем так называемые заглушки (stubs) и макеты(mocks). Данные тесты выполняются очень быстро и в идеальном мире должны составлять большую часть всех тестов на проекте.
Интеграционный тест (Integration test, Backend test, Contract test, API driven test)
Интеграционый тест тестирует работу модулей в комлпексе. Обычно покрывают публичную часть приложения изолируя необходимое кол-во модулей программы. Отбрасываем графический интерфейс вашего приложения и имитируем какие данные должен ввести пользователь и получить на выходе.
Функциональный тест (Functional or End-to-End test, GUI test, Walk-Through test)
Данные тесты полностью эмулируют поведение пользователей. в браузере. Пишется пошаговый тест, как пользователь должен себя вести в вашем приложении. На какую страницу приложения он зайдет, какую инфорацию заполнит, какую кнопку нажмет и т.д. Чаще всего такие тесты пишут тестировщики, но иногда и разработчики в зависимости от требований компании. Хорошим тоном является, когда такие тесты можно запускать без GUI- оболчки, чтобы в дальнейшем можно было использовать как часть процесса CI (Continuous Integration).
Ручное тестирование (Manual Testing)
Самый понятный вид тестирования. Надеюсь вы проверяете сделаную работу хотя бы так.
Тестирование на проекте
Чаще всего на проектах тестирование происходит примерно так:
Мануальное тестирование занимает львиную долю всех тестов на проекте, а иногда кроме мануального тестирования не используется ничего. Тестирование занимает очень много времени. Одни и теже действия нужно делать при каждом релизе. Разработчики при создании новой фичи ломают старую функциональность.
Чтобы достичь хороших результатов нужно действовать в следующем направлении:
Тестировщики занимаются автоматизацией функциональных тестов, а программисты тестируют свою часть с помощью юнит-тестов и интеграционных тестов.
Юнит тесты и интеграционные тесты выполняются очень быстро, поэтому их кол-во должно быть максимальным и покрывать все возможные случаи.
