Home

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

Оригинальная публикация: 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/

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

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

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

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

Оригинал статьи: http://katrinatester.blogspot.ru/2017/07/test-automation-canvas.html

Автор: Катрина Клоки (Katrina Clokie)

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

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

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

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

Более 5000 IT-специалистов собрала Международная конференция Стачка 2017. И, конечно, среди них были специалисты в области обеспечения качества, которые приехали поделиться своим опытом.

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