Vienta

 

 

Эх...

Чтобы заглядывать в код, нужно понимать, что там происходит. Я слышала истории, что разрабы писали тесты, чтобы они были зеленые, а не чтобы проверяли. Если понимания кода пока нет, то быстро оно не появится, хотя, к этому, безусловно, нужно стремиться.

для начала смотрите не в код проекта, он скорее всего очень сложный - а смотрите в код тестов, там код простой и понятный

 

 

 

Еще момент, что автотесты часто пишут по готовым ручным, значит создать эту ручные все же нужно.

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

 

 

 

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

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

 

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

 

Мне очень нравится то, что Вы говорите. В такой рабочей ситуации хочется оказаться. Можете, пожалуйста, тогда дать более конкретный совет? Если отбросить пример про поля, как простой, а взять конкретную задачу моей реальности. В аналоге Unity, который я тестирую, появился новый редактор, который мне отдали покрыть кейсами. Требований нет, писался из головы и теперь разработчик вместо требований, все рассказывает, объясняет. Как-то этот редактор тестировали пока разрабатывали (я тогда в компании еще не работала и ничего сказать не могу), баги есть, но в целом все работает. И вот я начинаю писать кейсы, нахожу похожие проверки, думаю как мне это лучше организовать и пока что даже не представляю что из этого и как можно отдать на тестирование разработчикам. Начать с разговора с разработчиком, что из этого он мог бы покрыть проверками, чтобы не проверять это в каждом регрессе, а значит и нет необходимости хранить в виде кейсов? А если он скажет, что ничего не может сделать, занят другими вещами, если менеджер мне скажет, что нет возможности выделить время на это сейчас? Как тогда быть? Создавать кейсы/чеклисты, стараться не плодить монстро-кейсы и доносить необходимость? Мне кажется, что это выглядит так, что мне дали покрыть функционал кейсами, а я с разворота - а давайте вы сами большую часть работы сделаете, а я буду делать что-то более важное. Если я сама в это не верю, то не смогу убедить других.

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

Привет всем) Совершенно не знаю в какой чат писать, по этому пишу сюда)

Я начинающие тестеровщик, мой руководитель дал мне задание зарегаться  на форме и спросить у более опытных людей, где найти примеры задания и отчетов по тестированию, чтобы знать на что опираться и как лучше писать отчеты, буду благодарна за помощь ))

p.s. Будет здорово, если кто нибудь сможет мне скинуть пример, HELP ME!!!!!!!    

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

 

 

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

то есть есть список кейсов, проваливаешься в один, а там только ссылка и больше ничего?

 

Главное же идея, а как именно оформить - смотрите сами.

 

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

 

Спасибо! Попробую приложить к своим кейсам, посмотрю, что получится.

 

 

Для этого должна быть определенная культура обеспечения качества в компании.

 

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

 

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

вводить такую систему просто

 

пусть отдел разработки в "Definition of Done (DoD)" добавит пункт "написать автоматические тесты"

 

а Вы потом при тестировании просто иногда заглядывайте в код, и смотрите чтобы там нормальные тесты были (конечно иногда там и должно быть 2*2=4, например если это тест АПИ а функционал уже протестирован уровнем ниже)

 

Эх...

Чтобы заглядывать в код, нужно понимать, что там происходит. Я слышала истории, что разрабы писали тесты, чтобы они были зеленые, а не чтобы проверяли. Если понимания кода пока нет, то быстро оно не появится, хотя, к этому, безусловно, нужно стремиться.

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

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

 

 

 

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

может скажете почему он нереализуемый в Вашем конкретном случае?

 

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

А еще в том, что это пример простой, но у меня в проекте сейчас похожие по сути, но более сложные наборы кейсов и ресурсов на это нет.

Извините, если говорю слишком уклончиво, пока не очень понимаю, что можно, а что нельзя рассказывать. Я тестирую аналог Unity, он включает в себя много разных редакторов и они используют одинаковые механизмы типа copy/paste или создание связей между объектами, я не чувствую себя вправе сказать - а покройте-ка мне тестами половину редактора, а я пока на остальное кейсы попишу.