Салют! Уже на следующей неделе стартуют занятия в новом потоке курса «QA-специалист», в связи с этим делимся с вами полезным материалом, переведенным специально для студентов курса. Поехали.
Функциональное тестирование сохраняет свою значимость даже при обширном внедрении автоматизации. Многие программные продукты требуют ручного тестирования для проверки и исследования всех функций и их взаимодействия.
К сожалению, многие тестировщики проводят только функциональное тестирование, не выходя за его рамки. Причинами этого могут быть отсутствие навыков, неумение писать код, боязнь неизвестного или ограниченное знание ландшафта тестирования.
Перефразируя Сэма Канера, тестирование программного обеспечения — это поиск информации о качестве продукта, которая может помочь стейкхолдерам в принятии обоснованных решений.
Помимо функционального тестирования есть и другие способы поиска информации. В этой статье рассмотрим шесть способов, которые помогли мне повысить эффективность моих проектов.
Тестировщики обычно изучают документы с требованиями, обсуждают их со стейкхолдерами, а затем разрабатывают тесты. Но мы все знаем, что бывают, не покрытые тест-кейсами, сценарии, которые появляются во время использования продукта. Большинство из них покрываются разработчиками, но некоторые могут стать неожиданностью для всех.
Команда разработчиков может помочь, составив список всех сообщений, которые есть в продукте, включая сообщения об ошибках, информационные сообщения и предупреждения. Это также послужит хорошей проверкой тестового покрытия, с точки зрения сообщений, отображаемых системой. Если тестировщики никогда не видели сообщение, которое будет показано пользователю, то им стоит вернуться назад и понять, в каких случаях это сообщение будет отображаться.
Однажды, получив список сообщений, я сразу заметил, что ряд из них были совершенно новыми для команды тестирования. Изучив, мы поняли, что они были из устаревшего кода и, несмотря на то, что мы больше не поддерживали этот функционал, они были в исходном коде. Этот код следовало удалить, так как он уже не влиял на продукт.
В зависимости от архитектуры приложения, подготовить подобный список может быть легко или сложно. Но если вы думаете, что это упражнение поможет команде тестировщиков лучше тестировать, то стейкхолдеры должны договориться о том, чтобы найти способ подготовить список сообщений. Попробуйте этот подход и проверьте насколько хорошо вы знаете свой продукт и какое у вас тестовое покрытие.
Многие продуктовые команды очень быстро выпускают первые версии, а затем думают о стабилизации кода после достижения определенного количества клиентов или по другим показателям. Быстрые релизы на начальном этапе обычно имеют приоритет над тем, чтобы делать релизы правильно. Но по мере того, как в дело вовлекается все больше разработчиков, возникает высокая вероятность появления несогласованности.
В процессе стабилизации продукта сосредоточьтесь на том, чтобы избавиться от любых несоответствий UX. Выполните UX-ревью всего приложения. Начните с иконок, текста, действий, функций и основных потоков. Используйте персонажей и мозговой штурм для полного ревью UX. Подумайте также о точках соприкосновения (touchpoints) для пользователей. Как вы справляетесь с ними? Есть ли в вашем приложении то, что вводит в заблуждение? По адресу https://cantunsee.space есть упражнения, которые помогут вам проверить ваши UI-навыки.
Когда мы сделали UX-ревью одного из активно используемых продуктов нашей компании, мы обнаружили шаблоны несогласованности и могли легко связать их с различными решениями, которые мы принимали как команда, выпуская фичи в спешке, отдавая разработку на аутсорс другой команде, выпуская фичи с устаревшими плагинами и так далее.
Жаль, что многие тестировщики работают в изоляции и не имеют ни малейшего представления о продуктах других компаний. Изучите своих конкурентов с помощью рекламной информации, веб-семинаров, демонстраций, новостей в СМИ и блогах, а затем выпишите фичи и проанализируйте сильные и слабые стороны вашего продукта.
Узнайте у ваших продуктовых команд, можете ли вы получить доступ к предложениям других компаний, и спросите, как вы можете помочь в анализе конкурентов. Помимо анализа функциональности, обратите внимание также на такие критерии как удобство использования, производительность, безопасность и доступность. Полезно сделать сравнительную таблицу “функциональность — критерии оценки” с баллами, которые набрали продукты.
Инструменты — благо для тех, кто знает, как их эффективно использовать. Они могут сэкономить много денег и времени и в значительной степени дополнить тестирование. Как тестировщик, вы должны обладать обширными знаниями о применяемых системах и используемых процессах.
Помимо автоматизации функциональных проверок и быстрого создания тестовых данных, существуют также инструменты для обнаружения паттернов в логах, для репликации данных из продакшена, для имитации функций, для записи действий пользователя и для реагирования на события на основе правил. Также для достижения большинства конечных целей нет необходимости покупать проприетарные инструменты. Это может быть простая программа из сотни строк, которая делает скриншот приложения на основе триггера в логе.
Иногда не всем бывает очевидно, насколько полезны те или иные инструменты, пока вы не продемонстрируете то, какую пользу они могут принести, поэтому изучите их возможности.
Как описано в книге Элизабет Хендриксон ”Explore It! Reduce Risk and Increase Confidence with Exploratory Testing”, один из способов предотвратить катастрофу — подумать о возможных заголовках плохих новостей, связанных с вашим продуктом или проектом, и протестировать эти риски. Тестировщики хорошо умеют думать о возможных сценариях аварий, и этот навык может помочь команде разработчиков избежать ошибок при написании кода, заранее экономя время и усилия.
Это может стать забавной игрой, в которую можно играть с несколькими стейкхолдерами, и она даст всем уверенность в том, что о рисках позаботятся. Когда мы проводили эту игру с одной из наших команд то, некоторые заголовки, придуманные службой технической поддержки и руководством, дали нам иную точку зрения — без этого мы никогда бы не подумали об этих тестах.
Из-за постоянного использования своего продукта команда тестирования может быть склонна к предвзятости. И то, что кажется тестировщикам ожидаемым поведением, на самом деле, может быть неудобным для пользователей. Вы можете изучить звонки в службу поддержки, чтобы узнать о боли клиентов и проблемах при использовании вашего приложения.
Однажды мы жаловались на фичу одного из наших продуктов и удобство ее использования, но это не было принято как баг. Хотя когда несколько клиентов начали обращаться с подобными проблемами юзабилити, то это было исправлено с высоким приоритетом. Этот случай придал нам большой авторитет в организации. И позже нас пригласили принять участие в многочисленных дискуссиях о решениях, касающихся удобства использования.
Голос клиента — это реальные данные, на которые вы должны обратить внимание, и вы можете использовать эти данные для того, чтобы внести свой вклад в развитие вашего продукта.
Эти шесть способов легко сочетаются с функциональным тестированием и приносят огромную пользу. Попробуйте их в своей работе по тестированию и расскажите нам о своем опыте.
На этом все. Ждем ваши комментарии и приглашаем на день открытых дверей, который пройдет уже 21 июня.
Резюме: Многие тестировщики проводят только функциональное тестирование, не выходя за его рамки. Но тестирование программного обеспечения — это поиск информации о качестве продукта, которая может помочь стейкхолдерам в принятии обоснованных решений, и существует множество способов поиска информации помимо функционального тестирования. В данной статье описаны шесть способов, которые помогут вам повысить эффективность ваших проектов.
Функциональное тестирование сохраняет свою значимость даже при обширном внедрении автоматизации. Многие программные продукты требуют ручного тестирования для проверки и исследования всех функций и их взаимодействия.
К сожалению, многие тестировщики проводят только функциональное тестирование, не выходя за его рамки. Причинами этого могут быть отсутствие навыков, неумение писать код, боязнь неизвестного или ограниченное знание ландшафта тестирования.
Перефразируя Сэма Канера, тестирование программного обеспечения — это поиск информации о качестве продукта, которая может помочь стейкхолдерам в принятии обоснованных решений.
Помимо функционального тестирования есть и другие способы поиска информации. В этой статье рассмотрим шесть способов, которые помогли мне повысить эффективность моих проектов.
1. Изучите все сообщения
Тестировщики обычно изучают документы с требованиями, обсуждают их со стейкхолдерами, а затем разрабатывают тесты. Но мы все знаем, что бывают, не покрытые тест-кейсами, сценарии, которые появляются во время использования продукта. Большинство из них покрываются разработчиками, но некоторые могут стать неожиданностью для всех.
Команда разработчиков может помочь, составив список всех сообщений, которые есть в продукте, включая сообщения об ошибках, информационные сообщения и предупреждения. Это также послужит хорошей проверкой тестового покрытия, с точки зрения сообщений, отображаемых системой. Если тестировщики никогда не видели сообщение, которое будет показано пользователю, то им стоит вернуться назад и понять, в каких случаях это сообщение будет отображаться.
Однажды, получив список сообщений, я сразу заметил, что ряд из них были совершенно новыми для команды тестирования. Изучив, мы поняли, что они были из устаревшего кода и, несмотря на то, что мы больше не поддерживали этот функционал, они были в исходном коде. Этот код следовало удалить, так как он уже не влиял на продукт.
В зависимости от архитектуры приложения, подготовить подобный список может быть легко или сложно. Но если вы думаете, что это упражнение поможет команде тестировщиков лучше тестировать, то стейкхолдеры должны договориться о том, чтобы найти способ подготовить список сообщений. Попробуйте этот подход и проверьте насколько хорошо вы знаете свой продукт и какое у вас тестовое покрытие.
2. Делайте ревью UX
Многие продуктовые команды очень быстро выпускают первые версии, а затем думают о стабилизации кода после достижения определенного количества клиентов или по другим показателям. Быстрые релизы на начальном этапе обычно имеют приоритет над тем, чтобы делать релизы правильно. Но по мере того, как в дело вовлекается все больше разработчиков, возникает высокая вероятность появления несогласованности.
В процессе стабилизации продукта сосредоточьтесь на том, чтобы избавиться от любых несоответствий UX. Выполните UX-ревью всего приложения. Начните с иконок, текста, действий, функций и основных потоков. Используйте персонажей и мозговой штурм для полного ревью UX. Подумайте также о точках соприкосновения (touchpoints) для пользователей. Как вы справляетесь с ними? Есть ли в вашем приложении то, что вводит в заблуждение? По адресу https://cantunsee.space есть упражнения, которые помогут вам проверить ваши UI-навыки.
Когда мы сделали UX-ревью одного из активно используемых продуктов нашей компании, мы обнаружили шаблоны несогласованности и могли легко связать их с различными решениями, которые мы принимали как команда, выпуская фичи в спешке, отдавая разработку на аутсорс другой команде, выпуская фичи с устаревшими плагинами и так далее.
3. Проведите анализ конкурентов
Жаль, что многие тестировщики работают в изоляции и не имеют ни малейшего представления о продуктах других компаний. Изучите своих конкурентов с помощью рекламной информации, веб-семинаров, демонстраций, новостей в СМИ и блогах, а затем выпишите фичи и проанализируйте сильные и слабые стороны вашего продукта.
Узнайте у ваших продуктовых команд, можете ли вы получить доступ к предложениям других компаний, и спросите, как вы можете помочь в анализе конкурентов. Помимо анализа функциональности, обратите внимание также на такие критерии как удобство использования, производительность, безопасность и доступность. Полезно сделать сравнительную таблицу “функциональность — критерии оценки” с баллами, которые набрали продукты.
4. Изучите возможности инструментов
Инструменты — благо для тех, кто знает, как их эффективно использовать. Они могут сэкономить много денег и времени и в значительной степени дополнить тестирование. Как тестировщик, вы должны обладать обширными знаниями о применяемых системах и используемых процессах.
Помимо автоматизации функциональных проверок и быстрого создания тестовых данных, существуют также инструменты для обнаружения паттернов в логах, для репликации данных из продакшена, для имитации функций, для записи действий пользователя и для реагирования на события на основе правил. Также для достижения большинства конечных целей нет необходимости покупать проприетарные инструменты. Это может быть простая программа из сотни строк, которая делает скриншот приложения на основе триггера в логе.
Иногда не всем бывает очевидно, насколько полезны те или иные инструменты, пока вы не продемонстрируете то, какую пользу они могут принести, поэтому изучите их возможности.
5. Подумайте о рисках, которые могут стать “ночным кошмаром”
Как описано в книге Элизабет Хендриксон ”Explore It! Reduce Risk and Increase Confidence with Exploratory Testing”, один из способов предотвратить катастрофу — подумать о возможных заголовках плохих новостей, связанных с вашим продуктом или проектом, и протестировать эти риски. Тестировщики хорошо умеют думать о возможных сценариях аварий, и этот навык может помочь команде разработчиков избежать ошибок при написании кода, заранее экономя время и усилия.
Это может стать забавной игрой, в которую можно играть с несколькими стейкхолдерами, и она даст всем уверенность в том, что о рисках позаботятся. Когда мы проводили эту игру с одной из наших команд то, некоторые заголовки, придуманные службой технической поддержки и руководством, дали нам иную точку зрения — без этого мы никогда бы не подумали об этих тестах.
6. Проведите время со службой поддержки
Из-за постоянного использования своего продукта команда тестирования может быть склонна к предвзятости. И то, что кажется тестировщикам ожидаемым поведением, на самом деле, может быть неудобным для пользователей. Вы можете изучить звонки в службу поддержки, чтобы узнать о боли клиентов и проблемах при использовании вашего приложения.
Однажды мы жаловались на фичу одного из наших продуктов и удобство ее использования, но это не было принято как баг. Хотя когда несколько клиентов начали обращаться с подобными проблемами юзабилити, то это было исправлено с высоким приоритетом. Этот случай придал нам большой авторитет в организации. И позже нас пригласили принять участие в многочисленных дискуссиях о решениях, касающихся удобства использования.
Голос клиента — это реальные данные, на которые вы должны обратить внимание, и вы можете использовать эти данные для того, чтобы внести свой вклад в развитие вашего продукта.
Эти шесть способов легко сочетаются с функциональным тестированием и приносят огромную пользу. Попробуйте их в своей работе по тестированию и расскажите нам о своем опыте.
На этом все. Ждем ваши комментарии и приглашаем на день открытых дверей, который пройдет уже 21 июня.
