Читая статьи на тему web-тестирования, вырисовываются условно две темы: 1) ручное тестирование вымирает, автотесты (здесь и далее под автотестами имеются в виду Selenium UI и REST-тесты) – наше все; 2) автоматическое тестирование – не панацея, без ручного тестирования не обойтись. При этом из статей намечается тенденция на рост требований к качеству программного обеспечения и скорости развития продукта. Wrike — это как раз тот случай, когда эти требования критически важны.
Продукту уже 12 лет, но он до сих пор активно разрастается. Деплои происходят раз в день, а иногда и два. Поэтому нам критически важно, чтобы регрессия проводилась исключительно на автотестах. Однако в Wrike (в компании) свыше 30-ти scrum-команд, а штат команды автоматизаторов не резиновый. В таких условиях ожидать автоматизации ручных сценариев в лучшем случае один-два спринта – не вариант. Опыт нашей компании говорит, что ручной тестировщик может самостоятельно писать автотесты, при соблюдении некоторых нюансов. В статье расскажу о них и почему, на мой взгляд, это умение не только помогает соответствовать тенденциям, но и будет полезно для самого тестировщика.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
В ходе этого цикла статей мы ищем альтернативу подходам к тестированию, основанным на артефактах – а именно, подход, основанный на деятельности.
В предыдущей части мы разбирали вид сценарного тестирования, используя одностраничные руководства, направляющие тестировщика в ходе сессии. Одностраничный документ заменяет явные, формальные, процедурные тест-кейсы темой и набором тест-идей, общих указаний или чеклистом. Чартер помогает в какой-то степени направить тестировщика, однако тестировщик сохраняет контроль над своей работой. У него есть достаточная свобода, чтобы принимать собственные решения на каждом этапе.
Это первая часть мини-серии статей о тестировании в реальной жизни. Цель этих статей – поделиться практической информацией о тестировании на основе реальных живых примеров. Идея цикла зародилась, когда я заметила, что множество известных мне ресурсов по большей части концентрируются на теории или на развитии существующего опыта, однако материалов о том, как это на самом деле делается в реальной жизни (и с чего начать), немного. Моя мини-серия основана на свежем опыте помощи в первичном тестировании мобильного приложения– это и будет примером тестирования в реальной жизни.
Всем привет! Если вы читаете эту статью, значит вам интересен мир тестирования: вы могли что-то слышать от друзей про профессию “тестировщик”, могли читать статьи или какие-то книги.
Уверена, вы хотели бы попробовать себя в новой роли, найти первую работу в тестировании, но у вас куча сомнений — ”у меня нет профильного образования, я — не программист, я не потяну”. Почему я в этом уверена — потому что сама прошла довольно долгий путь преодоления собственных страхов и сомнений, потому что студенты моих курсов приходят именно с такими страхами и неуверенностью в собственных силах.
В своей статье я расскажу, какими знаниями и умениями необходимо обладать, где их можно получить, как подготовиться и пройти собеседование на позицию “младший тестировщик” и устроиться на свою первую работу!
Какими навыками должен обладать начинающий специалист по тестированию, и где эти навыки получить?
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Автоматизировать CRUD-тестирование можно несколькими способами. Как минимум нужно проверить по одной операции из каждого раздела: создание, чтение, обновление и удаление. Для удобства давайте предположим, что:
Мы тестируем простое текстовое поле, которое использовали раньше.
Мы автоматизируем на уровне UI (автоматизацию API я буду обсуждать в других статьях).
Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.
Автор: Джеймс Бах (James Bach) Оригинал статьи Перевод: Ольга Алифанова
Алекс Бунарджич задал мне вопрос, который вдохновил меня на целую статью:
"Я считаю (и я убежден, что вы найдете способ убедить меня, что я в корне неправ), что если человек намерен улучшить качество, поддерживая высокие этические стандарты, то имеет смысл прищучить проблему в зародыше – или, как минимум, как можно ближе к источнику. Тестирование, как я понимаю, не связано с производством качества, и, следовательно, находится ниже по течению. Оно, конечно, тоже очень важно, но определенным образом смахивает на борьбу с ветряными мельницами. Неужели вам не хочется направить свои выдающиеся интеллектуальные качества на деятельность, связанную с производством качества? Я убежден, что если бы вы стали разработчиком или архитектором ПО, вы были бы не менее успешны и влиятельны, и, возможно, имели бы больший охват аудитории".
Несмотря на колоссальные возможности современных табличных редакторов, для многих команд разработки рано или поздно встает вопрос о внедрении специализированных инструментов (систем) для управления процессом тестирования в своих проектах. Какой же из них выбрать?
Такой вопрос в моей практике задавался не раз. Это подтолкнуло меня на создание этой обзорной статьи. Чтобы в будущем сэкономить немного времени себе и всем тем, кто также столкнется с этим вопросом. И пусть даже в конце статьи на него не будет ответа (извините за спойлер), но ваше подсознание, скорее всего, определится уже сейчас и в нужный момент на определенном проекте подскажет ответ.
В своих поисках я натыкался на множество аналогичных статей (в одной из которых я позаимствовал структуру сравнительной таблицы), но все они скупо перечисляют функции с сайтов этих систем и 1-2 скриншота интерфейса и зачастую содержат скрытую или открытую рекламу одного из таких инструментов. Мне же захотелось испытать каждую систему “на себе” и непредвзято поделиться увиденным, рассказать о своих ощущениях.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
В прошлый раз мы начали разбираться с тестированием CRUD. Как вы помните, CRUD означает "Create, Read, Update, Delete" (создание, чтение, обновление и удаление). В прошлый раз мы обсуждали тестирование создания и чтения, а теперь рассмотрим обновление и удаление.
Обсуждая операцию чтения, я упоминала, как важно тестировать сценарии, при которых данные в базе неверны. Это верно и для операции обновления. Только то, что текстовое поле предполагается обязательным и должно разрешать определенное количество символов, не означает, что именно так работает ваша база данных!
