Комментарии 7
мне особенно понравилось тестирование программного обеспечения
Я далек от тестирования, но тема, в принципе, интересная, поскольку, недавно опубликовал свой пет-проект ( https://habr.com/ru/articles/848836/ ) и, сейчас, самое время его протестировать. Естественно, делать это мне придется самому, поскольку проект абсолютно бесплатный.
Вы прямо не пишите, какими именно задачами занимаетесь. Но, по контексту, можно предположить, что это касается веб-программирования, поскольку про тестирование десктопных программ, я, на Хабре, статей не встречал.
Интересны были бы общие идеи в этом направлении. Пока же пользуюсь своей программой, пока не уткнусь в какой-нибудь неприемлемый баг. Потом, в зависимости от степени своей лени, пытаюсь устранить его. Только сам процесс устранения я называю отладкой. Меня же, интересует вопрос, а как, теоретически, этот процесс должен происходить на профессиональном уровне? Но, так как, данная тема не слишком «горячая» для меня, искать ответ, на Ютубе, влом. Хотя соответствующую статью, здесь, я бы прочитал.
Спасибо за интерес к статье!
На уровне разработки часто действительно сталкиваешься с подходом "протестировать, пока не наткнёшься на баг".
Профессиональное тестирование включает более структурированный процесс, который помогает найти деффекты до их обнаружения пользователем.
Рекомендации которые могу предложить:
1. Определите требования к продукту. Даже если это пет-проект, у вас есть требования и разбивка на функциональные блоки, судя по статье. Зафиксируйте требования письменно, это поможет не упустить критично важный функционал
2. Пропишите позитивные и негативные сценарии. Позитивные сценарии — это случаи, когда пользователь вводит корректные данные и использует приложение по назначению. Негативные — попытки нарушить работу программы: ввод некорректных данных, использование вне ожидаемых условий и т.д.
3. Ручное тестирование. Пройдитесь по всем сценариям, которые вы составили, чтобы найти дефекты.
4. Покройте код автотестами. Если у вас есть возможность, попробуйте внедрить юнит-тесты (например, с использованием библиотек JUnit, Pytest или других в зависимости от вашего языка программирования). Это поможет проверять логику программы автоматически при каждом изменении.
Тестирование веб или десктоп приложений могут отличаться тестовым окружением, но общим отстается требование к продукту из которого создаются тестовые сценарии.
Спасибо за подробные комментарии!
В принципе, все как бы понятно, за исключением концепции «автотестов». В чем именно здесь заключается автоматизация? И как это вообще выглядит? Типа, я пишу (вручную?) другие программы, которые запускают тестируемое приложение? Но, это же десктопные программы. Скажем, есть программа «Эксел», она стала, иногда, гдючить. Например, в части сортировки данных, то вообще отказывается сортировать их, то не позволяет сортировать по столбцам, без заголовков. А, при другом запуске, работает нормально. Какая, вообще, должна быть внешняя программа, чтобы протестировать подобные «непонятки»?
Другими словами, я представляю себе автотесты только как скрипты для доступа к веб-сервисам, с автозаполнением данных в полях форм, с последующим анализом ответов сервера. И то, только, для простых случаев. В сложных ситуациях, вижу только ручное тестирование. Вроде такого. Пользователю дается задание найти максимальное количество багов. Чем больше он их найдет, тем больше получит премию.
Для разработчиков ПО более практична, не столько технология (внешнего) тестирования (баги все равно, рано или поздно сами вылезут), сколько технология «правильной» разработки программы. Потому, что для сложных проектов заставить программу вообще работать – это уже успех. Основное (внутреннее) тестирование, при этом, происходит именно в процессе формирования кода и разработки эффективных алгоритмов. Самым очевидным решением для этого является логирование. Так, в своей программе, мне пришлось логировать практически всё. Чтобы, при, неправильной работе приложения, можно было в этих логах найти проблемные места. При этом, логирование работает в дебаг-версии программы, а в релизе – отключено.
А для разработки следующего проекта хочу внимательно ознакомиться с идеями написания «хорошего кода» по статье: «Структурный дизайн. Древний секрет простого и быстрого кода» ( https://habr.com/ru/companies/jugru/articles/858418/ ).
Но я решилась и записалась на 9-месячный курс по тестированию с нуля от Яндекс Практикума. Правда, закончить его не успела — на середине учёбы меня взяли на стажировку в Doubletapp и времени на прохождение практики на курсе не осталось, потому что я была Full-time загружена на стажировке.
После курсов мне хотелось скорее выйти на работу. Я попробовала пройти собеседование на стажировку в Doubletapp.
Хм... Что-то где-то не сходится. Так и тестируем
Спасибо за внимательное прочтение статьи!
Курс от Яндекса я действительно прошла наполовину, так как ушла на стажировку. Остальные курсы, упомянутые в статье, я завершила полностью, поэтому багов в формулировке здесь нет. Но приятно видеть такой внимательный подход — настоящая работа тестировщика!))
Спасибо за упоминание! Дельные советы :)
И от себя отмечу главное: не стоит сразу платить много тысяч за курс. Пройдите бесплатный, изучите профессию, а главное рынок, спрос и предложение. Тестирование пусть и является одним из самых очевидных направлений, которые хотя начать без кода, но и конкуренция возрастает в разы, а то и на порядок, именно по этому. Тестировщиков еще и меньше нужно, чем разрабов.
Тестирование с нуля: советы, которые я дала бы себе на старте