Срыв сроков выпуска ПО – часто возникающая проблема, от которой не застрахован ни один проект. Причины такого явления кроются в разнообразных непредвиденных ситуациях, связанных с деятельностью заказчиков, разработчиков или тестировщиков. К счастью, эту проблему, как и большинство других, можно предотвратить.
В данной статье я рассмотрю вопрос выделения достаточного количества времени на проведения тестов. Практика показывает, что именно на этом шаге создания продукта время зачастую экономится («там всего-то протестировать на полчасика – и все»). Для того, чтобы понять, почему нам важно выделить достаточно времени для проведения тестов, подробно рассмотрим, какие именно факторы могут привести к срыву сроков.
Что такое «достаточность времени» и как ее рассчитать?
1. Определение Итак, что подразумевается под «достаточностью времени», и чем «достаточное время» отличается от «номинального»? «Номинальное время» затрачивается на работу в идеальных условиях (без непредвиденных ситуаций). Но бывает ли так на практике?
Например, для установки компьютерной игры или программы в прилагаемой спецификации ПО приводятся номинальные и рекомендуемые (достаточные) характеристики ПК. Не следует ожидать от продукта высокой производительности, если технические параметры компьютера будут близки к номинальным требованиям. Именно поэтому рекомендуемые (достаточные) параметры для установки ПО всегда превышают номинальные.
В нашем же случае «достаточное время» – это время, которого гарантированно хватает для завершения поставленных задач даже в случае возникновения непредвиденных проблем. В этой статье я приведу реальные примеры из моей практики работы на двух проектах. Один из них обозначу «Отелем», а другой – «Утилитой».
Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.
На конференции Chief ConfeT&QA первое место поделили Анастасия Мусина с докладом “Тестировщики не винтики!” или “Не закручивайте гайки!” и Андрей Мясников с докладом “Что нам стоит дом построить”.
Доклад Анастасии мы уже опубликовали. А сегодня представляем доклад второго победителя Андрея Мясникова “Что нам стоит дом построить”.
Директор: «Ну вот, мы решили расширяться. Теперь ты не тестировщик-одиночка. Теперь ты руководишь отделом! Набирай людей и делай нам хорошее тестирование: не хуже, чем в «Пупкин Inc.»
Тебе дают полномочия, права и ресурсы. Но что с ними делать?
До этого ты тестировал один и писал баги в гугл-док, который показывал программистам. Но с командой так работать не получится! Что делать в такой ситуации? Как не ошибиться?
Мой доклад поможет вам составить список первоочередных задач в ситуации, когда вы становитесь тим-лидом или тест-менеджером. С чего начать? Как выбрать необходимые вам решения? Как распределить своё время?
В конечном счёте, всё в ваших руках. Но я помогу вам выжить первое время.
Тестировщики для контроля качества продуктов применяют средства автоматизации, анализаторы сетевого трафика, инструменты отладки… а также головной мозг для выполнения, так называемого, «ручного тестирования». Данное словосочетание неудачно по той причине, что процесс тестирования невозможно свести только к мышечной активности. Тем более руки в этом процессе задействованы незначительно. А вот от работы нервной системы в целом и зависит результат. В данной статье я постараюсь раскрыть то, как можно применять знания о высшей нервной деятельности человека для успешного решения задач по тестированию.
В тестировании есть такое понятие, как Monkey Testing - случайное нажатие на всевозможные кнопки приложения для того, чтобы его сломать. Действия эти не требуют каких-либо особых навыков, однако иногда помогают успешно находить даже сложные баги. Для автоматизации monkey testing существует много приложений на различных платформах.
В Android есть встроенное приложение UI Automation Exersizer Monkey, которое генерирует нужное количество случайных событий для телефона. Эти события могут быть самыми разными: одинарное нажатие, перетягивание, зум двумя пальцами, переключение системных кнопок, и даже переключение между различными пакетами приложения. Можно тонко настроить частоту определённых событий (зума, например) и задержку между ними. Инструмент это очень простой и не требует глубоких знаний для использования, однако при правильном подходе он позволяет значительно упростить себе задачи стресс-тестирования приложения. Для того, чтобы показать его работу, мы записали небольшое видео.
И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
cd /home
То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.
Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls…(в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
