Вопрос совершенно теоретический, заинтересовал по результатам спора с коллегами. Допустим, вы работаете в аутсорсе или там фрилансите, и вам падает задание: написать исчерпывающие чек-листы/тест-кейсы/тест-план для какого-либо проекта, а тестировать по этому добру будут потом совсем другие люди. Бывает ли такое? И возможно ли вообще - в смысле, возможно ли сделать подобную работу именно качественно/исчерпывающе?

Понятно, что для какого-нибудь типичного интернет-магазина, наверное, да, но если это достаточно сложный (пусть и небольшой) сервис с небанальной бизнес-логикой?

Да, такое бывает.
Это возможно, хоть и непросто.

Интересно, а у вас был такой опыт? Если не секрет, сколько времени заняло, большое ли было приложение? Надеюсь не слишком любопытна, но это для меня в какой-то степени крышеснос )

 

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

Неполный? Тогда это несложно - надо просто взять предполагаемую технологию и погуглить ее, прибавив слова top 10 mistakes :))

 

 

Да, такое бывает.
Это возможно, хоть и непросто.

Интересно, а у вас был такой опыт? Если не секрет, сколько времени заняло, большое ли было приложение? Надеюсь не слишком любопытна, но это для меня в какой-то степени крышеснос )

 

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

 

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

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

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

(целесообразность такого подхода - другой вопрос, конечно).

Здравствуйте. Могу ли я начинающий в тестировании, задать следующий вопрос? Возможно для кого то ответ очевиден. Получил задание для рассмотрения кандидатуры. на вакансию тестировщик. Необходимо протестировать огромную форму для заведения аккаунта сотрудника, форма имеет несколько вкладок, которые тоже имеют поля для заполнения. Возник вопрос: Могу ли я в чек-листе создать тест-кейс, который будет тестировать создание аккаунта, при полностью заполненных данных? Просто это огромное количество данных, не только имя но и опыт, оплата, навыки и и.д.

Маленькое замечание: чек-лист и тест-кейс это все же разные вещи формально, если вы пишете чек-лист, то каждый пункт его - это "проверка", "пункт чек-листа" и т.п. Тест-кейсы это немного другое.

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

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

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

1. Открыть страницу такую-то

2. Нажать кнопку Add item

3. Заполнить поля Item name и Description так-то и так-то

4. Нажать кнопку Add

Ожидаемый результат: показано successful message, item появился в таблице такой-то.

Меня похвалили и потом рассказали, что передо мной с гневом развернули претендента, который написал кейс примерно так:

1. Открыть страницу такую-то. Ожидаемый результат: На странице отображается такая-то таблица, такие-то меню и кнопки

2. Нажать кнопку Add item. Ожидаемый результат: открылась форма добавления предмета с такими-то полями

3. Заполнить поля Item name и Description так-то и так-то. Ожидаемый результат: поля заполнены, при вводе описания появился скролл

4. Нажать кнопку Add. Ожидаемый результат: показано successful message, item появился в таблице такой-то.

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

А чем вам Савин не угодил? Отличная книга о тестировании, которую надо читать первой. Чисто чтобы понять, что это вообще такое, идти ли дальше и т.п. Читать первой книгой какого-нибудь Канера или даже Куликова - просто ничего не поймешь (если, конечно, в тестирование не идет человек из какой-то смежной области).

Савин отлично создает интерес к тестированию, фан и мотивацию, это дает энергию к дальнейшему изучению. И это не стоит недооценивать.

Тем, что это фан, а не тестирование.
Канер вполне читается первой книжкой. Тестирование матричных принтеров можно пропустить, если хотите))

А фан - это, между прочим, ни разу не фигня, а мотивация, энергия, топливо для мозга.

Это примерно как прочитать "Доктора Хауса" и загореться стать врачом. Другое дело, что некоторые совсем глупые люди думают, что между книгой и реальной работой нет вообще никакой разницы, но в том, что они дураки, не книги и не фильмы виноваты.

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

А не кажется ли вам, что для реализации этой благородной цели вы выбрали не те средства? О_о

Вредная книга - это та, где написано, скажем

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

- добивайтесь исправления каждого найденного бага

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

и т.д.

(и то последний пункт, в принципе, не однозначен для всех времен и народов).

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

Для того, что вы хотите, нужен пост вроде вот этого  https://automated-te...shhiku/10995/39 (название там несколько ироническое).

 

Тема создана в надежде, что начинающие тестировщики наконец включат голову и…

Реально анриал.

Я уже год надеюсь на то, что тестировщики начнут учть computer science хотя бы на уровне https://habr.com/post/358610/ Но нет, туда даже программисты не ходят.

 

Громко смеялась с примера об электрической сети :)

понятно, что это пример алгоритма, но все-таки с реальностью тоже надо дружить...

А что смешного в примере с эл. сетью?

Извините за флуд, я выступила не в тему, не удержалась (хотя, похоже, конструктивного тут уже все всё сказали :))

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

а что именно не получается?

Не получается локатор написать, что ли? Потому что несколько элементов с одинаковыми атрибутами?

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

//a[@data-price-tab="retail"]

в помощь

https://www.guru99.c...h-selenium.html

https://chrome.googl...lfhmkeplbhddipe

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

Очевидно, работают в каких-то других организациях

https://fullstory.com/ может попробуйте. Записывает видео - что пользователь видит / делает на сайте. Сервис платный, цена зависит от требуемого количества видео в месяц (т.е. допустим заплатили за 100, он за первые 3 дня месяца записал 100 и все, до начала следующего не пишет). Не знаю, правда, скринит ли платежные данные, если нет, то у вас есть риск иметь некрасивый вид.

Классы тоже лучше писать через contains, если это позволяет найти однозначное соответствие (не отвалится, если допустим к этим элементам кто-то применит какой-то еще класс).

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

хотя как по мне у вас и в Windows, скажем так, есть куда расти.

автора текстов выкинуть в окно.

Уважаемые редакторы, вас в этом переводе ничего не смущает? Наверное, случайно выложили черновик.

 

Возможно, Вам не нужно знать о тестировании Web-безопасности, если…

.....
 

• ПО вашей компании хранит любой вид персонально идентифицируемой информации (она определена законом, но обычно она может быть использована, чтобы найти вас или вашу семью)

 

Было два кейса.

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

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

Мораль: если человек сам не понимает, что это работа, несмотря на то, что на нее можно приходить в шортах и шлепанцах с носками, то этого никак не объяснишь

Подписываюсь на тему и с нетерпением жду увлекательных историй

Кстати, сколько платят за перевод статьи?

Здесь не знаю, но в среднем по больнице весьма немного. Поверьте мне, это вот совершенно не самый плохой вариант. Я не рассказывала свой любимый анекдот, когда одно чудо - за деньги! на полном серьезе! - перевело compute slices как "вычислительные ломтики"?

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

Баг без ОР, конечно, не должен быть, но на практике возможен: например при таких-то шагах происходит крэш или какой-нибудь JS error. ОР - очевидно, что крэша быть не должно. Хотя, конечно, правильно написать, допустим, "Изменения сохранены", но, если это очевидно для всех, то просто опускают для краткости.

just for my education - что такое "баг-репорт плана разработки сайта"? это какая-то общеизвестная вещь?

А вам для передачи токена точно не Bearer схема нужна (а не Basic)?

(я наверное что-то путаю, но вдруг)

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

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

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

 

Условно говоря, вы вбили данные, при которых идет деление на ноль в отчете. И какой ОР вместо краша? Разработчику делать что? Показывать отчет? А что писать в ячейке, где деление на ноль? Показывать ошибку? Какую?

 

Вообще-то я сказала "когда это очевидно для всех" не просто так. Речь идет не обо всех крэшах в принципе, а о тех, которые происходят вместо очевидных действий. Например при попытке залогиниться или отправить сообщение на форуме :) И еще я написала "иногда так делают", а не "смело поступайте именно так".

 

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

По теме: я поняла, что автору надо написать документацию про само приложение, скрин которого мы видим (какая-то старая версия Trello, видимо), и описать один из тех багов, которые там сидят хвостиками помахивают. Фейсбук и Гугл ни при чем

Баг-репорты надо делать именно по картинке, а не по приложению. Типа "Deisgn logo"

Это же пользователь так назвал задачу, а не в приложении баг. https://trello.com/