Home

Вышел выпуск рассылки за первую половину февраля, его содержание доступно по ссылке.

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2017/01/11/test-cases-are-evil-or-are-they/

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

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

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

Ряд недостатков тест-кейсов прекрасно документирован в статьях и блогах. Это обычно что-то вроде подобного списка:

Автор: Эрика Чиковски (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) и продолжая совершенствоваться в сфере автоматизации, я дам рекомендации, как приобрести нужные знания и опыт.