#тестирование

6 постов
пост №1382

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

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

Как, наконец, делать сайты и приложения без ошибок?

Тестирование — самая малоизвестная и недооценённая область программирования. Мало кто из программистов пишет тесты. На тестировщиков многое смотрят с пренебрежением и считают, что это такие недо-программисты.

Гость нашего сегодняшнего эпизода ломает многие стереотипы. Максим Садым занимался тестированием в Амазоне, а теперь работает над новым протоколом управления браузерами в Гугле.

Ну и истории о том, как всё сломать, конечно!

Слушайте и подписывайтесь: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.

пост №1104

Тестирование пуш-уведомлений в iOS всегда было болью. Сколько раз я сам чуть не отправлял пуш «тест» в продакшен (после одного такого раза я перестал тестировать заголовок «Путин умер»), сколько раз видел «тест» от именитых брендов.
А всё потому что пуши работали только на физических телефонах, не на симуляторах.

Наконец-то, в XCode 11.4 можно просто перетащить файл с содержимым пуша в симулятор и он придет как пуш в приложение. Наконец-то! via

пост №934

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

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

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

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

​​А вот источник этого дизайна.

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

пост №237

Насчет журналистской солидарности, в отсутствии которой меня уличают (https://t.me/mediasrachi/736) . Журналисты не при чем (неуиновны).

Налицо или халтура разработки: не протестировали ничего толком, не подготовились к нагрузке; или некомпетентность руководства, когда к разработке приходят с запросом «сколько тебе нужно времени, чтобы это было готово завтра?».

Извините, если выглядело как наезд, это не так. Это была серия постов «смотрите, как не нужно делать».

Запуск больших проектов — сложно и больно, но зато, в теории, есть время подготовиться. Супер-важно, чтобы руководство понимало, что «у меня всё работает» не равно «можно запустить на 100 тысяч пользователей». Ответственность разработки — объяснить важность тестирования. Вот вам бесплатный хороший кейс, на который можно ссылаться.

пост №51

В рамках программы «вчерашние новости уже сегодня»:

Утилита для генерации программ на Java https://takipi.github.io/java-bullshifier/
Такая же для С https://embed.cs.utah.edu/csmith/

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

И во вторых — это просто красиво. Футурологи рассказывают нам о роботах, программирующих роботов — а оно уже давно в продакшене.