Как проходит День тестировщика

Содержание
  1. Как стать тестировщиком ПО: от собеседования до поиска первого бага
  2. Собеседование
  3. Первый рабочий день
  4. Первое задание
  5. Чек-лист для тестирования Pokémon GO
  6. Первый баг в трекер
  7. Тема
  8. Сценарий
  9. Назначение бага
  10. Проставление критичности
  11. Immediate (Blocker)
  12. Crit — Urgent
  13. High
  14. Normal
  15. Low
  16. Самообучение
  17. Суровая реальность начинающих тестировщиков. Пособие: что и как учить
  18. А нужны ли курсы?
  19. Что учить самостоятельно
  20. 1. Базовые знания
  21. 2. Практика
  22. 3. SQL
  23. 4. Unix
  24. 5. Selenium
  25. 6. Сети
  26. 7. Английский
  27. Другое
  28. Что поможет получить работу
  29. Выводы
  30. 7 советов, как не взбесить коллегу-тестировщика в его праздник
  31. 1. «Перепроверь-ка еще разок, там точно нет бага»
  32. 2. «До релиза неделя. Надеюсь, на ближайшие два дня ты не планировал других дел»
  33. 3. «Я быстренько подправил код. Посмотри, пожалуйста»
  34. 4. «Кажется, я уже разобрался с этим багом. Но точно не помню»
  35. 5. «Почему это я должен тестировать? Я же не тестировщик!»
  36. 6. «Игорь, сегодня работаешь в паре с Олегом. Тебе понравится»
  37. 7. «Я возьму твой девайс для тестов, ты же не против?»
  38. «Стал „тестировщиком“ за два дня»
  39. Как я сменил профессию за два дня
  40. Ожидания работодателей
  41. О чём спрашивают на собеседовании
  42. Примеры тестовых заданий
  43. Этапы развития и как их проходить
  44. Условия карьерного роста
  45. Горизонталь и вертикаль
  46. О стереотипах
  47. О личных качествах тестировщика
  48. День тестировщика: полезные навыки и будущее профессии
  49. Какие навыки нужны тестировщику
  50. Что искусственный интеллект изменит в работе тестировщика

Как стать тестировщиком ПО: от собеседования до поиска первого бага

Как проходит День тестировщика

Мой путь тестировщика начался с любопытства. С самого детства я занимался сборкой компьютеров и установкой ПО, в ходе работы регулярно возникали вопросы: «Почему не устанавливается? Почему не работает?». В этот момент я подумал, что хочу стать тестировщиком, заниматься выпуском качественного ПО и узнать ответы на все эти вопросы.

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

Собеседование

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

Например, задаём необычные вопросы, чтобы посмотреть, как мыслит человек:

  • Самолёт вылетает из точки А в 17:00, а прилетает в точку Б в 19:00. При этом находится в полёте три часа. Почему такое может быть?
  • Как сделать так, чтобы, получив обновлённое приложение, конкуренты не смогли узнать его новые функции?

Будьте готовы и к самому обычному заданию — протестировать простой предмет: лист бумаги, карандаш, сетевой фильтр и тому подобное.

Также для собеседования будет полезно:

  1. Изучить виды тестирования: функциональное и исследовательское тестирование, автоматизированные тесты (включая инструменты для него), нагрузочное и стресс-тестирования, smoke-тестирование.
  2. Дополнительно почитать о приёмочном тестировании и его критериях.
  3. Если мы говорим о тестировании веб-приложений, то это браузерная консоль и её работа, количество и версии браузеров, разрешения мониторов, инструменты тестирования вёрстки (pixel perfect).
  4. Если мы говорим о мобильных приложениях, это виды платформ, эмуляторы, monkey testing. Не забудьте о планшетах.
  5. Изучить виды баг-трекеров. Самые популярные: Jira, BugZilla, RedMine, Mantis. Посмотрите, как они работают, в чём их особенность.
  6. В перспективе — инструменты Jmeter, Postman, Charles. Они не очень сложны в освоении на базовом уровне.

Первый рабочий день

Первый рабочий день проходит стандартно: выдают компьютер, который нужно настроить, установить рабочие программы. Системный администратор готовит доступы к почте и корпоративным внутренним программам.

Не стоит спрашивать, где установить Skype, использовать в нём ник со школьных времён gangsta_666 или забавную картинку. Используйте в нике сочетание имени и фамилии, например ivansmirnov или smirnovivan, поставьте свою обычную фотографию.

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

Первое задание

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

Проявляйте инициативу. Если вам не дали чек-лист приложения, не ждите, а попросите его у ментора. Если в организации нет чек-листа, вы можете составить его сами. В нашей компании чаще чек-лист составляют в «Google Таблицах». Ниже мы привели пример такого чек-листа — вы сможете составлять свои по его примеру.

Коллеги будут удивлены, если составите чек-лист в виде карты мыслей, например в Xmind.net.

Чек-лист для тестирования Pokémon GO

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

Для наращивания тестовой базы новичок может сам расширять этот чек-лист. Junior-тестировщики в рамках обучения написанию чек-листов подготовили лист для тестирования приложения Pokémon GO. Тут описаны только позитивные кейсы.

Первый баг в трекер

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

Тема

В ней описывают проблему несколькими словами. Лучше, если она будет начинаться с отрицания: «не работает», «не происходит», «неправильно» и прочее. Например: «Не происходит синхронизация с сервером на iPhone 6», «Не работает воспроизведение видео в Nexus 5».

Сценарий

Пошаговое описание воспроизведения бага. Обращайте внимание на предусловие и знаки, которые предшествуют багу (например, загорелась красная кнопка слева).

Дополнительно можно приложить скриншоты с указанием мест, на которые стоит обратить внимание (можно использовать приложения Joxi, LightShot и другие), для более сложновоспроизводимых багов — записать видео. Когда наберётесь опыта, можете снимать и прикладывать логи.

https://www.youtube.com/watch?v=zP4HH5dg7kc

В конце сценария указывается среда, в которой проводилось тестирование: версия приложения, прошивка девайса (Android 6.0.1, iOS 9.3.2). Если это веб-приложение, дополнительно укажите версию браузера.

Назначение бага

Далее нужно назначить на кого-то баг. Узнайте у менеджера проекта или ментора, на кого вешать данный баг, кто из разработчиков за какую область проекта отвечает. Так вы познакомитесь с командой, чтобы в будущем самому назначать баги.

Проставление критичности

Виды критичности багов в большинстве трекеров представлены следующим списком:

Immediate (Blocker)

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

Crit — Urgent

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

High

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

Normal

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

Low

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

Самообучение

О важности самообучения все прекрасно знают — мои наставления будут банальны. Так что сразу к делу.

Ниже — несколько книг, которые лично рекомендую своим стажёрам:

  • «Тестирование DOT COM», Роман Савин — очень полезное пособие, практически настольная книга начинающего тестировщика. Содержит в себе львиную долю знаний для того, чтобы начать тестировать и успешно отвечать в ходе собеседования на вопросы, касающиеся технико-теоретической части.
  • «Как тестируют в Google» — более глубокая книга, описывающая организацию процессов, различные стратегии и подходы к тестированию. Книга помогает понять, что такое качество, как и на каких этапах на него можно влиять.
  • «A Practitioner’s Guide to Software Test Design», Lee Copeland — в книге расписаны виды тестирования как «белым», так и «чёрным» ящиком. Перечислены различные техники тестирования, а также то, как ими пользоваться и когда лучше применять. В книге можно найти интересную статью об исследовательском тестировании, которая очень полезна для начинающих тестировщиков.

Источник: https://Lifehacker.ru/testirovshhik/

Суровая реальность начинающих тестировщиков. Пособие: что и как учить

Как проходит День тестировщика

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

Считается, что сфера тестирования — это самый низкий порог для вхождения в сферу ИТ. На курсы тестирования приходят и таксисты, и строители, и домохозяйки — да все, кому не лень. И возраст — от 16 до 40. Но что ждёт их после?

Предположим, в Киеве 10 школ тестирования, в каждой из них за полтора месяца обучается по 15 человек. Затем — следующий курс. Выходит, каждый месяц около сотни человек со всех школ «готовы» идти и набираться опыта.

Теперь проанализируем количество вакансий. Я открыл dou.ua, а также it.rabota.ua, и нашёл аж 5 вакансий для Trainee/Junior Test Engineer. Предположим, что вакансии в течение месяца добавляются, и в целом их 10 штук.

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

Отсюда и появляется конкурс 50, 100, 200, 400, … человек на позицию — попасть на вакантное место не просто. HR-ы получают от 50 писем в день, в которых находятся резюме юных тестировщиков без опыта.

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

И в конечном итоге после 1-4 месяцев безуспешного поиска работы энтузиазм занять место под солнцем сходит на нет.

Итак, мы разобрали банальную стратегию неудачного старта в ИТ. Теперь попробуем найти хоть какой-то выход.

Алгоритм трудоустройства тестировщиком имеет 5 этапов:1. Прохождение курсов;2. Рассылка резюме;3. Собеседование;4. Ожидание;

5. Получение работы.

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

А нужны ли курсы?

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

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

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

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

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

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

А скорость решения разнообразных постепенно вопросов увеличивалась в разы.

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

— проблемы с самодисциплиной или нехваткой общения.

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

Хотите платить деньги (3k грн и больше) — платите, но потом не говорите, что вы закончили курсы, получили немыслимо красивый сертификат, а найти работу не можете. Всё дело не в курсах, а в вашем желании и мышлении. И не важно, техническая специальность у вас или нет. Я, например, по образованию экономист, и это не помешало тестировать и программировать в автоматизации.

Что учить самостоятельно

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

Мои уроки были бесплатными — я сделал их ради удовольствия и помощи друзьям и близким, которые хотели жить по-другому. Было 3 набора людей по 10-15 человек.

Из 1-го набора — 20%, из 2-го — 40%, из 3-го — 80% устроились на работу в течение 1-2 месяцев. Каждый раз я совершенствовал программу, подгонял ее под реалии рынка.

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

Итак, моя программа:

1. Базовые знания

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

Я рекомендую «Тестирование DOT COM» Романа Савина. Она большая, но читается на одном дыхании. Написана простым языком со смешными вставками.

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

Занимает времени => 1 неделя

2. Практика

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

Например, структура ответа на вопрос о том, как протестировать поле для ввода:1. Позитивные сценарии;2. Граничные значения;3. Эквивалентные классы;4. Негативные сценарии;

5. Еще придумайте свои варианты.

Посмотрите вот это видео, оно очень полезное для разнообразного виденья:

Тренируйтесь писать тест-кейсы и баг-репорты с полями:1. ID;2. Summary;3. Description;4. Severity/Priority;5. Expected result;

6. Actual result;

И не важно, где это будет — в Jira или Word, или даже в вашем уме.

Занимает времени => 1 неделя

3. SQL

Здесь вам пригодятся следующие сайты:
— w3schools.com/sql
— quizful.net/test

Тут — и теория, и практика по написанию запросов к базам данных. В последнем найдёте не только SQL. Стандартные вопросы по SQL: select, update, insert, delete, join (left, right, full), where, , functions. Но всё-таки лучше ориентироваться и во всех остальных.

Занимает времени => 1 неделя

4. Unix

Скачайте и установите Linux. Например, Wubi вам отлично в этом поможет. И Windows не попортите, и удалить легко сможете. Как его установить — Google вам в помощь. :)

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

Занимает времени => 2-3 дня

5. Selenium

Знания по автоматизации лишними не будут, хотя не думаю, что они вам сразу понадобятся. Опять же, идём в Google или на .

Посмотрите стартовый урок по IDE. Потом, если понимаете программирование, переходите на WebDriver. Если нет, начинайте понемногу учиться кодить, но не увлекайтесь, — сейчас это не профильное ваше задание. Разберите базовые команды Selenium IDE и хорошо с ними попрактикуйтесь.

Относительно программирования советую начинать изучение с основ C# или Java. После, если захотите, сможете без проблем в течение двух недель перейти на любой другой язык.
Мой путь был следующим: C => C++ => Java => Ruby

Занимает времени => 2-3 дня

6. Сети

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

Выучить бэкграунд вам поможет следующий материал — статья на habrahabr, это нулевая часть цикла «Сети для самых маленьких». Если сложно читать, есть видео на ютубе. Мне очень помог урок 2. Важно разобраться, что такое OSI, TCP/IP, HTTP, как проходит PING между двумя компьютерами.

И на собеседованиях я часто получал вопросы относительно сетей.

Занимает времени => 2-3 дня

7. Английский

Без английского будет сложно, поэтому советую или найти друзей-американцев, или пойти все-таки на курсы. В Киеве могу посоветовать бесплатные курсы английского с живыми американцами, куда я сам ходил: Big City English Club (Вернадского, 4).

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

Занимает времени => 1-2 месяца

Другое

Бывает, что в вакансии попадается что-то нестандартное, что вы не учили на курсах или не разбирали самостоятельно. То есть инструменты, которые зависят от проекта. Например: XML, JSON, HTML, CSS, XPath, CssSelectors, RedMine, TrackStudio, PivotalTracker, Jira, GIT, SVN, VMware, Selenium RC/GRID, SOAP-UI, TestComplete, Ranorex, Continious Integration Servers и т.п.

Но большинство таких технологий учатся за неделю. Если видите незнакомую технологию, сядьте перед монитором, и потратьте 2-3 часа. Это намного эффективнее, чем просто сидеть и бояться, что вы чего-то не знаете. Потом запишете эту технологию в свое резюме. Но только не пишите в него то, чего не знаете.

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

Как видим, весь процесс обучения займет ориентировочно 1-2 месяца, в зависимости от вашей скорости обучения. Точно так же, как и на курсах. Зачем платить за курсы, если вы можете всё это выучить сами? Было бы желание.

Что поможет получить работу

Документ по окончанию курсов, к сожалению, не поможет.

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

Кому нужен тот сертификат? А вот настоящий опыт с гуглом и ютубом — ценное преимущество. Если вы протестируете несколько сайтов с помощью тысячи тест-кейсов с разными поисковыми данными — это уже что-то.

Можно написать в сопроводительном письме к резюме, что вы готовы поработать на фирму бесплатно 3-… месяца. У меня знакомый бесплатно работал 6 месяцев программистом (специализировался на авиации) — научился, и теперь неплохо живёт.

Вам важно попасть в сферу ИТ и получить практический опыт. Не бойтесь недополучить $100-500 в первые месяцы. Подработайте где-нибудь в вечернюю или ночную смену. Сейчас вам главное попасть в сферу ИТ и получить практический опыт, а всё остальное приложится. Очень важно полюбить эту профессию, а не гнаться за деньгами.

Ещё один вариант: если у вас есть знакомый в сфере программирования или тестирования, попросите его платить вам $30-50 в месяц за то, что он будет вам давать что-то тестировать. Конечно, это не много по деньгам, но это опыт, и потом вы сможете смело написать в резюме: freelance, 2 месяца. Это будет честно, ведь вы получили реальный практический опыт.

Кстати, многие компании не показывают все вакансии на it.rabota.ua. И часто стараются их закрывать внутренними силами. Лучше всего делать так: на jobs.dou.ua/ratings смотреть список компаний, а потом открывать официальный сайт каждой и изучать открытые вакансии, и просто отсылать резюме независимо от того, есть там вакансия или нет.

Как мне кажется, сейчас нужно быть в разы более проворным и смекалистым, чем 2-3 года назад, так как наплыв людей в ИТ-сферу сильно увеличился, а вам надо выделить себя среди остальных кандидатов. Поэтому, кроме стандартных способов (простая рассылка резюме), стоит искать что-нибудь нестандартное. Некоторые идеи и варианты я привёл выше.

Выводы

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

Согласитесь, если вы не пошли на курсы и не получили работу, то, как минимум, вы не потратили деньги просто так. А если пошли и не получили, то потраченные деньги потом долго будут висеть в файле «log» ваших мозгов.

Здесь вам выбирать путь. Если есть желание, найдется и способ.

Будут вопросы — пишите: igor.nikityuk@gmail.com, skype: igor_nikityuk_

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

Подписывайтесь на наш Telegram-канал для джуниоров, чтобы не пропустить интересные вакансии, стажировки, курсы, статьи.

Темы: карьера, Суровая реальность начинающих тестировщиков, тестирование

Источник: https://dou.ua/lenta/articles/testing-newbie-guide-0/

7 советов, как не взбесить коллегу-тестировщика в его праздник

Как проходит День тестировщика

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

David Goehring CC BY

1. «Перепроверь-ка еще разок, там точно нет бага»

Начнем с фундаментальной проблемы. На форуме Ars Technica есть старая ветка, в которой один разработчик рассказывает о глубокой ненависти к «педантичным» тестировщикам. Его ужасно раздражает, что некоторые специалисты по тестированию тратят часы на поиск мельчайших багов. И что самое неприятное, они их всё-таки находят.

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

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

Юмор помогает прийти к взаимопониманию в этом вопросе. Вот статья, в которой тестировщики собрали «золотой фонд» высказываний разработчиков, пытающихся защитить свой код.

Советуем пробежаться по ним и представить, как эти «классические» фразы звучат с точки зрения тестировщика.

2. «До релиза неделя. Надеюсь, на ближайшие два дня ты не планировал других дел»

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

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

Как быть: Есть несколько моделей разработки. С точки зрения QA различают два основных подхода: каскадный и Agile. В первом случае тестировщики получают фрагменты кода поэтапно. Во втором случае они тестируют код параллельно с его написанием.

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

Tim Regan CC BY

3. «Я быстренько подправил код. Посмотри, пожалуйста»

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

Что может пойти не так: Проблема в том, что код после поверхностных изменений зачастую возвращается с еще большим количеством багов. Тестировщик тратил время на составление подробного отчета, а в ответ на него получил какую-то отписку. Ему предстоит пройти этот путь ещё несколько раз только потому, что разработчик не хочет тратить время на «незначительные баги».

Как быть: Очевидно, не стоит торопиться. Но этого мало. Нужно разобраться, почему вы не уделяете должное внимание отчету. Если это банальная лень, помочь себе можете только вы. Бывают и другие причины. Например, вы считаете, что QA-инженеры заваливают вас отчетами о малозначимых багах.

Тогда нужно прояснить этот вопрос на уровне руководства — должны ли тестеры отвлекать вас «по мелочам». Скорее всего, ответ будет положительный. Некоторые продакт-менеджеры даже просят разработчиков специально добавлять в код мелкие баги, чтобы тестировщики были всегда настороже.

Важно принять этот подход и относиться к баг-репортам с должным вниманием.

4. «Кажется, я уже разобрался с этим багом. Но точно не помню»

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

Что может пойти не так: Разработчики устраняют какой-то баг, вносят, как им кажется, «незначительные» изменения в код, забывают уведомить об этом тестировщиков и отсылают код на релиз. В итоге проблема всплывает, когда уже слишком поздно. И «крайним» зачастую оказывается тестировщик.

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

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

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

Tim Regan CC BY

5. «Почему это я должен тестировать? Я же не тестировщик!»

В некоторых командах ответственность за отладку всецело лежит на тестировщиках. Разработчики не утруждают себя тратой времени на самые очевидные unit-тесты. Они уверены, что это не их работа. По большому счету, так и есть, хотя существуют разные точки зрения на вопрос (с мнениями сообщества можно ознакомиться здесь).

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

Как быть: Многие разработчики выступают за самостоятельные тесты перед отправкой в QA-отдел. Это помогает не только разгрузить тестировщиков, но и научиться смотреть на продукт с точки зрения критика и пользователя.

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

В любом случае — даже если в команде есть QA-инженеры, жесткое разделение на разработчиков и QA — не самый оптимальный подход.

6. «Игорь, сегодня работаешь в паре с Олегом. Тебе понравится»

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

Что может пойти не так: Это эффективный способ отлавливания багов, но у него есть и минусы — люди могут быть не в восторге от нововведений.

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

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

Как быть: Главный совет — не рубить с плеча. Agile- и DevOps-практики могут казаться привлекательными, но без должной подготовки не дадут результата.

7. «Я возьму твой девайс для тестов, ты же не против?»

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

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

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

Dave Allen CC BY

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

Источник: https://habr.com/post/422513/

«Стал „тестировщиком“ за два дня»

Как проходит День тестировщика

Привет! Меня зовут Илья, и с сентября 2013 года я занимаюсь ручным тестированием. Сейчас работаю ведущим тестировщиком в Bell Integrator. В этой статье я расскажу, как начать карьеру в сфере QA, чем высокооплачиваемый тестировщик отличается от обычного и как прокачаться, чтобы тебя ценили. Главным образом буду говорить о ручном тестировании, но затрону и автоматизированное.

Как я сменил профессию за два дня

Я получил диплом экономиста, пару лет поработал по специальности — и понял, что заниматься этим я себя заставляю. Ушёл. Около года провёл в продажах и параллельно искал, чем заниматься дальше. И вот однажды я вспомнил кое-какую статью про тестирование и разговор со знакомым, который тестировал телефоны Motorola.

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

Основное — виды и уровни тестирования, реляционные базы данных и классы эквивалентности (одна из техник тест-дизайна). Я вбил это в поисковик и попал на сайт protesting.ru.

Информация там структурирована и хорошо изложена. Почитал, вник.

На следующий день я успешно прошёл собеседование в компанию с броским названием S&T International. Так начался мой путь в тестирование и IT в целом. Но не всё так просто. Получить работу — ещё не значит стать крутым специалистом. Поэтому самое интересное началось дальше.

Ожидания работодателей

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

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

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

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

Главные заказчики IT-услуг сейчас — банки, страховые фирмы и телеком. Идёшь работать в банк? Подучи банковские термины.

А если собираешься тестировать оборудование для нефтегазового сектора, на одной теории далеко не уедешь. Придётся изучать «железо».

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

О чём спрашивают на собеседовании

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

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

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

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

Чтобы войти в профессию, мне хватило материалов с protesting. А в более продвинутых темах я разобрался, обучаясь в GeekBrains по профессии «Тестировщик ПО». Например, освоил более сложные техники тест-дизайна, чем классы эквивалентности. Эти знания пригодились. 

Приведу пример «до» и «после». На телефонном собеседовании в крупном банке меня спросили, какие техники тест-дизайна я знаю. Ответ их не устроил, но мне дали ссылку на тест, где надо было набрать от 65% правильных ответов.

Увы, в тот раз мне даже поисковик не помог — настолько хитро были поставлены вопросы. А вот после курсов этот же тест на другом собеседовании я уже прошёл и получил предложения от нескольких отделов того же банка.

Правда, всё равно к ним не пошёл — отпугнули бюрократией. Но это другая история.

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

Примеры тестовых заданий

В банке мне дали схему XML-сообщения в виде таблицы с описанием полей и указанием, обязательны ли они. Нужно было проверить все варианты отправки сообщения.

В крупной розничной сети предложили более масштабное задание. Показали схему работы кассового складского оборудования и тестовую БД. Требовалось установить СУБД Firebird, написать несколько SQL-запросов для формирования выборки и составить тестовую модель по схеме работы.

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

Другой пример — задание на автотестирование от разработчика ПО. Надо написать на Python класс Deposits, который парсит страничку www.banki.ru и собирает информацию из блока «Предложения месяца > Вклады».

Результат должен выглядеть как таблица, где напротив названий вкладов — проценты. Дополнительно просят реализовать дочерний класс, который наследуется от Deposits и подбирает наиболее и наименее выгодный вклад.

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

Просили рассказать о самом интересном (!) случае из практики, а ещё — в чём состоит тестирование, что такое качество, какой у меня опыт автоматизации, какие пять команд Linux я чаще всего использую в работе.

Ещё просили назвать две-три книги или статьи по тестированию и программированию, а затем рассказать, что я из них вынес. На очном собеседовании давали тесты по SQL-запросам и командам Linux.

Кстати, когда вас спросят, какие книги по тестированию вы прочли, рекомендую назвать «Быстрое тестирование» (Калбертсон, Браун, Кобб) и «Тестирование DOT COM» Романа Савина. Чтобы понимать, о чём речь, прочтите хотя бы вступление к каждой из этих книг, а лучше — первую главу :)

Этапы развития и как их проходить

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

Джуниор. Ты проходишь подробные тесты, составленные кем-то другим. Задумываешься, на чём они основаны, и внезапно открываешь для себя существование документации. Отныне ориентируйся на неё! Даже если тест-кейс ей противоречит.

Тестировщик. Ты тестируешь программу по документации и ориентируешься на описание функциональности.

Тест-дизайнеры как отдельные работники — редкость, поэтому ты сам придумываешь, как протестировать приложение, чтобы отловить все возможные ошибки. Сам пишешь подробный план тестирования и тест-кейсы.

Дальше группируешь тест-кейсы логически и раздаёшь джуниорам. Это уровень старшего и ведущего тестировщика.

Исследователь. Самый сложный уровень — exploratory testing. Нет ни тестовой модели, ни подробной документации (в лучшем случае — список задач для разработчиков). Задача — найти все баги ПО. Тут придётся включить фантазию и моделировать работу конечного пользователя. Да не простого, а пользователя-ломателя.

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

Но прежде всего надо разобраться:

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

Полезно уметь подключаться к серверу или удалённой машине с помощью программ типа WinSCP. Но они только показывают файлы (в том числе логи), а для отправки команд серверу понадобится изучить ещё и Putty либо аналог. 

Плюс надо понимать, что такое командная строка, и знать основные команды Linux. Открою секрет: на первых порах можно ограничиться пятью командами, но их придётся запомнить.

Условия карьерного роста

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

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

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

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

Горизонталь и вертикаль

Профессиональный рост бывает вертикальным и горизонтальным. 

Для вертикального роста надо развивать административные и управленческие навыки, но и про техническую часть не забывать. Пусть ты уже не ловишь баги лично, но как руководитель должен понимать, кому передать задачу и как распознать обман, когда подчинённые говорят: «Сделали всё, что могли, но это надо тестировать четыре дня».

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

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

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

Помимо автоматизации есть ещё нагрузочное тестирование. Тут тоже надо быть немного программистом (писать скрипты) и аналитиком — уметь анализировать результаты.

Третий путь — совместить предыдущие варианты и стать универсальным специалистом. Для этого необходимо подтянуть навыки программиста и аналитика.

Я хочу попробовать себя в Data Science. Тут очень пригодится школьный и университетский курс математики и статистики.

О стереотипах

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

О личных качествах тестировщика

Мне запомнилась статья, где сказано, что хороший тестировщик «обладает ломательной психологией» :) Ещё говорят, что он должен понять то, чего не понял разработчик. Лично я считаю, отличие здесь — в направлении внимания к продукту. Разработчик глубоко знает узкую тему, а тестировщик меньше роет вглубь, но смотрит шире.

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

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

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

Хотите узнать больше о выпускниках курсов и факультета тестирования ПО GeekUniversity? Вот их истории:

Источник: https://geekbrains.ru/posts/stal-testirovshchikom-za-dva-dnya

День тестировщика: полезные навыки и будущее профессии

Как проходит День тестировщика
База знаний ИИБаза знаний ИИ

ЛентаДень тестировщика: полезные навыки и будущее профессии

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

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

Какие навыки нужны тестировщику

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

В будущем профессия трансформируется: тестировщикам предстоит больше работать на стыке физических объектов и программных алгоритмов.

Системы «умный дом», интернет вещей (IoT), развивающаяся робототехника — вектор тестирования смещается с веб-пространства на материальный мир.

Поэтому, возможно, придется поработать «руками», пригодится понимание электротехники и механики. Но и знание универсальных техник тест-дизайна останется актуальным для тестировщиков.

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

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

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

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

Но тем не менее усиливается роль автоматизированного тестирования, теперь сложно удивить Selenium'ом, и все шире внедряется язык Gherkin.

По словам Сидорова, намечается стойкий тренд на эти знания, который будет только усиливаться из-за распространения BDD и развития фрэймворков автоматизированного тестирования. Это можно проследить по тому, какие специалисты востребованы в США, где практически нет ручного тестирования.

В компании Bell Integrator уверены, что тестировщик будущего обладает широким спектром навыков, объединяя знания в сфере программирования и DevOps.

Эпоха monkey-тестеров уходит. Все чаще от тестировщика требуется умение писать автотесты, разворачивать тестовые стенды на виртуальных средах или настраивать элементы CI/CD.

От тестировщиков ждут навыков автоматизированного и юзабилити-тестирования, а также умения работать в проектах с Agile и DevOps. В компании «Мегафон» считают, что эти способности помогут быстрее выпускать на рынок качественные продукты. Кроме того в последнее время все большее распространение получает автоматизированное тестирование. 

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

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

Что искусственный интеллект изменит в работе тестировщика

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

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

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

Уже сейчас команды сталкиваются с тем, что старые классические схемы и подходы в тестировании не подходят в продуктах с искусственным интеллектом. Потому, по мнению экспертов ДИТ Москвы, в ближайшие несколько лет будут формироваться знания и опыт, в результате которых появятся новые методики.

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

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

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

Несмотря на то, что часть работы тестировщиков в перспективе перейдет роботам, говорить о полной замене человека вряд ли стоит, уверены в компании «СКБ Контур».

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

Как отмечают эксперты, системы с искусственным интеллектом и сами требуют тестирования. 

Допускаю, что вскоре появятся инструменты или framefork’и, которые позволят упростить автоматизацию тестирования с помощью ИИ.

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

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

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

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

Ручное тестирование будет все больше заменяться автоматизированным.

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

Роль тестировщика существенно изменится, и мы в Digtial Билайн уже идем постепенному к этому, запуская продукты по AI, проводя автоматизацию тестирования.

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

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

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

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

Работа в данном направлении начата и боты ИИ-тестирования уже проходят обучение.

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

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

Тестировщики с такими компетенциями станут дефицитом на рынке труда за счет сочетания качеств data scientist, разработчика, специалиста по ИИ и т.д. Подобные компетенции потребуются для тестирования софта путем подачи в ИИ-алгоритм огромных массивов данных о работе решения с последующим анализом.

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

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

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

Развитие AI/ML однозначно не «убьет» тестирование, отмечают «Инфосистемах Джет». Однако любая новая технология требует освоения, и тестировщик обязан быстро вникать во все новое. 

Чтобы разместить вакансию тестировщика в еженедельной подборке на ICT.Moscow, пришлите ссылку на запись в с информацией о ней.

#искусственный_интеллект#машинное_обучение#нейросети

#комментарии#тестирование

#Билайн#МегаФон#ДИТ#Инфосистемы_Джет#Сбербанк

Источник: https://ict.moscow/news/den-testirovshchika-osobennosti-raboty-i-razvitie-professii/

Делаем просто
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: