Оригинальная публикация: 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. И, конечно, среди них были специалисты в области обеспечения качества, которые приехали поделиться своим опытом.

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

Оригинал статьи: http://www.cassandrahl.com/blog/tester-interviews-techniques-and-tasks/

Автор: Кассандра Лонг (Cassandra Leung)

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

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

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

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

Автор оригинальной статьи: Джефф Листфилд, testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html

Перевод: Анатолий Ализар, Habrahabr.ru (https://habrahabr.ru/post/327394/)

Если тесты сбоят на ранее протестированном коде, то это явный признак того, что в коде появилась какая-то новая ошибка. Раньше тесты проходили успешно и код был правильный, сейчас тесты сбоят и код работает неправильно. Цель хорошего набора тестов заключается в том, чтобы сделать этот сигнал настолько ясным и чётко адресованным, насколько возможно.

Ненадёжные (flaky), то есть недетерминированные тесты ведут себя иначе. Они могут показать как положительный, так и отрицательный результат на одном и том же коде. Другими словами, сбой теста может означать, а может и не означать появление новой проблемы. И попытка воспроизвести ошибку путём перезапуска теста на той же версии кода может привести или не привести к успешному проходу теста. Мы рассматриваем такие тесты как ненадёжные, и в конце концов они теряют свою ценность. Если изначальная проблема — это недетерминизм в рабочем коде, то игнорирование теста означает игнорирование бага в продакшне.