Home

Автор: Таисия Рыбак, тренер курса "Управление требованиями"

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

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

Цель данного выступления - донести до слушателей развернутую информацию об эволюции схемы сертификации ISTQB - самой распространенной и успешной сертификации для специалистов по тестированию.

Evolution of the ISTQB(r) scheme, Gualtiero Bazzana, Milano, Италия

Если вы задались целью получить сертификат ISTQB, возможно, вас заинтересует наш тренинг Комплексная система подготовки тестировщиков по программе ISTQB FL, где подробно разбираются все тонкости экзамена, например: Бывают ли в тестах ISTQB ошибки? Или это ловушки?

Также напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-21, Москва,  май.

Как обычно для читателей нашего портала действует промокод на получение 10% скидки.

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

Обсудить в форуме

26 февраля в Минске пройдет очередная большая конференция выходного дня COMAQA Winter 2017, посвященная вопросам ручного и автоматизированного тестирования. Спикеры из ведущих IT-компаний Беларуси, России и не только соберутся вместе, чтобы рассказать о своем опыте в тестировании и управлении.

Для тех, кто не сможет присутствовать лично, будет организована онлайн-трансляция. В случае онлайн-участия, пожалуйста, зарегистрируйтесь.

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

Автор: Вероника Латипова

Перед каждым разработчиком ПО рано или поздно встает задача оценки качества выпускаемого продукта. Зачастую руководители небольших проектов считают непозволительной роскошью прибегать к услугам профессиональных тестировщиков. Ведь, на первый взгляд, кто, если не сам разработчик или пользователь может наилучшим образом найти недостатки в программе? По сути, в этом случае все исследование сводится к бета-тестированию («Бе́та-тести́рование (англ. betatesting) – интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю»).

Практика использования клиентов – потребителей продукта в качестве тестировщиков в последнее время стала достаточно популярной. Мы постараемся оценить очевидные на первый взгляд плюсы и минусы бета-тестирования и тестирования специалистами. Все ли из них оказываются «плюсами» или «минусами» при ближайшем рассмотрении?

Автор: Амир Гахрай (Amir Ghahrai)

Оригинал статьи: http://www.testingexcellence.com/choose-tests-automate/

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

Как вы решаете, какие тесты автоматизировать, а какие оставить для ручного тестирования?

Перед тем, как вы начинаете автоматизировать тест, вам нужно выяснить, какую выгоду вы получите от автоматизации этого теста, учитывая время, силы и ресурсы, вложенные в автоматизацию.

Ниже перечислены факторы, которые стоит принять во внимание, решая, какие ручные тесты должны или не должны быть автоматизированы. Как говорится, только то, что вы можете что-то автоматизировать, не означает, что вы должны автоматизировать все и вся.

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

Оригинал статьи: https://testingfromthehip.wordpress.com/2016/12/14/raise-problems-not-bugs/

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

Недавно я написал в своем твиттере примерно следующее:

"Когда рассказываете о чем-то, найденном в процессе тестирования, называйте это проблемой, а не багом. Вы поразитесь, насколько лучше вас начнут понимать".

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

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

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

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

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

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

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

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

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

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

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

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

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

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