В моём опыте обычно на разговоре «жить без них не можем, нужны автотесты» вызываются желающие, которым это интересно и которые понимают, зачем это нужно.
Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
Это иллюстрация в свободном стиле :) Графики основаны на опыте работы ТМом, РМом и консультантом в десятках компаний, и отражают лишь моё субъективное восприятие проблемы.
Я думаю, что самый главный критерий вложений в автоматизацию — это длительность последующей поддержки и развития продукта. Если мы над ним работали 5 лет, а впереди 10, то есть смысл вносить изменения в продукт для улучшения тестируемости и придумывать идеи по совершенствованию фреймворка автотестирования. Если же через полгода мы об этом проекте не вспомним, и на других проектах наработки переиспользовать не сможем, то почти всегда ручного тестирования достаточно и автоматизация будет пустой тратой.
1) Т.е. в вашем продукте не была заложена testability, и теперь вам сложно разрабатывать тесты? Вся статья примерно об этом.
2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?
Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
Ой, это я может не очень понятно выразилась. Когда что-то меняем по требованию заказчика, это всё-таки новая разработка и новый функционал.
Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
1) Не надо делать манкиджоб и нанимать манкилюдей. Манкипроблемы потом расхлёбывает весь проект, об чём и речь.
2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
Тестирование — это задача, которая является следствием невозможности выполнить что-то хорошо и правильно с первого раза, без взгляда со стороны.
Как будут называться люди, её выполняющие — неважно.
Я видела примерно следующую схему работы, результаты которой были просто отличными:
* Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
* Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
* Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.
В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
Это ужасно… я сейчас скажу это ужасное слово, от которого сводит зубы… но своевременно выписывать задачки — это дисциплина :( А потом — привычка.
А про текущие и глобальные: глобальные у меня в красивой майнд-карте и красивой гуглотабличке, с картинками и прочим, я их открываю не чаще раза в месяц. А оперативные — в таск-трекере.
«В последний момент» — это всё-таки последний момент с учётом рисков. Ахтунга бывает многовато, но результаты не страдают.
Про ФСБ и сервера — наверное, есть такие случаи, просто я пока не сталкивалась. С одной стороны, хочется строить работу так, чтоб ничего не увозили. С другой стороны, увезти могут что угодно и когда угодно, у нас страна такая. Всё, ни один гендир теперь не имеет права на отпуск, больничный или отгул??
Да, это сложно :) В этом и состояла кропотливая работа: выписывать такие активности, заставлять другим помогать их решать, а не «дай я сделаю». Зато со временем, когда появляются результаты и время, становится легче и приятнее это делать :)
1. У меня всё так и было, можете не рассказывать, наследств не получала :) Да, конечно, сразу ничего не получается, кто спорит? Надо ставить цели и фигачить, само по себе ничего не сделается.
2. У меня партнёры и близкие друзья — семья, муж с женой и 3 ребёнка. Когда начинали бизнес, ребёнка было 2, и «проводить больше времени с семьёй» было одной из целью бизнеса.
У меня самой нет такого опыта, но по наблюдениям я не могу сказать, что дети — «помеха». Опять же, это источник радости, энергии, мотивации — всего того, что нужно для продуктивной работы :)
С деньгами засада, да :) Со временем развивать бизнес становится чуть проще, поначалу это адски тяжело, ничего не хватает, бюджеты трещат по швам. НО! Есть ресурс, которого обычно ещё меньше, чем денег: это время. Поэтому поначалу, когда на старте ничего нет, можно отказать себе и в машине, и в отпуске, и в новом вейкборде — но только не в отличном сотруднике для своей команды.
Я читала одну книгу, к сожалению, не смогла найти название — надеюсь, кто-то подскажет. Там рассказывается про 4 энергии:
* физическая (сон, спорт, еда)
* ментальная (нагрузка: развитие, языки, шахматы, и наоборот, отдых для мозгов)
* эмоциональная (радость, удовольствие, близкие люди)
* духовная (участие в чём-то большем, призвание)
читала давно, но надеюсь что не сильно ошиблась :)
Я часто вспоминаю эту книгу. Если чувствую, что мне не хватает энергии, то какой? Физической? Бегом в бассейн. Ментальной? Туда же, отдохнуть от мыслей :) Эмоциональной? Встретиться с близким другом, поговорить по душам. Духовной? Пересмотреть в очередной раз свои цели, сделать полезное для других, а не для себя, позаботиться о ком-то.
Но у каждого и баланс свой, и подпитка энергий своя, и исследовать себя надо, чтобы понять, что именно питает.
В моём опыте обычно на разговоре «жить без них не можем, нужны автотесты» вызываются желающие, которым это интересно и которые понимают, зачем это нужно.
Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
А вот за некачественные продукты в случаях, когдя я не могу на это повлиять — обидно!
2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?
Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
Как будут называться люди, её выполняющие — неважно.
Я видела примерно следующую схему работы, результаты которой были просто отличными:
* Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
* Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
* Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.
В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
Баблосы и трудовые успехи — это всегда средство реализации тех самых жизненных целей, сами по себе они целями не являются.
А помрём все, и дети от этого не спасут. Вопрос только, как мы свои дни проживём, что после себя оставим.
А про текущие и глобальные: глобальные у меня в красивой майнд-карте и красивой гуглотабличке, с картинками и прочим, я их открываю не чаще раза в месяц. А оперативные — в таск-трекере.
Про ФСБ и сервера — наверное, есть такие случаи, просто я пока не сталкивалась. С одной стороны, хочется строить работу так, чтоб ничего не увозили. С другой стороны, увезти могут что угодно и когда угодно, у нас страна такая. Всё, ни один гендир теперь не имеет права на отпуск, больничный или отгул??
2. У меня партнёры и близкие друзья — семья, муж с женой и 3 ребёнка. Когда начинали бизнес, ребёнка было 2, и «проводить больше времени с семьёй» было одной из целью бизнеса.
У меня самой нет такого опыта, но по наблюдениям я не могу сказать, что дети — «помеха». Опять же, это источник радости, энергии, мотивации — всего того, что нужно для продуктивной работы :)
Я читала одну книгу, к сожалению, не смогла найти название — надеюсь, кто-то подскажет. Там рассказывается про 4 энергии:
* физическая (сон, спорт, еда)
* ментальная (нагрузка: развитие, языки, шахматы, и наоборот, отдых для мозгов)
* эмоциональная (радость, удовольствие, близкие люди)
* духовная (участие в чём-то большем, призвание)
читала давно, но надеюсь что не сильно ошиблась :)
Я часто вспоминаю эту книгу. Если чувствую, что мне не хватает энергии, то какой? Физической? Бегом в бассейн. Ментальной? Туда же, отдохнуть от мыслей :) Эмоциональной? Встретиться с близким другом, поговорить по душам. Духовной? Пересмотреть в очередной раз свои цели, сделать полезное для других, а не для себя, позаботиться о ком-то.
Но у каждого и баланс свой, и подпитка энергий своя, и исследовать себя надо, чтобы понять, что именно питает.