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

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

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

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

Несведущий человек скажет: "Ну что это за работа? Сиди да пялься в экран, тыкай кнопочки и проверяй, чтобы сообщение об ошибке было!". И будет неправ. Поверьте, если бы моя работа заключалась в том, чтобы сидеть на заднице ровно, рандомно тыкать кнопки и кричать "Я нашёл баааааг!!!", уворачиваясь от кружек девелоперов -- Я был бы счастлив. Первые две недели. А потом бы сильно заскучал.
На самом деле, бОльшая часть работы тестера - это документация. Ооооо, великая и ужасная Документация! Тестировщик - работа, требующая комплексного подхода, а чтобы покрыть всё - нужно это записывать. Если алгоритмизировать, то работа тестировщика выглядит примерно так:
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) - в комменты всё отвечу)
Ну и чукча не писатель, как умею - так и говорю, профессиональные писатели посмотрят и наверняка увидят кучу стилистических ошибок. Опять же приветствую любую критику в комменты))