В чём заключается работа тестировщика программного обеспечения?

Тестирование - неотъемлемый этап разработки программного обеспечения. Если не вдаваться в сугубо профессиональные детали, то всё на первый взгляд просто. Разработка всегда начинается с того, что пишется некоторый документ (или даже комплект документации), определяющий: каким функционалом должен обладать новый продукт или его часть, модуль, фича; какие методы разработки будут применяться; какие технологии, протоколы, схемы, сторонние продукты будут использоваться при работе этого продукта; формат и условия ввода-вывода, взаимодействие частей продукта между собой и всего продукта в целом со средой, пользователями, базами данных...; виды пользовательских интерфейсов (консольных, графических...), наборы и синтаксис используемых команд и поведение продукта в различных штатных и особых случаях. Короче говоря, детальное описание будущего продукта.

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

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

Затем наступает фаза, когда появляются тестовые образцы "готового" кода и необходимо его тестировать. Если формально, то применять по очереди согласно плана те самые созданные заранее кейсы и смотреть за результатами. Если результат отличается от указанного в кейсе или вообще всё сломалось, то это баг и надо срочно его куда-нибудь заносить. Инструментов для этого куча. Это два.

По всему этому пишутся отчёты. Куча отчётов. Потом ещё отчёты. И ещё один отчёт... Это три.

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

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

Конечно, это всё вот так, на пальцах и сумбурно. Но, во-первых, повторюсь, в Сети очень много чего написано про тестирование ПО, а во-вторых, тут всё очень субъективно и часто "завязано" именно на проект и принятую в команде методологию.

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

Тестирование ПО это интересно, сложно и очень нужно. И скажу больше, тестировщики есть не только в IT. Помните эти печати ОТК? Это тоже тестировщики. Тестируется всё - от лампочек до карьерных самосвалов. Я уже молчу про космические корабли, которые бороздят. Кто-то тестирует телефоны, кто-то даже тестирует TheQ потихоньку, а кто-то тестировал вашу дверную ручку.

Тестировщики (а официально инженеры по качеству) повсюду.

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

Подробнее - https://osa-it.ru/