Всё что вы хотели знать о Тестировании программ, но боялись спросить...

На Пикабу видел просто трильярды постов про программирование -  "C# за 21 день", "Unity игры и с чем их едят", "Лёгкий способ начать кодить" и прочее. Но почему-то я не встретил ни одного поста про тестирование! А ведь зря!
Короче, сидел я, писал доки и решил - вдруг кому будет интересно почитать не только про разработку, но и про другие области IT?

Всё что вы хотели знать о Тестировании программ, но боялись спросить... QA, Тестирование по, Тестировщики, Длиннопост, IT

Я работаю QA-Engineer'ом (Quality Assurance - обеспечение качества). QA - это человек(или целый хайвмайнд под названием "QA team"), основная задача которого - обеспечить, чтобы багов было ПРИЕМЛЕМОЕ КОЛИЧЕСТВО. Да, наша работа - не искать баги, а сделать так, чтобы баги не мешали бизнес-логике. Потому что есть такая аксиома - "Баги есть всегда". И это именно аксиома - если вы долго-долго-долго думали над структурой проекта, сделали всё вот прям идеально и сидите весь такой довольный с мыслью "А у меня в коде нет багов" - вы просто не залезли глубоко в свой проект))(Особо верующие в возможную непогрешимость девелоперов могут гуглить заезженную историю про американский самолёт в Мёртвом море и ошибку отрицательной высоты)


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

Всё что вы хотели знать о Тестировании программ, но боялись спросить... QA, Тестирование по, Тестировщики, Длиннопост, IT

Несведущий человек скажет: "Ну что это за работа? Сиди да пялься в экран, тыкай кнопочки и проверяй, чтобы сообщение об ошибке было!". И будет неправ. Поверьте, если бы моя работа заключалась в том, чтобы сидеть на заднице ровно, рандомно тыкать кнопки и кричать "Я нашёл баааааг!!!", уворачиваясь от кружек девелоперов -- Я был бы счастлив. Первые две недели. А потом бы сильно заскучал.
На самом деле, бОльшая часть работы тестера - это документация. Ооооо, великая и ужасная Документация! Тестировщик - работа, требующая комплексного подхода, а чтобы покрыть всё - нужно это записывать. Если алгоритмизировать, то работа тестировщика выглядит примерно так:
1)QA получает от бизнес-аналитика Specification(подробное техническое задание продукта)(и я буду сознательно применять английские термины ибо стандарт отрасли)
2)QA по документации пишет Test-cases(тестовые случаи, некий блок действий, которые нужно совершить для проверки фичи). И пишет он именно по документации, зачастую даже в глаза не видя продукта.
3)QA прогоняет кейсы. Если найден баг - заводится Bug report, и отправляется девелоперу (С комментариями "ахаха, нуп, тупейшая ошибка, лал!"(нет))
4)После исправления багов QA проводит Regression Test - проверка уже проверенных кусков фич, дабы фиксы багов не создали другие баги.
5)Если в спринте(а тут несведущим можно почитать про Agile методологии менеджмента проектов) багов нет - можно выпускать версию.
6)...
7)И вот так обычно не работает))) Это всё - в идеале, обычно все эти стадии идут вперемешку - QA может одновременно и покрывать кейсами новую фичу, и тестить продукт, и даже тестить без документации(Ad hoc), дабы просто выпустить минимально значимый продукт.

Давайте о стереотипах:
1)"Ничего делать и знать не надо, сиди да тыкай!!!" - а вот и неправда. Если тестер не знает например SQL и в принципе базы данных - он не сможет придумать, какие проверки стоит включить в тест-кейсы(например, он фатально упустит проверки про SQL-иньекции, и хитрый корейский хакер сделает DROP DATABASE, и больше не будет какого-нибудь сайтика). Тестер прогуливал в школе JSON - и когда придёт время тестить API он будет сидеть и хлопать глазами. По-хорошему, для работы тестировщиком желателен университетский курс инженера-программиста. Ну или 2 книжки по тестированию и пару месяцев изучать дополнительные технологии.
2)"Тестер ничего полезного не делает, на проекте всё делают программисты!" -  отчасти правда. Да, я не пишу код на продакшен. Но я обеспечиваю качество - я делаю так, чтобы юзер не страдал от ошибок. Ошибки не нравятся никому. И QA - он не только находит ошибки, его задача - и предотвращение ошибок. QA тестит всё что угодно - продукт, макеты, документацию, ̶т̶в̶о̶ю̶ ̶м̶а̶м̶к̶у̶(Простите, Хованский головного мозга разыгрался). QA всегда участвует во всех Scrum meetings(встреча команды с утреца), где слушает и перебивает всех своими кулстори во избежание багов.

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

DELETED
Автор поста оценил этот комментарий

а какие книги посоветуете?

раскрыть ветку (1)
5
Автор поста оценил этот комментарий

Роман Савин "Тестирование .com"
Святослав Куликов "Тестирование программного обеспечения"

показать ответы
3
Автор поста оценил этот комментарий

Дружище, вот тебя то я и ждал) Суть в чем, работаю продажником (не IT), образование чисто гуманитарное, 27 лет, есть желание всё бросить и начать с чистого листа, ненавижу продажи.. Как-то взгляд остановился на работе тестировщика - работа с компами, возможность работать удаленно, гораздо меньше живого общения с людьми, да и наверное еще в юности зацепили тексты Юры Бригадира, что наложило отпечаток) Сейчас читаю Савина. Что дальше? Куда идти, что читать, на чем практиковаться? Насколько Савин близок к реальности (а то тут некоторые пишут, что и тест-кейсы бывают не так часты в реальности и всё более условно)?

раскрыть ветку (1)
5
Автор поста оценил этот комментарий

курсы от крупных компаний(Я из РБ, так что рассказываю наши реалии), EPAM... на курсах дадут необходимый для старта опыт и понимание структуры работы в IT. Главное - иди на БЕСПЛАТНЫЕ курсы! суть бесплатных курсов в том, что с них компании готовят себе кадры, и они заинтересованы в хороших работниках.
Савин - он довольно актуален, но учти, это beginner уровень, ТОЛЬКО Савина для работы недостаточно.
Практиковаться - возьми любой сайтик да составь на него тестовый сценарий)

1
Автор поста оценил этот комментарий

было бы неплохо ознакомится с литературой, которая помогла на пути становления qa

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

я тут уже 3 раза написал)))
Савин Тестирование дот ком
Куликов Тестирование ПО

показать ответы
2
Автор поста оценил этот комментарий

Ну и две книжки по тестированию сюда зарекомендуй.

раскрыть ветку (1)
7
Автор поста оценил этот комментарий

Достойные книжки, которые рекомендовали и на курсах, и в универе -
Роман Савин "Тестирование .Com"
Святослав Куликов "Тестирование программного обеспечения"
Книжки читаются влёт, легко и приятно.

показать ответы
4
DELETED
Автор поста оценил этот комментарий
Specification(подробное техническое задание продукта)

Вы наверно имели ввиду Requirement


QA всегда участвует во всех Scrum meetings(встреча команды с утреца)

Далекоооо не всегда.

раскрыть ветку (1)
6
Автор поста оценил этот комментарий

1)Каждая спека - это требования, но не каждые требования - это спека. Нам всегда вдалбливали в голову, что Requirements и Specification - две немного разные сущности. Спека поподробнее, может в себя например включать Data Dictionary и бизнес-рулы.
2)Горе той команде, QA которой не знает, что творится на проекте))

показать ответы
2
DELETED
Автор поста оценил этот комментарий

1) А, понял. У нас это называется документация и пишется в конце цикла девелопером на свою фичу с привязкой к коду. Писать ее на начальном этапе проектирования малоэффективно.

2) Зачем мне ходить на стенд-апы? Я и так знаю в нужном объеме то, что мне нужно знать. Если есть 3-4 независимых группы девелоперов, то я все утру буду по стендапам тусить, а не работать. Норм конечно, если цель "лишь бы помитинговать да потрекаться" =))

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

1)У нас её пишет BA в самом начале. по спеке и кодят, и тестят, и обсуждают с заказчиком.
2)ну стендапы полезны бывают, можно без лишних проволочек поспрашивать девелоперов, они могут рассказать о  подводных камнях фичи, что протестить в этой фиче в первую очередь...

показать ответы
2
Автор поста оценил этот комментарий

У кого-то личная попаболь к автору или ко всей теме вообще?=)

Почти все коменты заминусованы были без объективных причин, аж устал исправлять.

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

да я не ради лайков же))) так, самовыражение.

1
Автор поста оценил этот комментарий

Продвижение в QA необходимо начать с нормального знания английского языка?

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

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

1)да
2)Несомненно легче, но фича в том что это 2 необходимых навыка. если ты ручной тестер - ты обязан знать английский, какой бы ни был твой уровень.

Автор поста оценил этот комментарий
Заходи в лигу, буду рад
раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Замётано)
Автор поста оценил этот комментарий

Сертификат ISTQB есть ?

Позиция я так понимаю не senior раз описана "вся" документация ?

И да, QA Engineer это не про тестировщиков. Позиция называется Software tester. И это не разница терминов. Требования к QA Engineer и Software tester на западе явно показывают разницу.

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

1)У меня есть более выгодные способы потратить почти 200 баксов.
2)Я не описывал всю документацию, иначе читатель вывернет челюсть в попытке зевнуть. но да, я не сеньор

Автор поста оценил этот комментарий

Wikitext-ru.svg Эту статью следует викифицировать.


Пожалуйста, оформите её согласно правилам оформления статей.


Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестаёт работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).


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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

я не сказал, что регресс проводится после фикса. регресс проводится после теста фиксов. "После исправления багов QA проводит Regression Test - проверка уже проверенных кусков фич"

4
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

да, согласен по всем пунктам!

1
Автор поста оценил этот комментарий

Проект на работе как раз проходит активную стадию QA, ох и бесите вы меня. Хотя я понимаю важность и нужность вашей работы, но бесите :D

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

примем за комплимент)))

10
DELETED
Автор поста оценил этот комментарий

Я уже писал это раньше в похожем посте и повторю еще раз. :)

Quality Assurance есть не тестирование, а обеспечение качества - работа с процессами на разных этапах разработки, проверка на соответствие стандартам и константный доеб менеджмента/девов/аналитиков на предмет того что код говно, на стандарты положен болт, дочь СЕО трахает аналитик, на кухне нет кофе, да и вообще все криворукие. По обязанностям действительно что-то между бизнес аналитиком и тестировщиком, только сам не тестирует. И да - реально QA вы найдете в действительно больших или очень серьезных проектах (крутой файнанс и банкинг например), потому что во проектах средней руки эти обязанности будут разделены между тест лидом, тест менеджером, архитектором и бизнес аналитиком. Куа может стоить серьезную деньгу, а тестировщик будет в среднем не дороже кодера.

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

раскрыть ветку (1)
6
Автор поста оценил этот комментарий

Ну термины - штука размытая, в разных процессах QA может принимать разные трактовки.

2
Автор поста оценил этот комментарий
А ещё иногда эта документация написана и вам выдана, но потом выясняется, что заказчик уже сто раз передумал, а новой доки ещё нет. И вот начинается это вылавливание комментариев, цитат из переписки, и всего такого. И как правило, они местами друг другу противоречат) а ещё ирогда тз на уровне "сделайте нам вот так", а о подробностях этого "вот така" надо выяснять чуть ли не клещами)

Но вообще да, когда есть хоть какое-то описание, это очень круто.
раскрыть ветку (1)
3
Автор поста оценил этот комментарий

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

2
Автор поста оценил этот комментарий

ТС, ты QA или AQA?
Где трудишься?)

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

QA
Всё тебе скажи))) Название не скажу, "поайпивычисляторы" вычислят, да и персональные данные, все дела.
Относительно небольшая контора, нас около 200 человек

1
Автор поста оценил этот комментарий
1. Как тестируют свои программы инди-девелоперы?
2. Я голосую за гайд по тестированию.
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

1)умные инди-девелоперы берут себе за еду в команду тестера. глупые - глупые инди-девелоперы сами и тестят свои продукты. Но нам ещё в универе вдолбили, что "Тот, кто пишет код - не может его тестировать!!"

2)посмотрим)

показать ответы
4
Автор поста оценил этот комментарий
Привет, коллега-багоборец!
Описанный текст, видимо, актуален для очень крупных команд.
В группах из 4-10 человек, по моему опыту, все чутка проще. Документации меньше, исследовательского тестирования больше, а тест-кейсы иногда заменяются на саму документацию (которую я по привычке именую диздоком).
раскрыть ветку (1)
3
Автор поста оценил этот комментарий

а вот кстати от проекта к проекту. был у меня один проект на старте карьеры, где я и доки в глаза не видел, тестируя Ad hoc)
А сейчас и проект не на крупную команду(всего 4 человека нас на проекте), но проект запутанный и сложный, и там без доков сложно.

1
Автор поста оценил этот комментарий

какие международные сертификаты тестировщика получали и какие пригодились?

какие могут пригодится?

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

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

показать ответы
2
Автор поста оценил этот комментарий

Сам пытался выполнить ТЗ на QA. Выполнил 90% ТЗ за 2 дня, дошёл до теста дубликатов (загруженных и созданных в системе) и тут влип вообще, ошибка на ошибке (хотя по идее так быть не должно), после перезапуска сервиса всё работает. Неделю думал как оформить в тестовом это. Время вышло - плюнул и пошёл в ТП этой же компании, с мыслью, что спокойно освоюсь и переведусь) Пока полёт нормальный.


А можешь сказать в принципе, что изучать человеку кроме данных двух книг (прочитал уже), после выполнения ТЗ - уже на работе и причём срочно? И на сколько актуален для QA - тех. англ? И ЯП для написания скриптов поначалу обязателен? Какой конкретно и уровень владения? SQL в целом общее понимание ( на уровне запросов) или конкретное знание той что в стеке? В целом какой уровень понимания базы IT нужен? Сетевые протоколы? Основы вёрстки? Ну и примерный план изучения технологий и до какого уровня можешь накидать - всем я полагаю будет полезно. За пост лови + :)

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

"А можешь сказать в принципе, что изучать человеку кроме данных двух книг (прочитал уже), после выполнения ТЗ - уже на работе и причём срочно? И на сколько актуален для QA - тех. англ? И ЯП для написания скриптов поначалу обязателен? Какой конкретно и уровень владения? SQL в целом общее понимание ( на уровне запросов) или конкретное знание той что в стеке? В целом какой уровень понимания базы IT нужен? Сетевые протоколы? Основы вёрстки? Ну и примерный план изучения технологий и до какого уровня можешь накидать - всем я полагаю будет полезно. За пост лови + :)"

1)Теории в данных книгах изложено достаточно, остальное - на практике
2)Английский - необходим, Intermediate+. у нас в компании документация на английском, переписка с заказчиком на английском, иногда даже daily meetup на английском. англ наше всё))
3)Поначалу - нет, но потом, когда например будут задачи протестить API - легче использовать jframe
4)университетский курс. Джойны, вью, триггеры
5)ну... не знаю как описать уровень понимания базы IT...
6)сетевые протоколы мастхев. не на мега-высоком уровне, но шутки про UDP и TCP понимать надо)) Http запросы, TCP...
7)вёрстка и CSS - мастхев.

показать ответы
8
DELETED
Автор поста оценил этот комментарий
Комментарий удален. Причина: данный аккаунт был удалён
раскрыть ветку (1)
4
Автор поста оценил этот комментарий

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

показать ответы
3
Автор поста оценил этот комментарий

2)"Тестер ничего полезного не делает.."

Это в нулевых осталось или мне везет? В любом случае инетересно что бы сказал такой "пограммист" перформанс-инженеру или автоматизатору, они относятся к QA.

раскрыть ветку (1)
4
Автор поста оценил этот комментарий

ну среди не-айтишных людей встречаются подобные. у нас даже 1 препод в универе подобное сказал как-то.

1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий

история про истребитель была напечатана еще в ЛКИ, кажется...

раскрыть ветку (1)
Автор поста оценил этот комментарий
Не в курсе, если честно, историю впервые услышал от брата лет 10 назад
показать ответы
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий
Уже есть, зайди в мой профиль, первый сверху)))
Но сразу говорю -- это был мой путь, может он и не самый быстрый и верный -- но он сработал.
1
Автор поста оценил этот комментарий

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

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

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

показать ответы
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

повторяю - привычка.

Автор поста оценил этот комментарий

4)После исправления багов QA проводит Regression Test - проверка уже проверенных кусков фич, дабы фиксы багов не создали другие баги.


ты точно тестировщик?

раскрыть ветку (1)
Автор поста оценил этот комментарий

А что можешь сказать о книге " Как тестируют в google" ? (Джейм Уиттакер Джейсон Арбон Джефф Каролло)

Ну и да расскажи как попасть в профессию, интересно :D

P.s. отличный постъ =)

раскрыть ветку (1)
Автор поста оценил этот комментарий

А давай я в следующем посте подробно распишу как попасть в профессию))

показать ответы
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
Автор поста оценил этот комментарий
Привычка.
1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

ну это уже прямо монструозно - тысячи человек))

1
Автор поста оценил этот комментарий
EPAM, да?
раскрыть ветку (1)
2
Автор поста оценил этот комментарий

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