quality assurance что это такое
Зачем вам нужен QA и как это позволит сэкономить деньги
Авторизуйтесь
Зачем вам нужен QA и как это позволит сэкономить деньги
В этой статье речь пойдёт не о том, как QA-инженеры делают свою работу. Мы поговорим о том, почему обеспечение качества (Quality Assurance, QA) — незаменимая часть процесса разработки.
Цель профессии QA-инженера — помочь создать качественный продукт. Их работа заключается не просто в поиске багов и не в обыкновенном тестировании. Основная задача QA-инженера — предотвратить дефекты и, следовательно, обеспечить высокое качество процесса разработки и его результатов. Это достаточно общее определение, поэтому в этой статье мы попытаемся рассказать о некоторых деталях, которые помогут осознать ценность QA.
Дефект или баг — фрагмент кода с ошибкой, из-за которого система не может выполнять свою функцию. Это не всегда означает, что всё не работает. Оно может работать, но не так, как надо.
25–26 ноября, Москва и онлайн, От 24 000 до 52 000 ₽
Так чем занимаются QA-инженеры? Они:
Важно отметить, что QA заинтересованы в том, чтобы сделать любой продукт удобным для пользователя как в плане функциональности, так и в плане дизайна. Для этого они тесно взаимодействуют со всеми членами команды и постоянно обращаются к заданным требованиям.
Теперь давайте разберём все этапы, на которых нужны QA, их роли на этих этапах и значимость их работы для бизнеса.
Когда вам нужен QA?
В этой части статьи мы опишем, что и когда делают QA. Этапы, описанные ниже, являются общими (и обобщёнными) частями цикла тестирования программного обеспечения (software testing life cycle, STLC).
Сбор требований
Это, наверное, самый важный этап. На первой встрече клиенты в общих чертах описывают, что они хотят. Они описывают функциональность приложения или сервиса и какими особенностями он должен обладать, но редко упоминают технологии, которые должны использоваться в продукте.
Во многих компаниях анализ требований к функциональности является обязанностью бизнес-аналитиков. Однако они не могут гарантировать совместимость технических компонентов. Поэтому на этом этапе кроме бизнес-аналитиков заняты и другие специалисты, включая QA. Задачи последних включают:
Валидация — процесс оценки проекта до начала разработки с целью выяснить, удовлетворяет ли потенциальный продукт требованиям пользователей и стоит ли вкладывать в эту идею усилия.
В течение этого этапа QA работают вместе с бизнес-аналитиками с целью выяснить, какой программный продукт может удовлетворить потребности пользователя. По сути, они проверяют, нужен ли продукт пользователям и рынку. Очень важно собрать отзывы пользователей, чтобы узнать, чего не хватает или что может быть улучшено (дизайн, функции) для обеспечения лучшего пользовательского опыта.
До прохождения валидации продукт может и не дойти до потребителя, даже если он отлично сделан с технической точки зрения. Также на этом этапе проверяется, принесёт ли продукт пользу клиенту. Иначе зачем вообще этим заниматься?
Планирование тестирования
На этом этапе QA определяют стратегию тестирования. Под определением стратегии имеется в виду оценка времени и усилий для всего проекта. После анализа требований QA создают документ, известный как тест-план. Он включает в себя ожидаемые результаты проекта, его масштаб и цель, а также определяет среду тестирования.
Без этого этапа процесс тестирования был бы полон неожиданных препятствий и непредвиденных обстоятельств. Чтобы дальнейшие этапы следовали строгой последовательности действий, QA должен составить и задокументировать план действий. В противном случае процесс может получиться неуклюжим.
Разработка тестов
Когда у нас есть тест-план, мы можем приступить к настройке среды тестирования и созданию тест-кейсов. Тест-кейс — это набор шагов, которые нужно выполнить, чтобы удостовериться, что в продукте нет ошибок и он работает согласно требованиям. После этого можно думать о критерии приемлемости — техническом стандарте, которому должен соответствовать программный продукт, чтобы считаться успешным.
Выполнение тестов
Этот этап многие считают единственной задачей QA — выполнение всех тест-кейсов по плану. Если какая-то часть системы работает хорошо, мы отмечаем её как прошедшую тестирование. Таким образом мы можем удостовериться, что ничего не пропустим и на выходе получим качественный продукт.
Если тест-кейс прошёл неудачно, значит в коде есть ошибка, и QA отправляют отчёт разработчикам, чтобы они проверили, что не так.
Отчёт о результатах
После тестирования продукта наступает время обсуждения, что было хорошо, а что не очень, для улучшения дальнейших циклов тестирования. Чтобы обеспечить быстрое исправление ошибок без каких-либо недопониманий со стороны разработчиков, каждая обнаруженная проблема должна быть хорошо задокументирована. Позже мы посмотрим на наиболее распространённые методы, которые используют QA для тестирования продукта с разных точек зрения.
Что такое цикл тестирования? Это частота, с которой мы проводим эти пять этапов тестирования.
Особенности работы QA
Множество компаний-разработчиков программного обеспечения работают спринтами — даётся список задач и две недели на их выполнение. Во время каждого спринта мы реализуем определённую часть требований к продукту и проходим через все пять стадий тестирования. Важно понимать, что тестирование не подразумевает только проверку каждого способа взаимодействия с продуктом. Конечно, и это тоже, но зачастую с системой можно сделать гораздо больше.
Если QA не участвуют в процессе разработки, то позже может оказаться, что команда разработчиков сделала что-то, что работает и работает хорошо, но не то, что нужно. Также QA помогают сократить время, необходимое для разработки новых тест-кейсов, так как чем раньше мы поймём, что и как мы собираемся тестировать, тем проще будет провести тестирование. Очень важно, чтобы разработчики и QA работали вместе, иначе всё превратится в соревнование «кто найдёт больше багов», что редко приводит к качественным результатам.
Теперь, когда мы знаем о циклах тестирования, можно вкратце рассказать, почему каждой команде нужен QA:
Вы могли заметить, что часто упоминается тестирование. Это потому, что есть такая отдельная дисциплина, как контроль качества (Quality Control, QC). Далее мы поговорим о работе QA, о разнице QA и QC, взаимосвязи SDLC и STLC, а также дадим детальное описание некоторых методов тестирования, используемых QA-инженерами.
Обеспечение качества и контроль качества
Контроль качества (Quality Control, QC) охватывает всю деятельность, направленную на то, чтобы убедиться, что продукт хорошего качества и отвечает заданным требованиям. QC-инженеры занимаются поиском дефектов в продукте до его выпуска. Можно сказать, что обеспечение качества включает в себя контроль качества.
Есть случаи, когда продукт не требует QA, а только QC. Например, если команда получает продукт, разрабатываемый другими людьми, с целью проверить, соответствует ли код требованиям.
В некоторых командах QA и QC совмещаются с другими ролями. Иногда разработчики пытаются проверить свой собственный код. Тем не менее, это сказывается на качестве, так как гораздо сложнее найти ошибки в своём коде, чем в чужом.
Цикл разработки программного обеспечения и цикл тестирования
Разработка и тестирование должны быть синхронными. Команда, как единое целое, несёт ответственность за продукт. Если разработка и тестирование не выполняются одновременно, то возможны задержки и несогласованности, что ведёт к низкому качеству продукта.
Надеемся, нам удалось вас убедить в важности одновременного проведения SDLC и STLC. Теперь мы перейдём к некоторым популярным методам составления тестов, которые QA-инженеры используют для обеспечения качества.
Методы составления теста
Тест-кейс (или просто тест) — пошаговый подход к тестированию функциональности программного продукта. По сути сюда входят тестируемый объект и способ тестирования.
Метод составления теста — процесс выбора тестов, которые подтвердят, что продукт соответствует спецификациям до его релиза.
Есть разные методы составления теста, каждый из которых выявляет недостатки определённого типа. Поэтому выбор метода зависит от типа продукта, его готовности и требований.
На картинке ниже представлены основные методы составления теста:
Давайте рассмотрим подробнее каждый метод и случаи, в которых мы их используем.
Статический. Этот метод тестирует исходный код, функциональные спецификации и спецификации требований до выполнения кода (до выхода в релиз). Этот метод определяет структурные недостатки. Это не одноразовая работа, поэтому мы стараемся начать её на ранних этапах процесса разработки.
На основе структуры. Мы используем такой метод, когда у нас есть полный доступ к коду. Проще говоря, он касается внутренней логики и структуры кода. Такие тесты помогают определить неправильную или отсутствующую логику и опечатки в коде.
На основе спецификации. Также известный как тестирование чёрного ящика, данный метод тестирования анализирует функциональность программного продукта без изучения кода. Исходя из требований, мы выбираем соответствующие методы составления тестов, которые помогают нам получить тест-кейсы.
На основе опыта. Это больше вспомогательный метод, который позволяет QA тестировать программное обеспечение на основе их предыдущего опыта работы с подобными системами.
Теперь вы знаете достаточно, чтобы понять, какой теоретической базой должен обладать специалист, проводящий тестирование качества. Количество требуемых навыков делает практически невозможным обеспечение качества продукта человеком, не являющимся QA.
В заключение
Неважно, каким простым кажется продукт, ведь в основе его качества лежит тонна проделанной работы. Как заметил Дон Норман, «Хороший дизайн гораздо сложнее заметить, чем плохой». В большинстве случаев QA-инженеры дают людям возможность наслаждаться продуктом, проверив, что всё работает хорошо.
Обеспечение качества включает много всего, от тестирования до анализа результатов. Большинству программных продуктов нужны QA-инженеры, чтобы:
Не так просто протестировать систему без особых навыков, даже опытному разработчику это вряд ли под силу. По этой причине в лучших командах QA и разработчики работают вместе; они могут объединить свои навыки для создания качественного продукта.
QA и QC: как их различать?
Если Вы никогда не сталкивались с такими понятиями, как Quality Assurance и Quality Control, на первый взгляд может показаться, что это один и тот же концепт, просто названный разными терминами. Однако это не совсем так. Есть целый список различий между QA и QC, и сегодня мы расскажем Вам как в них разбираться и больше никогда не путать.
QA (сокращение от английского «Quality Assurance», что переводится, как «обеспечение качества») это профилактический процесс, который обеспечивает соблюдение всех необходимых методов, процедур, стандартов и методов во время разработки продукта для достижения результата, максимально близкого к идеальному.
QC (сокращение от английского «Quality Control», что переводится, как «контроль качества») это процесс контроля качества, который обеспечивает соответствие продукции установленным заранее требованиям.
Таким образом, если QA нацелен на предотвращение дефектов на стадии тестирования, то QC устраняет недоработки и неполадки в уже готовом продукте.
С определением каждого из терминов мы разобрались, теперь давайте поговорим о том, что же еще отличает процесс обеспечения качества от процесса контроля качества.
Подход QA заключается во внедрении соответствующей системы управления качеством, оценке ее осуществимости и анализу всех сопутствующих действий, чтобы убедиться, что все работает так, как задумано. QC, в свою очередь, нацелен на выявление и ликвидацию источников проблем, напрямую влияющих на качество финального продукта, при поддержке специального оборудования.
В процессе разработки, Quality Assurance львиную долю внимания уделяет предотвращению появления дефектов и багов, в то время как Quality Control акцентирует свою деятельность на тестировании уже готового продукта с целью выявления и устранения дефектов.
Метод, использующийся QA, называется “профилактическим”. А действия, предпринимавшиеся отделом QC, можно назвать “корригирующими”.
Пример, описанный выше, доказывает важность таких процессов, как QA и QC. Именно благодаря этим процедурам релиз продукта будет иметь все шансы на достижение наилучших результатов, а также на привлечение новых лояльных клиентов и на последующее развитие и процветание.
Чтобы подытожить вышесказанное, будет полезно резюмировать различия процессов контроля качества и обеспечения качества.
Независимо от отрасли и назначения Вашего продукта, будь то интернет магазин или приложение погоды, процессы Quality Assurance и Quality Control помогут Вам реализовать конкурентоспособный продукт без багов и дефектов, что будет способствовать успеху и развитию бизнеса наилучшим образом.
Кто такой хороший QA?
Начнем с того, что в народе всех quality assurance инженеров (“по-нашенски”, инженеров отдела качества) обзывают тестировщиками. Это не совсем правильно, в реальности тестирование — это только часть задач QA, но кого бы это волновало. Поэтому пойдем в общем тренде и будем использовать привычное всем погоняло.
Итак, что же определяет хорошего тестировщика? Не будем опускаться до банальностей и говорить: внимательность, усидчивость, терпение, любопытство, талант все ломать и другую чепуху. Это все, конечно, важно, но не главное. В первую очередь у человека должно присутствовать чувство здравого смысла и ответственности.
Вот например, говорят, главное — иметь талант все ломать. Часто можно услышать, мол, что он в руки ни возьмет, все сломает. Это, конечно, похвально, но в работе тестировщика не главное что-то ломать. Тут к нам на помощь придет определение, которое нетрудно найти в Википедии.
Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.
Из него видно, что к ПО есть конкретные требования, и надо, чтобы они выполнялись. Если тестировщик ломал программу вместо того, чтобы проверить, выполняет ли она вообще возложенные на нее функции, в итоге он может получить стабильную, но не нужную заказчику фигню.
Я понимаю, что все любят истории, как кто-то облажался, их есть у меня. Я за свою трудовую деятельность поработал в разных местах и на разных проектах, поэтому был сам свидетелем или слышал от коллег много историй. Некоторые из них готов поведать. Ну и да, необходимая мантра: все совпадения случайны, а имена и названия выдуманы.
Тестирование и не только
Начнем по порядку. Как я уже говорил вначале, тестировщик занимается не только тестированием. Как вам такой каламбур? В крупных и солидных компаниях команду тестирования стараются подключать к проекту на самой ранней стадии, т.е. на этапе сбора требований, но так делают не везде и не всегда.
Однажды во время приемочного тестирования пользователь завел критический баг, т.к. одно из требований не выполнялось. Суть претензии была в том, что пользователь на экране не нашел необходимый ему атрибут (для тех, кто в танке — поле со значением). Тестировщик, понятное дело, полез в спецификацию, проверил, что в приложении этот атрибут присутствует, и радостный побежал рассказывать пользователю, что все хорошо.
Вы уже понимаете, что история на этом не кончается.
Тестировщик попытался объяснить пользователю, в чем тот не прав, нарвавшись на порцию негатива и негодования. Пользователь усадил его рядом и открыл требования, на основе которых писались спецификации. Одно из этих требований почти дословно гласило следующее: ”Атрибут должен отображаться на каждом экране”. Одно предложение, а сколько смысла! Затем он открыл приложение и начал рандомно навигироваться на разные экраны, приговаривая: “И где же этот атрибут?”. Понятное дело, что пользователь откровенно издевался, но формально он имел на это право. Беда в том, что дальше пошла эскалация, и в процесс обсуждения проблемы вовлекалось все больше народу. Под конец пользователя убеждали, кроме самого тестировщика, несколько ПМов и толпа аналитиков, а тот был непреклонен и требовал уже невозможного.
В итоге компромисс был найден, и в требовании появился список нужных экранов, на которых атрибут должен находиться, но это потребовало больших изменений в коде программы, соответственно, весь цикл разработки пришлось проходить заново, но в ускоренном темпе. Компания потратила дополнительные деньги, не говоря уже о репутационных издержках, у сотрудников стресс и переработки. Всего этого можно было избежать, если бы тестировщика подключили в начале проекта и он смог посмотреть требования на наличие двусмысленности — это как минимум, либо попозже, чтобы проверил спецификацию на соответствие требованиям. И да, частенько тестировщики работают с реальными пользователями напрямую, что требует от них навыков подавления стресса, психоаналитики и экстрасенсорики.
Без фанатизма
Идем дальше, весьма иронично, сам процесс тестирования характеризуется бородатым анекдотом:
Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар.
Заказывает:
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
–1 кружку пива,
qwerty кружек пива.
Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают.
Не каждый понимает, что тестировать можно бесконечно. Идеал недостижим, а у проектов есть вполне конкретные сроки, в которые надо укладываться. Так вот, был один тестировщик, который при прохождении тест-кейса постоянно его фейлил. Время шло, проект уже начал подходить к концу, и разработчик преодолел все найденные проблемы. И тут тестировщик заявляет, что основная необходимая функциональность не работает. Все понимают: починить ее в срок не получится.
В ходе разбирательств выясняется: во время тестирования сценарий ни разу не был пройден полностью до злополучного момента. Тестировщик находил недочет в начале процесса, который тестировал, заводил тикет и бросал на полпути. При этом продолжить тестирование было возможно, т.к. все найденные ошибки его не блокировали. Впоследствии у всей команды традиционные стресс и переработки.
Кстати, этим грешат некоторые пользователи на приемочном тестировании, объявляют баг критичным и бросают работу. Это сильно затрудняет работу, т.к. в общем потоке проблем, которые вообще могут проблемой не являться, теряются действительно критичные баги.
Мораль такова: хороший тестировщик никогда не остановится, найдя первый попавшийся баг. Он пройдет весь сценарий от начала и до конца, попутно записывая все найденные баги, а если упрется в блокирующую прохождение ошибку, будет искать workaround, т.е. обходной путь. И когда убедится в том, что обходных путей нет, остановится.
Тут есть один нюанс. Чаще всего проекты делаются в условиях сжатых сроков, ну или не очень сжатых, но вполне конкретных. Бывает, что человек распыляется на бесконечное тестирование одного поля, вводя в него все возможные и невозможные варианты значений. При этом по требованиям заказчика надо проверить выполняемую приложением функцию, хоть и с использованием значения из этого поля. В результате он рискует потратить время впустую и не проверить главное. Тестировщик должен уметь грамотно оценить свои силы и критичные места приложения. Не нужно тестировать те места, которые тестирования не требуют. Главное то, что приложение должно выполнять возложенную на него функцию. Сначала нужно добиться выполнения прямого сценария, а потом уже повышать качество выполнения до нужного уровня.
Язык мой — враг мой
Далее… Проблемы с документацией могут быть не только у аналитиков, но и у тестировщиков. Неоднократно было замечено, что не только разработчики не умеют внятно описать содержание тикета в соответствующем его поле, но и сами тестировщики не могут нормально написать порядок действий, вызывающих ошибку. Это большая проблема. Кто-то просто не понимает, из-за чего ошибка возникает, и не заморачивается выяснением шагов. У кого-то вообще проблемы с грамотностью.
Что это все за собой влечет? Тут ответ и ежу понятен, но на примерах, конечно, интереснее.
Существует когорта тестировщиков, которые, видя перед собой ошибку, просто записывают тот миллион шагов, в том числе и мусорных, которые его привели к багу. Они не воспроизводят ошибку и не выясняют, что конкретно из сделанного ее вызывает. При этом они могут записать набор шагов, который с этой ошибкой вообще не связан. Разработчик будет пытаться воспроизводить, в какой-то момент у него вскипит голова, и он пойдет лично разбираться с тестировщиком. Они вместе будут разбираться и оба потратят кучу времени на лишние коммуникации. Благо это все быстро лечится временем и опытом, хотя бывают и клинические случаи.
С грамотностью же все сложнее. На моей практике был случай, когда QA лиду нужно было исправить описание нескольких десятков тикетов, т.к. они должны были отправиться заказчику в отчете о проделанной работе. Это случилось потому, что большая часть команды не смогла грамотно сформулировать свои мысли на английском.
Но и с русским тоже бывают проблемы, слава богу, реже. Тут все то же самое, плохо написанное описание приводит к тому, что тикет, как футбольный мячик, начинает скакать между людьми, не попадая в ворота. Хорошо, если команда сидит вся в одном помещении и может просто поговорить, не вставая от монитора. Сложнее — если команда распределенная. Совсем плохо, если разноязычная. Самое худшее, что может произойти в итоге, это то, что тикет будет сделан неправильно из-за недопонимания и будет переоткрываться тысячу раз. А то и к заказчику улетит в одном из релизов с вывернутой логикой.
Личное пространство
Еще одна проблема — это тестовые стенды и тестовые данные. В разных компаниях это происходит по-разному, но частенько такое бывает, что сотруднику выдаются права на рабочий сервер заказчика или выдают его базу данных для тестирования. Казалось бы, что может пойти не так?
А вот дофига чего… Если у кого-то есть доступ на сервер заказчика, с одной стороны — это удобно, можно посмотреть проблемы из первых рядов и не ванговать ошибку по фотографии. Но тут есть риск испортить данные заказчика, что может привести к серьезным последствиям. Я уже молчу о тех случаях, когда такой доступ вообще запрещен законом.
Был случай, когда у заказчика на 3 дня отвалился сервер. Разработчик все это время не мог понять, почему это произошло, и судорожно искал ошибку, а бизнес терпел убытки. В итоге выяснилось: компания наняла на аутсорс индусов, там народ, не мудрствуя лукаво, выдал всем админские права. Всем — это значит, даже той девочке, которая в компании работает 3 дня, а компа в ее деревне отродясь не было, поэтому срок знакомства у них еще меньше. Но девочка оказалась жутко талантливая, она умудрилась найти в админке базовую сущность и поменяла ее тип, после чего закономерно все отвалилось и перестало работать. Нетрудно догадаться, как она взлетела по карьерной лестнице после этого.
Такая же ерунда и с данными от заказчика. Опять же, я не говорю про случаи, когда это запрещено законом. Если есть возможность работать на реальных данных — это прекрасно, но с этим надо быть осторожным. Все наверно слышали истории про случайные отправки писем или сообщений с тестового сервера реальным пользователям. Так вот, это не шутки. Такое реально случается, причем достаточно часто. Ладно, если эти сообщения озаглавлены как тестовые и имеют вменяемое содержание, но бывает, что люди куражатся и пишут то, о чем потом жалеет вся команда разработки приложения.
Организационные моменты
Я уже сам себя начал утомлять обилием текста, поэтому последнее. Тестировщик должен постоянно поставлять своему начальнику актуальную информацию о своей работе. По таким отчетам, если они сделаны правильно, начальник делает вывод о состоянии проекта в целом. Не только о работе одного тестировщика или всей команды тестирования, но и о работе команды разработки и о стадии, на которой проект находится. Также такие отчеты позволяют сделать анализ для планирования будущих релизов и т.д и т.п.
Есть много примеров, когда эта работа не делалась или делалась ненадлежащим способом, от чего у начальства возникало чувство неопределенности со всеми вытекающими последствиями. Расскажу самый яркий.
Однажды тестировщика поставили на новый проект. Поскольку он его плохо знал, ему дали задание разобраться и записать наблюдения. Так как это было нечто неформальное, договорились, что писать будет в гуглдоке. Человек начал выполнять задание, через неделю это задание было проверено, тестировщика похлопали по плечу и он продолжил работу. Шли месяцы, у начальства появилось беспокойство, почему в багтрекере нет тикетов и ничего на проекте не делается. Начали разбираться, оказалось, что человек продолжает писать в том самом гуглдоке. Никто же не сказал “Горшочек, не вари” и не остановил тестировщика, а он исправно продолжал разбираться и записывать наблюдения, при этом никак не давая о себе знать. Баги есть, и он их нашел, но никому не сказал, а лишь записал в файлик, о котором спустя неделю уже все забыли.
По факту, ожидание было, что человек продолжит работу уже формально, т.е. в багтрекере, давая своими тикетами работу разработчикам, но этого не произошло. Создалось впечатление, что человек ничего не делал, хоть он и работал. Понятно, что проблема была не только со стороны тестировщика, но если бы он делал регулярный отчет о своей деятельности, то недопонимания удалось бы избежать.
Нередко недостаток информации создает ощущение о плохом тестировании продукта, что не была протестирована та или иная часть функционала. Чтобы такого не возникало, нужно составлять подробные отчеты, это особенно важно на крупных проектах.
Заключение
Надо понимать, что QA — это, по сути, адвокат пользователя. В любой непонятной ситуации, связанной с работой приложения, тестировщик должен ставить себя на его место. Если путем этой нехитрой манипуляции сознанием выяснится, что приложение чем-то не устраивает, то надо заводить тикет. И это может быть кнопка не в том месте или другая мелочь с точки зрения разработчика, но часто бывает так, что для пользователя эта мелочь может превратиться в ад и точку раздражения. Как пример можно взять дикое количество всплывающих окон в приложении. Да, программа выполняет свою функцию, но пользоваться ей затруднительно, т.к. выполнение этой функции занимает много времени и сил пользователя, который вынужден жмакать кучу лишних окон с загрузками и прочим, вместо того чтобы сделать всю работу на одном экране.
А если человек ответственно и со здравым смыслом подходит к своей работе, то ему удастся избежать большинство проблем на своем пути, не только в профессии QA.