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

На Пикабу видел просто трильярды постов про программирование -  "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) - в комменты всё отвечу)
Ну и чукча не писатель, как умею - так и говорю, профессиональные писатели посмотрят и наверняка увидят кучу стилистических ошибок. Опять же приветствую любую критику в комменты))

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

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

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

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

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

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

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

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

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

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

прямо с сайта EPAM)

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

спасибо

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

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

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

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

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

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

а какого уровня ISTQB?
они же разные, насколько я знаю

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

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

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

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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку