Продолжается опрос по языкам программирования. Уже собрано почти 7000 ответов. Заполняйте анкету!
×Закрыть

Консультация по организации QA процесса

В последнее время остро стала проблема нехватки компетенции QA в нашей команде (веб разработка на php, drupal). Дело в том, что когда читаешь литературу по тестированию, то сталкиваешься с планом тестирования, тест кейсами, чек листами и другими полезными вещами. Но на практике сталкиваешься с максимум проверить что функционал тикета работает как написал разработчик и проверить сайт в разных браузерах. Но никакой документации не ведется, никаких сценариев тестирования при релизах нет.

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

Автоматические тесты (phpunit, simpletest, behat) мы писать умеем, но почти не пишем.

Еще один вопрос по этой теме — это как вы продаете автоматическое тестирование? Какие аргументы вы предоставляете клиентам и как оцениваете обьем трудозатрат?

Буду очень признателен за помощь.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Автоматические тесты (phpunit, simpletest, behat) мы писать умеем, но почти не пишем.
Все зависит от специфики проекта, иногда их невыгодно писать или специфический функционал, что проще «руками», у нас продуктовая компания и мы покрыли тестами менее 5% функционала на уровне регресса. Смоуки почти на 90%.
Но никакой документации не ведется
Так начните вести.
1. Это полезно, очень граммотно структурирует знания
2. Пригодится для иных проектов
3. При приходе нового человека всегда есть с чем ознакомиться
4. Иногда глаз замыливается одно и тоже смотреть, а тут чеклист глянул и «о Боже, я фидлер не включил», оказалось что ресурс не грузился

Всё-таки хотелось бы узнать в чем именно выражается нехватка компетенции QA в вашей команде. И как вы сможете понять, что компетенция QA достаточна?

Попробовала описать, как у меня на проектах: docs.google.com/...dit?usp=sharing Может будет полезно.
Может позже дополню, а может и нет.

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

Вопрос есть, а вот конкретной проблемы нет. Документация ради документации или что-то в текущей постановке процесса не устраивает?

Но никакой документации не ведется
это зря)
никаких сценариев тестирования при релизах нет
ну накидать хотя бы чек лист с acceptance criteria дело быстрое
как внедряются процессы тестирования в «продвинутых» командах
зависит от проектов. Если это толстый и долгий проект на несколько лет — один разговор, если куча мелких, которые длятся 1-2 месяца — другой.

Давайте оговорим как бы вы поступили на проекте на пол года для команды из 4 разработчиков? Какую документацию и в какой форме вы бы вели?

Кину скайп в личку. Тут писать на пол страницы, и не факт что оно все вам нужно)

Кому не надо, пролистает. Пишите, не стесняйтесь.
Как-никак тема данного вопроса не расходится с темой топика, так что, вашему предположительному комментарию тут самое место ;)

Согласен, инфа будет полезной

Мне не сильно хочется писать огромную простыню — я же тоже на работе) В скайпе можно уточнить конкретнее что есть, чего нет, что не так и что надо и дать какой-то совет.

если есть вдохновение, то можно написать отдельную статью по организации QA-процессов и прислать в Ленту)

Ни вдохновения, ни времени, ни амбиций)) По крайней мере сейчас)

Есть много нюансов. Еще многое зависит от заказчика. Было на практике, требовал все подряд, ну это его право. Вот щас работаю в компании где вычеркнули некоторые документы с целью экономии времени и продуктивности QA.

Про авто.тесты можно щас не думать, пока не поймете как работать с QA и собственно как лучше им делать свою работу. Я лично не знаю как продают это но примерно так- «Есть возможность заменить ручной труд, даем гарантию уменьшить количество багов+апнуть скорость и процесс тестирования» это конечно не так, там это все круче преподносится, но суть такая же.

а проекти у вас які? якщо у вас 1 проект на тиждень) то ясно що тут немає смислу робити якісь ТС, а чекліста виставичть.
якщо у вас проекти довготривалі — то тут ваші QA «ніачом» ;)

а на рахунок automation :
якщо проект великий, і довготривалий, і скажемо після релізу ми його підтримаємо і релізимо кожні 2 тижні нові фічі/сторінки і тд то тоді ми робими автотести, щоб при цих частих релізах бути впевненими, що у нас від цих «фіч» нічого старого не зламалося)

речь идет о проектах от 1500-2000 часов. Тоесть для нашей команды это 3-4 месяца плюс несколько месяцев поддержки и новых фич. Как вы определяете что покрывать автотестами? Как ведете документацию по проекту?

Может Вам просто нанять хорошего консультанта, с большим опытом в использовании того, о чем он консультирует, вместо просеивания плевел в поисках зерен?

Я полностью вас поддерживаю касаемо консультанта. Посоветуйте пожалуйста кого нибудь. Или как определить хорошего консультанта от не очень?

Ну например меня, если нужно не на вчера.
Как распознать хорошее от плохого вопрос философский, как и с подбором бригады для ремонта квартиры.
По бритве Оккама,- обещающий невозможное, даже когда вы, будучи далеко от QA, заподозрите неладное, мол, согласно его словами из надутых щек якобы появится кнопка «Сделать офигенно» и покрытие кода авто-тестами превысит отметку 60%.

От так завжди — про якість продукту починають думати, коли вже рак на горі свиснув.

Процес тестування повинен починатися як мінімум на етапі розробки (а краще — ще раніше).

Попросіть якогось Lead QA щоб проконсультував вас коротко, або найміть когось, щоб налаштував процес — це буде набагато ефективніше, чим перечитувати отримані тут поради (яких по форумах та блогах тестувальників і так немало) і пробувати їх застосувати.

П.С. автоматичне тестування не у всіх випадках себе окупляє, якщо часто міняються реквайрменти і проекти короткотривалі — то резону його «продавати» — витрати перевищать профіт.

Подписаться на комментарии