Home

Оригинальная публикация

Привет! Я Екатерина Васильева, инженер-тестировщик ГК «Солар». В нашей работе есть извечный вопрос, как сделать тестирование быстрым, качественным и эффективным. И знаете, что помогает? Правильная организация процесса. В «Соларе», например, мы активно используем концепции DoR (Definition of Ready) и DoD (Definition of Done) при тестировании продуктов. Эти критерии, хоть и встречаются чаще в разработке, оказались невероятно полезны и для нас, тестировщиков. Они помогают четко понимать, когда задача готова к тестированию, а когда уже можно выдохнуть и сказать: «Готово!». В итоге — никаких срывов сроков и релизы день в день. В этой статье я расскажу на примере Solar webProxy, как DoD и DoR помогают нам повысить качество тестирования и с какими трудностями мы столкнулись, внедряя эти критерии.

Опубликован выпуск рассылки за октябрь.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

Давным-давно я обещала рассказать о документации, которую я создаю и использую в ходе тестирования. С тех пор я перешла в другую компанию, что, конечно, повлекло риск, что создаваемая и используемая мной документация изменится, адаптируясь под нужды нового руководства, его клиентов и их подходов к работе. Однако я сейчас много читаю о сессионном тест-менеджменте (намереваясь попробовать свои силы в более структурированном исследовательском тестировании и связанных с этим сессионных отчетах), и я снова вернулась к этой теме.

Если конкретнее, я читала статью Пола Карвальо, где он упоминал про тест-руководства; эта идея, как мне кажется, схожа с документами, с которыми я постоянно работаю.

Так как я долго собиралась написать эту статью, не буду тратить на нее много времени. Однако мне хочется поделиться информацией, потому что я никогда не видела похожих шаблонов (помимо описанного Полом), и мне хочется не забыть, откуда все пошло, пока я пишу. Эта статья – мой способ поразмышлять, узнать что-то новое и вырасти над собой, поэтому хотелось бы вернуться к ней в будущем и посмотреть, что и как изменилось.

Автор: Пронин Дмитрий, Иви (AQA-lead клиентского тестирования)

Привет! Мы в онлайн-кинотеатре Иви любим писать автотесты, особенно клиентские (Потому-что клиентские приложения - это первое, а иногда и единственное, что видят наши пользователи). У нас 4 основных платформы - Android, Web, Smarttv, iOS (Android и iOS - еще подразделяются на мобильную и tv версии).

И немного про сами автотесты. В основном все они интеграционные. Мы используем почти полные копии бэка, автоматически разворачиваемые в k8s (об этом как-нибудь потом). Общее количество  стремится к 7 тысячам, а среднее количество на одну платформу - к полутора. Особенность всей этой конструкции состоит в том, что мы максимально стремимся к использованию нативных фреймворков или к использованию того стэка, который лучше всего подойдет для поддержки проекта. Это заставляет агрессивно выделять общий функционал, избавляться от копипасты и держать архитектуру и подходы как можно более похожими от проекта к проекту.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Загляните в свежий Интернет, и вы, скорее всего, найдете Еще Одну Статью про Регрессионное Тестирование, утверждающую, что регрессионное тестирование нужно автоматизировать, потому что это механическая повторяющаяся деятельность.

То, что механистическая проверка результата работы функций снова и снова – это механическая повторяющаяся деятельность, абсолютно верно, но это тавтология, чересчур упрощающая регрессионное тестирование. Что еще хуже, она может заставить нас чересчур упрощать наши представления о том, что должно произойти, и какие навыки нужно применить. Посмотрим, сможем ли мы улучшить эти представления.

Автор: Ekaterina Noga, оригинальная публикация

Работая QA часто слышала в голове голос «а точно ли все проверила?» и иногда он бывает полезен, но если не научиться голос использовать и затыкать, то он начинает вредить. Ниже я расскажу об этом тревожном таракане и о том, как он проявляется.

Во время работы возникает много ситуаций, которые дают каждому уникальный опыт. В этой статье я хочу поделится своим опытом и теми знаниями, которые из него получила. Надеюсь мои слова окажутся в какой‑то степени полезными. В любом случае буду рада комментариям и надеюсь, что они помогут мне увидеть себя со стороны и стать лучше.

Автор: Филипе Фрайр (Filipe Freire)
Оригинал статьи
Перевод: Ольга Алифанова

Во втором эпизоде обзора инструментов, а также в моей пародии про нагрузочное тестирование «Как быстро разбогатеть», я упоминал, как активно продавцы коммерческих инструментов нагрузочного тестирования употребляют нагрузочную терминологию, искажая ее, чтобы попытаться обдурить потенциальных покупателей. Крупнейшее искажение – это хищнические и (почти) криминальные схемы, основанные на описании, как «виртуальные пользователи» и схожие концепции продаются и описываются для тех, кто отвечает за затраты на нагрузочное тестирование.

Меня зовут Юрий Заковряшин. Я занимаюсь разработкой ПО более 40 лет, преподаю курсы по технологиям разработки программного обеспечения и программированию на платформе Java в СПбПУ Петра Великого.

В этой статье я расскажу о некоторых приемах в разработке тестов, которые позволяют на практике избежать серьезных пробелов в тестировании качественных характеристик программных систем. Статья предназначена для начинающих тестовых инженеров, но может быть полезной и более опытным разработчикам.