13.07.2017 16:04 |
Автор: ведущий инженер по тестированию компании "Лаборатория качества" Юлия Бурматова Оригинал статьи: http://quality-lab.ru/transforming-chaos-into-order/

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

Автор: Клэр Рэклесс (Claire Reckless)
Оригинал статьи: https://dojo.ministryoftesting.com/lessons/so-what-is-software-testing
Перевод: Ольга Алифанова
Если бы вам пришлось ответить на вопрос "Что такое тестирование?", что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений.
Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет.
Из чего состоит тестирование
Расследование
Расследование определяется как "наблюдение или изучение путем близкого наблюдения и систематического изучения" [1].
Процесс тестирования должен быть расследованием. Мы не всегда знаем, что получим на выходе, но наша задача – выяснить информацию, которая поможет людям принимать решения. Это не просто сравнение работы системы со спецификацией, где прописан ожидаемый результат. Мы должны мыслить критически, задавать сложные вопросы, рисковать, подмечать то, что на первый взгляд кажется несущественным, а при тщательном анализе оказывается важным и требующим дальнейшего изучения. |
Подробнее...
|
12.07.2017 09:17 |
Оригинал публикации:
http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727 Большинство занимающихся тестированием хоть раз испытывали желание нажать «волшебную» кнопку и смотреть, как программа все делает сама. Все любят автоматизацию. Это быстро, надежно, позволяет оптимально использовать ресурсы за счет работы ночью и не требует вмешательства человека. Казалось бы, наконец найдено решение проблемы эффективности. Но так ли все происходит на самом деле? Ожидание №1: Можно тратить время на изучение фреймворка и тест-кейсов при автоматизации нового приложения. Реальность: Автоматизация занимает много времени, денег и, самое главное, терпения. Написание скрипта автоматизации требует от тестировщика знания сферы деятельности, автоматизации тест-кейсов и возможности выбрать соответствующий фреймворк. Автоматизация, как и разработка приложений, нуждается в тестировании. Скрипты, написанные с помощью автоматизации, необходимо тщательно проверить, используя все тестовые данные и негативное тестирование. Инструмент, не прошедший такое тестирование, приводит к ошибкам в скрипте во время работы. |
Подробнее...
|
|
11.07.2017 16:28 |
Порекомендуй своим иностранным коллегам англоязычный курс Software-Testing.Ru по Selenium и получи 10% от его стоимости на свое обучение.
1. Коллега, пришедший по вашей рекомендации, получит скидку 10%. 2. Вы получите на свой счет 10% от стоимости курса сразу после оплаты вашим коллегой. Эту сумму вы сможете использовать при покупке любого тренинга из нашего расписания.
При оплате, пожалуйста, попросите коллегу указать ваши имя, фамилию и эл.адрес.
|
11.07.2017 10:06 |
Вышел выпуск рассылки за конец июня, его содержание доступно по ссылке.
Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.
Подписаться на рассылку можно по ссылке. |
10.07.2017 09:48 |
Оригинал статьи: https://dojo.ministryoftesting.com/lessons/getting-started-with-cross-browser-testing
Автор: Алекс Лэнгшалл (Alex Langshall)
Перевод: Ольга Алифанова.
Вы, как тестировщик, получили на тестирование юзер-стори, и ответственный за нее разработчик попросил вас провести кросс-браузерное тестирование. Что это значит? Зачем тестировать юзер-стори в разных браузерах? Какие браузеры выбрать для тестирования? На что обращать внимание в процессе?
Тестировщики должны задавать эти вопросы и себе, и другим заинтересованным лицам, если для юзер-стори или проекта требуется тестировать в различных браузерах. Детально проанализировать поведение приложения тяжело даже в одном браузере, не говоря уже о всем многообразии браузеров, которое может поддерживаться вашим приложением. Давайте разберем эти вопросы детальнее и рассмотрим возможные пути решения, которые сделают ваше кросс-браузерное тестирование успешным.
Определение кросс-браузерного тестирования
Кросс-браузерное тестирование – это тестирование фичи в различных релевантных приложению браузерах. Это важная часть тестирования: несмотря на существование веб-стандартов, разные браузеры внедряют их различным образом. На глубоком уровне разные элементы страницы ведут себя по-разному в разных браузерах. Поведение фичи в Safari, к примеру, может сильно отличаться от ее работы в Chrome.
Если есть вероятность функциональных или косметических отличий в поведении системы в разных браузерах, без кросс-браузерного тестирования просто не обойтись. Оно должно проводиться для каждого аспекта удобства использования, отображения или функциональности, разрабатываемого вашей командой.
Кросс-браузерное тестирование удостоверяет, что пользовательский опыт будет единым вне зависимости от браузера. Неважно, новый это код или уже существующая фича: приложение должно единообразно работать в разных браузерах. Оставим за кадром споры об "ужасном Internet Explorer": многие пользователи вынуждены пользоваться браузером, предоставленным им на работе, в школе, или выбранным из-за определенных характеристик другого ПО. Все они заслуживают того, чтобы их нужды принимались во внимание вне зависимости от того, насколько хорошим или плохим вы считаете выбранный ими браузер. |
Подробнее...
|
07.07.2017 09:29 |
Автор: ведущий специалист по тестированию компании "Лаборатория качества" Виктория Юркевич Оригинальная публикация: http://quality-lab.ru/questions-to-ask-testers-at-a-job-interview/ Популярный в свое время лозунг «Кадры решают все!» актуален сейчас как никогда. И это неудивительно. Ранее в нашем блоге уже говорилось о том, сколько тестировщиков нужно проекту. В данной статье я приведу алгоритм, позволяющий оптимально прособеседовать кандидатов при подборе и получить ответы на важные для дальнейшей совместной работы вопросы.
В каждом проекте существует определенный список требований к тестировщикам. Все хотят, чтобы команда состояла из опытных активных супер-специалистов широкого профиля (и конечно, с минимальными финансовыми запросами). Давайте все-таки будем реалистами! Для многих руководителей процесс собеседования кажется достаточно простым и сводится к одному – определить, подходит ли кандидат на должность.
Безусловно, это самая важная задача, но помимо нее есть и другие: оставить положительное впечатление о компании у того, кто по каким-то причинам не подошел; мотивировать классного специалиста на работу; оценить предполагаемого кандидата с точки зрения его личных достоинств, навыков и потенциала. Как правило, все это нужно успеть сделать в процессе одного интервью.
В этой статье вы не найдете перечней технического характера или вопросов на проверку логики и склада ума подбираемых тестировщиков. Я постараюсь составить алгоритм, который поможет вам учесть самую важную вещь: как найти не только специалиста, но и человека команды (то есть, человека, способного вписаться в команду и быть продуктивным не только за счет своего профессионального опыта, но и за счет личных качеств и особенностей). |
Подробнее...
|
06.07.2017 08:08 |

Оригинальная публикация: https://habrahabr.ru/company/yamoney/blog/329926/#radius-porazheniya Однажды наша команда решилась на эксперимент по расстрелу боевой платежной системы реальными деньгами. Это позволило бы понять, сколько сможем выдержать мы вместе с нашими партнерами. Об этом неоднозначном опыте и хочу рассказать.
К исследованию побудили два фактора: появление у нас собственного процессинга карт и предстоящая крупная распродажа одного из популярных в РФ онлайн-ритейлеров.
Идея выглядела вполне бюджетной – примерно на 125 000 р. (по 1 р. на операцию), но кто же знал, как все обернется. Особая перчинка в том, что вся информация об эксперименте долгое время была закрыта и впервые публикуется в открытом источнике.
Как оказалось, мы не одиноки – ни один из наших банков-партнеров еще полгода назад не знал своего настоящего «потолка» и решал проблемы по мере поступления. По сути, они просто добавляли новые мощности прямо во время распродаж, хотя и не всегда успешно. Будущие жертвы Система карточных платежей (Mastercard в нашем случае) соединяет между собой множество внешних организаций, у каждой из которых свой зоопарк систем. Под нагрузку карточных платежей попадают практически все они, поэтому сразу посмотрим на всех участников. Ниже представлена упрощенная схема взаимодействия нескольких организаций для обеспечения возможности оплатить какой-то товар картой через сервис Яндекс.Денег: |
Подробнее...
|
05.07.2017 09:53 |
Оригинал статьи: http://testdetective.com/performance-testing-tutorial/
Автор: Лукас Розуонек (Łukasz Rosłonek)
Перевод: Ольга Алифанова
Я заметил, что большинство тестировщиков слабо знакомо с такой областью, как тестирование производительности. В основном мы концентрируем усилия на функциональных аспектах тестирования, оставляя тестирование производительности, масштабируемости и настройки на откуп разработчикам. Но ведь стабильность – важная часть качества продукта, особенно в эпоху распределенных сетей, когда приложения масштабируются независимо и опираются на интеграцию через HTTP-протоколы. Другой аспект качества – способность увеличивать масштаб наших систем. Для того, чтобы справиться с ростом трафика, нужно знать пропускную способность ПО.
Инженеры хорошо знакомы с такими инструментами, как JMeter, Gatling, Tsung. Они относительно просты в использовании, но люди зачастую плохо разбираются в анализе выданных ими результатов, и не умеют делать выводы на их основании. Собеседуя кандидатов на должность тест-инженера, я часто встречаю людей, утверждающих, что они имеют опыт тестирования производительности, но не владеющих знаниями о метриках этого вида тестирования, а также о его элементарных положениях. Основная цель нагрузочного тестирования и тестирования производительности – не умение обращаться с соответствующими инструментами, а знания, полученные в результате их использования. Цель этой статьи – осветить основные аспекты этой области.
|
Подробнее...
|
03.07.2017 16:34 |
Автор: Сергей Бронников Оригинальная публикация: https://bronevichok.ru/ Каждый раз, когда я встречаюсь с проектом, в котором без причины изобрели свой новый формат отчётов мне хочется сделать что-то ещё для популяризации существующих форматов. За последнее время таких случаев было несколько. В первый раз я добавил поддержку подсветки синтаксиса TAP в библиотеку highlight.js, потом добавил поддержку синтаксиса формата SubUnit. Ну и в последний раз после встречи с одним из таких проектов я собрал воедино всю информацию по этим форматам в одном месте и получилась небольшая книжка. Таким образом этот текст -- мой крестовый поход против разножопицы с тестовыми результатами в разработке ПО :) В наше время ни один серьёзный программный проект не обходится без тестирования. Тестирование может быть ручное и автоматизированное, компонентное и системное, регулярное и не очень, но оно должно быть. А если тестирование регулярное, то вместе с ним появляются отчёты о результатах тестирования. И чем больше ваш проект, тем больше у вас данных о проведенном тестировании. В современных проектах темпах темп разработки ПО настолько высокий, что некоторые продукты успевают релизиться несколько раз в неделю, а некоторые и несколько раз в день. При правильном подходе отчёты о тестировании могут принести много пользы при разработке. Из этой статьи вы узнаете какая польза от отчётов о результатах тестирования, какие форматы отчётов существуют и как навести порядок с хранением и анализом таких отчётов в вашем проекте. |
Подробнее...
|
03.07.2017 09:59 |
Автор: Стив Кросс (Steven Cross)
Оригинал статьи: https://stevencrossblog.wordpress.com/2016/12/02/curiosity-killed-the-tester/
Перевод: Ольга Алифанова.
Итак, тестирование! Все мы его любим. Я точно знаю – мои друзья-приятели его обожают. Мы его понимаем, мы постоянно учимся новому, мы пытаемся улучшить свои подходы и методы, читаем книги, ходим на семинары и конференции… и я могу продолжать до бесконечности. Мы стремимся сделать мир лучше.
В наши дни (конечно, это громко сказано и очень зависит от контекста) конкретный набор требований, четко определенный список приемочных критериев и непротиворечивое, полное понимание, как же приложение должно себя вести – это нечто из мира розовых пони.
Возможно, это правда, но даже если нет, тестировщики не должны бояться задавать вопросы. Когда я сам начинал, в наши головы буквально вдалбливали, что тестировщик никогда не додумывает. Однако это не оправдание для того, чтобы отключить свой здравый смысл, конечно.
В ушах коллектива нынче набатным колоколом звучит манифест Agile, и личности и взаимодействия между ними находятся в центре внимания. Разговаривайте с людьми. Разговаривайте с собой (попытайтесь только не свихнуться). Встаньте из-за этого вашего залитого кофе стола и поболтайте с коллегой. Спросите его о чем-нибудь. Поработайте над чем-нибудь. Те, кто помнит Боба Хоскинса, помнят его знаменитую фразу "Разговаривать – это хорошо". |
Подробнее...
|
|
|