Мой личный опыт показывает, что там, где TDD активно практикуют - ошибок на проде гораздо меньше. Но, безусловно, случается всякое и TDD не гарант хорошего продукта
Дело в том, что уже многие годы в каждой команде, которой я руководил и на которую я оказывал влияние, применялась методология TDD. Ошибки, конечно, всё ещё случаются, но проникновение в продакшн проблем, способных «повалить» проект, снизилось практически до нуля, даже несмотря на то, что частота обновления ПО и количество задач, которые нужно решить в процессе обновления, экспоненциально выросли с тех пор, когда случилось то, о чём я рассказал в начале
TDD - это просто подход к организации написания своей части проекта. Этот подход далеко не всегда соблюдается и в крупных компаниях. Но да, очень большое количество ошибок можно избежать используя такой подход. Однако стоит понимать, что сколько свой продукт не тестируй, всегда найдется пользователь, который нажмет куда-то не туда
К TDD можно относиться как к Agile. Методология хорошая, часто помогает, но не все ее используют или следуют всем канонам, что не мешает выпускать хороший продукт в срок
Но тестирования всей платформы компетентным человеком было бы достаточно, чтобы обнаружить то, что нашел я и обнаружить то, что мне найти не удалось
Я согласен с тем, что имеется и обратная сторона медали. И в конечном счете решение принимать основателю или команде. Я показал на примере, что бывает, если перестать думать о тестировании проекта
К сожалению, изначально сам хабр против рекламы и видит в четком указании проекта в данной статье рекламу проекта. Вы всегда можете обратиться к правилам сайта по ссылке https://habr.com/ru/docs/help/rules/
Если вам хочется самостоятельно потыкать что-либо - вы всегда можете самостоятельно найти проект. Если говорить про этот проект - то ссылку на платформу можно найти в поисковике, вбив, например, "Маркетплейс игровых ценностей"
Возможно вы правы, не уточнял про тех лида у разработчиков. Думаю, что раз была команда из 7 человек - кто-то руководил разработкой, не вижу иной возможности организации разработки командой из 7 человек
Единственное, приведу точную цитату разработчика, с которым я общался. Решать кто виноват я не хочу, но, видимо, все понимали на что идут выкатывая такой продукт. Мне кажется, что тестирование продукта могло бы указать на то, что решение было принято слишком рано. Но от такого решения пострадать могут пользователи платформы
Примерно во второй половине января выкатили ОЧЕНЬ сырой MVP (при этом мы узнали об этом в самый последний момент, а нам надо было минимум ещё три недели, чтобы устранить баги). Таких ресурсов было недостаточно, не говоря о том, что у нас не было ни тестировщиков, ни безопасников.
У меня нет цели продать себя кому-либо в данный момент, так как я трудоустроен и доволен своим местом работы. Статью я написал из-за того, что ранее с подобным подходом к разработке продового (рыночного) продукта не сталкивался
Мне кажется, что данный стартап вполне может превратиться в нечто крупное, если руководство стартапа будет принимать корректные действия. Связываясь с основателем, я хотел помочь им поделившись информацией о платформе. К сожалению, основатель не захотел со мной сотрудничать со словами: "нам очень интересно, быть может мы с вами свяжемся через 3-4 месяца"
Искренне надеюсь, что стартап сделает выводы и исправит недостатки платформы. Дабы не компрометировать и не рекламировать платформу - я убрал всё, что могло указывать на нее
Спасибо за ваш комментарий! Согласен со многими вашими мыслями!
а тем более делать лишь его ответственным за тестирование
Хочу обратить внимание, что я не предлагаю делать только одного человека ответсвенным за тестирование, это в корне неправильно. В статье я призываю обращать больше внимания на тестирование своего продукта. Выделение компетентного человека, который будет проводить тестирование системы по юзер-кейсам, я считаю необходимо.
Чем раньше тестировщик начнет смотреть систему - тем более корректно она будет работать. Все баги, на которые мне удалось наткнуть, в компаниях, в которых я работал и работаю сейчас, обычно находят тестировщики.
Разработчики, мне кажется, должны тестировать свой код и интеграцию своего кода с другими частями проекта. Но, в случае если проект большой, разработчик будет не в силах протестировать весь проект и тем более с большей вероятностью не будет вкурсе всех юзер-кейсов проекта
нужно на проекте настоитить режим работы такой, чтобы разработчики могли менять роли.
Это скорее уже зависит от конкретного проекта. Я не припомню, чтобы встречал, что разработчик занимается тестированием всей системы. Своего кода - да, всей системы - нет. И раз вы в пример парадокса приводите меня - стоит отметить, что я имею опыт работы тестировщика, а в данный момент развиваюсь как java программист.
Благодарю за отзыв. Прислушался и постарался отредактировать статью в тех рамках, чтобы она более корректно несла свой посыл Теперь статья не содержит разработку вредоностного ПО и рекламу моих услуг (коих я и не предоставляю)
Согласен с
Поэтому оно должно проводиться в контролируемых условиях и иметь одной из задач минимизацию возможных негативных последствий.
При проведении своих тестов платформы я старался минимизировать возможные негативные последствия (добивался багов только на своих аккаунтах, не трогая чужие, предупредил администрацию сайта о том флуде, который был оставлен мной, извинился перед администраций сайта за доставленные неудобства). При проведении тестов я не выходил за рамки обычного пользователя и лишь оптимизировал свою работу с помощью кода. К сожалению, к какому-либо тестовому окружению мне не предоставили доступ
Описанная ситуацию скорее про порчу имущества. Я же лишь показал неудобства системы. Я целенаправленно не проводил тестирование безопасности, дабы не огрести в дальнейшем) Также я предложил помощь в поиске и исправлении недостатков Буду надеяться, что адвокат мне не понадобится)
Согласен с тем, что безопасность через неясность не работает. Практически все url, которые я использовал, можно было найти в консоли разработчика. Как мы знаем, существуют различные методы тестирования. В данном посте я не рассматривал тестирование безопасности или нагрузочное тестирование. Я провел лишь функциональное тестирование. Моей основной задачей было показать, что бывает, когда продукт разрабатывается без тестирования
И, как верно упомянул Rive (https://habr.com/ru/post/564816/#comment_23193070), открытая документация экономит время подбора урлов и параметров. Однако в данном случае она также позволяет найти админ запросы, которые уже можно будет тестировать на безопасность
Мне кажется, в статье очень скудно рассмотрели фреймворки. Точно тоже самое можно сделать просто вбив эту тему в инет. Много чего упустили.
По той же java: spring boot - это, конечно, хорошо, но это скорее про в целом разработку back-end (и микросервисы, и монолит). У spring-а есть куда более интересные фреймворки для микросервисов: Spring Cloud, Spring Integration. Хорошая статья - https://habr.com/ru/company/jugru/blog/341026/ И в целом по спрингу советую видео с конференций Евгения Борисова (можно на ютубе найти)
Думаю, стоит в статье рассказать коротко о том, почему стоит использовать тот или иной фреймворк и что он дает. Так, например, я не знаком с Restlet, а ваше описание мне не дало ровно никакой информации об этом фреймворке и если я захочу узнать о нем больше - мне придется лезть в гугл и искать какую-либо иную статью
Как итог, скорее всего (мое мнение) вашу статью минусуют потому, что она не дает хоть какой-то полезной информации о фреймворках. Куда полезнее было бы просто вывести по 1 графику на язык о популярности каждого из фреймворков языка - информации людям, не знакомым с фреймворками, дало бы столько же, но на это было бы хотя бы интересно посмотреть тем, кто в теме всех или большинста приведенных технологий
Мне кажется, что не должно быть разницы кто автор статьей. Научная статья, как продукт, ничего общего обычно не имеет с личными предпочтениями. Имеет смысл контролировать то, что печатается в статье: не допускать статьи с пропагандой чего-то незаконного, с фейк/не фейк статьями, плагиатом и прочее. Но если научные статьи правдивые, качественно написаны и нравятся людям (из последнего следует то, какое количество людей данную статью прочтут), то какая разница кто он: наркобарон, заключенный или фашиствующий некропедозоофил?
На счет последнего: с проблемой доступа к не-фейковым научным статьям - согласен
Не согласен с тем, что TDD едва ли помогло бы
Мой личный опыт показывает, что там, где TDD активно практикуют - ошибок на проде гораздо меньше. Но, безусловно, случается всякое и TDD не гарант хорошего продукта
Советую к прочтению следующую хорошую статью: https://habr.com/ru/company/ruvds/blog/450316/
Просто приведу из нее цитату
Спасибо за ваш комментарий!
TDD - это просто подход к организации написания своей части проекта. Этот подход далеко не всегда соблюдается и в крупных компаниях. Но да, очень большое количество ошибок можно избежать используя такой подход. Однако стоит понимать, что сколько свой продукт не тестируй, всегда найдется пользователь, который нажмет куда-то не туда
К TDD можно относиться как к Agile. Методология хорошая, часто помогает, но не все ее используют или следуют всем канонам, что не мешает выпускать хороший продукт в срок
Но тестирования всей платформы компетентным человеком было бы достаточно, чтобы обнаружить то, что нашел я и обнаружить то, что мне найти не удалось
Привет! Спасибо за ваш комментарий!
Я согласен с тем, что имеется и обратная сторона медали. И в конечном счете решение принимать основателю или команде. Я показал на примере, что бывает, если перестать думать о тестировании проекта
К сожалению, изначально сам хабр против рекламы и видит в четком указании проекта в данной статье рекламу проекта. Вы всегда можете обратиться к правилам сайта по ссылке
https://habr.com/ru/docs/help/rules/
Если вам хочется самостоятельно потыкать что-либо - вы всегда можете самостоятельно найти проект. Если говорить про этот проект - то ссылку на платформу можно найти в поисковике, вбив, например, "Маркетплейс игровых ценностей"
Спасибо за ваш комментарий!
Возможно вы правы, не уточнял про тех лида у разработчиков. Думаю, что раз была команда из 7 человек - кто-то руководил разработкой, не вижу иной возможности организации разработки командой из 7 человек
Единственное, приведу точную цитату разработчика, с которым я общался. Решать кто виноват я не хочу, но, видимо, все понимали на что идут выкатывая такой продукт. Мне кажется, что тестирование продукта могло бы указать на то, что решение было принято слишком рано. Но от такого решения пострадать могут пользователи платформы
Спасибо за ваш комментарий!
У меня нет цели продать себя кому-либо в данный момент, так как я трудоустроен и доволен своим местом работы. Статью я написал из-за того, что ранее с подобным подходом к разработке продового (рыночного) продукта не сталкивался
Мне кажется, что данный стартап вполне может превратиться в нечто крупное, если руководство стартапа будет принимать корректные действия. Связываясь с основателем, я хотел помочь им поделившись информацией о платформе. К сожалению, основатель не захотел со мной сотрудничать со словами: "нам очень интересно, быть может мы с вами свяжемся через 3-4 месяца"
Искренне надеюсь, что стартап сделает выводы и исправит недостатки платформы. Дабы не компрометировать и не рекламировать платформу - я убрал всё, что могло указывать на нее
Спасибо за ваш комментарий! Согласен со многими вашими мыслями!
Хочу обратить внимание, что я не предлагаю делать только одного человека ответсвенным за тестирование, это в корне неправильно. В статье я призываю обращать больше внимания на тестирование своего продукта. Выделение компетентного человека, который будет проводить тестирование системы по юзер-кейсам, я считаю необходимо.
Чем раньше тестировщик начнет смотреть систему - тем более корректно она будет работать. Все баги, на которые мне удалось наткнуть, в компаниях, в которых я работал и работаю сейчас, обычно находят тестировщики.
Разработчики, мне кажется, должны тестировать свой код и интеграцию своего кода с другими частями проекта. Но, в случае если проект большой, разработчик будет не в силах протестировать весь проект и тем более с большей вероятностью не будет вкурсе всех юзер-кейсов проекта
Это скорее уже зависит от конкретного проекта. Я не припомню, чтобы встречал, что разработчик занимается тестированием всей системы. Своего кода - да, всей системы - нет. И раз вы в пример парадокса приводите меня - стоит отметить, что я имею опыт работы тестировщика, а в данный момент развиваюсь как java программист.
Благодарю за отзыв. Прислушался и постарался отредактировать статью в тех рамках, чтобы она более корректно несла свой посыл
Теперь статья не содержит разработку вредоностного ПО и рекламу моих услуг (коих я и не предоставляю)
Согласен с
Поэтому оно должно проводиться в контролируемых условиях и иметь одной из задач минимизацию возможных негативных последствий.При проведении своих тестов платформы я старался минимизировать возможные негативные последствия (добивался багов только на своих аккаунтах, не трогая чужие, предупредил администрацию сайта о том флуде, который был оставлен мной, извинился перед администраций сайта за доставленные неудобства). При проведении тестов я не выходил за рамки обычного пользователя и лишь оптимизировал свою работу с помощью кода.
К сожалению, к какому-либо тестовому окружению мне не предоставили доступ
Описанная ситуацию скорее про порчу имущества. Я же лишь показал неудобства системы. Я целенаправленно не проводил тестирование безопасности, дабы не огрести в дальнейшем)
Также я предложил помощь в поиске и исправлении недостатков
Буду надеяться, что адвокат мне не понадобится)
Привет! Спасибо за твой комментарий!
Согласен с тем, что безопасность через неясность не работает. Практически все url, которые я использовал, можно было найти в консоли разработчика.
Как мы знаем, существуют различные методы тестирования. В данном посте я не рассматривал тестирование безопасности или нагрузочное тестирование. Я провел лишь функциональное тестирование. Моей основной задачей было показать, что бывает, когда продукт разрабатывается без тестирования
И, как верно упомянул Rive (https://habr.com/ru/post/564816/#comment_23193070), открытая документация экономит время подбора урлов и параметров. Однако в данном случае она также позволяет найти админ запросы, которые уже можно будет тестировать на безопасность
Мне кажется, в статье очень скудно рассмотрели фреймворки. Точно тоже самое можно сделать просто вбив эту тему в инет.
Много чего упустили.
По той же java: spring boot - это, конечно, хорошо, но это скорее про в целом разработку back-end (и микросервисы, и монолит). У spring-а есть куда более интересные фреймворки для микросервисов: Spring Cloud, Spring Integration. Хорошая статья - https://habr.com/ru/company/jugru/blog/341026/ И в целом по спрингу советую видео с конференций Евгения Борисова (можно на ютубе найти)
Думаю, стоит в статье рассказать коротко о том, почему стоит использовать тот или иной фреймворк и что он дает. Так, например, я не знаком с Restlet, а ваше описание мне не дало ровно никакой информации об этом фреймворке и если я захочу узнать о нем больше - мне придется лезть в гугл и искать какую-либо иную статью
Как итог, скорее всего (мое мнение) вашу статью минусуют потому, что она не дает хоть какой-то полезной информации о фреймворках. Куда полезнее было бы просто вывести по 1 графику на язык о популярности каждого из фреймворков языка - информации людям, не знакомым с фреймворками, дало бы столько же, но на это было бы хотя бы интересно посмотреть тем, кто в теме всех или большинста приведенных технологий
Мне кажется, что не должно быть разницы кто автор статьей. Научная статья, как продукт, ничего общего обычно не имеет с личными предпочтениями. Имеет смысл контролировать то, что печатается в статье: не допускать статьи с пропагандой чего-то незаконного, с фейк/не фейк статьями, плагиатом и прочее. Но если научные статьи правдивые, качественно написаны и нравятся людям (из последнего следует то, какое количество людей данную статью прочтут), то какая разница кто он: наркобарон, заключенный или фашиствующий некропедозоофил?
На счет последнего: с проблемой доступа к не-фейковым научным статьям - согласен