Когда пришло время иметь отдел QA?
Отдел обеспечения качества (QA) - это целая куча тестировщиков, которые разоблачают ваши приложения весь день, давая зеленый свет для релизов, обращаясь с альфа / бета-программами. И многое другое.
Но без отдела контроля качества в компании-разработчике проблемы возникают на местах слишком часто, и их решение стоит дороже. Тем не менее, большинство компаний начинаются в гараже, где один сотрудник является самим собой, а затем вырастает в компанию по разработке программного обеспечения.
Когда вы говорите, что это создать такой отдел? Какое-то отношение к размеру компании, проблемам, с которыми она сталкивается?
12 ответов
Как только вы можете себе это позволить. У вас никогда не будет продукта, который был бы столь же надежным без отдела обеспечения качества, чем с одним. Программисты не делают хороших людей для обеспечения качества, и всегда лучше, чтобы второй человек (или больше) проверял, как работает приложение.
Все хорошие компании по разработке программного обеспечения и организации с хорошими ИТ-отделами, которые создают программы, имеют команду qa. Это жизненно важно для разработки программного обеспечения.
Будучи бывшим менеджером по обеспечению качества в успешной софтверной компании, я бы сказал, что расти, как только вы выпустите свою первую программу. (До, если возможно). Действительно, как только ты можешь себе это позволить. Но, как разработчик, вы должны проводить большую часть тестирования самостоятельно в течение всего цикла разработки, а не только в конце. Работа QA (в зависимости от того, какую книгу вы читаете) состоит в том, чтобы обрабатывать множество устаревших тестов, SMOKE-тестирование, регрессионное тестирование, тестирование в реальном мире, а также написание автоматизированных процедур тестирования, процессов и планов и т. Д.
Специальное тестирование - только малая часть того, что должен делать QA. Есть два основных направления для обеспечения качества. 1) выполняет ли программное обеспечение то, что оно должно делать, и отвечает требованиям таким образом, чтобы клиент мог его использовать, и 2) не выполняет ли программное обеспечение то, что оно НЕ должно делать.
Плановое, процедурное и специальное тестирование являются основой QA. Я обнаружил, что если вы проводите только один тип тестирования или другой, у вас не будет успешного цикла QA.
Когда я работал самостоятельно, я выпустил программное обеспечение без QA, но могу вам сказать, что оно ВСЕГДА более подвержено ошибкам, независимо от того, сколько я его тестирую. Второй + набор глаз - лучшая вещь для программного обеспечения.
Просто убедитесь, что вы строите свою команду из компьютерных фанатов ADD. Таким образом, вы получите лучшие результаты.:) Люди, которые PROUD, когда они могут заставить кого-то программное обеспечение идти круто... хех.. (Шучу.. Я знаю много тестеров QA, которые не имеют ADD)...
Отдел обеспечения качества (QA) - это целая куча тестеров, разоблачающих ваши приложения весь день
Я обеспокоен тем, что вы рассматриваете QA как "группу тестировщиков, разоблачающих ваше приложение", так как QA является препятствием для конечного продукта. Это заставляет меня думать, что у вас был плохой опыт с QA в прошлом. Вместо этого попробуйте взглянуть на ценность, которую QA приносит вашей компании. Вы хотите, чтобы конечный пользователь мог положиться на ваш продукт с самого начала. Если конечный пользователь обнаруживает проблемы или дефекты и расстраивается из-за вашего приложения или веб-сайта, он все меньше доверяет вашему приложению. QA должен уменьшить риск потери доверия пользователей к вашему приложению. Если QA не делает этого, тогда они не приносят значение, которое необходимо для любого приложения. В этот момент вам нужен новый QA. Не только кнопки-толкатели. QA, который знает приложение так же хорошо, как и разработчик. QA, который сотрудничает с разработчиком и владельцем продукта, чтобы убедиться, что все находятся на одной странице в отношении требований и ожиданий в конечном продукте.
Последнее замечание: разработчики не QA. Разработчики должны надевать свои QA шляпы только тогда, когда это абсолютно необходимо. Это сложно в небольшой компании из 1 или 2 разработчиков. Поэтому я согласен с другими, когда они говорят, получить QA, как только вы можете. В моем месте расположения крупной компании по разработке программного обеспечения разработчики надевают шапку QA только тогда, когда у нас жесткие сроки, которые необходимо соблюдать, а время QA стоит дорого. Даже когда они надевают свои QA-шапки, процесс тестирования проверяется одним из ведущих QA в этой группе разработчиков, чтобы убедиться, что разработчик полностью и эффективно тестирует приложение. Только до тех пор, пока лидерство по обеспечению качества не будет удовлетворено уровнем тестирования, которое было выполнено в части, которую тестировал разработчик, будет подписывать руководство по обеспечению качества в этой части.
Чтобы играть адвоката дьявола: "Отдел QA" - красная сельдь, и во многих случаях отговорка.
Давайте сначала разберемся с красной сельдью. "Отдел" - это утверждение организационной структуры, кто отчитывается перед кем; это вторично. "QA" - это общий термин, не имеющий особого значения. (Не верьте мне? Вот тест - хотите ли вы, чтобы " не гарантировать качество"? Конечно, нет. Все хотят.)
Так чего же вы действительно хотите здесь? Вы хотите узнать о режимах сбоев в вашем программном обеспечении раньше, чем ваши пользователи.
Если у вашего программного обеспечения есть "проблемы" в этой области, то это означает, что работа по определению режимов сбоев еще не завершена, и вы можете нанять кого-нибудь, кто сделает это.
Я считаю, что описание работы разработчика должно включать, по крайней мере, некоторые из них. Если я найму тестеров, я бы предпочел, чтобы им приходилось усердно работать, чтобы найти способы отказа. Если приложение рухнет в течение нескольких секунд после того, как тестер приложит к нему руки, разработчики услышат об этом прямо. Фраза "вопиющий дефект" приходит на ум.
На выезд. По правде говоря, вы не можете поставить качество в продукт после факта. Но "мы должны нанять несколько тестеров" - это крик многих разработчиков, поймавших с поличным, превращая код намного ниже приемлемого уровня качества. (Я знаю - я был одним из них.)
Так что, если вы нанимаете кого-то с опытом тестирования, то IMHO будет правильным, чтобы заставить его работать вместе с разработчиками. Отчетность тому же менеджеру. С той же миссией: сделать это правильно в первую очередь.
Я предполагаю, что вы органично развиваете отдел QA: даже если вы программист соло, вы должны выполнять часть работы, которую выполняет специалист по QA.
Если, например, один человек тратит 10% своего времени на выполнение мероприятий по обеспечению качества, то, как только вы доберетесь до десяти человек, у вас может быть один человек, посвященный обеспечению качества.
Мы небольшой новый стартап с одним разработчиком. Всякий раз, когда мы говорим о добавлении дополнительных ресурсов, мой первый ответ - нанять меня как QA!
Это зависит. Если вы небольшая компания с небольшой эффективной командой и низкий уровень ошибок, вероятно, это не самая большая проблема, которую вам нужно решить.
Если рынок заставляет вас производить быстрее, число разработчиков растет, и уровень ошибок начинает ухудшать ваши отношения с клиентами, тогда вы можете рассмотреть возможность исправления процесса, сделав его более формализованным.
Хитрость для выживания в небольшой компании заключается в том, чтобы внедрить процесс только тогда, когда его ценность окупается. Если вы нанимаете людей для улучшения качества, он должен быть достаточно большим, чтобы окупать себя, что означает, что до этого качество должно быть довольно плохим (и наносит ущерб бизнесу).
Часто лучший процесс поддержки гораздо важнее, потому что даже лучшая группа QA все еще время от времени позволяет ошибкам появляться там. Клиенты будут более впечатлены вами, если вы хорошо справитесь с исправлениями / исправлениями (они не заметят значительного уменьшения количества ошибок, если только предыдущие версии не были действительно очень плохими).
Павел.
Как только кодовая база становится настолько большой, что один человек не может знать все детали.
Причиной этого является то, что 90% регрессий создаются потому, что программисты не знают всей картины и возможного побочного эффекта своего кода на остальную часть системы. В таких случаях вы даже не знаете, что никогда не должны указывать -1 как параметр возраста или что-то в этом роде. В большинстве случаев интерфейсы должны быть четкими и иметь проверку на наличие ошибок, но в больших кодовых базах он проскальзывает, даже когда вы спешите, чтобы уложиться в крайний срок, или если долгие часы работы снижают концентрацию.
Итак, хотя вы должны выполнять базовое тестирование, даже когда вы выступаете в одиночку, такие вещи, как юнит-тесты и аналогичные средства автоматического тестирования, должны использоваться, как только код станет достаточно большим, чтобы вы (или кто-либо еще, кто мог бы работать с вами) не может понять всю систему в уме.
Ну что ж - вам нужен кто-то, кроме программиста, который написал тестирование кода. Это не значит, что вам нужен отдел контроля качества. Во многих магазинах бизнес-аналитики также проводят тестирование, которое намного экономичнее, потому что тестирование можно проводить только на более поздних этапах сборки, а не во время анализа требований и проектирования. В очень маленьком магазине вы, вероятно, даже не используете слово "бизнес-аналитик", но вы понимаете, что я имею в виду - люди, занимающиеся разработкой или дизайном, которые не пишут код. Даже в очень крупной компании эта модель имеет свои преимущества; испытательные группы могут вести собственную жизнь.
Он должен работать без QA, но с
- CI Software
- Руководство по программированию (и анализу, и дизайну, и...) и некоторые инструменты, чтобы "заставить" программиста идти с ними
- некоторые отзывы сейчас и потом
- этапы тестирования, например team-test-environment, интеграция (все приложения вместе) и консолидация (аналогично интеграции, но с копиями производственных данных)
- если нужна группа планирования выпуска
- и.. ну.. хорошие мастера-программисты
Если у вас есть компания из одного-двух человек, которая нанимает тестера, это может быть излишним Попробуйте потратить некоторое время на тестирование самостоятельно. Или попросите друга-разработчика (которого нет в команде) какое-то время поиграть с приложением. Или спросите друга (не разработчика) - почти как тестирование приемки пользователем.
Наймите, когда вы начнете продавать программное обеспечение, когда у вас будет 3 или более разработчиков, когда у вас будет много мыслей для тестирования (и я имею в виду на самом деле тестирование не "оно начинается на моей машине", а "я имею пытался сокрушить это в течение нескольких часов, но это все еще работает. Может быть, я должен стать действительно творческим?').
В настоящее время я управляю компанией-разработчиком программного обеспечения для гаражных предприятий, сейчас я заменяю отдел вопросов и ответов семьей и друзьями, я звоню им или заставляю их прийти на несколько сортов пива и протестировать мой продукт для меня.
До сих пор это "тестирование в прихожей" работало довольно хорошо, но опять-таки мой продукт не нацелен на технически квалифицированных пользователей, если бы мне было труднее найти тестеров.
Если у вас нет легкодоступных родственников и друзей, я бы порекомендовал добавить объявление в ваши местные объявления или список друзей, должно быть трудно найти нескольких студентов или кого-то, кто будет проверять минимальную заработную плату.
Что касается того, когда нанимать штатного специалиста по обеспечению качества, я бы сказал, что это зависит исключительно от финансового состояния компании.