Home

Автор: Эрика Чиковски (Ericka Chickowski)

Оригинал статьи: https://techbeacon.com/5-proven-ways-blow-your-test-automation-budget

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

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

Это позволяет организации быть гибкой, но создает проблему управления издержками. Распыление ответственности за автоматизацию и ее инструменты усложняет QA-экспертам оценку того, сколько в точности автоматизация тестирования стоит.

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

Промокод для получения 10% скидки: s-t.ru

До 28 февраля действуют льготные цены на оплату участия в конференции.

26-27 мая 2017 г. в Москве пройдет 21-я международная конференция в области обеспечения качества ПО «Software Quality Assurance Days».

Приглашаем вас принять участие в работе 21-й Международной конференции специалистов в области обеспечения качества ПО – SQA Days.

Конференция, как всегда, охватит широкий спектр профессиональных вопросов в области обеспечения качества, ключевыми из которых являются:

• Методики и инструменты тестирования ПО;
• Автоматизация тестирования ПО;
• Подготовка, обучение и управление командами тестировщиков;
• Процессы обеспечения качества в компании;
• Управление тестированием и аутсорсинг;
• Совершенствование процессов тестирования и инновации.

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

Автор: Наталья Руколь

Многие руководители проектов ищут универсальный ответ на вопрос: «Каким должно быть соотношение тестировщиков и разработчиков»? В некоторых компаниях дело доходит до утверждения нормативов: например, численность тестировщиков должна составлять 40% от команды разработки, или на каждого разработчика должен приходиться один тестировщик. Для обоснования этого соотношения нередко подбирается некая универсальная статистика по отрасли. Существует ли оптимальный рецепт?

Правильного соотношения не существует

Универсальные ответы всегда чреваты неточностью. Представьте: вы приходите к врачу и начинаете ему жаловаться на свою проблему. Он, не дослушав, выписывает лекарство:

— Какой у Вас вес? 80? Значит, по нормативу Вам надо пить 2 таблетки в день.
— Но подождите, доктор, у меня не простуда, а перелом ноги!
— Не отвлекайте, у нас норматив. Следующий!

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

Автор: Виктор Славчев (Viktor Slavchev)

Оригинал статьи: http://mrslavchev.com/2017/01/09/the-non-manual-unautomated-tester/

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

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

Ручное и автоматизированное тестирование превратились из описания вакансии в способ, которым тестировщики описывают, чем занимаются.

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2017/01/drop-the-crutches/

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

Эта статья – адаптация моих последних твитов. По ссылкам – ответы на некоторые из ваших вопросов. Как всегда, вопросы и комментарии приветствуются.

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

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

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

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

Есть ли в продукте проблемы, которые угрожают своевременному успешному завершению проекта?

Автор: Андрей Шальнев

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

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

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

Мне пришлось осваивать автоматизацию «с нуля», т. е. не имея академического образования в сфере IT, навыков программирования и практики работы в смежных «технических» направлениях (например, в системном администрировании). Теперь, уже имея опыт написания тестов на двух языках программирования (Python и Java) и продолжая совершенствоваться в сфере автоматизации, я дам рекомендации, как приобрести нужные знания и опыт.

Автор: Джоэл Монтвелиски (Joel Montvelisky)

Оригинал статьи: http://qablog.practitest.com/complexity-also-a-bug/

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

В прошлом месяце я участвовал в конференции DevOps в Тель-Авиве. Я делал заметки об интересных вещах, про которые рассказывали люди – как и многие на конференции – и затем убрал блокнот – как делают, опять же, многие после конференции.

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

Вот что там было написано:

Сложность – это тоже баг. Сложность повышается и будет продолжать повышаться.

Под этим предложением были заметки о презентации этого спикера.

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

Суть его речи сводилась к тому, что компании, занимающиеся разработкой ПО, должны выбрать, кто будет справляться с этой сложностью. Он смотрел на это с точки зрения DevOps, и поэтому сказал, что варианта тут три – разработка, IT или конечные пользователи.

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

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

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

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

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

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

Если вы задумались над внедрением автоматизации, вам стоит обратить внимание на записи выступлений с конференции CEE SECR “Разработка ПО”. В своих докладах специалисты рассказали о том, почему такая необходимость возникла на их на проектах, с чего они начинали процесс автоматизированного тестирования, а также о применяемых в работе инструментах.

Разработка системы автоматизированного тестирования при помощи фреймворка Protractor для web-приложений

Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ