Home

29 мая в Санкт-Петербурге прошел #ITsubbotnik - встреча опытных специалистов, на которой эксперты ЕРАМ рассказывали о разработке и тестировании ПО. В потоке QA прозвучало 3 доклада, посвященных автоматизированному тестированию, и доклад на тему тестирования производительности.

Сергей Мишанин в докладе «Report Portal. Руководство для адептов Cucumber» рассказал, что такое EPAM Report Portal и почему его нужно использовать, также о том, как интегрировать его в тестовую систему на базе Cucumber, какие при этом есть подводные камни и как их можно обойти.

Роман Иовлев в докладе «Java edge in test automation» поведал про возможности Java 8, популярную библиотеку-плагин Lombok и мощный фреймворк для автоматизированного тестирования JDI.

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

Антон Шапин и Денис Клыков выступили с докладом «Visualization, storage and comparison results of performance testing», в котором отвечали на вопросы: как визуализировать результаты прохождения тестов, как сравнивать результаты разных тестовых прогонов, и где хранить результаты тестов.

Автор: Брэд Томпсон (Brad Thompson)

Оригинал статьи: http://thinktesting.com/articles/role-of-confidence-in-software-testing/

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

Уверенность: "Твёрдая вера в кого-что-н., убеждённость". (http://dic.academic.ru/)

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

Автор: Ярослав Хорошкин

Оригинальная публикация: http://quality-lab.ru/experience-with-using-scrumban-in-testing/

За последние 20 лет Agile, Lean, Scrum и Kanban неуклонно завоевывают популярность в различных сферах и отраслях экономики. И это правильно, так как именно благодаря гибким технологиям многие компании смогли закончить свои проекты быстрее и\или увеличить прибыль. 

Но что же такое Agile и Lean? Что такое Scrum и Kanban? Чем они хороши, и какая между ними разница? И самое главное: как все это работает в сфере тестирования? В данной статье я постараюсь ответить на эти вопросы.

Подводим итоги опроса по зарплатам в тестировании в 2017 году.

Всего в опросе приняло участие около 1500 человек.

Ниже вы найдете зарплатные диаграммы по городам за 2017 и 2016 годы. По горизонтали шкала зарплат, по вертикали количество проголосовавших, получающих зарплату в этом диапазоне. Цветом выделен опыт работы (расшифровка справа на картинке).

Москва, 2017г.

Кликните на картинку, чтобы увеличить изображение

Оригинальная публикация: https://habrahabr.ru/company/pvs-studio/blog/330762/

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

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

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

Поговорим о деньгах, потерянных из-за ошибок в программном обеспечении, и росте нашей зависимости от программного кода. Тема неоднократно обсуждаемая (в том числе моим коллегой — Андреем Карповым — "Большой Калькулятор выходит из-под контроля"), и каждый новый пример доказывает: качество кода — не то, чем можно пренебрегать.

В конце мая в Самаре прошел очередной ITsubbotnik EPAM, который собрал 240 участников. Это конференция для опытных специалистов, на которой эксперты ЕРАМ рассказывают об основных трендах, проблемах и их решениях в разработке и тестировании ПО.

В этот раз на конференции в рамках докладов QA говорили об эволюции Selenium WebDriver и объективных причинах, трансформировавших одно из решений в Web стандарт, о следующей фазе решений Desktop-ной автоматизации, обсуждали развитие инструментов мобильной автоматизации, озвучили последние новости Appium-а, а также посмотрели на Robotic Process Automation свежим взглядом, приведя примеры реальных проектов, реализуемых здесь и сейчас.

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

Доклады можно посмотреть в записи:

Оригинал статьи: https://beaglesays.wordpress.com/2017/07/16/the-illusion-of-quality-assurance/

Автор: Пол Симан (Paul Seaman)

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

Когда я только начинал тестировать, моя должность обозначалась как "Тестировщик". С тех пор прошло много лет, и я побывал как тестировщиком, так и QA-специалистом. Моя предыдущая должность называлась "Старший QA-аналитик", а нынешняя – "Старший инженер по тестированию". В официальных коммуникациях я всегда использую точное название своей должности, но вне их я представляюсь как тестировщик. Я горжусь этим званием и тем, что оно для меня значит. Уже долгое время я протестую против "QA-специалиста", потому что это название кажется мне глуповатым. К сожалению, его популярность растет. К еще большему сожалению, мне кажется, что люди, представляющиеся как QA, ставят QA выше и главнее тестирования. Проблема в том, что когда они описывают, что же такое "обеспечение качества", они на самом деле говорят о добросовестном, компетентном тестировании.

Не пошла ли мода называть тестировщиков "специалистами по обеспечению качества" из Agile? Я, если честно, понятия не имею. Не думаю, что Agile стоит у истоков переименования тестировщиков в QA-специалистов, но судя по разговорам тестировщиков на конференции LAST, Agile-методология внесла в эту проблему свой вклад. Не будем называть имен, вот краткое содержание диалогов тестировщиков:

• Если вы ждете, когда же начинать тестировать, сдвигаться влево уже поздно.
• Тестировщики – привратники на пути качества благодаря образу своего мышления.
• Мы обеспечиваем качество, тестировщики этого не делают. Мы убеждаемся, что все сделано правильно.

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

Оригинальная публикация: http://quality-lab.ru/how-to-understand-cutomers-needs/

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

К сожалению, наладить единство понимания бывает не очень просто, так как:

- руководители проектов, выступающие в роли заказчиков тестирования, не всегда делятся «очевидной» информацией;
- специалисты по тестированию зачастую пытаются навязать проекту некое «правильное» (в их понимании) тестирование.

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