Автор: ведущий инженер по тестированию компании "Лаборатория качества" Юлия Бурматова

Оригинал статьи: http://quality-lab.ru/transforming-chaos-into-order/

Проекты с идеальным порядком, к сожалению, встречаются крайне редко. Чаще всего мы сталкиваемся с хаосом разной степени беспорядочности: от «черт ногу сломит» до мелких проблем, лишь изредка дающих знать о себе (например, при появлении новых сотрудников). Но, закрывая глаза даже на совсем небольшие дефекты, мы все больше приближаемся к настоящему «апокалипсису», способному «убить» самые интересные и стабильные проекты. Все как в «теории разбитых окон»: чем чаще мы не замечаем проблемы – тем больше их становится, и тем прочнее они внедряются в нашу жизнь. Увы, по-другому не бывает.

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

Автор: Клэр Рэклесс (Claire Reckless)

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/so-what-is-software-testing

Перевод: Ольга Алифанова

Если бы вам пришлось ответить на вопрос "Что такое тестирование?", что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений.

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

Из чего состоит тестирование

Расследование

Расследование определяется как "наблюдение или изучение путем близкого наблюдения и систематического изучения" [1].

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

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

http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727

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

Ожидание №1: Можно тратить время на изучение фреймворка и тест-кейсов при автоматизации нового приложения.

Реальность: Автоматизация занимает много времени, денег и, самое главное, терпения. Написание скрипта автоматизации требует от тестировщика знания сферы деятельности, автоматизации тест-кейсов и возможности выбрать соответствующий фреймворк.

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

Порекомендуй своим иностранным коллегам англоязычный курс Software-Testing.Ru по Selenium и получи 10% от его стоимости на свое обучение.

1. Коллега, пришедший по вашей рекомендации, получит скидку 10%.
2. Вы получите на свой счет 10% от стоимости курса сразу после оплаты вашим коллегой. Эту сумму вы сможете использовать при покупке любого тренинга из нашего расписания.

При оплате, пожалуйста, попросите коллегу указать ваши имя, фамилию и эл.адрес.

Вышел выпуск рассылки за конец июня, его содержание доступно по ссылке.

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

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

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/getting-started-with-cross-browser-testing

Автор: Алекс Лэнгшалл (Alex Langshall)

Перевод: Ольга Алифанова.

Вы, как тестировщик, получили на тестирование юзер-стори, и ответственный за нее разработчик попросил вас провести кросс-браузерное тестирование. Что это значит? Зачем тестировать юзер-стори в разных браузерах? Какие браузеры выбрать для тестирования? На что обращать внимание в процессе?

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

Определение кросс-браузерного тестирования

Кросс-браузерное тестирование – это тестирование фичи в различных релевантных приложению браузерах. Это важная часть тестирования: несмотря на существование веб-стандартов, разные браузеры внедряют их различным образом. На глубоком уровне разные элементы страницы ведут себя по-разному в разных браузерах. Поведение фичи в Safari, к примеру, может сильно отличаться от ее работы в Chrome.

Если есть вероятность функциональных или косметических отличий в поведении системы в разных браузерах, без кросс-браузерного тестирования просто не обойтись. Оно должно проводиться для каждого аспекта удобства использования, отображения или функциональности, разрабатываемого вашей командой.

Кросс-браузерное тестирование удостоверяет, что пользовательский опыт будет единым вне зависимости от браузера. Неважно, новый это код или уже существующая фича: приложение должно единообразно работать в разных браузерах. Оставим за кадром споры об "ужасном Internet Explorer": многие пользователи вынуждены пользоваться браузером, предоставленным им на работе, в школе, или выбранным из-за определенных характеристик другого ПО. Все они заслуживают того, чтобы их нужды принимались во внимание вне зависимости от того, насколько хорошим или плохим вы считаете выбранный ими браузер.

Автор: ведущий специалист по тестированию компании "Лаборатория качества" Виктория Юркевич

Оригинальная публикация: http://quality-lab.ru/questions-to-ask-testers-at-a-job-interview/

Популярный в свое время лозунг «Кадры решают все!» актуален сейчас как никогда. И это неудивительно. Ранее в нашем блоге уже говорилось о том, сколько тестировщиков нужно проекту. В данной статье я приведу алгоритм, позволяющий оптимально прособеседовать кандидатов при подборе и получить ответы на важные для дальнейшей совместной работы вопросы.

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

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

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

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

https://habrahabr.ru/company/yamoney/blog/329926/#radius-porazheniya

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

К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.

Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.

Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно.

Будущие жертвы

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

Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег: