Тестирование ПО

Содержание
Изучение логов
Что такое логи
Типы логов (уровни)
Где находятся логи в Windows
Где находятся логи в Linux
Тестирование пользовательского ввода
Изучение спецификаций
Контроль версий
Обязанности тестировщика
Баг-трекеры
Документация
Полезно знать
Как задавать вопросы
Книги и статьи о тестировании
Словарь
Другие статьи о Тестировании
Тестирование API изображение с сайта www.andreyolegovich.ru
Фото: freepik.com

Цель работы тестировщика

Зачем нужно тестировать софт?

Идёт 2024-й год и такой вопрос задают реже, но ответ на него знать нужно.

Если вы тестируете свой личный софт - вам виднее.

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

Тестировщик вообще нужен бизнесу для того, чтобы снять с разработчиков самую простую работу. Просто потому, что время тестировщика дешевле.

Изучение логов

Логи в стиле Матрицы изображение с сайта www.andreyolegovich.ru
Логи в стиле Матрицы. Фото: freepik.com

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

Что такое лог

Если Вы начали заниматься IT совем недавно и не знаете, что такое логи - попробую объяснить в двух словах.

Логи - это обычно текстовые файлы в которые программы записывают результаты своей работы.

Какие бывают логи

Лог может быть подробным, тогда он занимает больше места на диске и отвлекает больше ресурсов.

Чтобы сократить занимаемое место можно записывать только самые важные события.

Один и тот же софт может иметь несколько режимов логирования. Режим задаётся в настройках и отличается уровнем детализации.

Степень детализации может отличаться очень сильно. От никаких или минимальных записей вроде

2022-03-22-10-06-01T Включился
2024-10-05-00-00-01T Выключился

До записи каждого действия.

Часто одной и той же программе можно указать разный уровень подробности логов.

Типичные уровни логов - слева на право детализация растёт

OFF - FATAL - CRITICAL - ERROR - WARN - INFO - DEBUG - TRACE - ALL

Далеко не всегда используются все уровни. Например, во встроенном в Python модуле logging уровней всего пять, два из которых (INFO и DEBUG) отключены по умолчанию

CRITICAL - ERROR - WARN - INFO - DEBUG

Распространённый приём в работе тестировщика - на время тестирования включать подробное логирование - от DEBUG и выше.

Затем возвращать настройки в INFO или WARN для экономии места.

Для работы с логами может пригодится знание скриптовых языков программирования, или текстовых препроцессоров (sed, grep, awk)

Пример: показать только сегодняшние ERROR и WARNING строки из лога а также те, где присутствует слово panic

grep '2024-10-05' topbicycle.log | grep -E 'ERROR|WARNING|*panic*'

Пример ведения лога о вызовах функций с помощью декораторов - можете изучить в статье «Декораторы в Python»

Где лежат логи в Windows

Лог файл обычно называется по дате, например 2024-10-05-heiheiru-log.txt или 2024-10-05-heiheiru.log

Расположение лог файла обычно зависит от конкретного проекта, например:

У одного клиента логи могут лежать в

C:\Users\andreyolegovich.ru\AppData \Roaming\AO\AO_Client\logs

а у другого в

C:\ProgramData\AO2\AOClientPC

Glassfish на Windows server может писать в

C:\glassfish4\glassfish\domains\domain1\config\project-2024-10-05.log

Где лежат логи в Linux

В Linux системные логи находятся в

/var/log/

Например, лог утилиты cron за сегодня находится в

/var/log/cron-20241005

Иногда проще спросить расположение логов у разработчика

Зачастую полезно посмотреть, что именно клиент пытается отправить на сервер.

Откройте логи с помощью Notepad++ и сделайте поиск по слову POST

Советую не пренебрегать опцией Find All in Current Document.

Find all in current document

Зачастую смотреть полный лог нет смысла. В нём может быть очень много мусора, который легко убрать с помощью текстовых препроцессоров.

О том как это сделать Вы можете прочитать в статьях sed grep awk и как бонус - «Комады Bash для тестировщика»

Кто должен читать логи: тестировщик или разработчик

Однажды мне задали такой вопрос, и я здесь вполне категоричен - конечно, тестировщик.

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

Конечно, разработчик и сам может всё это сделать. Но его время стоит дороже и для бизнеса выгодно, чтобы всё что может делать тестировщик делал тестировщик.

Тестирование пользовательского ввода

Если есть хотя бы небольшой шанс того, что Вы будете тестировать что-то связаннное с user input, почитайте статью Big List of Naughty Strings

Изучение спецификаций

Перед началом работы над новым проектом Вам нужно будет изучить одну или несколько спецификаций.

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

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

Interfaces - спецификация интерфесов

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

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

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

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

Контроль версий

В прошлом для контроля версий использовались различные решения, например SVN , но уже довольно продолжительное время стандартом считается GIT поэтому советую изучать именно его.

Руководств и тренировочных материалов довольно много, моё можете найти в статье «GIT для начинающих»

gitlab-basics

requestb.in
en.wikipedia.org/wiki/Test_stub
Валидатор JSON

Чем занимается тестировщик

Нужно помнить, что тестирование сильно зависит от того, в какой компании работает тестировщик.

Это очевидно, но тем не менее акцентирую внимание на том, что очень сложно стать универсальным тестировщиком, разве что сменив несколько работодателей из разных IT сфер.

Я прочитал некоторые вакансии в рунете и в LinkedIn и сделал подборку популярных требований и описаний задач.

Постараюсь перевести их на понятный новичку язык.

Тестирование отдельных задач в тестовом и рабочем окружениях

Имеется в виду, что Вам придётся иногда тестировать в продакшене - то есть не dev а prod версию.

Если Вы тестируете сервер, который хостится Вашей конторой, то разница только в ответственности.

Если сервер на стороне клиента - готовьтесь подключаться по VPN, настраивать SSH туннель, а в худшем случае - разбираться в SSL сертификатах.

Покрытие тест-кейсами функционала системы

Означает, что нужно изучить спецификацию и понять, что можно протестировать. Затем описать эти тесты.

Проверка входящих баг-репортов из Tech Support

Клиенты обычно жалуются на баги и не только на баги.

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

Вы проверяете воспроизводится ли баг в тестовом окружении, если нет, то ковыряетесь в production логах где-нибудь на Kibana.

Функциональное тестирование и отслеживание качества выпускаемого сервиса

Здесь всё понятно - проверять нужно выполняет ли продукт свою функцию. После этого проверить насколько качественно и удобно для пользователя он это делает

Анализ функциональности сервиса

Может означать всё что угодно. Похоже скорее на задание для исследовательского тестирования.

Общение с командой разработки и менеджерами, принятие совместных решений об улучшении сервиса.

Это неотъемлемая часть работы практически любого инженера по тестированию, причём не только софта.

Локализация и документирование дефектов.

Под локализацией обычно понимают выяснение источника проблемы. Это выливается в поиск логов, относящихся непосредственно к ошибке и отслеживанию stack trace.

Документация это: описать что вызывает баг, какое действие клиента или какой конкертно запрос. Максимальное количество полезной информации приветствуется.

Обязательно указывать версию ПО в которой был получен баг и приложить логи.

Оптимизация процесса тестирования внутри команды и постановка задач разработчикам автотестов

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

Запуск и анализ результатов автотестов

Это очевидное продолжение предыдущего пункта.

Проведение ручного функционального тестирования

Функциональное тестирование мы уже обсудили, в этом пункте ключевое слово - ручное. Нужно будет кликать мышкой, делать запросы к API, нажимать на кнопки, всё зависит от продукта. Если Ваша компания производит мухобойки - возможно придётся бить мух.

Участие в регрессионном тестировании

Регрессионное тестирование обычно означает следующее. У Вас уже есть работающий продукт, но к нему пришёл Change Request (CR) и разработчики сделали новую фичу.

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

Для этого Вам придётся проделать все известные манипуляции с продуктом. Обычно под Regression Test есть отдельный документ, если Вы придумали что-то новое - просто добавляете это туда. Довольно скучный процесс.

Ведение тестовой документации, подготовка тест кейсов

Рутина, без которой никуда особенно в большиъ компаниях.

Регистрация найденных дефектов в баг-трекере, контроль их исправления.

Назначение баг-трекеров это упрощение контроля за ошибками.

Трекеров очень много, один из самых популярных это Jira .

Можете изучить неполный список баг-трекеров .

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

Взаимодействие с командой разработки.

Взаимодействие с разработчиками - это весело. Пример из жизни: в логах найдена неизвестная ошибка

2019-01-10 10:01:15 [ERROR]: Something is not ok

О ней написан репорт. Разработчик выпустил фикс. Тестировщик проверил и не увидев больше этого предупреждения в логах зааксептил.

Прошла неделя, тестировщик тестирует совершенно другую историю и вдруг

2019-01-17 10:01:15 [DEBUG]: Something is not ok

Тестировщик звонит разработчику и говорит, что ошибка снова появилась.

Первый вопрос разработчика - « А на каком уровне логов ты смотришь?»

Оказалось, что разработчик просто глубже закопал эту ошибку - теперь она не видна на ERROR уровне лога а видна только на DEBUG.

Вот такой фикс.

Присылайте свои истории в комментарии. Лучшие я включу в статью.

Куда складывают задачи и/или баги

Список планировщиков проектов и багтрекеров:

Попарное и общее сравнение:

На сайте wikipedia

На сайте softwareinsider.com , например Jira vs. Yodiz

На сайте Jira

Где пишут документацию

Confluence

Автоматизация тестирования

Эта глава слишком разрослась и переехала на отдельную страницу

«Автоматизация»

Полезно для тестировщика

Иметь:


опыт работы по scrum или знание теории данной методологии

Понимание процесса разработки и тестирования;
знание и понимание процессов Agile

Frontend тестировщикам пригодится опыт тестирования frontend-а клиентских приложений.

Знать:

что такое регрессия
smoke/UAT-тестирование
positive/negative тест-кейсы
тест-сьюты
тест-раны
про граничные значения,
про типы вводимых данных,
про необходимость соответствия дизайн-макетам в тестировании.
баг-трекинговые системы (JIRA или другие);

Основные команды Linux - читайте мою статью Комады Bash для тестировщика

Английский язык - читайте мою статью Советы по изучению английского языка

Уметь:

Какими качествами должен обладать тестировщик

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

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

Тестировщик работает в связке с несколькими специалистами разного профиля: разработчиками, менеджерами, другими тестировщиками.

То, что нужно для успешного взаимодействия с ними, обычно описывают как

Если продукт быстро развивается, либо довольно сложный, либо тестировщика берут с прицелом на создание отдела QA с нуля - важными будут

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

Как задавать вопросы

Приведу конкретный пример, чтобы вы знали к чему быть готовым.

Вы ищете тест, который проверяте правильное ли значение у величины floating_value

Зашли вы, например на github или gitlab и ищете в директории tests по слову floating_value ничего не находите и решате сократить слово до float мало ли переменная называется по-другому.

Ничего не находите и пишете разработчику или QA-лиду

Первый вариант

Так и так мол искал в тестах https://company.gitlab.com тест на floating_value. По ключевому слову float вообще ничего нет.

Получаете ответ

Ключевое слово float это плохой выбор - ищи по floating_value

Второй вариант

Так и так мол искал в тестах https://company.gitlab.com тест на floating_value. По ключевому слову floating_value вообще ничего нет.

Получаете ответ

Попробуй поискать пошире, например float

Как нужно было писать

Так и так мол искал в тестах https://company.gitlab.com тест на floating_value. По ключевым словам floating_value и даже float вообще ничего нет.

Вывод: Не оставляйте адресату лишнего пространства для манёвра

Книги и статьи о тестировании

Просто несколько книг. Я никакие не советую так как сам пока не смог себя заставить прочитать. Напишите в комментариях если что-то хотите посоветовать.

Словарь тестировщика

Термины идут не по алфавиту, а по смыслу. Сначала база, а потом, те, что на неё опираются.

Объективное доказательство
(Objective Evidence)

Объективные доказательства описывают то, что наблюдал тестировщик, что на самом деле произошло или не произошло.

Объективные доказательства должны содержать достаточные данные, чтобы рецензент мог доказать их соответствие критериям приёмки (Acceptance Criteria) теста.

Сравнение объективных доказательств с критериями приёмки приводит к прохождению или провалу теста.

Следует иметь в виду, что такие утверждения, как Пройдено (Passed), Провал (Failed) и как ожидалось (As Expected), никогда не рассматриваются как объективное свидетельство выполненного теста.

Верификация дизайна
(Design Verification)

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

Проверочные мероприятия проводятся на нескольких этапах и уровнях проектирования устройства.

Деятельность по проверке может включать испытания, инспекции/обзоры и анализы.

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

Валидация дизайна
(Design Validation)

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

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

Видите, какие скучные и не до конца внятные определения даны выше?

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

Cherry Picking

Выбор фич для следущего релиза, подробности здесь

Тестирование API изображение с сайта www.andreyolegovich.ru
Фото: freepik.com

Результат теста

Должен включать в себя:

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

Идентификационный номер тест кейса, который был проведён. Это особенно актуально для больших компаний с обширными библиотеками тестов.

Дату проведения теста.

Описание тестового окружения, использованного во время тестирования. Например, тип компьютера.

Заключение об Успехе/Провале теста. Так называемое Pass/Fail statement

Объективное доказательство (Objective Evidence)

Список найденных дефектов в случае провала теста.

Как писать тест репорт

Есть разные взгляды на то как формулировать результаты. Кто-то любит страдательный залог (Passive Voice) а кто-то пишет от первого лица.

Пример иллюстрирующий преимущества последнего

От первого лица

In Settings Menu changed MegaFactor 1 from 0.5 to 0.6 and MegaFactor 2 from 0.01 to 0.02

Страдательный залог

In Settings Menu MegaFactor 1 was changed from 0.5 to 0.6 and MegaFactor 2 was changed from 0.01 to 0.02

Как видите, первый вариант короче.

Полезный софт и другие материалы

Похожие статьи
Тестирование ПО
Основы профессии
Где учиться на тестировщика
Учебник по тестированию API
Тестирование API
Автоматизация тестирования
Теория
Реальные примеры работы Junior QA инженера
Selenium
Playwright
Тестирование с помощью Python
PyTest
UnitTest
Robot Framework
SOAP UI
JMeter
JUnit
Locust
Wireshark
Netdata
Команды Bash для тестировщика
Clumsy 0.2
Jira
Pivotal Tracker
Интеграционное тестирование
Bug Report
Интервью с тестировщиками
Список открытых API
Контакты и сотрудничество:
Рекомендую наш хостинг beget.ru
Пишите на info@eth1.ru если Вы:
1. Хотите написать статью для нашего сайта или перевести статью на свой родной язык.
2. Хотите разместить на сайте рекламу, подходящуюю по тематике.
3. Хотите поддержать сайт материально
4. Нашли на сайте ошибку, неточности, баг и т.д. ... .......