Comments 25
Экономится время на подбор урлов и параметров.
Привет! Спасибо за твой комментарий!
Согласен с тем, что безопасность через неясность не работает. Практически все url, которые я использовал, можно было найти в консоли разработчика.
Как мы знаем, существуют различные методы тестирования. В данном посте я не рассматривал тестирование безопасности или нагрузочное тестирование. Я провел лишь функциональное тестирование. Моей основной задачей было показать, что бывает, когда продукт разрабатывается без тестирования
И, как верно упомянул Rive (https://habr.com/ru/post/564816/#comment_23193070), открытая документация экономит время подбора урлов и параметров. Однако в данном случае она также позволяет найти админ запросы, которые уже можно будет тестировать на безопасность
Как-то электрики у знакомых по всей деревне переставили счётчики из помещений на улицу. Потом какие пионеры от нечего делать, а может тестировали на прочность, покрошили непривычное оборудование у десятка домов. Где-то стекло не выдержало прямое попадание камнем, где то корпус сдался под натиском железного прута. Потом всех этих тестировщиков конечно нашли и наказали... Ждём статью "пентестинг без адвоката")
Описанная ситуацию скорее про порчу имущества. Я же лишь показал неудобства системы. Я целенаправленно не проводил тестирование безопасности, дабы не огрести в дальнейшем)
Также я предложил помощь в поиске и исправлении недостатков
Буду надеяться, что адвокат мне не понадобится)
Хотя стоит отметить, что, несмотря на жалобы пользователей, меня так и не заблокировали - спишем это на недостаток функционала администраторов.
Итак злоумышленник или конкурент испортил первое впечатление пользователей о платформе
Тут вы сами пишете, что ваши действия с продуктом на продакшене имели в конечном счёте негативные последствия. Сюжет представленной "детективной истории" содержит различные факты несанкционированного доступа и разработки вредоносного ПО в корыстных целях рекламы ваших услуг. Это все не очень этично и однозначно не законно.
Любой профессиональный тестировшик знает, что тестирование это серия экспериментов и некоторые эксперименты могут быть опасными. Поэтому оно должно проводиться в контролируемых условиях и иметь одной из задач минимизацию возможных негативных последствий. На продакшене проводят лишь ограниченный набор тестов, а все остальное - только в специально предназначенных для этого окружениях.
Благодарю за отзыв. Прислушался и постарался отредактировать статью в тех рамках, чтобы она более корректно несла свой посыл
Теперь статья не содержит разработку вредоностного ПО и рекламу моих услуг (коих я и не предоставляю)
Согласен с Поэтому оно должно проводиться в контролируемых условиях и иметь одной из задач минимизацию возможных негативных последствий.
При проведении своих тестов платформы я старался минимизировать возможные негативные последствия (добивался багов только на своих аккаунтах, не трогая чужие, предупредил администрацию сайта о том флуде, который был оставлен мной, извинился перед администраций сайта за доставленные неудобства). При проведении тестов я не выходил за рамки обычного пользователя и лишь оптимизировал свою работу с помощью кода.
К сожалению, к какому-либо тестовому окружению мне не предоставили доступ
«Тестирование — это важно. [..] не поленитесь и выделите отдельного человека для тестирования [..] подбирая команду на проект, обязательно обращайте внимание, чтобы в команде был человек, ответственный за тестирование системы»
С тем, что тестирование важно — согласен совершенно. То, что нужно нанимать в штат отдельного тестировщика, а тем более делать лишь его ответственным за тестирование — категорически нет. Это антипаттерн в CD.
Начнем с того, что рядовой тестировщик такие уязвимости не найдет. Такие дыры может найти пентестер, или разработчик, который знает, что искать. Тестировщик может найти функциональные баги, но для этого как бы нужна спецификация. А какие у стартапов могут быть спецификации, если они работают по принципу «главное запустить скорее»?
Нельзя пренебрегать фактом, что увеличивание штата команды увеличивает коммуникационную нагрузку. А следовательно замедляет разработку. И это опять же не соотносится с принципом стартапа.
Я думаю, в условиях стартапа, можно подключать незвисимых тестировщиков с краудсорсинга. Чтобы шлифануть самые острые занозы. А так — обратная связь с пользователем, быстрая починка, и изменение. Вот, что такое стартап.
Распространенный аргумент, против перекладывания задач тестирования на разработчиков это, что якобы прогаммист не должен тестировать свой код. Юнит тесты — да. Проверить, что фича работает — да. Тестировать весь продукт — нет.
Но вот парадокс, автор статьи — разработчик и успешно принял на себя роль тестировщика чужого проекта. Из этого следует что? Что нужно на проекте настоитить режим работы такой, чтобы разработчики могли менять роли.
Ладно, вы скажете, не ну, «свежий взгляд» нужен. А то если разработчики будут поочередно одевать пальто дежурного тестировщика, то им все примелькается и эффективность сойдет на нет. Ладно, привлекайте время от времени независимых тестировщиков, они подкинут идей, если глаз замылился.
Перекладывая проверку продукта на специального человека, вы лишаете ценного опыта свою команду. Опыт получает тестировщик а не разработчик. А этот опыт ему нужен, чтобы делать меньше ошибок. А так разработчик работает в режиме, сделал, выкатил, насыпало багов в джиру, починил, выкатил. Он вникает в ошибку в багтрекере только до тех пор, пока занимается ее починкой, и эмоционально не привязан к ней. А вот если он ее сам найдет, это будет опыт.
Спасибо за ваш комментарий! Согласен со многими вашими мыслями!
а тем более делать лишь его ответственным за тестирование
Хочу обратить внимание, что я не предлагаю делать только одного человека ответсвенным за тестирование, это в корне неправильно. В статье я призываю обращать больше внимания на тестирование своего продукта. Выделение компетентного человека, который будет проводить тестирование системы по юзер-кейсам, я считаю необходимо.
Чем раньше тестировщик начнет смотреть систему - тем более корректно она будет работать. Все баги, на которые мне удалось наткнуть, в компаниях, в которых я работал и работаю сейчас, обычно находят тестировщики.
Разработчики, мне кажется, должны тестировать свой код и интеграцию своего кода с другими частями проекта. Но, в случае если проект большой, разработчик будет не в силах протестировать весь проект и тем более с большей вероятностью не будет вкурсе всех юзер-кейсов проекта
нужно на проекте настоитить режим работы такой, чтобы разработчики могли менять роли.
Это скорее уже зависит от конкретного проекта. Я не припомню, чтобы встречал, что разработчик занимается тестированием всей системы. Своего кода - да, всей системы - нет. И раз вы в пример парадокса приводите меня - стоит отметить, что я имею опыт работы тестировщика, а в данный момент развиваюсь как java программист.
Плюсую
Начнем с того, что рядовой тестировщик такие уязвимости не найдет. Такие дыры может найти пентестер, или разработчик, который знает, что искать.
На рынке много прохиндеев которые только кнопочки нажимают. Для уровня стартапа описанный продукт вполне неплох, архитектура просматривается.
Учитывая нежелание заказчика проводить тестирование, понятно почему разработчики подобные "мелочи" проигнорировали. Если фичи работают корректно, то способа как сломать систему нестандартными действиями можно много где найти.
Имхо отдельным тестировщик здесь бы не помог, в лучшем случае найденные им недоработки упали бы мертвым грузом в бэклог, т.к. сервис ещё не набрал оборотов, шлифовать смысла нет.
Но скорее всего одним тестировщиком бы это неограничилось и бюджет бы значительно вырос, соглашусь, что фриланс-пентест сессии бы были лучшем выходом.
Хоть автор и говорит, что не рекламирует услуги, Но из контекста статьи и комментов делаю вывод, что он готов к взаимовыгодному сотрудничеству с заказчиком сервиса.
Интересна позиция автора :)
Почему бы свои таланты не "продать" тем компаниям, которые готовы их адекватно оценить ?
А что по этому "горе-стартапу", забил бы на них болт, они сами себе могилу копают.
Спасибо за ваш комментарий!
У меня нет цели продать себя кому-либо в данный момент, так как я трудоустроен и доволен своим местом работы. Статью я написал из-за того, что ранее с подобным подходом к разработке продового (рыночного) продукта не сталкивался
Мне кажется, что данный стартап вполне может превратиться в нечто крупное, если руководство стартапа будет принимать корректные действия. Связываясь с основателем, я хотел помочь им поделившись информацией о платформе. К сожалению, основатель не захотел со мной сотрудничать со словами: "нам очень интересно, быть может мы с вами свяжемся через 3-4 месяца"
Искренне надеюсь, что стартап сделает выводы и исправит недостатки платформы. Дабы не компрометировать и не рекламировать платформу - я убрал всё, что могло указывать на нее
Тут дело не в тестировании, а в том что на проекте не было тех лида, который провел бы production readiness review. Код ревью видимо тоже не было…
Спасибо за ваш комментарий!
Возможно вы правы, не уточнял про тех лида у разработчиков. Думаю, что раз была команда из 7 человек - кто-то руководил разработкой, не вижу иной возможности организации разработки командой из 7 человек
Единственное, приведу точную цитату разработчика, с которым я общался. Решать кто виноват я не хочу, но, видимо, все понимали на что идут выкатывая такой продукт. Мне кажется, что тестирование продукта могло бы указать на то, что решение было принято слишком рано. Но от такого решения пострадать могут пользователи платформы
Примерно во второй половине января выкатили ОЧЕНЬ сырой MVP (при этом мы узнали об этом в самый последний момент, а нам надо было минимум ещё три недели, чтобы устранить баги). Таких ресурсов было недостаточно, не говоря о том, что у нас не было ни тестировщиков, ни безопасников.
Данная статья ещё раз доказывает важность тестирования. А ведь если бы был использован принцип разработки через тестирование всех этих проблем удалось бы избежать.
Это замечание из категории "знал бы прикуп - жил бы в Сочи". Описанные автором проблемы едва ли решились бы через TDD
Не согласен с тем, что TDD едва ли помогло бы
Мой личный опыт показывает, что там, где TDD активно практикуют - ошибок на проде гораздо меньше. Но, безусловно, случается всякое и TDD не гарант хорошего продукта
Советую к прочтению следующую хорошую статью: https://habr.com/ru/company/ruvds/blog/450316/
Просто приведу из нее цитату
Дело в том, что уже многие годы в каждой команде, которой я руководил и на которую я оказывал влияние, применялась методология TDD. Ошибки, конечно, всё ещё случаются, но проникновение в продакшн проблем, способных «повалить» проект, снизилось практически до нуля, даже несмотря на то, что частота обновления ПО и количество задач, которые нужно решить в процессе обновления, экспоненциально выросли с тех пор, когда случилось то, о чём я рассказал в начале
Спасибо за ваш комментарий!
TDD - это просто подход к организации написания своей части проекта. Этот подход далеко не всегда соблюдается и в крупных компаниях. Но да, очень большое количество ошибок можно избежать используя такой подход. Однако стоит понимать, что сколько свой продукт не тестируй, всегда найдется пользователь, который нажмет куда-то не туда
К TDD можно относиться как к Agile. Методология хорошая, часто помогает, но не все ее используют или следуют всем канонам, что не мешает выпускать хороший продукт в срок
Но тестирования всей платформы компетентным человеком было бы достаточно, чтобы обнаружить то, что нашел я и обнаружить то, что мне найти не удалось
пожалуйста, все же напишите открыто что за проект. Очень раждражает каждый раз это вот стыдливое раскланивание перед рекламой и рекламщиками, такое ощущение что миром правят рекламщики. Просто напишите открыто что за проект, я тоже хочу потыкать в него палочкой!
К сожалению, изначально сам хабр против рекламы и видит в четком указании проекта в данной статье рекламу проекта. Вы всегда можете обратиться к правилам сайта по ссылке
https://habr.com/ru/docs/help/rules/
Если вам хочется самостоятельно потыкать что-либо - вы всегда можете самостоятельно найти проект. Если говорить про этот проект - то ссылку на платформу можно найти в поисковике, вбив, например, "Маркетплейс игровых ценностей"
Думаю пора написать видение изнутри проекта, а не собранную информацию через сломанный телефон с надуманными фактами.
Начнем с команды.
Первая команда/студия которая взялась за данный проект оказалась мошенниками или просто безалаберными людьми которые взяли на себя ответственность и не смогли ее реализовать, не смотря на все подписанные договоры, личные договоренности, дедлайны - выполнено было около 5% работы, проект понес убытки, как денежные так и потерял около 6 месяцев времени, после еще около 6-8 месяцев судебных разбирательств, в которых удалось вернуть денежные средства, конечно за упущенную выгоду, пользование чужими денежными средствами и потерянное время взыскать ничего не получилось, но те денежные средства которые были переданы на счет ООО "..." были возвращены. Ни о каких 7 человек речи не было, цифра 7 выдумана или взята из недостоверных источников, что является клеветой.
Вторая команда - тоже студия, но с более молодыми разработчиками, количество разработчиков варьировалось, несколько человек подбирались специально под проектную работу, а не на оклад, от куда взялись цифры указанные в посте - не знаю, очередные придуманные цифры.
Речь о фрилансе - выдуманный факт, никогда не прибегали к фрилансу и не будем, даже работая с разработчиками, которых студия брала под проектную работу, позиционировали их как своих сотрудников, так как у нас есть единый договор, а кого уже нанимает студия к себе в команду, это их дело, для нас главное выполненный результат в заложенные сроки. Повторю еще раз, к фрилансерами мы никогда не обращались, если подобного рода люди и приобщались к проекту, то это была инициатива владельца студии, на согласование это никогда не выходило, для подтверждения своих слов могу приложить скриншоты, так как клевета и реклама за счет других - черный метод который отразиться на карме.
Запуск - Примерно во второй половине января выкатили ОЧЕНЬ сырой MVP (при этом мы узнали об этом в самый последний момент, а нам надо было минимум ещё три недели, чтобы устранить баги). Таких ресурсов было недостаточно, не говоря о том, что у нас не было ни тестировщиков, ни безопасников. Очередной выдуманный факт - проект не был выкачен в январе, так как на тот момент имелось множество недоработанных моментов, даже не смотря на возгласы разработчиков - МЫ СТАРТАП, МЫ ДОЛЖНЫ ЗАПУСКАТЬСЯ НА МВП. основатель не стал двигать недоделанный продукт. Умение автора перевернуть картину под правильным углом в пользу себе, явно дает понимание об отсутствие объективного мышления.
Стартап в России - Очень много советчиков, но есть одно НО! Еще до момента формулирования советов " вам нужен тестировщик" "безопасник" и т.д. - мы все это знали и знаем гораздо больше без каких либо советов. По данным заявлениям видно отсутствие предпринимателей и стартаперов в данном топике - Стартап это в первую очередь ресурсные расходы - деньги и время. Мы исходили из выделенных бюджетов и урезали касты практически везде где это можно было.
Общее - При этом основатель категорически был против финансировать тестирование проекта, считая это пустой тратой времени - Выдуманный факт для драматизма наверно, не знаю. До написания статьи я связался с CEO проекта и предложил ему обсудить ошибки, которые удалось мне найти, а также решение этих проблем. Да, автор списался с руководителем проекта, где проявил интерес о вакансии тестировщика, а так же о продажи недочетов которые указаны выше, после данной беседы автору было сказано, что в данный момент проект не обладает определенными бюджетами и готов сотрудничать на другой основе = партнерство, волонтерство или просто помощь, но в случае, когда данная вакансия станет актуальной с возможность оплаты труда, с ним свяжутся, после чего автор сказал хорошо и в ближайшее время сообщу вам по поводу недочетов которые нашел. Повторю еще раз - проект не отказывался от подобных единиц, проект не мог себе позволить это из-за ограниченного бюджета. Вся информация, представленная выше, с уст разработчиков или основателя проекта Возможно из уст разработчика, который работал в проекте 6 месяцев назад, но точно не из уст основателя - цитата основателя из переписки в telegram "Данная информация на которую вы хотите получить ответы, является конфиденциальной по этому я не могу вам ответить на ваши вопросы" (с) Да автор прислал целый список вопросов, начиная от сколько людей в команде, кто финансирует проект до как часто вы созваниваетесь и какое печенье едите на встречах. Ну и очередная надуманная ложь - Стоит отметить, что по словам разработчиков проекта, тестирование не проводилось из-за невозможности договориться с основателем.
Итог - в статье указаны множество недостоверных фактов, выдуманных для подведения читателя к ключевому моменту - Продажа услуг. Автор акцентировал несколько раз на том, что у него в данный момент имеется работа на полную ставку, хотя в общении с руководителем проекта несколько раз упомянул что ему интересно трудоустройство или продажа тех уязвимостей которые он нашел, а так же оставленные контактные данные ниже подтверждают это, в связи с чем можно сделать вывод, данная статья является грамотным маркетинговым ходом для привлечения внимания, а не в сторону что проектах необходима тестирование, а в сторону что "Я тестировщик, Я сделал это, Я молодец, менЯ возьмите на работу".
За настойчивость ставлю + пареньку, за выдуманные факты и псевдо инсайдерскую информацию, а так же совет заниматься не QA, а маркетингом, с таким подходом заработать денег проще, да и правильно свои таланты применить можно. Из данный статьи можно было сделать отличную коллаборацию, если бы Автор изначально рассказал бы о своих намерениях, а не сделал это в тайне нарушая законы.
Ну и совет на будущее, подписывайте NDA ( сможете денежно компенсировать клевету ) с разработчиками, как это сделали мы, так как с определенной вероятностью вам попадется "злокачественная опухоль" в виде разработчика юных лет, который понесет много выдуманных фактов не соображая о последствиях.
данный пост написан основателем проекта иногда упоминая себя в 3м лице.
Продукт без тестирования