кволити контроль что это
Quality control: что это такое и что значит Quality? Терминология
Quality Control (QA) — это «контроль качества», а точнее, это процесс, который отвечает за соблюдение ожидаемого качества продукции путем тестирования, выявления и устранения его неисправностей.
Quality Control — что это?
Quality Control идет очень плотно с другим процессом в тестировании — Quality Assuran c e (QA). Очень часто эти процессы принимают за один и тот же, хотя по факту они отличаются и обозначают разные мероприятия. QC и QA направлены на общее действие — улучшить качество программного продукта, но применяются на разных этапах продукта и ориентированы на разные цели. Поэтому, чтобы точно понять, что это такое — Quality Control, нужно разобраться с обоими понятиями.
Quality Control и Quality Assurance
Quality Assurance — это процесс, который описывает все требования к программному продукту, чтобы его состояние было максимально близким к идеальному. Помимо самих требовании, это т процесс также описывает инструменты для достижения указанных требований:
Получается, что процесс QA по иерархии стоит «выше» процесса QC, является более «широким» и «включает» Quality Control в свое описание. QA старается предотвратить дефекты ПО в процессе его разработки и тестирования, а Quality Control предусматривает устранение недоработок и ошибок уже в готовой программе.
Чем отличаются Quality Control и Quality Assurance?
Терминологию этих процессов мы определили. Давайте подробнее остановимся на их различиях.
Различия по цели. Q u ality Assurance преследует цель — улучшить процессы разработки и тестирования, чтобы не было дефектов. Quality Control преследует более простую — выявить и устранить недостаток в рабочей программе.
Разная направленность. QA направлен на процесс разработки продукта. QS направлен на уже разработанный продукт.
Разные методы. Методы работы Quality Assurance являются профилактическими, а методы работы Quality Control — конкретно-техническими.
Разное распределение ответственности. В QA ответственность за должное качество продукта лежит абсолютно на всех участниках разработки программы. В QC ответственность лежит на конкретной команде или разработчике, которые ищут дефекты в программе и устраняют их.
Различная последовательность. QA — это процесс, который обеспечивает качество до наступления контроля качества. QC — это процесс, который начинает применяться после окончания обеспечения качества. То есть сначала идет процесс QA, а после него включается процесс QC.
Quality Control и Quality Assurance на практике
отсутствие кнопки покупки;
нет кнопки «Подняться наверх»;
постоянно выскакивает какое-то назойливое сообщение с какими-то предложениями, а само сообщение невозможно просто закрыть;
сложная форма заказа, которая постоянно сообщает о какой-то ошибке;
не работают фильтры сортировки товара по нужным вам параметрам;
Вроде небольшие недоработки, но они создают негативное отношение к этому интернет-магазину. Каждый такой обнаруженный вами недостаток снижает вероятность, что вы в этом интернет-магазине что-то купите. В итоге настает момент, когда вы просто закрываете вкладку с этим магазином и ищете другой.
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Тестирование, контроль качества (QC) и обеспечение качества (QA), что это?
Для человека, который только собирается начинать карьеру в ИТ, эти три термина могут показаться если не идентичными, то очень близкими. Это все о тестировании программного продукта. Более того, встречаются даже отдельные менеджеры продукта, которые не до конца понимают смысл этих понятий управления качеством ПО, в результате проект выходит за рамки бюджета, результат не соответствует ожиданиям и т.д. Итак, чтобы избавить вас от потенциальных проблем из-за непонимания этих базовых понятий, представляем вам краткую характеристику этих терминов.
Три уровня тестирования ПО
Итак, общую схему взаимоотношения этих понятий можно представить следующим рисунком:
Теперь давайте рассмотрим это более подробно.
Менеджер проекта (PM) уделяет процессу управление качеством много времени. Предполагается, что это – задача РМ, но конечно же менеджер проектов не сможет сделать все как надо сам. В команде обязательно должен быть хотя бы один QC специалист и несколько тестировщиков, а еще зачастую функции QA выполняет руководитель команды тестировщиков, который хорошо понимает, что и когда должно быть сделано. Одним словом, в процессе обеспечения и контроля качества должна быть задействована целая команда.
В QA входит разработка плана тестирования, и его проведение согласно этому документу, а также, оценка и контроль результатов. QC-специалисты анализируют результаты тестирования и устраняют найденные дефекты. По сравнению с QA, QC требует больших затрат времени и его проводят после завершения этапа обеспечения качества. Так сложилось, что многие считают тестировщика и QA-инженера одним лицом, но как вы видите, роли и обязанности тестировщиков, QA и QC довольно сильно отличаются. Скорее можно сказать, что QC и QA – это следующие логические этапы профессионального тестировщика.
Джуниоры-тестировщики тестируют ПО по сценариям, а их старшие коллеги разрабатывают эти планы, тест-кейсы и всю систему контроля качества в целом.
Вместо выводов
Здесь мы рассмотрели разницу между понятиями «тестирование», «QA» и «QC». Хотя это и разные вещи, но конечная цель у них одна – выдать на рынок качественный продукт, удовлетворяющий потребности клиентов.
Никто не умеет создавать идеальные программы сразу, это факт. Но люди разработали целую систему контроля качества, которая реально работает и дает результат. При правильном применении QA и QC позволяют не только свести ошибки и дефекты к минимуму, но и предотвратить их появление еще на этапе разработки.
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, QC или тестировщик?
В прошлом я «офисный планктон» офис менеджер, но чуть больше двух лет начала свой путь в IT.
И вот уже больше двух лет я развиваюсь в направлении контроля качество ПО и работаю дома в пижаме.
Мысль о написании данного поста появилась уже довольно давно. Но было откровенно лень времени все не хватало. Сейчас же я нахожусь в поисках места для трудоустройства (очень не люблю слово «работа») и решала заняться постом или серией постов, как получится.
Цели у меня самые эгоистические.
А именно: собирая информацию для постов, освежить свои знания и обзавестись новыми.
Начну, пожалуй, с терминов QA (Обеспечение качества), QC (Контроль качества) и Test (Тестирование).
Очень часто в названии вакансии можно встретить QA специалист, QA инженер и пр.
Из описания же, если оно соответствует реальным требованиям, становится ясно, что требуется тестировщик, а в лучшем случае специалист по контролю качества. Если же описание составлялось HR без согласования со специалистами, то на собеседовании может ожидать большой-большой сюрприз
в виде обязанностей тестировщика (еще и джуниора) и соответствующей зарплатной вилки.
Итак. QA (Quality Assurance) – Обеспечение качества продукта.
Что же делает данный специалист. Он собирает информацию о продукте и думает: как можно улучшить процесс разработки, какие методики внедрить/убрать в работе всех участников процесса: разработчиков, аналитиков и тд. Он находит причину «недомогания» и «лечит» продукт.
QС (Quality Control) – Контроль качества продукта.
Специалист по контролю качества часто на практике оказывается либо старшим тестировщиком, либо единственным. Он уже и сам тестирует, и собирает информацию от других специалистов- тестировщиков, и принимает решение можно ли релизить продукт. У специалиста по контролю качества есть, так называемое, право вето. Мне удалось им воспользоваться один раз за время работы на последнем проекте. Не всегда к QC прислушиваются, но…
Мы вплотную приблизились к обязанностям тестировщика.
Тестировщики в зависимости от специализации и навыков:
1. Ищут ошибки в продукте и регистрируют их в систему
2. Исследуют требования к ПО и выявляют расхождения
3. Общаются с клиентами и анализируют их потребности
4. Взаимодействуют с разработчиками, техподдержкой, другими участниками процесса и помогают им
5. Автоматизируют тесты
6. Разрабатывают тестовую документацию, составляют отчёты
Получилось скомкано. Чукча не писатель. Но, надеюсь, кому-нибудь пост окажется полезным.
В процессе написания поняла, что не знаю, что еще написать. Спрашивайте – отвечу в комментах или в новом посте, если вопросов будет много или ответ будет большим.
Конструктивная критика приветствуется.
Спасибо за внимание)
Он собирает информацию о продукте и думает: как можно улучшить процесс разработки, какие методики внедрить/убрать в работе всех участников процесса: разработчиков, аналитиков и тд.
Лол, QA, который бы пояснял как девелопить продукт, аналитикам, как анализировать, а мененджерам пояснял по процессам. Упороться.
Помогите плз понять суть)
Необходимо найти все возможные переходы на страницу link_page.php
и определить коды ответа сервера при использовании данных переходов.
Разработчик наблюдает работу тестировщика
Тестинг VS Тестинг на поде
С днем тестировщика(с подарком)
Хочу поздравить всех причастных к профессии тестировщиков с праздником.
Так случилось, что сегодня перечитывая книгу Святослава Куликова «Тестирование программного обеспечения. Базовый курс.» я наткнулся на таблицу классификации тестирования по методам Black box и White box. Эта таблица в книге занимает 4 страницы(стр. 107-111), на которых перечислены виды тестирования рассмотренные в книге, а их около 100. Достаточно трудно воспринимать такую 4-х страничную таблицу в отрыве от понимания каждого вида тестирования и я решил создать Google таблицу в которой просто систематизировал и чуть более визуализировал эту информацию. Вся информация взята из вышеупомянутой книги, никакой отсебятины.
В первую очередь материал подготовлен для удобства обучения, тренировки и использования в качестве повседневной шпаргалки для тестировщиков. Пользуйтесь на здоровье. Ещё раз с праздником!
На материал в таблице как, на заимствованный из вышеуказанной книги, распространяется лицензия «Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International».
Кто такой хороший QA?
Начнем с того, что в народе всех quality assurance инженеров (“по-нашенски”, инженеров отдела качества) обзывают тестировщиками. Это не совсем правильно, в реальности тестирование — это только часть задач QA, но кого бы это волновало. Поэтому пойдем в общем тренде и будем использовать привычное всем погоняло.
Итак, что же определяет хорошего тестировщика? Не будем опускаться до банальностей и говорить: внимательность, усидчивость, терпение, любопытство, талант все ломать и другую чепуху. Это все, конечно, важно, но не главное. В первую очередь у человека должно присутствовать чувство здравого смысла и ответственности.
Вот например, говорят, главное — иметь талант все ломать. Часто можно услышать, мол, что он в руки ни возьмет, все сломает. Это, конечно, похвально, но в работе тестировщика не главное что-то ломать. Тут к нам на помощь придет определение, которое нетрудно найти в Википедии.
Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.
Из него видно, что к ПО есть конкретные требования, и надо, чтобы они выполнялись. Если тестировщик ломал программу вместо того, чтобы проверить, выполняет ли она вообще возложенные на нее функции, в итоге он может получить стабильную, но не нужную заказчику фигню.
Я понимаю, что все любят истории, как кто-то облажался, их есть у меня. Я за свою трудовую деятельность поработал в разных местах и на разных проектах, поэтому был сам свидетелем или слышал от коллег много историй. Некоторые из них готов поведать. Ну и да, необходимая мантра: все совпадения случайны, а имена и названия выдуманы.
Тестирование и не только
Начнем по порядку. Как я уже говорил вначале, тестировщик занимается не только тестированием. Как вам такой каламбур? В крупных и солидных компаниях команду тестирования стараются подключать к проекту на самой ранней стадии, т.е. на этапе сбора требований, но так делают не везде и не всегда.
Однажды во время приемочного тестирования пользователь завел критический баг, т.к. одно из требований не выполнялось. Суть претензии была в том, что пользователь на экране не нашел необходимый ему атрибут (для тех, кто в танке — поле со значением). Тестировщик, понятное дело, полез в спецификацию, проверил, что в приложении этот атрибут присутствует, и радостный побежал рассказывать пользователю, что все хорошо.
Вы уже понимаете, что история на этом не кончается.
Тестировщик попытался объяснить пользователю, в чем тот не прав, нарвавшись на порцию негатива и негодования. Пользователь усадил его рядом и открыл требования, на основе которых писались спецификации. Одно из этих требований почти дословно гласило следующее: ”Атрибут должен отображаться на каждом экране”. Одно предложение, а сколько смысла! Затем он открыл приложение и начал рандомно навигироваться на разные экраны, приговаривая: “И где же этот атрибут?”. Понятное дело, что пользователь откровенно издевался, но формально он имел на это право. Беда в том, что дальше пошла эскалация, и в процесс обсуждения проблемы вовлекалось все больше народу. Под конец пользователя убеждали, кроме самого тестировщика, несколько ПМов и толпа аналитиков, а тот был непреклонен и требовал уже невозможного.
В итоге компромисс был найден, и в требовании появился список нужных экранов, на которых атрибут должен находиться, но это потребовало больших изменений в коде программы, соответственно, весь цикл разработки пришлось проходить заново, но в ускоренном темпе. Компания потратила дополнительные деньги, не говоря уже о репутационных издержках, у сотрудников стресс и переработки. Всего этого можно было избежать, если бы тестировщика подключили в начале проекта и он смог посмотреть требования на наличие двусмысленности — это как минимум, либо попозже, чтобы проверил спецификацию на соответствие требованиям. И да, частенько тестировщики работают с реальными пользователями напрямую, что требует от них навыков подавления стресса, психоаналитики и экстрасенсорики.
Без фанатизма
Идем дальше, весьма иронично, сам процесс тестирования характеризуется бородатым анекдотом:
Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар.
Заказывает:
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
–1 кружку пива,
qwerty кружек пива.
Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают.
Не каждый понимает, что тестировать можно бесконечно. Идеал недостижим, а у проектов есть вполне конкретные сроки, в которые надо укладываться. Так вот, был один тестировщик, который при прохождении тест-кейса постоянно его фейлил. Время шло, проект уже начал подходить к концу, и разработчик преодолел все найденные проблемы. И тут тестировщик заявляет, что основная необходимая функциональность не работает. Все понимают: починить ее в срок не получится.
В ходе разбирательств выясняется: во время тестирования сценарий ни разу не был пройден полностью до злополучного момента. Тестировщик находил недочет в начале процесса, который тестировал, заводил тикет и бросал на полпути. При этом продолжить тестирование было возможно, т.к. все найденные ошибки его не блокировали. Впоследствии у всей команды традиционные стресс и переработки.
Кстати, этим грешат некоторые пользователи на приемочном тестировании, объявляют баг критичным и бросают работу. Это сильно затрудняет работу, т.к. в общем потоке проблем, которые вообще могут проблемой не являться, теряются действительно критичные баги.
Мораль такова: хороший тестировщик никогда не остановится, найдя первый попавшийся баг. Он пройдет весь сценарий от начала и до конца, попутно записывая все найденные баги, а если упрется в блокирующую прохождение ошибку, будет искать workaround, т.е. обходной путь. И когда убедится в том, что обходных путей нет, остановится.
Тут есть один нюанс. Чаще всего проекты делаются в условиях сжатых сроков, ну или не очень сжатых, но вполне конкретных. Бывает, что человек распыляется на бесконечное тестирование одного поля, вводя в него все возможные и невозможные варианты значений. При этом по требованиям заказчика надо проверить выполняемую приложением функцию, хоть и с использованием значения из этого поля. В результате он рискует потратить время впустую и не проверить главное. Тестировщик должен уметь грамотно оценить свои силы и критичные места приложения. Не нужно тестировать те места, которые тестирования не требуют. Главное то, что приложение должно выполнять возложенную на него функцию. Сначала нужно добиться выполнения прямого сценария, а потом уже повышать качество выполнения до нужного уровня.
Язык мой — враг мой
Далее… Проблемы с документацией могут быть не только у аналитиков, но и у тестировщиков. Неоднократно было замечено, что не только разработчики не умеют внятно описать содержание тикета в соответствующем его поле, но и сами тестировщики не могут нормально написать порядок действий, вызывающих ошибку. Это большая проблема. Кто-то просто не понимает, из-за чего ошибка возникает, и не заморачивается выяснением шагов. У кого-то вообще проблемы с грамотностью.
Что это все за собой влечет? Тут ответ и ежу понятен, но на примерах, конечно, интереснее.
Существует когорта тестировщиков, которые, видя перед собой ошибку, просто записывают тот миллион шагов, в том числе и мусорных, которые его привели к багу. Они не воспроизводят ошибку и не выясняют, что конкретно из сделанного ее вызывает. При этом они могут записать набор шагов, который с этой ошибкой вообще не связан. Разработчик будет пытаться воспроизводить, в какой-то момент у него вскипит голова, и он пойдет лично разбираться с тестировщиком. Они вместе будут разбираться и оба потратят кучу времени на лишние коммуникации. Благо это все быстро лечится временем и опытом, хотя бывают и клинические случаи.
С грамотностью же все сложнее. На моей практике был случай, когда QA лиду нужно было исправить описание нескольких десятков тикетов, т.к. они должны были отправиться заказчику в отчете о проделанной работе. Это случилось потому, что большая часть команды не смогла грамотно сформулировать свои мысли на английском.
Но и с русским тоже бывают проблемы, слава богу, реже. Тут все то же самое, плохо написанное описание приводит к тому, что тикет, как футбольный мячик, начинает скакать между людьми, не попадая в ворота. Хорошо, если команда сидит вся в одном помещении и может просто поговорить, не вставая от монитора. Сложнее — если команда распределенная. Совсем плохо, если разноязычная. Самое худшее, что может произойти в итоге, это то, что тикет будет сделан неправильно из-за недопонимания и будет переоткрываться тысячу раз. А то и к заказчику улетит в одном из релизов с вывернутой логикой.
Личное пространство
Еще одна проблема — это тестовые стенды и тестовые данные. В разных компаниях это происходит по-разному, но частенько такое бывает, что сотруднику выдаются права на рабочий сервер заказчика или выдают его базу данных для тестирования. Казалось бы, что может пойти не так?
А вот дофига чего… Если у кого-то есть доступ на сервер заказчика, с одной стороны — это удобно, можно посмотреть проблемы из первых рядов и не ванговать ошибку по фотографии. Но тут есть риск испортить данные заказчика, что может привести к серьезным последствиям. Я уже молчу о тех случаях, когда такой доступ вообще запрещен законом.
Был случай, когда у заказчика на 3 дня отвалился сервер. Разработчик все это время не мог понять, почему это произошло, и судорожно искал ошибку, а бизнес терпел убытки. В итоге выяснилось: компания наняла на аутсорс индусов, там народ, не мудрствуя лукаво, выдал всем админские права. Всем — это значит, даже той девочке, которая в компании работает 3 дня, а компа в ее деревне отродясь не было, поэтому срок знакомства у них еще меньше. Но девочка оказалась жутко талантливая, она умудрилась найти в админке базовую сущность и поменяла ее тип, после чего закономерно все отвалилось и перестало работать. Нетрудно догадаться, как она взлетела по карьерной лестнице после этого.
Такая же ерунда и с данными от заказчика. Опять же, я не говорю про случаи, когда это запрещено законом. Если есть возможность работать на реальных данных — это прекрасно, но с этим надо быть осторожным. Все наверно слышали истории про случайные отправки писем или сообщений с тестового сервера реальным пользователям. Так вот, это не шутки. Такое реально случается, причем достаточно часто. Ладно, если эти сообщения озаглавлены как тестовые и имеют вменяемое содержание, но бывает, что люди куражатся и пишут то, о чем потом жалеет вся команда разработки приложения.
Организационные моменты
Я уже сам себя начал утомлять обилием текста, поэтому последнее. Тестировщик должен постоянно поставлять своему начальнику актуальную информацию о своей работе. По таким отчетам, если они сделаны правильно, начальник делает вывод о состоянии проекта в целом. Не только о работе одного тестировщика или всей команды тестирования, но и о работе команды разработки и о стадии, на которой проект находится. Также такие отчеты позволяют сделать анализ для планирования будущих релизов и т.д и т.п.
Есть много примеров, когда эта работа не делалась или делалась ненадлежащим способом, от чего у начальства возникало чувство неопределенности со всеми вытекающими последствиями. Расскажу самый яркий.
Однажды тестировщика поставили на новый проект. Поскольку он его плохо знал, ему дали задание разобраться и записать наблюдения. Так как это было нечто неформальное, договорились, что писать будет в гуглдоке. Человек начал выполнять задание, через неделю это задание было проверено, тестировщика похлопали по плечу и он продолжил работу. Шли месяцы, у начальства появилось беспокойство, почему в багтрекере нет тикетов и ничего на проекте не делается. Начали разбираться, оказалось, что человек продолжает писать в том самом гуглдоке. Никто же не сказал “Горшочек, не вари” и не остановил тестировщика, а он исправно продолжал разбираться и записывать наблюдения, при этом никак не давая о себе знать. Баги есть, и он их нашел, но никому не сказал, а лишь записал в файлик, о котором спустя неделю уже все забыли.
По факту, ожидание было, что человек продолжит работу уже формально, т.е. в багтрекере, давая своими тикетами работу разработчикам, но этого не произошло. Создалось впечатление, что человек ничего не делал, хоть он и работал. Понятно, что проблема была не только со стороны тестировщика, но если бы он делал регулярный отчет о своей деятельности, то недопонимания удалось бы избежать.
Нередко недостаток информации создает ощущение о плохом тестировании продукта, что не была протестирована та или иная часть функционала. Чтобы такого не возникало, нужно составлять подробные отчеты, это особенно важно на крупных проектах.
Заключение
Надо понимать, что QA — это, по сути, адвокат пользователя. В любой непонятной ситуации, связанной с работой приложения, тестировщик должен ставить себя на его место. Если путем этой нехитрой манипуляции сознанием выяснится, что приложение чем-то не устраивает, то надо заводить тикет. И это может быть кнопка не в том месте или другая мелочь с точки зрения разработчика, но часто бывает так, что для пользователя эта мелочь может превратиться в ад и точку раздражения. Как пример можно взять дикое количество всплывающих окон в приложении. Да, программа выполняет свою функцию, но пользоваться ей затруднительно, т.к. выполнение этой функции занимает много времени и сил пользователя, который вынужден жмакать кучу лишних окон с загрузками и прочим, вместо того чтобы сделать всю работу на одном экране.
А если человек ответственно и со здравым смыслом подходит к своей работе, то ему удастся избежать большинство проблем на своем пути, не только в профессии QA.