Четыре из пяти соискателей-QA хотят научиться работать с автотестами. Не все компании могут осуществить такие желания ручных тестировщиков в рабочее время. Wrike провёл школу автоматизации для сотрудников и реализовал это желание для многих. Я в этой школе участвовал именно как ученик-QA.
Я научился работе с Selenium и сейчас самостоятельно поддерживаю определённое количество автотестов практически без помощи извне. И, по итогам нашего совместного опыта и моих личных выводов, я постараюсь вывести ту самую формулу как можно более идеальной школы автоматизации.
Добро пожаловать в финальную часть цикла статей о взаимоотношениях между тестированием и продуктовыми рисками. В первой части я обсуждал, почему говорить о тестировании продуктовых рисков лучше, нежели о типах тестирования. Во второй части мы говорили о выявлении продуктовых рисков путем тестирования, и я опубликовал модель своего подхода.
В этой, третьей и последней части я собираюсь рассказать о проактивном и реактивном качестве, предотвращении и обнаружении багов. О тестировании до и после того, как создан код, и о том, как выявленные риски и переменные могут помочь лучше проектировать тесты, чтобы снизить эти риски. Я также покажу ряд моделей, чтобы пояснить различные петли обратной связи во время тестирования.
В пятницу 13 декабря, менее чем через две недели, состоится Международная онлайн конференция по тестированию QAZDay 2019.
Ежегодные конференции QAZDay - это:
авторские онлайн мастер-классы
доклады только от спикеров-практиков
2000+ удаленных участников
13 декабря – 4+ потока, более 40 докладов.
✔ Этой зимой нашу конференцию посетит Lokesh Sangewar (Mixed QA specialist; Pune, India) и расскажет в сжатом сверх структурированном виде о том что, когда и как Автоматизировать, озвучит вопросы объемов и приоритетов в докладе “Automation – How to succeed, what to watch out for”.
✔ Из Санкт-Петербурга приедут поделиться опытом Таисия Толстунова (QA manager, член ПК множества конференций, люблю аналитиков и требования. Предпочитаю людей компьютеру, хоть и интроверт. В тестировании больше 12 лет.) с докладом «База знаний в компании» и Анастасия Заречнева(Страстная охотница за багами в web. Люблю все оптимизировать, дружу с автотестами и с людьми, поэтому руковожу отделом и пишу плохой код в свободное время. Участник международных QA конференций.) с докладом «Грабли вхождения в Автоматизацию тестирования».
✔ Mixed QA Lead Станислав Бадов (г. Минск, Беларусь) в своем докладе "Зачем мы тестируем? Или как понять, что мы организовали это правильно" поделится опытом планирования тестов, поиска и постановки верных приоритетов, выстраивание совместной работы команды с клиентом, важную роль тестовой стратегии и жизненно необходимых метрик определения качества на примере работы в России, Швейцарии, Бельгии и Беларуси. Стас более 10 лет в IT, 6 лет в функциональном тестировании, управлении тестированием и построении процессов в телекоммуникационном домене OSS и BSS систем на больших проектах в Швейцарии и Бельгии. Руководил он-сайт процессами подключения и тестирования новых интеграции в проекте BSS трансформации в пределах 60 систем. Занимается переходом сотрудников от функционального тестирования в автоматизацию, трансформацией в Mixed QA специалиста.
✔ И еще много интересных докладов. Можете убедиться.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал Перевод: Ольга Алифанова
Мы начинаем публиковать перевод книги Рикарда Эдгрена "Записная книжка тест-дизайнера". В первой главе книги он говорит о теоретической основе тест-дизайна, его научной базе и особенностях пространства тестирования.
Эта книга описывает способы извлечения пользы из множества источников информации, необходимых для энергичного системного тестирования.
Я начал разбираться в этом вопросе глубже, когда в сто пятый раз ощутил, что существующие техники тест-дизайна не отражают мой подход после десятилетней работы с одним и тем же набором продуктов. Это вылилось в расширенную генерализацию идей, о которых я узнал благодаря коллегам (я учился у всех своих коллег, но особенно у Хенрика Эмилссона и Мартина Янссона. Библиография отражает наиболее важные моменты. Хочется также поблагодарить рецензентов, которые потратили свое время на то, чтобы сделать ценные замечания: это Роберт Бергквист, Лиза Криспин и Мэтью Хоссер).
Я собираюсь описать комплексное слияние тест-стратегии, тест-анализа, тест-дизайна и выполнения тестов – задачи, которые теоретически можно разделять, но на практике они переплетены. Книга не рассказывает о деталях отдельных тест-кейсов – тест-дизайн может выражаться в однострочных записях, чартерах или ментальной модели в вашей голове. Я пишу о том, как справиться со сложностями продукта, развивать навыки и обучаться по ходу дела.
Я хочу сделать упор на результатах тестирования, на широкой выборке, делающей возможными озарения (концепция "озарения" набирает популярность в тестировании, впервые, насколько я знаю, об этом написал Джонатан-Бах в статье Session-Based Test Management – журнал "Software Testing and Quality Engineering", 11/00, см. также Rikard Edgren, Testing is an Island, A Software Testing Dystopia, EuroSTAR conference 2008) и нацеленной на полноценное освещение важных областей (об освещении областей см. Rikard Edgren, Is your testing saturated?). Возможно, книга лучше всего подойдет ручным тестировщикам, которые концентрируются на важных проблемах – людям, которые хотят выяснить важную информацию, а не удовлетворяются соответствием или несоответствием требованиям.
Книга рассказывает про методы тест-дизайна, которые долгое время применяются как мной, так и многими другими тестировщиками (о работе тестировщика написано много статей, но Фиона Чарльз затронула основные моменты в статье Modeling Scenarios using Data).
Недавно я сменил проект — пришел в новую разработку, где до меня не было никакого тестирования, ни ручного, ни автоматического. Условий на инструментарий (за исключением того, что это Python) заказчик не накладывал, так что я сделал собственный выбор. В этой статье я расскажу, почему в таких условиях предпочел Robot Framework. А в конце будет немного специально написанных под статью примеров, иллюстрирующих, о чем речь.
Автоматизацией тестирования я занимаюсь уже более 10 лет, а с Robot Framework взаимодействовал порядка трех из них.
Как я отметил выше, не так давно я пришел на новый проект, где начал автоматизацию тестирования с нуля. Подробностей о проекте рассказать не могу — NDA. Отмечу лишь, что это крутой инструмент автоматизации, который в перспективе должен сэкономить массу человеческих ресурсов. Построен он из микросервисов. Пока что моя работа касается четырех из них, но в будущем я расширю свою деятельность и на другие — все упирается в то, что у меня лишь 8 рабочих часов в сутки. На все нужно время.
Отсутствие тестирования в случае этого проекта было тождественно отсутствию рекомендуемого инструментария. В рамках стека Python у меня была свобода выбора. И я ей воспользовался.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую мы можем протестировать. Почему? Потому что текстовые поля дают доступ к приложению и его базе данных. Валидация текстового поля – это то, что предотвращает появление в базе плохих данных. Эти данные могут вызвать разнообразные проблемы для пользователей и разработчиков. Валидация также предотвращает атаки межсайтового скриптинга и SQL-инъекции.
Читая статьи на тему web-тестирования, вырисовываются условно две темы: 1) ручное тестирование вымирает, автотесты (здесь и далее под автотестами имеются в виду Selenium UI и REST-тесты) – наше все; 2) автоматическое тестирование – не панацея, без ручного тестирования не обойтись. При этом из статей намечается тенденция на рост требований к качеству программного обеспечения и скорости развития продукта. Wrike — это как раз тот случай, когда эти требования критически важны.
Продукту уже 12 лет, но он до сих пор активно разрастается. Деплои происходят раз в день, а иногда и два. Поэтому нам критически важно, чтобы регрессия проводилась исключительно на автотестах. Однако в Wrike (в компании) свыше 30-ти scrum-команд, а штат команды автоматизаторов не резиновый. В таких условиях ожидать автоматизации ручных сценариев в лучшем случае один-два спринта – не вариант. Опыт нашей компании говорит, что ручной тестировщик может самостоятельно писать автотесты, при соблюдении некоторых нюансов. В статье расскажу о них и почему, на мой взгляд, это умение не только помогает соответствовать тенденциям, но и будет полезно для самого тестировщика.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
В ходе этого цикла статей мы ищем альтернативу подходам к тестированию, основанным на артефактах – а именно, подход, основанный на деятельности.
В предыдущей части мы разбирали вид сценарного тестирования, используя одностраничные руководства, направляющие тестировщика в ходе сессии. Одностраничный документ заменяет явные, формальные, процедурные тест-кейсы темой и набором тест-идей, общих указаний или чеклистом. Чартер помогает в какой-то степени направить тестировщика, однако тестировщик сохраняет контроль над своей работой. У него есть достаточная свобода, чтобы принимать собственные решения на каждом этапе.
