Кто такой тестировщик и как им стать с нуля

Краудтестинговые платформы – “ясли для тестировщика”

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

Работа практически на всех краудтестиновых платформах строится по одному принципу. Есть какое-либо вводное обучение. Далее идет вводные тест. Если все хорошо, Вас допускают к реальным проектам. И Вы можете начать прокачивать свой рейтинг, ведь от этого будет зависеть и Ваша “зарплата”.

А “доход” обычно начисляется в английских тугриках. И в принципе он достаточно неплохой.

Да. Помните. Чем “крупнее” ошибки Вы находите, тем выше Ваше вознаграждение!

Краудтестинговые платформы в основном “буржуинские”. Вот некоторые из них. Часть только на английском (или немецком языках). Часть переведена (не полностью) на русский. Но велика вероятность получения задания на английском языке.

Если Вы работали на одной их них, оцените ниже, какая понравилась больше.

test.io– одна из старейших платформ краудтестинга

www.testbirds.com – есть вариант для русскоязычных пользователей.

www.passbrains.com – еще один сайт для тестирования ПО

www.globalapptesting.com – еще краудтестинговый сайт

ubertesters.com – еще одна (немецкая) платформа для тестирования

testlio.com – еще ловите сайтик для тех, кто ищет работу тестировщика ПО без опыта

www.crowdtesting.ru – и еще. Это уже на русском языке, что является редкостью в мире тестировочных платформ.

Про условия работы на этих сервисах лучше сами посмотрите у них. Заодно и с платформами ознакомитесь.

QA-специалисты — это те, кто видит всю картину

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

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

Это означает, что работа тестировщика не может быть ограничена механическим исполнением тест-плана.

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

Что нужно для нагрузочного тестирования?

1. Общие требования. Нам нужно понимать, чего мы ожидаем от нашей системы в контексте нагрузки и производительности, хотя бы в общих чертах. Это может звучать просто, но не всегда у людей есть ясное представление о таких требованиях. «Система должна отвечать быстро под высокой нагрузкой» — это не требование, это пожелание. Я покажу примеры удачнее дальше в статье.
2. Специалисты. Для проведения НТ нужны инженеры. Поскольку серьёзное тестирование всегда требует автоматизации, нужны инженеры с навыками тестирования и разработки, а также аналитики и девопсы.
3. Платформа для тестового окружения. Если вы делаете НТ в первый раз — вам определённо понадобится подготовить инфраструктуру. Хорошо если у вас внедрён подход IaC (англ. infrastructure as a code, инфраструктура как код), он очень пригодится для создания окружения, подобного проду. Если нет — надо внедрять или придётся страдать даже на небольших конфигурациях. И в подавляющем большинстве случаев тестирование на проде — плохая идея. Но есть и исключения, можете погуглить «Netflix testing in production».
4. Время. НТ — это очень затратный по времени процесс, особенно когда вы делаете его впервые. Автоматизация экономит много времени, но всё равно нужно быть готовым потратить на подготовку и проведение НТ несколько дней или существенно больше, зависит от масштабов прода, используемого стэка, сценариев использования и поставленных задач.

Data-Driven Testing

Это тестирование, управляемое данными. При таком подходе тестовые данные хранятся отдельно от тест-кейсов, допустим, в файле либо в базе данных. Такое разделение логически упрощает тесты.

Data-Driven Testing используется в тех проектах, где нужно выполнить тестирование отдельных приложений в нескольких средах с большими наборами данных и стабильными test cases.

Обычно при DDT выполняются следующие операции:
— извлечение части тестовых данных из хранилища;
— ввод данных в форму приложения;
— проверка результатов;
— продолжение тестирования со следующим набором входных данных.

Подход Data-Driven Testing:

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

Кто такой QС Engineer

Контроль качества (QC) — часть международного стандарта управления качеством ISO 9000. Суть контроля качества сводится к поиску дефектов и ошибок после создания продукта.

Таким образом, специалист, чья работа крутится вокруг тестирования — это QC Engineer, по-русски, тестировщик.

Должностные обязанности QC Engineer

Примерный обобщенный список:

• Оценка и внедрение программного обеспечения для тестирования.

• Проверка продукта на соответствие установленным требованиям и ожиданиям.

• Настройка автоматического тестирования.

• Поиск дефектов или ошибок, которые могут подорвать доверие покупателей к вашим продуктам.

• Проверка, что конечный продукт соответствует стандартам компании, стандартам отрасли, законам.

• Составление отчетов об испытаниях и проверках.

• Выявление и документирование ошибок и дефектов, которые необходимо исправить перед выпуском продукта.

• Выявление и документирование ошибок и дефектов, которые можно исправить после отправки продукта.

• Тестирование инструкций, гайдов, документации.

• Работа со специалистами по обеспечению качества.

• Оценка отзывов и жалоб клиентов — поиск и рекомендации решений, которые “сделают их счастливыми”.

• Мониторинг поступления на рынок только высококачественной продукции.

Кто такой QA Engineer

Обеспечение качества (QA) — часть международного стандарта управления качеством ISO 9000, которая помогает компаниям соответствовать требованиям, удовлетворять потребностям клиентов и постоянно улучшать свои процессы и процедуры.

Должностные обязанности QA Engineer

Примерный обобщенный список:

• Планирование, разработка и внедрение политики, процессов и процедуры обеспечения качества.

• Документирование и обновление типовых инструкций и лучших решений (best practices).

• Проверка процессов, процедур и документации на соответствие правилам и стандартам.

• Мониторинг текущих процессов с целью их улучшения.

• Обучение производственных и инженерных групп соблюдению установленных процессов и процедур.

• Анализ первопричин и внедрение решений, направленных на устранение проблем, обнаруженных в текущих процессах и процедурах.

• Сбор и оценка отзывы клиентов.

ВАЖНО. Даже если в компании есть четко определенная позиция QA Engineer, обеспечивать качественный процесс, создавать качественный продукт остается обязанностью каждого участника команды. . В общем, QA Engineer, если такой есть на проекте, человек, который прицельно отследит и поможет подтянуть проседающий процесс разработки: направит, надоумит, отправит учиться или подкинет инструментов и идей

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

Из каких блоков состоит стандартное интервью

Сначала — представить компанию, описать процессы, рассказать про команду и ожидания от будущего коллеги. Сразу скажу, в этой части люблю оставлять «ловушки»: о чём-то сознательно не рассказываю, чтобы на этапе вопросов от кандидата ему было, о чём спросить, а мне — можно было углубиться в подробности.
Дальше — очередь кандидата: его опыт, контекст применения инструментов, методик. Как часто они в компании релизили, что делали, зачем, почему. На этом этапе меньше интересует рассказ про продукты. Иногда люди уходят в дебри, говорят про тонкости реализации архитектуры их приложений

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

Завершает обязательный этап с вопросами от кандидата. Есть такое понятие как инвертированное собеседование. Это для меня как интервьюера круче всего. Когда создается впечатление, что не ты собеседуешь, а тебя собеседуют: задают вопросы, как устроен процесс разработки, что с CI/CD, как у вас автотесты, а какой фреймворк, зачем, почему… В этот момент понимаешь, что специалисту не всё равно, он вовлечён, а еще понимаешь, что его волнует. И для себя делаешь пометки: например, человек больше смотрит вширь. Очень важно, чтобы человек задавал вопросы, которые помогали бы ему подстраховаться от ошибок, которые он совершил на прошлом месте. Если человек рассказывает, почему ушёл из прошлой компании и на собеседовании не подкладывает себе соломки под ту же причину — для меня это тревожный звонок.
Под конец — оргвопросы. Зарплатные ожидания: всегда прошу озвучить кандидатов минимум, исходя из базовых потребностей — дети, семья, ипотека. И максимум: если у человека есть адекватная профессиональная оценка собственных навыков, компетенций по рынку — это здорово. По возможности я стараюсь прямо давать кандидатам обратную связь, чтобы у них было понимание, как всё прошло. Хотелось бы, чтобы собеседования проходили в таком свободном формате — это позволяет расстаться на позитивной ноте, даже если конкретно сейчас кандидат на место не подходит. У меня много примеров, когда с кандидатами расстались по причине «сейчас не время», и спустя какой-то период мы с ними работаем.

Результаты внедрения нагрузочного тестирования в Miro

1. Понятный и описанный процесс. Чётко описано, какие шаги нужно выполнить и что нужно делать на каждом из шагов.
2. Большие тесты: 200K, 500K пользователей online при типичном сценарии использования. Каждый сложный тест зачастую проходит много итераций перед успешным выполнением, поэтому без автоматизации столько раз гонять большие тесты было бы чрезвычайно долгим и утомительным занятием, полным ошибок.
3. Проверка компонентов перед выкаткой на прод.
4. Обоснованный выбор параметров компонентов для поддержки планируемой нагрузки. То есть не просто с потолка брать «ну наверное хватит сотни воркеров», а выбирать параметры на основе результатов проверок.
5. Автоматизация, упрощение и ускорение проведения НТ. Я говорил в начале про список из 16 пунктов, которые надо было пройти вручную при каждом запуске НТ на кластере. Теперь это один конфиг и одна команда. Больше автоматизации даёт больше надёжности и больше возможностей уделить время более творческим и сложным задачам.
6. Деградационное тестирование (начало). Автоматическое выполнение тестов по реалистичному API сценарию на типичной нагрузке каждую ночь на последней версии сервера и построение графиков трендов для отслеживания динамики показателей скорости ответа и числа ошибок.

Как ты пришёл (-ла) в QA Automation?

АЛЕКСЕЙ БЕДУНКЕВИЧ: Я стартовал как обычный ручной QA на последнем курсе БГУИР (февраль 2010-го), скорее это планировалась как временная подработка, пока я буду делать тестовое задание для одной компании, занимавшейся разработкой систем компьютерной безопасности. К моменту выхода у меня был неплохой опыт работы с C/C++, ASM, .Net. Я поработал какое-то время ручным тестировщиком и через пару лет незаметно для себя перешел в авто. Просто однажды меня поставили на проект, спросили: «Сможешь?». «Смогу», – ответил я. Вот примерно так в 2013-м я начал карьеру автоматизатора. Потом было много проектов на Java/C#/Python/JS.

Летом 2019-го я перешел в должность Group Manager, и на данный момент у меня в группе тестирования 35 человек.

АЛЕКСЕЙ ПОБОЛЬ: Поработав мануальщиком на протяжении 3 лет, устал от монотонности, хотелось упростить себе работу через автотесты. Основной мотив – попробовать что-то новое, изучить язык программирования.

Так работали всегда

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

Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:

Прохождение каждого тест-кейса ручное, поэтому процесс тестирования занимает много времени. Количество тест-кейсов в регрессии по естественным причинам постоянно растет, и принимается решение о создании внутри QA-отдела команды автоматизации.

Так как новоиспеченная команда набиралась из-за необходимости ускорить цикл регрессии, который состоит из black-box тестов, то и автоматизация происходит на уровне black-box: через GUI или API. Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее. 

Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов. Учитывая огромное количество black-box сценариев, находящихся в очереди на автоматизацию, получаем анти-паттерн тестирования Ice-Cream Cone, в котором количество самых медленных и самых дорогостоящих GUI-автотестов намного больше количества дешевых и быстрых модульных и интеграционных тестов.

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

Может ли новичок-нетехнарь стать хорошим QA-специалистом

Порог входа в тестирование довольно низкий. Чтобы стать тестировщиком, не требуется техническое образование. Главное, чтобы человеку была интересна сфера IT и он хотел развиваться в этом направлении. Об этом говорит в своём интервью на hh.ru руководитель департамента обеспечения качества ПО Veeam Software Игорь Кацев.

На сайте Software-Testing.ru опрашивали тестировщиков из России и СНГ по поводу их образования. Оказалось, что в профессию приходят и достигают в ней карьерных высот разные люди: технари, гуманитарии, экономисты, юристы, люди с двумя высшими и люди без диплома вообще.

Что делает тестировщик ПО, кто он?

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

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

Говоря о том, что нужно знать тестировщику ПО, стоит упомянуть следующие дисциплины и понятия:

• система контроля версий Git;
• основы баз данных и тестирования ПО;
• HTTP, а также особенности разных операционных систем (BASH, CMD, PowerShell);
• сетевые протоколы;
• язык запросов SQL;
• инструменты, используемые для управления процессом тестирования, в частности JIRA, TestLink и другие;
• системы отслеживания ошибок;
• основы хотя бы одного языка программирования, в приоритете Java, JavaScript, C#.

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

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

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

Какие бывают

В ИТ-среде в свя­зи с тести­ро­ва­ни­ем и каче­ством при­ня­то три обо­зна­че­ния:

QA — quality assurance, самый глав­ный по каче­ству;QC — quality control, кон­тро­лёр каче­ства;Tester — тести­ров­щик.

В раз­ных ком­па­ни­ях эти обо­зна­че­ния могут сли­вать­ся или допол­ни­тель­но раз­де­лять­ся, но в целом кар­тин­ка такая.

QA — это тот, кто дума­ет о каче­стве про­дук­та в целом, при­чём не толь­ко о конеч­ном коде, но и все­го про­цес­са раз­ра­бот­ки. Напри­мер:

Как понять поль­зо­ва­тель­ские сце­на­рии, в кото­рых веро­ят­нее все­го воз­ник­нут ошиб­ки? Как их собрать? Как систе­ма­ти­зи­ро­вать? Как ниче­го не упу­стить? (Напри­мер, как понять, какие имен­но пред­ме­ты люди могут дога­дать­ся засу­нуть в мик­ро­вол­нов­ку, и как защи­тить­ся от иди­о­тов, кото­рые засу­нут туда дина­мит?)Как соеди­нить запро­сы людей, тре­бо­ва­ния биз­не­са и реаль­ные воз­мож­но­сти про­дук­та с точ­ки зре­ния каче­ства? Что если наш про­дукт совсем не дела­ет то, чего поль­зо­ва­те­ли могут ожи­дать? Напри­мер, если они будут сушить в мик­ро­вол­нов­ке кош­ку — это чья про­бле­ма? Будем ли мы с этим что-то делать?Кто, как и в каком поряд­ке будет исправ­лять ошиб­ки? Как мы будем повтор­но тести­ро­вать места с ошиб­ка­ми?Что и как тести­ро­вать от вер­сии к вер­сии про­грам­мы, что­бы это было доста­точ­но быст­ро, но не в ущерб каче­ству?

Мож­но пред­ста­вить, что QA — это дирек­тор по каче­ству, глав­ный чело­век на пути у багов. Он не менее важен, чем глав­ный архи­тек­тор или ИТ-директор. Мно­гие его функ­ции могут пере­се­кать­ся с функ­ци­я­ми дру­гих ИТ-директоров.

QC — это тот, кто сфо­ку­си­ро­ван на тести­ро­ва­нии само­го про­дук­та:

Что имен­но тести­ру­ем? Какие функ­ции, кноп­ки, состо­я­ния, сце­на­рии?Какие резуль­та­ты тести­ро­ва­ния нам нуж­ны? Какие исхо­ды пра­виль­ные, а какие — ошиб­ки?Как авто­ма­ти­зи­ру­ем тесты? Что нуж­но обя­за­тель­но прой­ти руч­ка­ми?Как син­хро­ни­зи­ро­вать рабо­ту несколь­ких тести­ров­щи­ков? Как рас­пре­де­лить зада­чи, обла­сти, слои?

Мож­но пред­ста­вить, что это такой глав­ный бри­га­дир тести­ров­щи­ков. Его рабо­та — что­бы тесты шли ров­но и чёт­ко, без про­блем. Разу­ме­ет­ся, очень полез­но, если он уме­ет непо­сред­ствен­но тести­ро­вать.

Тести­ров­щик — это тот, кто тести­ру­ет про­дукт: про­хо­дит его руч­ка­ми или пишет авто­ма­ти­че­ские тесты; опи­сы­ва­ет баги; обща­ет­ся с раз­ра­бот­чи­ком по пово­ду этих багов; зано­во тести­ру­ет исправ­лен­ное.

Кто такие тестировщики

Начем с того, что QA-инженер — одна из самых недооценённых профессий в нашей индустрии. Зарплаты тестировщиков обычно намного меньше, чем зарплаты программистов. Соответственно, эта сфера меньше привлекает талантливых людей. А если уж они и попадают в неё, то стремятся как можно быстрее продвинуться в разработку или управление проектами, чтобы зарабатывать больше.

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

Чтобы понять эту мысль, давайте разберём, как в теории должен происходить процесс разработки.

• Идеальный product-manager создает максимально детализированный спек продукта и передаёт его идеальному дизайнеру.
• Идеальный дизайнер, в свою очередь, рисует продуманные до мельчайших деталей UI- и UX-мокапы.
• Техлид компании распределяет работу между разработчиками.
• Идеальные разработчики в кратчайшие сроки (и, разумеется, без багов) имплементируют спек, тщательно проверяя и документируя свой код.
• Идеальные QA-инженеры пишут тест-план на основе детального спека и сверяются с UI-диаграммами, полученными от дизайнера.
• Проверка продукта становится тривиальной задачей и он выходит в продакшн.

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

Как провести собеседование с кандидатом на позицию QA Engineer

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

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

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

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

Но перед этим, HR-специалисту нужно подготовиться к интервью, чтобы представить бренд работодателя в лучшем свете

При подготовке к интервью важно сформировать образ кандидата мечты, составить список его профессиональных качеств и требований к позиции QA

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

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

Перспективы

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

Сегодня пока еще отсутствует возможность максимальной эффективной автоматизации процесса тестирование юзабилити программ или их частей. Речь идет в данном случае об игровых продуктах и мобильных приложениях, насыщенных анимацией и другими визуальными эффектами. Поэтому ручной тестировщик в течение следующие 5-10 лет не «умрет», а будет профессионально эволюционировать. Чтобы сохранить собственную востребованность как специалиста, уже сейчас желательно заняться саморазвитием, получением новых знаний и оттачиванием обретенных навыков.

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

F.A.Q QA — обеспечение качеством

Что такое обеспечение качества программного обеспечения?

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

Каждой программе требуется тестер?

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

Что такое план тестирования?

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

Как мне может помочь юзабилити-тестирование?

Юзабилити-тестирование измеряет простоту использования программного приложения. Как таковая, она является неотъемлемой частью качества программного обеспечения. Даже самый интересный и продаваемый программный продукт пострадает в популярности, если он покажет громоздкое удобство использования.

Почему в программном обеспечении есть ошибки?

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

Как тестируются сайты?

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

Что такое качество программного обеспечения?

Качество программного обеспечения — это соответствие программного обеспечения его требованиям.

Что такое регрессионное тестирование?

Регрессионное тестирование — это цикл обеспечения качества, при котором ошибки, обнаруженные во время предыдущего обзора обеспечения качества, «регрессируются», чтобы гарантировать, что

• а) они были исправлены разработчиками,
• b) в результате исправлений не было создано никаких новых ошибок.

Кто такой бета-тестер?

Бета-тестер — это тот, кто тестирует бета-версию программного приложения. Они могут быть профессиональными тестировщиками или членами целевой аудитории программного обеспечения.

Что должен знать и уметь хороший тестировщик?

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

Если говорить о джуниорах, то здесь можно выделить общие навыки:

• Хорошие знания в клиент-серверной архитектуре.

• Хороший тестировщик должен понимать механизм взаимодействия веб-приложений, уметь локализовать проблему вне зависимости от того, возникла ли она на фронтэнде или бэкенде.

• Специалисту необходимо иметь базовые навыки использования специализированного софта, уметь использовать инструменты devTools, иметь представление о работе снифферов, знать базовые команды консоли Windows. 

Крайне важны soft-скиллы:

• Умение общаться с коллегами.

• Умение ясно излагать мысли.

• Способность четко описать проблему разработчику.

• Умение работать с документацией.

• Понимание стандартов разработки ПО.

• Внимательность.

• Настойчивость.

• Готовность доказать и отстоять свою позицию, основываясь на документации или здравом смысле.

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

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

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

Testing and Debugging

Testing − It involves identifying bug/error/defect in a software without correcting it. Normally professionals with a quality assurance background are involved in bugs identification. Testing is performed in the testing phase.

Debugging − It involves identifying, isolating, and fixing the problems/bugs. Developers who code the software conduct debugging upon encountering an error in the code. Debugging is a part of White Box Testing or Unit Testing. Debugging can be performed in the development phase while conducting Unit Testing or in phases while fixing the reported bugs.

Previous Page
Print Page

Next Page  

Что нужно, чтобы стать хорошим QA-инженером

Для начала стоит понять, ваше ли это. Я бы выделил несколько основных особенностей работы и черт характера, чтобы заниматься тестированием.

Техническая эрудиция

«Technical savvy», как иногда пишут в вакансиях, и желание разбираться в технологиях. Вы должны интересоваться тем, как что работает, как что устроено внутри. Это понимание сослужит хорошую службу в будущем и обычно идёт в связке с необходимым хорошему тестировщику любопытством.

Вы когда-нибудь ставили и настраивали Linux — для себя, чисто из интереса? Пытались разобраться, как работает блокчейн? Делали друзьям сайт на WordPress? Если нет, попробуйте и проследите за своей реакцией. Интересно ли, подстегивают ли сложности найти решение, покопаться в Google и на форумах? Когда конечный результат не тот, появляется ли желание докопаться и сделать, чтобы всё начало работать как надо? Если вы ответили «да», скорее всего, тестирование вам подходит.

Disclaimer Внимательный и искушённый читатель скажет, что я сейчас описал админа/девопса, но хороший тестировщик, на мой взгляд, обязан иметь желание и возможность и разбираться во внутренностях продукта, и уметь настроить (перестроить, почистить, твикнуть, заморозить, залить данными) тестовое окружение.

Ориентированность на пользователя и бизнес

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

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

В вакансиях часто пишут «ориентированность на детали, перфекционизм». Они нужны, но только если правильно сфокусированы.

Умение структурировано думать и писать

Проведите мысленный эксперимент: представьте, что вам нужно описать, как тестировать центральный замок автомобиля. Вы начнёте писать, например, «открыть, закрыть», но есть же разные состояния: «открыть уже открытое», «закрыть уже закрытое», — или разные точки воздействия: можно открывать брелком, ключом, кнопками изнутри

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

Умение работать с большими объёмами данных и быстро учиться

В работе вам скорее всего понадобится навык работать с большими и плохо структурированными объёмами информациями (также известными как «спецификация», «техническое задание», «корпоративная база знаний»), быстро понимать как работает сложная (и не всегда логично написанная) система и быстро получать базовые знания в абсолютно разных областях. Если ваш проект про управление финансовыми портфелями — придётся разобраться в финансах, если про управление складом — в логистике и т. д. Хороший способ проверить себя — взять и успешно пройти какой-нибудь курс на coursera.com по незнакомому и фундаментальному предмету, желательно на английском.

Умение говорить с людьми на неприятные темы

Очень много и очень хорошо говорить.

Middle Java Developer

L2U, Москва, Новосибирск, можно удалённо

tproger.ru

Вакансии на tproger.ru

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