Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

как ввести тестирование в массы

management
Теги: #<Tag:0x00007f7b6a31e8f8>

(lexand) #1

надо както втянуть команду в процесс тестирования

тоесть они пишут тесты, но не считают их чем то нужным, соотвественно и подход местами такой

хотя после прочтения некоторых постов на форуме, все таки придется часть тестов убрать или разрешить не писать как примитивные
но тут друга проблема, как определить примитивность теста не вылезит ли это тем что команда перестанет писать тесты и на кучу остального кода
эээх тяжело быть тим лидом в первый раз....

вроде и рассказываю каждый раз почему надо, зачем, как, что это даст
но все равно както не то.... не оказывает оно того эффекта что я ожидаю, хотя лично сам к тестированию шел, месяцев наверно 6, пока окончательно не припекло

особенно одно доставляет, некоторые считают что задача тестировщиков ломать чужой код, а они програмисты... у них такой склад мышления что ломать они не могут, а могут только создавать....

 


(KaNoN) #2

Можно настроить народ на более конструкивный лад: преподнести тесты, как подтверждение работоспособности того, что они написали. Причем, подьвердить не только то, что код работает при простых заготовленных данных, но еще и обрабатывает разные сложные ситуации.


(Mykhailo Poliarush) #3

тут нужен для начала контекст определить

правильно ли я понимаю:

- Вы лид в команде разработчиков?
- у вас есть отдельная команда тестировщиков?
- кто пишет автотесты и для чего?
- занимаются ли разработкой автотестов тестировщики?
- Вы анализировали почему команда, считает, что не нужно писать автотесты?

Надо бы сначала выяснить почему люди не хотят, а потом уже искать решение.
Потому, что предлагать решение без идентификации самой проблемы не даст никакого эффекта и результата.

Скорее всего команда просто не понимает зачем это им нужно. И просто выполняет поручение сверху. 
А надо чтобы они прониклись идей. 

Должен быть какой-то value для всей команды, на основании которого можно воздействовать на команду.
Например, % успешных сборок, % открытых дефектов, % переоткрывающихся дефектов и т.д.
Т.е. на основании этого, можно на пальцах показать ЗАЧЕМ, а также прослеживать изменяется что-то от внедрения автоматизации или нет.

Но все же могу сказать один вариант. Программисты народ ленивый.
Вы как отвественный человек отвечаете за качество.
Потому сделайте ход конем. Предложите им альтернитиву или отказываемся писать тесты и выполняем тесты руками или будем писать тесты.

Другая возможная проблема. Нет хорошей видимости и использования автотестов.
Т.е. они пишутся, но их никто не использует при разработке. А надо чтобы использовали.
Подлюкчите CI, установите процесс запуска тестов на регулярной основе и нотификацию на разработчиков.
И прослеживайте, что рейт успешных тестов не должен снижаться.

В любом случае надо узнать в чем проблема. Это просто, надо идти в команду и говорить, с каждым в отдельности и с командой в целом.


(lexand) #4

- Вы лид в команде разработчиков?

скажем ИО тим лида, дело в том что мы географически разделены и компания ищет тимлида локального с командой

- у вас есть отдельная команда тестировщиков?

нет

- кто пишет автотесты и для чего?

програмисты и пишут, я контролирую написание
для чего...
проект сильно большой, ну относительно большой
но сильно длительный, очень длительный, куча этапов развития после релиза, не исключена замена кадров за такой срок
не исключены и более серьезные переделки в будущем
и вот для всего этого нужно построить тестовую базу котрая не даст развалится всему на части
как говорит техдир "исключить эффект одеяла, когда одни тянут на себя и ломают что то у других"

- занимаются ли разработкой автотестов тестировщики?

соответственно - нет

- Вы анализировали почему команда, считает, что не нужно писать автотесты?

вот именно это я сейчас и пытаюсь сделать с вашей помощью

 

да команда не понимает зачем это нужно - это факт
первая причина как я уже сказал - задача тестировщиков ломать чужой код, а они програмисты... у них такой склад мышления что ломать они не могут, а могут только создавать....

CI - настроен но де конца. Тут еще вот что...
может это я не совсем правильно понимаю это, но
я считаю что часть тестов сам разработчик должен выполнять до комита
остальную тяжелую артилерию выполняет CI сервер - и он следит больше не столько за тем что наколбасил разработчик, сколько за тем на сколько "удачно" новый код интегрировался в мастер ветку.

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

Потому сделайте ход конем. Предложите им альтернитиву или отказываемся писать тесты и выполняем тесты руками или будем писать тесты.

был у нас недавно очень серьезный разговор
к слову, серверная часть покрыта тестами почти вся (но даже для нее есть вот такие вот проблемы)
вот почти слово-в-слово

-лучше посадить девочку тыкать на кнопки, чем  писать никому не нужные тесты
- и ты уверене что она не сделает гдето ошибку, это же человеческий фактор, время, деньги и куча все остального
- у нее будет usecase по которому она будет делать шаг за шагом то что нужно
- хорошо давай так. Давай ты проверишь сейчас все UI которое уже есть и которое не покрыто тестами, засечем сколько времени это займет, приблизительно прикинием сколько раз ты ошибся вводя данные в одну и туже форму, ведь через какоето время ты устанешь, и начнешь сбоить. А потом посчитаем сколько денег это все стояло фирме. Сколько времени ты мог потратить для пользы как програмист ну и т.д. и т.п.
- ...
 

Подлюкчите CI, установите процесс запуска тестов на регулярной основе и нотификацию на разработчиков.
И прослеживайте, что рейт успешных тестов не должен снижаться.

вот пока уведомления и не настроены
но оказалось и это проблема
есть возможность по тимсити отсылать либо имейли либо джаббер сообщения
на что я с техдиром выслушал тираду, что "и так эти сообщения никто не читает (приходят от багтрекера и системы контроля версий)
а если еще и машина будет присалать уведомления о том что должны делать програмисты то это вообще бред, вы пытаетесь использовать то что (как же он так сказал..) давным давно все отбросили как нецелесообразное" (как то так, крутится в голове, вспомнить не могу).

Скорее всего команда просто не понимает зачем это им нужно. И просто выполняет поручение сверху. 
А надо чтобы они прониклись идей. 

Должен быть какой-то value для всей команды, на основании которого можно воздействовать на команду.
Например, % успешных сборок, % открытых дефектов, % переоткрывающихся дефектов и т.д.
Т.е. на основании этого, можно на пальцах показать ЗАЧЕМ, а также прослеживать изменяется что-то от внедрения автоматизации или нет.

судя по всему именно так и происходит
но даже сейчас бывают моменты, когда они что то меняют, а тесты помогают найти все места которые оказались затронуты этим изменением
я уже думал, сделать ход конем - выкинуть на время все тесты и пусть каждый письменно гарантирует что его код полностью рабочий и не разрушает работоспосбность остальных частей
но это проблема все равно, задачи принимать мне, мне проще посмотреть правильно ли они написали тесты, и запустить эти тесты на проверку (пусть даже сейчас вручную), чем лазить по коду, и руками делать проверки

поедем вот опять, буду разговаривать еще
тестировиков пока взять мы не видим смысла, но проблему решить надо


(Олег1986) #5

вот пока уведомления и не настроены
но оказалось и это проблема
есть возможность по тимсити отсылать либо имейли либо джаббер сообщения
на что я с техдиром выслушал тираду, что "и так эти сообщения никто не читает (приходят от багтрекера и системы контроля версий)
а если еще и машина будет присалать уведомления о том что должны делать програмисты то это вообще бред, вы пытаетесь использовать то что (как же он так сказал..) давным давно все отбросили как нецелесообразное" (как то так, крутится в голове, вспомнить не могу) 

 

Можно сделать настройку таким образом, что пока все автотесты не прошли положительно, то раскладка на продакшен не проходит. Как сделано у нас, после каждого комита запускаются юнит тесты, если юниттест поломался, то разрабу,кто делал последний комит приходит уведомление о том, что сломался тест, пока он его не починит и все юнит тесты не пройдут, он не сможет добавть свой код в раскладку. Далее после того как заявки на раскладку сформированы, на тестовой базе запускаются все ui тесты, ставятся ошибки, пока ошибки не исправятся и все ui тесты по новой не пройдут положительно, раскладки на продакшенне происходит


(apetrovskiy) #6

А какие тесты у вас уже есть? Какие тесты они запускают руками - юнит-тесты, интеграционные или что-то кликают?

У нас как раз идёт реорганизация проектов (стандартизация разработки, да и смена хозяина), на многих проектах пирамида Кона перекошена: на эйджальных от рождения проектах преобладают юнит-тесты и интергационнаые тесты, на монстроидальных ("коровах" в терминах маркетологии) - акцептанс сьюты.

Вам, как органайзеру тестирования, надо продумать, что не покрыто по пирамиде Кона и квадрантам Марика. Разработчикам, помимо обещаний аццких мук в случае отстутсвия тестов, предложите разнообразные развлечения. К примеру, у нас вошли в моду тест-игры: команды меняются проектами на час, вносят изменение в продакшн-код, собирают тесты другой команды и смотрят, покраснели ли они. Или по коду тестов силятся понять, что делает тест, да и кусок продукта (не поняли - виноваты авторы тестов). Или соревнование (уже есть в треде) на предмет, у кого тесты зеленее на CI.


(lexand) #7

у нас немного по другому сейчас и будет потом
но в целом идем почти к такой же идее, поломал последний комит будь бобр исправляй


(lexand) #8

у нас почти 100% (около 800 тестов, проходят за минуты 3-4, но это пока и тесты не все, тоесть еще все реализовано, и 3 минуты на них много, по тихоньку оптимизируем скорость) покрытие блочными и интеграционными тестами всей серверной части (Java, PHP) - благо тут както оно лего пошло может потому что народ видел что там я уже кучу всего натворил и они делали по аналогии

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

и потихоньку начал вводить приемочные/функциональные тесты - и вот на них все стопорнулось, но как оказалось, из-за возникшего на этом фоне конфликта, и блочные и интерграционные попали под раздачу тоже. Как бы это сказать... если приказным тоном я и тех дир скажем что блин пишем иначе растрел - писать будут, но я так не хочу, ибо качество таких тестов будет сомнительным. Я и так долго бился пока рассказывал как правильно данные подбирать, моками пользоваться и прочее.... а если еще похобно будут рапботать типа "нате и отстанте". Может я не так воспринимаю что то? и так и должно быть - в тупо приказной форме?

просто сколько везде все читаешь, слушаешь - везде говорят - идею надо продать? надо что бы ее у вас купили? тупыми приказами ничего толком не добъетесь.

чисто блочных именно JavaScript - очень мало, там просто у нас нечего и тестировать толком (поэтому думаю даже не стоит заморачиваться с введением их в автоматический процесс (JsTestDriver)).  А все остальное (ExtJS) - только через Selenium. Хотя я думаю что при определенном подходе можно было и JsTestDriver использовать, но там с асинхронными кусками такие извращения получаются что ну его )).

по Марику
у нас квадранты Q1 и Q2 (почти только начали ), Q3 - как исследовательские тесты я пользую, остальные не знаю (сделал пометочку рассказать народу как встретимся ))
Q4 - если не брать в рассмотрение тестовые фремворки, то есть немного, я их писал для выбора правильных компонентов, но сейчас они роли не играют.вообще
в будущем скорее всего появятся, где надо будет жестко контролировать производительность некоторых компонентов

аццкие муки 
в крайнем случае

а вот идея с играми толковая, я думал как устроить такой канзас сити шафл )).... только все не мог придумать с какой стороны подойти

спасибо


(apetrovskiy) #9

Всегда пожалуйста, ещё, наверное, можно попробовать дать написание автотестов на код коллег - это всегда азартно ("нашёл у тебя, братан, забавную багу...").