что такое билд в тестировании
Семь правил тестировщика
«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»
Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?
Тогда прошу под кат!
Свою карьеру тестировщика я начал в одной небольшой фирме, занимающейся тестированием самолетного ПО. Там было только автоматизированное тестирование, все процессы были уже построены, в общем — не сильно сложная работа. Мне показали основы написания кода на Visual Basic, показали как запускать тесты, и отправили в дальнее плавание.
Затем моё студенчество закончилось, захотелось больше интересной работы, и я перешел в другую компанию на должность простого ручного тестировщика. Тут нужно сделать небольшое отступление — в небольших кампаниях/отделах тестировщик порой выполняет целую кучу задач, не связанных напрямую с тестированием. Например, развертывание тестовой среды, ведение нескольких веток продукта в сорс контроле, саппорт выпущенных продуктов и т.д. Я попал именно в такую ситуацию.
Поначалу все было хорошо — мы делали свой 1 проект, я все делал руками, и у меня еще оставалась куча свободного времени.
Но постепенно проектов становилось все больше, программисты постоянно фиксили баги, нужно было накатывать билды чуть ли не каждый час. В какой-то момент я заметил, что на собственно тестирование я трачу лишь 40% времени. Остальное время занимают какие-то левые активности. Тогда я понял первое простое правило:
1. Если ты тестировщик, то можно и нужно автоматизировать не только тестирование
Именно тогда я сделал простую табличку в Excel, и отметил все задачи, на которые тратилось время. И нашел то, что выжирало больше всего времени — банальная выкладка билдов (обновление файлов, екзешников и т.д.). Вечером дома я зарылся в яндекс, и нашел, как убрать эту активность в 0. Я посмотрел синтаксис билдов на нашем билд-сервере, и сделал автоматическую выкладку всего этого хозяйства. После этого я привязал запуск билда к check-in’у в сорс контроле, и обрадовался жизни — у меня опять появилось свободное время! Тогда же я понял второе простое правило:
2. Автоматизируй то, что даст наибольший выигрыш по времени
Постепенно проекты росли, и появились системы, расположенные на нескольких серверах. И, о ужас, — конфиги разработчиков не работали на серверах! А программисты почему-то(!) не хотели их править. Я опять полез ковыряться в билд-машине, и обнаружил, что конфиги можно легко менять на этапе сборки. Тогда я понял третье простое правило:
3. Полностью изучи работу билд-машины
Примерно тогда же в моем распоряжении появилась первая виртуальная ферма на Hyper-V. Через пару месяцев я уже не представлял себе, как жил до этого. Настолько легко и просто оказалось поднимать тестовые стенды! Отсюда четвертое простое правило:
4. Подними сервер виртуализации
В то время компания очень сильно выросла, и внезапно оказалось, что для простого заведения учетки в домене нужно писать заявку админам с обоснованием и подтверждениями. Какое-то время мы терпели, а потом я сделал свой тестовый домен. Через месяц я понял, что не только сервер виртуализации был необходим. Отсюда пятое простое правило:
5. Сделай, наконец, свой тестовый домен
Когда я поднимал тестовый домен, то обнаружил на сервере забавную вещь — Power Shell. Как оказалось, кучу вещей можно сделать без интерфейса — заводить пользователей, настраивать IIS, делать правила в файрволе, устанавливать сервисы и т.д. Кроме того я узнал, что это можно делать не только на своей машине!
И если какую-то задачу на удаленной машине нужно будет сделать больше трёх раз, я всегда пишу скрипт — экономия времени огромна.
В общем, шестое простое правило:
6. Разберись с PowerShell/cmd/bash
В какой-то момент я осознал, что даже не приступив к автоматизации тестирования, я автоматизировал все остальное!
Тогда я взялся делать свой первый огромный(как мне тогда казалось) проект по автоматизированному тестированию одной огромной монструозной бизнес-функции. Делал я его долго, мучительно, но все-таки сотворил. Вот только там было столько костылей, неявных зависимостей, хардкода и прочего добра, что как-либо поддерживать это создание воспаленного ума оказалось невозможным. Именно тогда я понял, почему эти умные программисты допускают столько косяков… Но это была не последняя монструозная система в моем исполнении — их было еще много. В общем, самое главное седьмое правило:
7. Хочешь автоматизировать? Учись правильно программировать! Прочитай книги по архитектуре программ
Именно тут проявила себя цитата, вынесенная в эпиграф. Только сделав несколько ужасных проектов, обломав кучу зубов на поддержке своих творений, я начал понимать то, что написали эти умные дядьки в своих книгах. Только тотальная нехватка времени и тупизна работы по копированию файликов из одного место в другое толкнули меня на путь автоматизации. Только полностью влившись в команду разработки я начал писать относительно нормальный код.
А потом я втянулся. И следующие несколько книжек в плане на прочтение — о программировании. Причем я не буду переходить в программисты, это не моё. Ну а программирующим тестировщиком я уже стал.
И главное, не нужно бояться автоматизации. Это не всегда огромные труды, которые могут принести мифическую прибыль в будущем. Посмотри вокруг! Что-то можно сделать мышкой? С вероятностью в 95% это можно заскриптовать. Ты выполняешь ручные операции уже в пятнадцатый раз? Значит заскриптовать их нужно было еще вчера.
И еще одно пожелание. Научился сам, просвети своих коллег — согласитесь, интереснее работать с людьми, которые делают красивые, сложные проекты, а не ходят в грязном свитере и страдают от своей работы.
Желаю интересных багов, хороших проектов и дружных коллег-программистов!
Build-Deploy-Test. Непрерывная интеграция
Непрерывная интеграция (англ. Continuous Integration, далее CI) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения проблем интеграции результатов работы нескольких разработчиков.
Подчеркну, что это не методика и не стандарт, это ПРАКТИКА, и она подразумевает постоянную работу и вовлеченность всех членов команды. Зачем? Да чтобы не дожидаться конца проекта для проведения интеграции и внезапного всемирного коллапса. Кроме того задача CI — обезопаситься от разрушительных изменений в следствие рефакторинга, добавления нового функционала, изменений архитектуры и кучи других непредвиденных или известных проблем.
С помощью интеграционных сборок можно избавиться от синдрома «не знаю, на моей машине всё работает». Также мы защищаемся от «плохого кода», часто повторяющихся багов, «кривых» слияний. CI увеличивает возможности обратной связи потому, что она позволяет следить за состоянием проекта в течение дня.
Как мы пришли к непрерывности
Мы разрабатывали ядро, сервисные компоненты. Кроме того, нужно было протестировать производительность и установку-удаление компонентов. А также было требование к разработке – 100% покрытие кода юнит-тестами. В итоге у нас: автотесты, юнит-тесты, 4 тестовые среды, частично реализованные компоненты, «падающие» сборки и баги (куда без них?) и один тестировщик на 14 разработчиков. А хочется, чтобы всё само собиралось, устанавливалось, тестировалось и удалялось. И, конечно, очень хочется отдавать максимально стабильный и качественный результат основной команде тестирования.
Тестировать одному на 4-х системах, когда только у нас в команде 15 человек — мягко говоря, затруднительно. Поэтому мы решили попробовать подход Microsoft – Build-Deploy-Test. А успевать за разработкой тестировщику помогали следующие инструменты: TFS 2012, MSTest Manager 2012, Visual Studio 2012 Ultimate. Со временем перешли на 2013.
Мы решили сделать 2 CI сервера: Jenkins и TFS сервер. На первом у нас все собиралось раз в час в отладочном режиме (дебаг режиме). Затем происходила установка на сервер, прогон дымовых тестов (тесты, что приложение запускается) и после этого уже начиналась деинсталляция. Sonar запускал все модульные и интеграционные тесты раз в день, по ночам. Это решало проблему с нестабильностью сборки и скорейшего оповещения разработчиков о проблемах. На втором CI сервере (TFS build server) у нас сборка так же осуществлялась в отладочном режиме. Затем осуществлялась установка на тестовую машину и запуск функциональных автотестов. После того, как все тесты завершились (не важно, успешно или нет) происходила деинсталляция.
Мы решили сделать 2 сервера CI, чтобы отделить тесты разработчиков (модульные и интеграционные) от функциональных тестов тестировщиков. Сборки на Jenkins делались существенно чаще, чтобы реагировать на падающие тесты сразу. А сборки на TFS осуществлялись тестировщиком при необходимости и ежедневно по ночам, поскольку полный цикл функционального тестирования занимает много времени. Кроме того, чтобы всё строилось в Release конфигурации и код, как минимум, был всегда компилируемым, мы ввели Gated Check-in сборку. Когда программисты или тестировщик заливают изменения в TFS, сначала происходит сборка всей системы в Release конфигурации и изменения попадают в TFS только при условии его успешности. Если же есть проблема – изменения не применяются и сборка в TFS остается работающей.
Автоматизацию функциональных тестов мы начали с выбора их типов. Microsoft предлагает следующие:
Generic тесту нужно указать *.exe файл и параметры, которые ему надо скормить. Каждый тест-кейс в TFS был связан с generic тестом. Для автотестов у нас было по одному проекту на каждый компонент и при запуске автотеста из TM, вызывается generic тест, который передает нужному *.exe файлу номер текущего автотеста, а дальше выполняется необходимый метод.
Процесс Build-Deploy-Test в целом выглядит следующим образом: разработчики делают изменения, перед заливкой изменений Build Server собирает всё в Release конфигурации и если сборка проходит, изменения заливаются на сервер.
Дальше по функциональному тестированию.
По Build-Deploy-Test подходу имеется 3 роли – Build Controller(BC), Test Controller(TC) и Test Agent (TA). У нас Build Controller совпадает с нашим Build Server и Test Controller.
Build Controller следит за сборками проекта, он собирает бинарники в папку сборки (Gated Check In тут не подходит, для тестирования были отдельные конфигурации сборки). Test Controller нужен для управлением запусками, хранения результатов тестирования. А Test Agent получает команду от ТС о запуске набора тестов, команду на развертывание и все параметры запуска, в том числе набор generic тестов.
Тестировщик открывает Microsoft Test Manager, выбирает там тест-план, который ему нужен, конфигурацию для запуска, сборку, которая будет использоваться, и тестовую среду. И всё! Остальное делает Тest Controller. Он получает набор параметров для тестового запуска (включая расположение папки с бинарниками) и запускает на тестовой среде установку. После того, как отработает скрипт установки, Test Agent запускает поочерёдно все выбранные тесты. После выполнения всех тестов запускается скрипт очистки, который удаляет приложение и, подчищая за собой тестовую систему, возвращает её в начальное состояние. Далее Тest Аgent передаёт управление Тest Сontroller, сообщая ему о своей готовности. Тest Сontroller забирает все временные папки тестового запуска, помещает результаты в TFS (их потом можно посмотреть через TM) и отображает результат тестов в TM – успешно выполненные тесты и не очень успешные.
Настройки тестовых сред
Все сборки у нас хранятся на Build Server. Там же находятся и generic тесты. После запуска автотестов в Microsoft Test Manager (TM), Test Controller создаёт на тестовой машине временную папку, куда копирует generic тесты и создаёт свой deploy.bat и clean.bat файлы. Эти скрипты состоят из 2-х частей. Первая — определение всех переменных запуска, в том числе и название директории сборки, а вторая часть – содержимое нашего deploy файла, который мы указали для этих тестовых настроек.
Таким образом, получается, что TC создаёт обертку для скрипта, который мы ему указали, как deploy скрипт (назовём его Call Deploy скрипт).
В нашем случае этот скрипт, выполняет копирование всей директории билда на тестовую машину, затем он вызывает другой скрипт установки – Deploy скрипт, который был в этом билде. Нам это нужно для того, чтобы скрипт развертывания имел версионность, чтобы он мог обновляться вместе с билдом.
Этот скрипт уже выполняет все приготовления к установке, поскольку все скрипты реализуются в одной среде окружения, они имеют доступ к переменным, которые передал им TC. Используя их, скрипт обновляет конфигурацию и выполняет установку приложения. После завершения развертывания, к работе приступает Test Controller, который даёт задание Test Agent о выполнении тестов (тех самых generic тестов, которые он скопировал во временную папку). Эти generic тесты вызывают *.exe файл по указанному им пути и передают программе в качестве параметра номер тест-кейса. Автотест вызывает определенный метод в зависимости от переданного ему параметра.
После того, как все автотесты выполнены, Test Controller начинает процесс очистки. Для этого он вызывает скрипт-обёртку, которую создал вначале. Он определяет параметры и вызывает Call Clean скрипт, который лежит на всех тестовых системах. Call Clean запускает Clean скрипт, который выполняет деинсталляцию приложения, затем собирает все логи, архивирует их и перемещает во временную папку запусков, созданную Test Controller, чтобы после завершения очистки все логи загрузились в TFS и подцепились к запуску тестов.
У нас есть билды, которые по расписанию запускают Build-Deploy-Test подход. Для этого указывается специальный шаблон процесса в определении сборки. Раз в неделю происходит запуск такой сборки. В её настройке указано, какие тесты нужно выполнять, с какими настройками и на какой тестовой среде должны запускаться выбранные тесты.
Весь процесс начинается с запуска на Build Controller, который подает на Build Agent параметры для сборки (какие проекты собирать, в какой конфигурации – у нас это Release/Debug) После того, как Build Agent соберёт всё, Build Controller передаёт управление Test Controller вместе с параметрами для запуска автотестов – это набор автотестов, тестовая среда и тестовые настройки.
У нас в компании для каждой тестовой среды используются свои тестовые настройки и своя сборка.
После запуска Test Controller он начинает процесс развертывания, затем передает на Test Agent тестирование и после этого Test Controller запускает скрипт очистки системы.
Если тестовая среда состоит из 2-х машин, то это должно быть указано в Test Manager, для них создается одна тестовая среда, в которой будет 2 машины. На каждой машине стоит свой Test Agent, подключенный к TFS, чтобы эти машины были видны в TM. За каждой машиной закрепляется отдельная роль, к примеру, Database Server и Клиент.
В этом случае при запуске будет происходить то же самое, но тестовая среда будет состоять из 2-х машин и запускаться тесты будут только на одной машине, логи также можно собирать разные в зависимости от роли.
Проблемы при настройке Build-Test- Deploy процесса
Как оказалось, powershell скрипты не годятся для deploy/clean скриптов, для них подходят только cmd или bat. И, более того, если задать ему использование батника и из батника вызывать powershell скрипт, Test Manager игнорирует этот вызов. Точно так же он игнорирует и все sleep, wait и даже ping несуществующего хоста с таймером (нам нужен был sleep после остановки/запуска сервисов). Приходилось даже для таких простых вещей писать отдельные костыли, которые запускались из батника.
По мере эволюции проекта, эволюционировали и тесты. Сначала это был набор библиотек, поэтому можно было в скрипте развертывания просто копировать их и запускать тесты, а затем удалять их. И все были счастливы. Затем наши доблестные разработчики обернули всё в msi-пакеты, которые надо было запускать с множеством параметров. И удалять соответственно. Здесь уже задача усложнилась с изменениями параметров, которые надо подавать. Для этого мы использовали те параметры, которые Тest Сontroller передает Тest Аgent. Этого хватало.
Далее появилось много инсталляционных пакетов msi, которые надо ставить в определённой последовательности и с множеством параметров и конфигурационных файлов. Для того чтобы конфигурация проходила в зависимости от тестовой системы, мы подменяли все строки подключения со строки по умолчанию на нужную, подменяли все пути, параметры и прочее (всё это тоже брали из параметров запуска автотестов). Ещё нужно было сделать удаление MSMQ (Microsoft Message Queuing) очередей. Простыми батниками эту задачу не решить, поэтому я написала на PS такой скрипт. Но тут ждал очередной сюрприз – ну не хочет MicroSoft Test Manager работать со своим прославленным powershell. Непонятно почему. В итоге опять это решалось в самих автотестах.
Финальным (на данный момент) этапом установки стала одна единственная программка с пользовательским интерфейсом, в которой выбираются нужные компоненты и параметры и она уже сама запускает все необходимые файлы установщика с параметрами. Аналогично удаление. Мы автоматизировали установку без необходимости задавать значения в пользовательском интерфейсе. Установщику подается на вход сконфигурированный xml файл с нужными параметрами (частично использовались те, что можно передать с Test Controller) для установки и удаления. Всё остальное происходит так же.
Итак, мы автоматизировали и поставили весь процесс. Конечно, средства достижения непрерывной интеграции могут значительно отличаться от проекта, от предпочтений, традиций и политики компании. И мы можем помочь решить, что нужно именно для вашей компании.
воскресенье, 17 января 2016 г.
Это не баг, ты просто криво собрала билд
Большинство задач в релизе — небольшие улучшения или мелкие правки багов. В этом случае разработчик все быстренько делает и отдает в тестирование готовое приложение. А вот когда улучшение серьезное, одна задача разбивается на две — сделать на сервере и на клиенте. Появляется возможность поработать по TDD — сначала тесты, потом разработка.
Писать тесты без реализации тяжело. Привык, что написал и сразу отлаживаешь: запускаешь, смотришь на падение и думаешь, ты накосячил в тесте или в коде правда баг. Когда отладиться нельзя, нужно быть особо внимательным. Высший пилотаж — написать тесты так, что при первом прогоне они все пройдут. Или упадут, но из-за найденного бага в коде, а не потому, что вы накопипастили лишнего.
Я иногда забываю какую-нибудь мелочь при написании теста. Например, заполнить колонку А в таблице Б. Запускаешь тест, а он разваливается. Иногда с непонятным сообщением типа NullPointerException. Поди угадай, ты налажал или в коде бага. Я иду к разработчику, вместе смотрим и находим. Мой косяк в тесте =)
Поэтому, когда я жалуюсь Васе (разработчику), что у меня не проходит тест, он сначала пытается отмахнуться:
— А startdate в таблице связей заполнила?
— А id_cat в таблице cat точно равно id_cat в таблице animals? (see foreign key)
— А это сделала?
Конечно, иногда такой вопрос наводит меня на мысли, но я же обучаюсь)) И типовые проблемы проверяю сама перед тем, как идти с вопросом. К чему это я? А к тому, что пока ты баг не локализуешь, хрен докажешь, что он есть! И хорошо, когда код полностью готов. Показываешь, что вручную падает на том же месте — значит, ошибка не в автотесте, а в коде. Живой случай из практики:
Делаем большую доработку. Пока я занималась другими задачами, успели сделать не только серверную часть, но и клиентскую. Это здорово — я люблю потыкать вручную, это наводит на мысли и идеи.
Радостно потираю ручки, стартую билд, запускаю новую функцию — не работает о_О
Как так? Иду к разработчику:
— Но почеееееему?
— Ну так функция новая, по умолчанию выключена. Поменяй в админке WOW_FEATURE = ENABLE и перезапусти.
— ОК.
Поменяла, перезапустила, отвлеклась. Другие дела переделала, вернулась к своему локально развернутому стенду — а он не разворачивается! В логах текст:
Not found file bla-bla-bla\service.jar\bla\bla\bla\file.txt
Я опять к разработчику:
— Так и так.
— Эм. Этот файл должен выкачиваться из SVN при сборке. А сам файл у тебя есть?
— Есть!
— А локально собранный есть?
— *проверила* Есть!
— А в репозитории локальном?
— *проверила* Есть!
— А внутри собранного билда, в этом jar проверяла?
— ДА! Вот тебе мой билд, проверь.
— *проверил* У меня все работает, это у тебя локально какие-то проблемы.
А разработчики болеют, нельзя подозвать их, чтобы пошаманили над компом. Но такие проблемы правда бывают. Поэтому не стала копать, когда именно воспроизводится баг, поверила разработчику.
Тут прилетела критикал задача, пришлось отложить шаманства — новую фичу будем выпускать в следующем релизе, текущий в приоритете. Отвлеклась на день или два. Потом появилось время и я вернулась к новому функционалу.
Пересобрала все сборки и на всякий случай пересоздала схему базы данных. Поднимаю билд — поднимается. Ура ура ура, я смогу потыкать функционал ручками. Потираю ручки, запускаю функцию. А она не работает (злобный смайлик).
Напрягаю память, ах да, она же пока DISABLE. Я пересоздала базу, где хранится состояние, вот она снова и выключена. Меняю на ENABLE, ребутаю. И снова эта ошибка! АГА! ТАК БАГ ВСЕ-ТАКИ ЕСТЬ. И вот почему моя сборка у разработчика поднялась — он поднимал на своей схеме БД, где функционал был выключен. Ну, теперь ты от меня не отмажешься!
Переоткрыла задачу, описала, как воспроизводить. Разработчик посмотрел — правда баг. Оказалось, неправильно было настроено приведение абсолютного пути к относительному. Поэтому, хотя файлик реально и был, найти его система не могла. А искать пыталась только в том случае, когда включался новый функционал.
Основные определения и понятия тестирования ПО
Чтобы с головой погрузиться в новую профессиональную область, важно изучить язык, на котором говорят её представители. Ведь специальная лексика не только описывает инструменты или процессы, с которыми тестировщики работают ежедневно, но и облегчает общение с коллегами на около рабочие темы.
К примеру, вы уже могли слышать фразу «это не баг, а фича». Объяснить её далёкому от информационных технологий собеседнику не так просто: в отличие от бага, который является ошибкой, фича ― это не дефект, а заранее и сознательно придуманная опция, которая служит изюминкой. Слишком долго, не так ли?
Использование подобных словечек поможет вам проявить свои знания на собеседовании и найти общий язык с HR, уже работающим в ИТ-индустрии человеком. Итак, какие же понятия и определения будут полезны каждому начинающему QA-специалисту?
Базовые термины
Баг (bug) ― это ошибка или дефект программного обеспечения. Он проявляется, когда фактическое поведение системы отличается от ожидаемого. Дефекты могут быть критическими и влиять на использование ПО или незначительными, когда их присутствие незаметно для пользователя.
Тестирование (testing) ― это исследование поведения программного продукта, основной целью которого является выявление багов. Понятия контроль качества (quality control, QC) и обеспечение качества (quality assurance, QA) часто используются в качестве синонимов, но это ошибка. Ведь тестирование нацелено на поиск ошибок в уже готовом ПО, а обеспечение качества задаёт условия, в которых дефекты появляться не будут.
Подробно об отличиях данных явлений мы рассказали в нашей статье.
Тестовое покрытие (test coverage) ― это совокупность тестов, которые проявляют работоспособность той или иной функциональности ПО. Чем больше проверок, тем шире тестовое покрытие, тем больше возможностей отследить поведение системы в различных условиях и выявить критические или незначительные дефекты.
Верификация (verification) ― оценка ПО или его компонентов с точки зрения соответствия всем заявленным к нему требованиям.
Валидация (validation) ― это проверка работоспособности функциональности приложения.
Релиз (release, RTM) ― выпуск программного продукта на рынок, например, размещение мобильного приложения в App Store или Google Play.
Артефакты ― это документы, которые используют в процессе тестирования. Подробнее о том, какими они бывают, расскажем далее.
Артефакты
Спецификация (specification, спек) ― детализированное описание работы приложения, которое включает технические свойства.
Баг-репорт (bug report, отчёт об ошибке) ― описание действий или условий, которые привели к выявлению дефекта. О принципах составления безупречного баг-репорта мы уже рассказали в одной из наших статей.
Подобные отчёты создают в баг-трекинговой системе (bug tracking system, система отслеживания ошибок). Это программа для описания и контроля дефектов. Наиболее распространённой является Jira. Новичку привыкнуть к работе в этой системе непросто, но освоить азы вы сможете с поддержкой опытного преподавателя-практика на базовом курсе от QA Academy.
План тестирования (test plan) ― в этом документе содержатся все данные о проводимой проверке: описание программного продукта, стратегия тестирования, сроки выполнения поставленных задач, используемые в процессе инструменты и оборудование, оценка потенциальных рисков и прочее.
Чек-лист (checklist, контрольный список) ― перечень параметров, которые нуждаются в проверке.
Тест-кейс (test case, тестовый случай) ― своего рода сценарий или описание последовательности шагов при проведении тестирования.
Тестовый набор (test suite) ― несколько тест-кейсов, которые объединены по типу тестирования или другим признакам.
Типы тестирования
Мануальное (ручное) ― непосредственная проверка работы ПО тестировщиком.
Автоматизированное ― оценка качества программного продукта с применением программных средств (автотесты).
Тестирование производительности (performance testing) ― анализ работы приложений под различными нагрузками.
Функциональное тестирование (functional testing) ― проверка возможности ПО в заданных условиях решать необходимые пользователю задачи.
Тестирование безопасности (security testing) ― определение безопасности ПО: защищено ли оно от атак хакеров, несанкционированного доступа к данным и т. д.
UX-тестирование (usability testing, юзабилити-тестирование) ― исследование логики и удобства использования ПО.
Подробнее о различных подходах оценки качества ПО вы узнаете из нашего материала по классификации видов тестирования.
Ещё несколько полезных слов
Фиксить (от англ. to fix — исправлять) — вносить правки, исправлять ошибки.
Локаль (от англ. locale — место) — региональные настройки или параметры ПО.
Билд (от англ. to build — строить) — финальный вариант программного продукта или его элемента, который готов к тестированию.
Асайнить (от англ. to assign — назначать) — закреплять за кем-то задачу или часть работы.
В аттаче (от англ. to attach — приложить) — добавлять к письму или сообщению документ. Например, отправить на почту письмо с CV в аттаче означает, что было отправлено письмо с приложенным к нему резюме.
Букать (от англ. to book — бронировать) — резервировать.
Бэкапить (от англ. backup — дублирование) — создавать резервные копии документов или данных на случай их потери или удаления.
Дебаджить, дебажить (от англ. to debug — отлаживать) — настраивать или регулировать работу.
Тул (от англ. tool — инструмент) — программа, которая используется при тестировании.
Фича (от англ. feature — особенность) — некий аспект ПО, который служит его характерной особенностью.
Резюмируем
Мы постарались собрать самые важные слова и понятия, которые будут полезны на старте карьеры в QA. Они облегчат понимание профильной литературы и общение с коллегами. Поможет обогатить лексику регулярное чтение статей про тестирование, тематические блоги и литература.
Но быстрее всего пополнить словарик вы сможете в процессе живого общения во время рабочего процесса. Чтобы уже через несколько месяцев вы смогли реализоваться в QA, записывайтесь на курсы Академии сегодня!