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

↓ Содержание статьи ↓

	Изучение логов
	Тестирование пользовательского ввода
	Курсы тестирования ПО
	Изучение спецификаций
	Контроль версий
	Обязанности тестировщика
	Баг-трекеры
	Документация
	Автоматизация тестирования
	Полезно знать
	Книги о тестировании
	Словарь
	Теория
	Реальные примеры работы
	Софт для тестирования

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

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

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

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

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

2020-02-10-16-06-01T Включился
2020-02-10-16-08-23T Выключился

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

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

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

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

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

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

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

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

а у другого в

C:\ProgramData\AO2\AOClientPC

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

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

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

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

О том как это сделать Вы можете прочитать в моей статье Текстовые препроцессоры: SED, Grep, AWK

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

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

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

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

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

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

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

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

1.) Связать бизнес логику с запросами, описанным в спецификации интерфейсов.

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

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

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

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

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, нажимать на кнопки, всё зависит от продукта. Если Ваша компания производит мухобойки - возможно придётся бить мух.

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

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

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

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

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

Рутина, без которой никуда.

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

Суть баг-трекеров как раз в удобстве контроля. Их много, у Вас скорее всего 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.

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

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

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

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

Jira
Trello
Pivotal Tracker
Bugzilla
CA
Asana
Basecamp
Redmine
Team Foundation Server
FogBugz
GitHub Issues
Axosoft
Mantis
Trac
Yodiz
YouTrack



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

На сайте wikipedia

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

На сайте Jira

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

Confluence

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

Selenium

Cucumber

Robot Framework

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

Иметь:

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

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

Знать:

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

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

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

Уметь:

Работать с системами управления версиями - обычно это GIT реже SVN

Мой самоучитель по работе в GIT можете изучить здесь

Работать с Chrome Devtools
чётко и ясно излагать свои мысли
Писать скрипты на одном из популярных языков программирования, например на Python

Обладать следующими качествами:

Скрупулезность и внимательность к деталям
Умение работать в команде
Ответственность
Стремление к развитию
самостоятельность в принятии решений;
инициативность и ответственность;
желание и умение работать в динамичной команде;
чувство юмора.
Внимание к деталям, ответственность, аккуратность, педантичность, усидчивость

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

• Cem Kaner, Jack Falk, Hung Quoc Nguyen - Testing Computer Software

SSCC18 - сколько памяти выделять

Реальные примеры работы

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

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

Тестирование с помощью Selenium + Python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теория

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

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

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

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

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

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

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

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

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

Дефекты

Список дефектов составляется в случае провала теста. Каждый дефект должен содержать в себе описание проблемы в такой форме, что несоответствие между ожидаемым результатом и реальным может быть воспроизведено и в дальнейшем исправлено.

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

После иправления должны быть простестированы те же самые тест кейсы, в которых были найдены эти дефекты (если это ещё возможно).

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

Разница между валидацией и верификацией

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

Валидация - это проверка соответствия устройства/программы требованиям пользователя.

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

В то же время валидная программа, может содержать отклонения от спецификации и не пройти верификацию.

Где учиться на профессию тестировщик ПО

Популярность профессии растёт, а в университетах такой программы ещё нет.

Эту нишу в данный момент закрывают различные курсы. Перечислю самые крупные. Советовать не буду - изучите лучше самостоятельно на их сайтах.

Курс от образовательного центра Mail.ru GEEKBRAINS

Перейти на сайт GEEKBRAINS

Курс от образовательного центра Нетология

Перейти на сайт Netology.ru

Курс от онлайн университета SkillBox

Перейти на сайт SkillBox.ru
В зависимости от того в какой области тестирования Вы будете специализироваться Вам могут понадобиться более глубокие знания по предмету.

Например, тестировщику web-приложений пригодятся знания Java-script или PHP, которые не особо нужны в других областях.

Если работа предусматривает написание сложных скриптов, например, для нагрузочного тестирования, то полезно изучить Python. Имейте в виду, что на август 2019-го года актуальная версия Python это 3.7. Если Вам предлагают изучить версию ниже 3.0 это должно вызвать подозрение, так как знания быстро устаревают и учиться нужно тому, что актуально в данный момент.

Большинству тестировщиков пригодятся знания по работе с базами данных.

Если продукт, который Вы будете тестировать, предназначен для конечных пользователей, например, покупателей интернет магазина, то Вам пригодятся знания в области UX/UI

Ниже я нашёл несколько курсов, которые могут хорошо дополнить набор умений современного тестировщика ПО.

Интервью с тестировщиками

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