4 самые популярные системы тестирования и оценки персонала. полный обзор

Что такое тестирование?

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

Согласно стандарту ANSI / IEEE 1059, тестирование можно определить как: процесс анализа элемента программного обеспечения для обнаружения различий между существующими и требуемыми условиями (дефектами / ошибками / ошибками) и для оценки характеристик элемента программного обеспечения.

SunRav Web Class — простая система опроса и тестирования

SunRav Web Class — сервис от компании SunRav Software для онлайн-аттестации сотрудников.

Описание SunRav WEB Class

1. Пробная версия. Вы получите доступ к программе после регистрации на сайте.
2. Возможности. Web Class — это площадка для хранения тестов и проверки знаний сотрудников. Встроенного конструктора нет. Тест придётся собирать в другой программе компании — tMaker.
3. Формат платформы. Только коробочная версия.
4. Уровень сложности интерфейса: 3 из 5.
5. Брендирование. Можно сменить логотип.
6. Виды тестов. В системе вы можете собрать задания двух : «верно — неверно», «поставь балл от 1 до 10». Программа tMaker поможет расширить этот список до семи: появятся вопросы с единственным и множественным выбором, соответствие, упорядоченный список и вопрос с открытой строкой, в которую нужно вписать вопрос.
7. Особые возможности. Нет.
8. Статистика. Есть четыре типа отчётов: матрица ответов, результаты пользователей, групповые отчёты и отчёты по темам. Формат отчётов — csv.
9. Цена. Компания продаёт только бессрочные лицензии. Цена на устройство — 29 000 рублей. Корпоративная лицензия обойдётся в 95 000 рублей.

Обзор возможностей SunRav WEB Class

Кому подходит SunRav WEB Class

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

Клиенты SunRav Software

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

Плюсы и минусы тестовых моделей

Плюсы MBT:

Использование тестовых моделей развивает аналитическое мышление за счет постоянного анализа (сюрприз!) тестируемой системы. Лучший способ развить этот тип мышления — применять его для решения задач, например, для создания абстрактной схемы продукта или его компонента.
Моделирование улучшает понимание системы как у того, кто модель создает, так и у команды, которая ревьюит и использует ее. Приятный бонус: спустя некоторое время благодаря модели можно научиться предугадывать поведение системы в тех или иных обстоятельствах.
Тестовую модель поддерживать легче, чем много тест-кейсов (за счет абстрактности и того, что кейсов много, а модель одна).
MBT позволяет взглянуть на систему (или ее часть) в целом и увидеть неочевидные зависимости.
Создание и поддержание тестовой модели способствует синхронизации понимания работы системы внутри команды. Это очень полезно для избегания неоднозначных ситуаций и решения спорных вопросов «на берегу» до начала разработки.
Благодаря математической подоплеке наличие модели позволяет автоматизировать нахождение оптимального пути, пути с задействованием всех состояний и т.д. Кроме того, тестовую модель можно использовать как основу для проектирования автотестов.
Несомненно, модель делает процесс адаптации новичка в проект более эффективным. «Лучше один раз увидеть, чем сто раз услышать» тут как раз работает

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

Минусы MBT:

• Если в модели есть ошибка, это может привести к фундаментальному недопониманию внутри команды. Именно поэтому важен следующий пункт.
• Желательно, чтобы в моделировании (или ревью модели) участвовала вся команда. Во-первых, это позволяет исключить недопонимания, во-вторых, активирует силу коллективного разума.
• Как и в случае с тестовой документацией, надо не лениться, поддерживать и регулярно обновлять модель. Если на это нет времени и/или недостаточно знаний, стоит поставить под сомнение целесообразность использования тестовых моделей в проекте.
• Иногда создание модели занимает больше времени, чем написание простого чек-листа. Особенно это актуально для больших и многокомпонентных систем: если модель начинают создавать после того, как внутри системы уже существует куча не до конца понятных зависимостей, это может стать довольно долгим (но, скорее всего, того стоящим!) процессом.
• Использование тестовых моделей требует определенных навыков абстрактного мышления вкупе с внимательностью к мелочам. Скорее всего, если вы успешно работаете в тестировании, у вас есть все эти навыки, но нужно быть осторожными и никогда не отключать критическое мышление даже по отношению к собственным трудам.

Какие виды тестирования существуют

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

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

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

Есть несколько видов тестирования:

StartExam — система онлайн-тестирования в аккуратном дизайне

StartExam — разработка «Милдсофт». В 2006 году руководство компании решило тестировать сотрудников, но не нашла подходящего решения на рынке и разработало своё.

Обзор возможностей StartExam

В StartExam включен конструктор тестов, центр тестирования и аналитики, который автоматически проверяет ответы сотрудников.

Описание StartExam

1. Пробная версия. Чтобы получить доступ к StartExam, нажмите кнопку «Демо-доступ» и заполните форму на сайте: имя, номер телефона. С вами свяжется менеджер компании и отправит пароль от системы после подробного интервью: что за компанию представляете, для каких целей нужен StartExam, сколько человек планируете тестировать. Срок пробного периода разный — все зависит от того, как договоритесь с представителем StartExam.
2. Возможности. В StartExam встроен конструктор тестов и опросов. Есть и сервис аналитики — он проверяет ответы и собирает отчёты. В самом тесте широкий выбор настроек: можно ограничить время на выполнения заданий и число попыток, включить автоматическое перемешивание вопросы перед началом теста.
3. Формат платформы. StartExam работает через интернет и не требует установки на компьютер.
4. Уровень сложности интерфейса: 2 из 5. Чтобы собрать тест и провести срез знаний, достаточно посмотреть пятиминутную видеоинструкцию — всё интуитивно понятно.
5. Брендирование. Вы можете добавить логотип, перекрасить систему в нужные цвета и даже оформить отчёты в корпоративном стиле.
6. Виды тестов. Создавайте опросы и проверочные тесты из 9 типов заданий: единственный и множественный выбор, сортировка, соответствие, текстовый ввод, эссе, шкала Ликерта, видеоинтервью и оценка 360 градусов.
7. Особые опции. Помимо вопросов в тест можно добавить слайды информацией. Если сотрудник ошибётся, StartExam автоматически отправит его на этот слайд.
8. Статистика. В отчёте StartExam по умолчанию 29 полей. Среди них ФИО, дата и время теста, количество набранных баллов, оценка доверия, верификации. Выбирайте нужные параметры и отключайте лишние.
9. Цена. Зависит о количества тестирований в месяц. Минимальный пакет — 200 тестов за 6 000 рублей.

Кому подходит StartExam

Подходит больше всего
Не подходит
Планируете поставить тестирование сотрудников на поток.
Ищите коробочную систему тестирования.
Хотите запустить оценку 360 градусов.
Результаты тестов важно хранить в базах данных компании.
Не хотите устанавливать систему на сервер компании.
 

Как обычно проходит тестирование

Как правило, тестировщики начинают работать с программой сразу после начала проекта:

• Составляют тест-план, где описан весь объём работ по тестированию и определено, когда их можно закончить. Это примерный документ — в процессе разработки в него не раз внесут изменения: уточнят стратегию и виды тестирования, расписание работ и так далее.
• Разрабатывают тест-кейсы — перечень конкретных действий и сценарии для проверки каких-то определённых функций программы.
• Решают, нужна ли автоматизация: стоит ли разрабатывать и запускать автоматические тесты или можно обойтись тестированием вручную.

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

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

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

Автоматизированное тестирование облегчает проверку и экономит время. Лучше всего это работает в сложных приложениях с большой функциональностью.

Карьера тестировщика: варианты развития

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

Вертикальное развитие

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

В каждом сегменте тестирования существуют свои грейды, которые определяют уровень специалиста: junior, middle и senior. Руководителем всех специалистов является test-lead или team-lead в зависимости от специфики компании. На некоторых проектах может быть также отдельный инженер по качеству, head of QA.

Из начинающего специалиста тестировщик может дорасти до любого из уровней, главное — постоянно держать себя в тонусе. Азы профессии освоить не трудно, а вот развиваться дальше и на каждом этапе приобретать новые знания уже гораздо сложнее. Конечно, всё зависит от человека, но, например, от junior до middle возможно дорасти в среднем за год.

Горизонтальное развитие

Второй вариант — развиваться как специалист и прокачивать hard skills, а в дальнейшим благодаря ним можно будет выбрать наиболее интересное направление. Тестировщик может стать автотестером или специалистом по тестированию юзабилити, безопасности, производительности. При этом есть профессионалы, которые могут совмещать оба варианта.

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

Спрос на автоматизированное тестирование

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

Ручное и автоматизированное тестирование: рассматриваем преимущества и недостатки подходов

tproger.ru

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

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

Переход в смежные сферы

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

Как тестировщику стать разработчиком — отвечают эксперты

tproger.ru

Книги на английском языке

Cem Kaner, James Bach, Bret Pettichord

«Lessons Learned in Software Testing»

Книга привлекает практической направленностью: авторы с богатейшим опытом собрали 293 урока, где коснулись основных вопросов тестирования ПО. Будет полезна и для новичков, и для опытных специалистов.

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

Boris Beizer

«Software Testing Techniques»

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

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

Ajay Balamurugadas, Sundaresan Krishnaswami

«Mobile Testing: Ready Reckoner»

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

в формате PDF

Mike Andrews, James A. Whittaker

«How to break web software»

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

Ее можно перечитывать много раз и находить новые способы решения насущных задач. Автор рассказывает о различных типах атак: на сервер, на клиент, state based и других. Описание атаки состоит из вводной части, сферы применения и инструкции о том, как ее проводить.

James A. Whittaker

«How to Break Software Security»

Вторая книга Витакера — пошаговое руководство по тестированию безопасности приложений. Ее лучше читать после «How to break web software».

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

Автор рассказывает о верхнеуровневых классах проверок, например, на уровне кода или GUI, и приводит 19 атак на защищенность приложения. Каждое описание атаки или инъекции состоит из вводной части, описания случаев применения и руководства по нему.

Gerald M. Weinberg

«Perfect Software and other illusions about testing»

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

Автор приводит реальные типичные ошибки в подходах, а учиться на ошибках — самое полезное дело. В совместной работе специалисты часто переводят стрелки друг на друга и отказываются фиксить и документировать баг, ссылаясь на то, что это не их зона ответственности. Что с этим делать и как с этим жить — в том числе рассказывает Gerald M. Weinberg.

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

Цель

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

• Функциональное
• Нефункциональное

Функциональное тестирование направлено на проверку того, какие функции ПО реализованы, и того, насколько верно они реализованы.

Нефункциональное – проверка корректности работы нефункциональных требований. Оценивается, КАК программный продукт работает. Эта проверка включает в себя следующие виды:

Тестирование производительности – работа ПО под определённой нагрузкой.

• Тестирование пользовательского интерфейса – удобство пользователя при взаимодействии с разными параметрами интерфейса (кнопки, цвета, выравнивание и т. д.).
• Тестирование UX – правильность логики использования программного продукта.
• Тестирование защищенности – определение безопасности ПО: защищено ли оно от атак хакеров, несанкционированного доступа к данным и т. д.
• Инсталляционное тестирование – оценка вероятности возникновения проблем при установке, удалении, а также обновлении ПО.
• Тестирование совместимости – тестирование работы программного продукта в определённом окружении.
• Тестирование надежности – работа программы при длительной средней ожидаемой нагрузке.
• Тестирование локализации –оценка правильности версии программного продукта (языковой и культурный аспекты).

Что тестируют на разных этапах разработки

Есть несколько уровней тестирования. Их проводят в разное время:

1. Модульное тестирование делается в самом начале, когда готовы те куски кода, которые можно проверить по отдельности: объекты, классы, функции, программные модули. Тесты пишутся отдельно для каждой функции или метода. На этом этапе проверяют работоспособность части кода, нет ли регрессии — не появились ли после изменения кода ошибки там, где раньше всё работало нормально. Это самый нижний уровень тестирования, часто это делают те, кто пишет код.
2. К интеграционному тестированию переходят после модульной проверки. Здесь тестируют связи между проверенными элементами и то, как программа взаимодействует с операционной системой, оборудованием.
3. Системное тестирование показывает, соответствует ли готовая система функциональным и нефункциональным требованиям.
4. Приёмочное тестирование проходит, когда заказчик принимает приложения от разработчиков. Его цель — убедиться, что продукт удовлетворяет требованиям клиента. На основании этого покупатель решает, готова ли программа или её нужно дорабатывать.

В зависимости от этапа разработки перед тестировщиками стоят разные цели:

• Когда пишется код, нужно найти как можно больше сбоев и дефектов, чтобы их исправить.
• Во время приёмочного тестирования нужно показать заказчику, что система работает без ошибок.
• На этапе сопровождения программы тестирование помогает исправить баги, которые появились в коде после изменения.

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

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

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

Зашли вы, например на

или
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
вообще ничего нет.

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

Правила составления тестов

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

Как составлять вопросы для теста

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

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

Простой языкФормулировка вопроса должна быть четкой, ясной, простой и понятной. Использование сложных текстовых конструкций необходимо минимизировать. Не перегружайте текст вопроса ненужной информацией. Исключайте из текста обороты, не несущие в себе смысловой нагрузки. Например, фразы “Как вы думаете”, “на ваш взгляд”, “по желанию”. Не используете в формулировке непонятные термины или сокращения.

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

Сократите отрицанияИзбегайте использования негативных суждений в формулировке задания. При использовании отрицания четко обозначьте его — например, выделите строчными буквами «НЕ», «НЕТ», «НАИМЕНЬШЕЕ», «КРОМЕ».

Как составлять ответы для теста

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

Внешний видПравильные и неправильные ответы должны быть однозначны по содержанию и структуре. Желательно, чтобы все ответы были краткими и одинаковыми по своей длине. Старайтесь максимум текста выносить в тело вопроса. Длинный вопрос и короткие ответы предпочтительнее, чем короткий вопрос и развернутые ответы.

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

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

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

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

Количество ответовРекомендуемое количество вариантов ответа для теста с одиночным выбором — 4, для теста с множественным выбором 5-6.

Нет подсказокПравильный ответ не должен содержать грамматической подсказки (выделения, однокоренные слова). Все варианты ответов должны грамматически верно сочетаться с вопросом. Каждый вариант ответа должен логично продолжать изначальное предложение. То есть, если их склеить, то должно каждый раз получаться нормальное предложение без пропущенных слов.

Нет обобщенийНе используйте варианты ответов: «все вышеперечисленное верно», «все указанные ответы неверны», «ни одного». Это вводит ученика в заблуждение. Если вы хотите, чтобы студент выбрал все варианты ответа в задании, то используйте вид теста с множественным выбором (чек-бокс).

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

Когда составлены вопросы и ответы, нужно поместить их в уроки электронного курса.

QA, QC и тестирование

Так в чем же разница между QA и тестированием и что такое Quality Control?

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

Можно оформить их соотношение в виде таблицы:

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса.

Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:

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

То есть качеству объекта внимание уделяется еще до создания самого объекта.

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

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

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

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

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

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

API

и задача тестировщика здесь сводится к тому, чтобы

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

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

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

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

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