Когда вы договорились о том, что хотите автоматизировать, следующий шаг – это выбор подходящего инструмента. Я, как тестировщик, наблюдала разговоры об этом со стороны, когда менеджеры и люди, выбирающие инструмент, обсуждали ровно один фактор.
Он уже прошел обкатку, собрал разнообразные отзывы. Тренер Ольга Назина рассказала в своем блоге о том, как строился курс, в чем его особенность, что студентам нравится, а что нет.
Представьте, что перед Вами поставили задачу: протестировать API веб-сервиса. На этом этапе возникает довольно много вопросов, начиная от “Что именно требуется протестировать? Функционал? Нагрузку? Юзабилити?” до “Чем отличается список проверок для тестирования API от чек-листа для проверки UI”? В данной статье я поделюсь своим опытом составления проверок и кейсов для функционального тестирования SOAP API крупного государственного проекта со сложной логикой; мы обсудим, как лучше писать проверки и на что следует обратить особое внимание; в конце я представлю примерный вид документа с результатами тест-дизайна, которым будет удобно пользоваться и который не стыдно показать менеджеру или заказчику.
Желаем вам найти сотни важных багов и не дать им проскользнуть в релиз, изучить новые технологии и инструменты, покорить сложнейшие проекты и стать образцом для подражания!
Начинающие тестировщики – желаем успешно найти отличную работу и быстро стать мастерами своего дела!
Тест-аналитики – пусть документация будет внятной, а заказчики – отзывчивыми!
Автоматизаторы – чистого вам кода и надежного инструментария!
Тест-менеджеры – пусть ваша команда всегда работает, как часы!
С наступающим Новым Годом и Рождеством, наше любимое сообщество! Есть ли у вас профессиональные планы и цели на Новый Год? Поделитесь на форуме, и все новогодние обещания обязательно исполнятся!
Мы подготовили для вас вредные советы – постарайтесь не следовать им в наступающем году, и тогда все ваши профессиональные мечты обязательно сбудутся!
Публикуем запись доклада Антонины Фанталиной "Автоматизация регресса бекендов. Без СМС и автотестов" с прошедшего в Новосибирске QA DevDay.
Тоня тестирует навигатор в 2ГИС. Проект объёмный, а имеющиеся unit-/функциональные/интеграционные тесты не всегда находят проблемы. В своём выступление Тоня рассказала, как проверить API на изменения с помощью diff-ответов от сервера, и поделилась муками выбора между Diffy, Karate и кастомным решением.
Тренер по тестированию Ольга Назина подготовила для читателей нашего портала новогодний подарок — подборку переводов исследовательских туров от James A. Whittaker из книги Exploratory Software testing!
Исследовательское тестирование — серьезная тема, провести его полноценно может только опытный тестировщик. Это ведь не просто «потыкать рандомно», все равно нужен план тестирования.
James A. Whittaker нашел способ проводить исследовательское тестирование даже начинающими тестировщиками. Он составил методику туров, которые может выполнить любой. Фактически каждый тур — это тот самый план, по которому мы будем тестировать. План, уже составленный за нас!
Если вы еще не пользовались методикой, обязательно попробуйте. А Ольга Назина подготовила подборку любимых туров, которые находят баги практически везде:
Сегодня мы рассмотрим POST-запросы. Они, пожалуй, наиболее важные из всех REST-запросов, потому что добавляют новые записи в базу данных приложения. Очень важно как следует их протестировать, потому что они напрямую влияют на качество данных вашей базы.
Усилия по тестированию прилагаются на различных уровнях автоматизации в приложении. Вот некоторые из них, которые я, согласно личному опыту, нахожу интересными:
Автоматизация на юнит-уровне – она редко касается кого-либо, кроме разработчиков, и я считаю, что это правильно. В норме цель юнит-тестов – это предоставление быстрой обратной связи о правильности работы кода. Конечно, они подвержены тем же болезням, что и автоматизация в целом – "утверждающе-демонстративному" образу мышления при создании тестов. Даже если тесты используются в методологии управления через тестирование, они не особенно полезны, если сообщают только о том, что продукт работает. Фактически любой тест, который не подвергает систему суровым испытаниям с целью выявления проблем – это просто показуха.
Тут важно помнить, что очень глупо полагать, что наличие юнит-тестов означает, что что-то вообще тестировалось, или же что нужда в других уровнях тестирования благодаря наличию юнит-тестов снизилась. Юнит-тесты просто сообщают, что наш код готов двигаться дальше по цепочке тестирования. Не больше, не меньше!
Вышел выпуск рассылки за первую половину декабря, его содержание доступно 
