Что пишут в блогах

Подписаться

Онлайн-тренинги

 Все онлайн-курсы

Конференции

Разделы портала

Про инструменты

Лучшие вакансии

.
Выбирайте с умом
13.02.2017 00:00

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: http://www.ontestautomation.com/choose-wisely/

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

В своей недавней статье, опубликованной на TechBeacon, я утверждал, что тесты на уровне API копают золотую жилу скорости выполнения, стабильности (как стабильности запуска, так и стабильности требуемой поддержки) и тестового покрытия. Однако я забыл упомянуть, что именно сподвигло меня написать такую статью. Об этом я и расскажу.

На самом деле причина для такой темы у меня была только одна: я слишком часто вижу, как все идет наперекосяк, когда люди начинают писать автотесты. Сейчас я работаю с несколькими клиентами над двумя разными проектами, и их объединяет стремление к end-to-end тестам (зачастую при помощи инструментов вроде Selenium или Protractor), с проверками, которые выходят за рамки юнит-тестов.

Вот вам пример. Я работаю над проектом, в котором мы собираемся создать автоматические проверки для веб-магазина, который продает электронные сигареты и аксессуары для них в Соединенных Штатах Америки. В магазине несколько продуктовых категорий, возрастных групп покупателей (некоторые продукты можно приобретать, если вам больше 18, некоторые – если вам больше 21, некоторые продукты не учитывают возраст, и так далее). К тому же это США – 50 разных штатов, и в каждом свои правила и законодательство. Короче говоря, возможных комбинаций тут куча (я не считал, но точно в районе сотен). К тому же из-за жестких правил США, и штрафов за нарушение этих правил, автотесты должны включать абсолютно все возможные комбинации.

Звучит логично, но проблема в том, что заказчик предлагает написать автоматизированный end-to-end тест для каждой из возможных комбинаций. Следовательно, нам нужно создать заказ для каждой комбинации продуктовой группы, возрастной группы и штата, и каждый заказ включает заполнение трех или четырех разных форм и несколько переходов по страницам. Другими словами, такой тест будет медленно запускаться (счет пойдет на часы), и его будет тяжело поддерживать.

Подробнее...
 
Особенности подготовки начинающих тестировщиков
10.02.2017 12:03

Автор: Юлия Бурматова

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

Все мы когда-то были новичками: в тестировании или в другой сфере – не важно. Мы одинаково спотыкались, блуждали в поисках правильного пути и далеко не всегда быстро находили решение. Порой у нас опускались руки от многократных ошибок, и в голове прочно утверждалась мысль: «Я – неудачник и все делаю не так!».

Я хорошо помню свой самый первый проект с реальными задачами, свои большие от страха глаза, когда мне поручили составление тестов. Я совершенно не знала, с чего начинать. И больше всего меня мучило не абстрактное «как это делается?», а «как это сделать правильно?».

С тех пор прошло почти три года, я многому научилась – самостоятельно и с помощью замечательных коллег, с которыми мне посчастливилось работать. А еще за все это время я успела неоднократно побывать в роли наставника новичков, которые приходили в нашу компанию, и стать одним из тренеров курса «Школа успешных тестировщиков» Натальи Руколь.

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

Подробнее...
 
Новости тестирования за февраль
09.02.2017 11:59

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

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

 
Тест-кейсы – зло! Или все-таки нет?
08.02.2017 10:36

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

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

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

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

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

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

Подробнее...
 
Пять способов угробить ваш бюджет на автоматизацию
06.02.2017 11:50

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

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

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

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

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

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

Подробнее...
 
SQA Days 21: конференция для тестировщиков, Москва, промокод на скидку
03.02.2017 14:09

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее...
 
Не ручной, не автоматизатор, а неведома зверушка
02.02.2017 10:46

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

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

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

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

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

Подробнее...
 
Wanted: Test Engineer (Automated testing)
31.01.2017 17:09

Мы – американская компания DealerSocket и один из самых успешных проектов на рынке автоиндустрии в США. 31% всех автомобилей США продаются с использованием разработанного нами программного обеспечения. У нас есть Центры Разработки в США и в России. Головной офис находится в Сан-Клементе (Калифорния). Мы создаем и обслуживаем сайты для таких компаний, как Jaguar Cars, Volkswagen Konzern, Mercedes-Benz и т.д.

Прямо сейчас нам нужен Тест Инженер в офис в Калининграде (единственный офис в России). По обязанностям – 95% автоматизация тестирования.

Наши технологии: Codeception, Selenium WebDriver, PHP, TeamCity, Vagrant, Git.

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

У нас: белая зарплата, ДМС, гибкий график, курсы английского в офисе, поездки на конференции, компенсация занятий спортом, а по воскресеньям мы играем в баскетбол.

О вакансии: https://moikrug.ru/vacancies/1000022376
О компании: http://dealersocket.com/
О Калининградском офисе: http://www.dealerfire.com/dealersocket-kaliningrad/

 
Бросьте костыли!
31.01.2017 10:57

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

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

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

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

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

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

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

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

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

Подробнее...
 
Освоение автоматизации тестирования для тех, кто не имеет опыта программирования
30.01.2017 11:37

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

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

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

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

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

Подробнее...