Автор: Рикард Эдгрен (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) Оригинал статьи Перевод: Ольга Алифанова
В ходе этого цикла статей мы ищем альтернативу подходам к тестированию, основанным на артефактах – а именно, подход, основанный на деятельности.
В предыдущей части мы разбирали вид сценарного тестирования, используя одностраничные руководства, направляющие тестировщика в ходе сессии. Одностраничный документ заменяет явные, формальные, процедурные тест-кейсы темой и набором тест-идей, общих указаний или чеклистом. Чартер помогает в какой-то степени направить тестировщика, однако тестировщик сохраняет контроль над своей работой. У него есть достаточная свобода, чтобы принимать собственные решения на каждом этапе.
Это первая часть мини-серии статей о тестировании в реальной жизни. Цель этих статей – поделиться практической информацией о тестировании на основе реальных живых примеров. Идея цикла зародилась, когда я заметила, что множество известных мне ресурсов по большей части концентрируются на теории или на развитии существующего опыта, однако материалов о том, как это на самом деле делается в реальной жизни (и с чего начать), немного. Моя мини-серия основана на свежем опыте помощи в первичном тестировании мобильного приложения– это и будет примером тестирования в реальной жизни.
Всем привет! Если вы читаете эту статью, значит вам интересен мир тестирования: вы могли что-то слышать от друзей про профессию “тестировщик”, могли читать статьи или какие-то книги.
Уверена, вы хотели бы попробовать себя в новой роли, найти первую работу в тестировании, но у вас куча сомнений — ”у меня нет профильного образования, я — не программист, я не потяну”. Почему я в этом уверена — потому что сама прошла довольно долгий путь преодоления собственных страхов и сомнений, потому что студенты моих курсов приходят именно с такими страхами и неуверенностью в собственных силах.
В своей статье я расскажу, какими знаниями и умениями необходимо обладать, где их можно получить, как подготовиться и пройти собеседование на позицию “младший тестировщик” и устроиться на свою первую работу!
Какими навыками должен обладать начинающий специалист по тестированию, и где эти навыки получить?
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Автоматизировать CRUD-тестирование можно несколькими способами. Как минимум нужно проверить по одной операции из каждого раздела: создание, чтение, обновление и удаление. Для удобства давайте предположим, что:
Мы тестируем простое текстовое поле, которое использовали раньше.
Мы автоматизируем на уровне UI (автоматизацию API я буду обсуждать в других статьях).
