просто пишите юнит тесты на джаваскрипте

поздравляю с юбилеем!

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

но тут оказались трэш-тесты от Джеквони :) теперь одним попкорном не обойдешься :)

 

 

я прошла обучение на software-testing по java

а бэджик где?

это наверное лучше спрашивать на форумах где Apple TV девелоперы сидят

ну и как получается тестировать? что уже протестировали? какие баги уже нашли? что девелоперы сказали? какие баги они уже пофиксили?

это видимо задачка с собеса чтобы выяснить, понимает ли кандидат что вообще такое границы и где их надо и не надо применять

 

 

Спасибо) Такое дали задание

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

делается это путем изучения JMeter

попробуйте

 

 

Это какой-то описан человек из прошлого века - который боится гита.

ну тестировщики многие боятся гита, и много чего другого боятся. 

вот и приходится "психологические" статьи им писать

ну уже лучше

только тут немного перемудрили:

git pull origin master

достаточно будет простого 

git pull

наверное мало информации так как все пользуются http://rest-assured.io/

 

 

Не надо додумывать, надо уточнять.

а мне кажется это хорошо когда человек додумывает

тогда сразу видно, что выше чем на джуна кандидат не тянет

ну смотря где будет запущен этот бот

если на Вашей машине, то можете посмотреть трафик через Wireshark

если запущен на чьей-то чужой машине, то никак ;)

 

 

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

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

можно ли сказать что вторая система однозначно лучше? вроде все лучше видно, значит лучше?

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

а в первой системе используя "blame" можно трассировать до тикета и затем до эпика, и ресурсов на это уходит 0

 

 

Не надо пытаться исправить ошибки управления техническими средствами.

прям загадками говорите, ну точнее труизмами

вообще на любой вопрос можно ответить труизмом

 

Как говорил величайший менеджер двадцатого столетия: «Меняться совершенно не обязательно. Выживание - дело добровольное.»

Если вам платыт за растрату денег фирмы, я ничего не могу с этим сделать.

а поподробнее можно? 

так ведь может эти две трассировки и есть та самая "растрата денег фирмы"?

хотя если та трассировка достигается простым "blame" из гита, то она уже как-бы и есть, бесплатно

 

 

• Существует трассируемость требований на тесты. Да, мы знаем что и как покрыли. 

• Существует трассируемость тестов на задачи, да мы знаем что протестировано, где и как.

а вот это не оверкилл будет?

если тесты добавлены, прокодревьюены, то пусть и лежат/бегают себе?

 

 

Однозначно сказать нельзя, зависит от размера и критичности проекта. Если проект позволяет работать без требований - пожалуйста.
Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

ну вот у Гугла например - "аппликация" огромная, количество тестов просто несчетное. Но есть ли у них система управления требованиями, где все вот в тексте описано как где и что должно работать?

 

 

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

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

 

 

Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

на мастере все тесты должны быть зелеными, тогда и поддержки надо 0, и никакого "непрерывного внимания"

 

 

Неплохо. К сожалению доказать руководству и разработчикам, почему не надо начинать с регресса автоматизацию, особенно когда прописано в kpi, практически невозможно(.

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

 

 

Нет ничего нормального)

если у кого нет ничего нормального - надо начинать с юнит-тестов тогда :)

 

 

Не совсем понял, про какие лайфхаки тут говорится ))

- если у Вас в холодильнике вдруг кончилось молоко, что делать? есть "лайфхак" - сходить в магазин за молоком!

а вообще просто такое кричащее название для статьи, и никаких лайфхаков

когда-то сталкивались с чем-то похожим

добавили флаг в конфиг по которому система определяет это дебажная сборка или продовая

если система определяет что сборка дебажная то дополнительные средства безопасности отключаются

наверное можно как-то лучше определять, без конфига

 

 

А нет возможности дернуть API взаимодействия с устройством и скормить ей тестовый токен из самой таблетки?

а там разве так всё просто?

прихожу почитать Кристин когда хочется треша, не разочарован и в этот раз

"убирается лидин зеро" - это функциональная ошибка, но точно не "стабильность системы", то же самое с апострофом и тире

что валидация влияет на функциональность, про это вообще забыли

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

тестировать и блокировать точки с запятой из текстовых полей из-за боязни инъекций это просто верх глупости, она будет уверена что аппликация 100% безопасна но её тут же сломают через любой Постман