Ежедневно появляются десятки тысяч различных приложений, веб-сайтов, миллионы строк программного кода. Это естественный процесс, поскольку цифровая индустрия проникла во все сферы человеческой жизни: медицину, строительство, науку и другие. Однако при создании программного обеспечения неизбежно возникает проблема его качества.

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

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

  • функциональность,
  • внешний вид,
  • юзабилити,
  • производительность и тому подобное.

Как раз этими вопросами занимается тестировщик. Это современная профессия, которая становится все более и более актуальной, ведь тестировщик нужен для каждого приложения с момента его первого запуска.

Приложения очень отличаются друг от друга. Это могут быть веб-приложения, десктопные, мобильные приложения или даже игры. Они могут быть реализованы на определенных платформах или быть кроссплатформенными.

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

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

Детально изучите техническое задание

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

Скрыть отсутствие квалификации практически невозможно. И если о таком обстоятельстве становится известно — это очень сильно бьет по вашей репутации.

Продумайте наперед возможные трудности

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

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

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

Поэтому обязательно перед началом выполнения работы подумайте над возможными проблемами, задайте наводящие вопросы, предложите добавить в ТЗ то обязательное условие, что упустил заказчик.

Делайте работу в срок или даже быстрее

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

Делайте работу качественно

Качество и тестирование – это нераздельные понятия. Вы должны всегда помнить об этом. Если вы понимаете, что из-за сложности или сроков не сможете выполнить работу качественно – не беритесь за нее. В этом случае постарайтесь аргументированно предложить другие условия: сроки, способы реализации, приемы тестирования и т. д.

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

Если вы заводите баг-репорт, делайте это качественно. Приведу пример скриншота одного из баг-репортов, который демонстрирует эту стратегию:

----------

  1. Для простановки графических элементов используйте специализированный софт (SnagIt, Jing, Camtasia), не рисуйте их кривыми линиями в Paint.
  2. Выделяйте прямоугольником только проблемную область, не захватывайте лишнее.
  3. Желательно добавлять стрелку, которая уточняет, на что именно следует обратить внимание.
  4. Если вы показываете ошибку, прямоугольник и стрелка должны быть красного цвета. Если вы рядом показываете макет, то на макете делайте их цвет зеленым. Красный цвет традиционно означает наличие ошибки — то, на что необходимо обратить особое внимание. Зеленый цвет всегда указывает на правильный вариант (шаблон, макет, прототип).

---------------------------------

  1. Желательно ограничиться одним скриншотом на один баг-репорт. Лучше собрать несколько небольших скриншотов в один, как это показано выше. Несколько скриншотов неудобно сравнивать между собой, если они находятся не в рамках одного изображения.
  2. Иногда скриншоты не достаточно наглядны. Тогда лучше запишите видео. Особенно это актуально для функциональных багов.

В примере видно как «зависает» страница при клике по кнопке «Да».

Такую ошибку лучше показать на видео, поскольку скриншот не может показать процесс.

Если вы составляете чек-лист, также делайте это качественно.

  1. Чек-лист должен быть приятным на вид. Для этого используются цвета, шрифты, тексты заголовков подсвечиваются жирным. Успешно пройденные пункты — зеленые. Пункты, содержащие ошибки — красные, заблокированные — серые. Это наиболее привычные и хорошо узнаваемые цвета. Лучше использовать такие же или их оттенки. Фрагмент такого чек-листа показан ниже.

--------

Вообще, все что вы делаете, должно быть не только качественным, но и красивым. Выработайте у себя такую привычку.

  1. Чек-лист должен быть информативным. Заказчик должен легко в нем ориентироваться. Пункты, где были найдены ошибки, должны содержать примечания. В примечаниях следует указать номер ошибки и дать ее заголовок, как это показано выше.

  2. Заблокированные пункты по каким-либо причинам следует также сопровождать примечаниями, ссылаясь на ошибки.

Не стесняйтесь предлагать

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

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

Не забывайте об отчетности

После выполнения работы сделайте отчет, покажите что именно и как вы сделали. Если вы что-то не смогли протестировать по объективным причинам, напишите об этом. Как обычный пользователь, внесите предложения по улучшению проекта. Напишите, сколько часов вы потратили. Заказчик должен быть уверен, что вы старались, рационально потратили время на проект и сделали все, что требовалось согласно ТЗ или даже чуточку больше.

Если вы будете следовать таким несложным рекомендациям, то у вас всегда будут проекты, а отзывы о вашей работе будут только позитивными. Успехов вам!

P.S. Давайте вместе сделаем цифровой мир лучше! ☺