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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

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

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

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

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

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

Теми: PHP, QA, web development

Ctrl + Enter

anonymous 11.03.2015 20:30

Все зависит от специфики проекта, иногда их невыгодно писать или специфический функционал, что проще «руками», у нас продуктовая компания и мы покрыли тестами менее 5% функционала на уровне регресса. Смоуки почти на 90%.

Но никакой документации не ведется

Так начните вести.
1. Это полезно, очень граммотно структурирует знания
2. Пригодится для иных проектов
3. При приходе нового человека всегда есть с чем ознакомиться
4. Иногда глаз замыливается одно и тоже смотреть, а тут чеклист глянул и «о Боже, я фидлер не включил», оказалось что ресурс не грузился

Відповісти

Підтримати

Iam Tacc 04.03.2015 19:43

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

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

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

Andriy Kulishov 04.03.2015 14:54

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

anonymous 04.03.2015 13:11

это зря)

никаких сценариев тестирования при релизах нет

ну накидать хотя бы чек лист с acceptance criteria дело быстрое

как внедряются процессы тестирования в «продвинутых» командах

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

Yuriy Gerasimov Lead Developer в ImageX 04.03.2015 13:43

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

anonymous

anonymous 04.03.2015 14:07

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

Yuriy Gerasimov

anonymous 04.03.2015 14:10

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

Andrey Shustov QA Engineer – Go interactive! 04.03.2015 14:17

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

anonymous 04.03.2015 14:42

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

Andrey Shustov

Валентина Шимкович 04.03.2015 18:09

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

anonymous 04.03.2015 18:29

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

Валентина Шимкович

Юра Резник QA Engineer 04.03.2015 12:36

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

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

NoNameNoSecondName 04.03.2015 10:37

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

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

Yuriy Gerasimov Lead Developer в ImageX 04.03.2015 10:54

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

NoNameNoSecondName

Котэ гуляющее само по себэ 04.03.2015 00:33

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

Yuriy Gerasimov Lead Developer в ImageX 04.03.2015 10:55

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

Котэ гуляющее само по себэ

Котэ гуляющее само по себэ 04.03.2015 16:43

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

Oleg Antonov 04.03.2015 00:24

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

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

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

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

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

18 коментарів

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