Vla8islav

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

Есть корзина и интернет-магазине, ее надо протестировать, как и любую другую задачу, в сжатые сроки.

Итак, придумываем, что тестировать:

1. Все проверки должны быть согласованы со спеком поведения корзины для авторизованного и не авторизованного пользователя.
2. Добавление одной вещи в корзину всеми предусмотренными спецификацией способами.
3. Удаление одной вещи из корзины всеми предусмотренными спецификацией способами.
4. Попытка добавить/удалить вещи способами, не предусмотренными спецификацией. Надо проверить, что каждый случай будет вменяемо обработан: сообщение об ошибке, подсказка или просто отсутствие реакции. Пятисотые при отхождении от предусмотренного поведения не допустимы.
5. Добавление нескольких вещей с одним id всеми предусмотренными спеками способами.
6. Добавление нескольких вещей с одним названием, но разными id: в корзине они должны отображаться как два разных итема.
7. Корректность отображения значения при добавлении вещи: я бы добавил две вещи с разными размерами, чтобы удостовериться, что значение в корзине не отображается одно и то же.
8. Размер в корзине(если он отображается) меняется тогда, когда админы сайта его меняют.
9. Адекватная обработка сценария, когда после добавления пользователем вещи в корзину ее либо удаляют, либо деактивируют.
10. Корзину можно наполнить разными наименованиями товара до предела, указанного в спеке. Система не дает выйти за указанные пределы.

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

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

Тест-кейс - достаточно тяжелый документ в плане времени на написание и поддержку. Если бы я был единственным представителем QA на проекте, мой ответ был бы - ноль, достаточно чеклиста.

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

Я один тут вижу противоречие? Если члену команды мучительны процессы в том виде, в котором они существуют сейчас - это важнейшая тема, которая должна быть поднята на следующей встрече, и члены команды должны приложить все силы, чтобы ее решить.

По мне так первый шаг в такой ситуации - немедленно рассказать об этом своим коллегам. Потому что это - потенциально очень большой риск для команды. Люди не железные.

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

Если мне на вход дадут невнятную мешанину из кода, разработанного по столь же невнятной документации, при этом от меня будут ожидать довольных пользователей через, допустим, неделю(крайний срок поставки релиза), то я, скорее всего, заявление напишу. Потому что, по-честноку, согласие на такую работу будет с моей стороны в некоторой степени враньем. Я в такой ситуации могу переговорить с заинтересованными лицами, составить краткий тест-план и проверить то, что будет наиболее приоритетным, так, как мы договорились. Будут ли после этого недовольные пользователи заводить баги - вопрос открытый.

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

 

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

 

Это методологии разработки, а не тестирования:

 

TDD - Test Driven Development

BDD - Behaviour Driven Development

 

То есть разработка в себя тестирование не включает?

TDD или BDD очень хорошо себя зарекомендовала, как методолгия несомненного улучшения качества кода. Казалост бы - вот она смерть тестирования, но постойте. 

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

О какой смерти тестирования может идти речь после внедрения инновационной методики тестирования в рабочий процесс?

А насчет предвзятости разработчиков - это недостаток, над устранением которого разработчику надо работать.