В повседневной жизни мы используем множество различных приложений, а интернет уже стал неотъемлемой частью жизни. За каждым из приложений — будь то сервис для заказа пиццы, билетов или бронирования отельных номеров — стоят люди, которые делают жизнь намного комфортнее за счет собственно приложений.
Над созданием приложений обычно трудятся тестировщики и разработчики, которые рассматривают этот процесс с разных ракурсов.
Попробуем разобраться в том, как тестировщики и разработчики взаимодействуют друг с другом во время работы над программными продуктами.
У этих людей одна и та же задача, а именно, сделать качественный продукт, но способы их мышления отличаются. Отличие, собственно, в том, что представители этих профессий идут к намеченной цели разными путями.
- Разработчик думает: «Как создать приложение?»
- Тестировщик: «Как взломать?»
Их взаимодействия отчасти напоминают отношения Тома и Джерри. (Но конечный результат достигается только за счет слаженной совместной работы).
Под главным вопросом, который задает себе тестировщик — «как взломать приложение?» — не подразумевается, что его девиз — разрушать работу разработчика. Это лишь означает, что тестировщики за счет нестандартного мышления и попыток смотреть на вещи глазами пользователей пытаются протестировать на приложении все возможные сценарии. Такой подход имеет целью не допустить того, чтобы ошибки обнаружились уже после релиза.
В разработке приложения важную роль играет жизненный цикл разработки ПО (или SDLC). Прежде тестирование приложений производилось в последнюю очередь. Но этот подход не оправдал себя: устранение ошибок на самом последнем этапе разработки обходится довольно дорого. И во избежание подобных затруднений сейчас тестирование ПО проводится на каждом этапе SDLC.
Тестировщики рассматривают приложение с другой творческой точки зрения, и этот фактор во многом становится определяющим.
Содержание
Рассмотрим работу тестировщика на разных этапах SDLC:
#1) Сбор требований и анализ:
На этом этапе после сбора всех необходимых данных составляется документ требований.
Документ этот доступен участниками команды, которые делятся своими соображениями, а также задают вопросы. Вопрос может быть любым — от особенностей определенного раздела до нюансов, которые могут повлечь потенциальные ошибки.
Рассмотрим наглядный пример: требование конечного пользователя — «запрещены какие-либо специальные символы в поле ввода».
Роль разработчика: написать код для поля ввода таким образом, чтобы при вводе специального символа появлялся соответствующий индикатор ошибки.
Точка зрения тестировщика: тестировщик вначале проверит указанное требование, после чего будет прорабатывать множество сценариев. Обычно у него появляются вопросы такого характера:
- Если какие-то специальные символы появятся в поле ввода, будут ли они высвечиваться для пользователя так же, как и другие, или иначе?
- Что если пользователь скопирует какую-либо комбинацию специфических буквенно-цифровых символов?
Подобных сценариев, которые продумывают тестировщики, изучая документ с требованиями, может быть довольно много.
Для оценки любого продукта или приложения тестирование предполагает охват всех возможных сценариев. Ведь люди обращаются с приложениями по-разному, и конечным пользователем может быть кто угодно.
#2) Дизайн системы/приложения
После сбора данных и составления требований разработчик приступает к работе, которая предполагает изучение плана дизайна приложения перед его практической реализацией.
Тестировщики, опираясь на свои знания и креативное мышление, анализируют все потенциальные сценарии для новых функций, расширений, интеграций, обновлений UI и всего того, о чем упоминается в требованиях. Они создают тест-кейсы, списки для проверки работоспособности и данные — когда приложение передается команде тестировщиков, тестовые параметры уже готовы.
#3) Этап реализации:
На данном этапе разработчики фактически завершают работу над системой.
С их точки зрения функционал должен быть идеальным и эффективным.
Разработчик сосредоточен на реализации функционала, тестировщик же все свои силы и способности расходует на тестирование функциональных возможностей. Бывают случаи, когда разработчики не до конца понимают требования, и после применения тестовых сценариев в приложении возникает ошибка.
#4) Системное тестирование:
На данном этапе разработчики загружают приложение в среду для тестирования с определенным набором функциональных возможностей, которые были реализованы разработчиком в данном конкретном релизе.
Разработчики отправляют приложение тестировщикам, предполагая, что реализованный функционал идеален и соответствует всем требованиям; они отдают приложения тестировщикам, чтобы лишний раз это подтвердить.
Но для тестировщиков, помимо основного функционала, существует множество других способов, посредством которых конечный пользователь обращаться с приложением. И это уже задача тестировщика — исследовать каждый из возможных сценариев.
#5) Этап сопровождения
На данном этапе производится проверка того, что было достигнуто общими усилиями тестировщиков и разработчиков.
В дальнейшем приложение уже отправляется пользователям. Если все работает, как и предполагалось, тогда проблем нет. Но если сложности все-таки возникают, тогда вновь понадобится совместная работа тестировщиков и разработчиков.
Важные аспекты, определяющие роль разработчиков и тестировщиков:
Разработчики должны удостовериться в том, что в продукте, который они создали, отсутствуют какие-либо дефекты, тестировщикам, в свою очередь, необходимо обнаружить все баги (если таковые имеются) к определенному сроку.
Разработчики являются специалистами в определенной технической области и благодаря своим навыкам могут создать продукт, соответствующий требованиям заказчика. Тестировщики — это третья сторона, участвующая в проекте, предполагаемый виртуальный пользователь приложения, который сообщает о об ошибках/багах.
Работа тестировщика:
Конечно, многие разработчики могли бы заниматься тестированием. Но здесь все дело в человеческом факторе. Мы не можем беспристрастно относиться к собственным разработкам. Нужен взгляд со стороны.
«Тестер» — это человек, который высказывает собственные суждения, исходя из практического опыта применения разных сценариев.
Хороший тестировщик отдает себе отчет в том, что пользователи, осваивая новые продукты, допускают множество ошибок. Как правило, чтению инструкций они предпочитают практические действия, чтобы посмотреть, что из этого выйдет.
Поэтому главный вопрос для тестировщика: «Что может пойти не так?». Основная же задача разработчика — создать продукт в соответствии с требованиями.
Хороший тестировщик и хороший разработчик:
Хороший тестировщик способен работать в конфликтных ситуациях.
Зачастую бывает крайне сложно отыскать источник дефекта — это может быть баг в коде, документации, дизайне, дефекты могут и вовсе отсутствовать. Работа тестировщика заключается в том, чтобы сообщать о каждом обнаруженном баге.
Хороший разработчик — тот, кто позитивно воспринимает замечания, диагностирует проблему и устраняет ее. Но разработчики зачастую стремятся избегать конфликтных ситуаций, что сказывается на эффективности работы.
Итог
Резюмируя вышеизложенное, можно сказать, что разные подходы способствуют созданию качественного продукта и порой помогают найти единственно верное решение.
Каждый занимается своим делом. Разработчик создает приложение, тестировщик — тестирует.
Чтобы сделать качественное приложение разработчику нужен критик, способный замечать несовершенства программного продукта.
