У нас в стране всё ещё бытует мнение, что человек должен овладеть какой-то профессией, и кормиться ею всю жизнь. Но эта самая жизнь сегодня меняется так быстро, что веками действующая схема работает всё хуже. Экономика оцифровывается, профессии исчезают, людей заменяют роботы и чат-боты. Поэтому сегодня всё труднее построить себе безбедное будущее, выбрав в молодости какое-то направление. Увы, но у нас пока не принято радикально менять профессию. И чем старше человек, тем труднее для него принять саму мысль, не то что решиться на это: «Как так, я уже 20 лет этим занимаюсь, опыт наработал, репутацию, а тут опять учиться, как школяру, и начинать с низов?». Да, решение непростое. Но чем сильнее экономико-технологические перемены будут влиять на занятость, тем актуальнее будет стоять вопрос смены профессии для всё большего количества людей. Но если человек сам хочет заняться чем-то новым, по желанию, а не из-за давления обстоятельств, то ему уже ничто не помешает.

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

Всё ближе момент, когда мы выпустим в свет наше решение, свежее, новенькое и сияющее. Волнительно? Не очень, ведь мы его уже проверили со всех сторон.

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

На основе этого плана мы ставим задачи разработчикам и «аудиторам» — коллегам из других отделов, которые проводят ревью решения (да, это тоже лайфхак). Надеемся, эта шпаргалка пригодится для подготовки к релизу продукта в прод.

Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.

На протяжении последних шести лет я занимаюсь разработкой и приёмочным тестированием самых разных по сложности и размеру приложений для проведения и сопровождения клинических исследований. Big data, огромное количество визуализаций и представлений, хранилища данных, ETL и тому подобное. Продуктом пользуются врачи, менеджмент и люди, которые участвуют в контроле и наблюдении за исследованиями.

Для приложений, которые оказывают или могут оказать прямое влияние на жизнь и здоровье пациентов, обязателен формальный процесс приёмочного тестирования. Результаты приёмочного тестирования вместе с остальным пакетом документации предоставляются для аудита в FDA (Food and Drug Administration, США). FDA выдаёт разрешение на использование приложения в качестве инструмента контроля и проведения клинических исследований. В общей сложности в моей команде разработано, протестировано и отправлено в продакшен более тридцати приложений. В данной статье я коротко расскажу о приёмочном тестировании и развитии инструментов в одной отдельно взятой маленькой группе.

Note: я не претендую на истину в последней инстанции и прекрасно понимаю, что большая часть того, о чём я пишу, — монолог Капитана Очевидность. Но я надеюсь, что описанное окажется полезным и начальному уровню, и командам, которые сталкиваются с этим в повседневной работе, или хотя бы порадует тех, у кого процессы попроще.

Over the past six years, I have worked on developing and acceptance testing of the applications for conducting and supporting clinical trials. Applications of various sizes and complexity, big data, a huge number of visualizations and views, data warehousing, ETL, etc. The products are used by doctors, clinical trials management and people who are involved in the control and monitoring of research.

For the applications that have or can have a direct impact on the life and health of patients, a formal acceptance testing process is required. Acceptance test results along with the rest of the documentation package are submitted for audit to the FDA (Food and Drug Administration, USA). The FDA authorizes the use of the application as a tool for monitoring and conducting clinical trials. In total, my team has developed, tested and sent to the production more than thirty applications. In this article, I will briefly talk about acceptance testing and improvement of tools used for it.

Note: I do not pretend to be the ultimate truth and completely understand that most of what I write about is a Captain Obvious monologue. But I hope that the described can be useful to both the entry level and the teams that encounter this in everyday work, or at least it may make happy those who have simpler processes.