Статья о переходе из метода черного ящика в метод серого и белого. Писать про IDE я буду уже для junior+ и middle. Если QA специалист (ключевое слово специалист) владеет навыками Dev, то это не означает, что он это будет делать за разработчика)))) Советую перечитать вступление. Devtools для всех необходим и писать «Зачем ты сюда лезешь, закрой» прям по-детски?
Спасибо за комментарий. Это сделано для разгрузки визуальной информации. Если это наоборот напрягает, то напишите почему и в следующей статье будет меньше скрытого текста)
Тут немного путаем стаж и грейд, сеньора-помидора хоть куда возьмут, а джуну тестеру придется поскитаться и высока вероятность наткнуться на тоже самое. Мы в первую очередь растем как специалисты, если вы достигли максимума или хотя бы мидл+, то можно и права покачать.
Спасибо за комментарий, в статье я поставил акцент на факт того, что разработчик делает функционал по задаче и может повлиять на аналитику функционала, если есть для него явные технические расхождения. Тестировщик тестирует, но также он выполняет тестирование удобства использования. Тут уже вопрос к аналитике, а не к разработчику. И связываться с заказчиком минуя аналитика бессмысленно. Я частично согласен с вами, но если у вас есть опыт и вы как QA можете влиять на продукт путем обеспечения качества, то можно провести аналитику самому путем тестирования и просто согласовать это. Далее идем к разработчику и демонстрируем факт изменения требований. Но если нет требований, то и нет аналитики. Тема моего поста как тестировать без требований, а вы судя по всему говорите о наболевшем.
Спасибо за письмо! А вы такие письма пишите только когда не согласны с терминами или же еще и хвалите за проделанную работу?
Статья для джунов, для джунов не элементарно, и судя по количеству сохранений статьи в закладки - не так уж это элементарно)
Статья о переходе из метода черного ящика в метод серого и белого. Писать про IDE я буду уже для junior+ и middle. Если QA специалист (ключевое слово специалист) владеет навыками Dev, то это не означает, что он это будет делать за разработчика)))) Советую перечитать вступление. Devtools для всех необходим и писать «Зачем ты сюда лезешь, закрой» прям по-детски?
Если планируете стать QA senior в большой ИТ компании, то должны. Если оставаться на уровне принеси-подай, то не должны получается)
Спасибо за комментарий. Это сделано для разгрузки визуальной информации. Если это наоборот напрягает, то напишите почему и в следующей статье будет меньше скрытого текста)
Легкий код, потому-что для джунов! И вы правы, что комментарий неверный тк 2000 это 2 секунды, а описано как 0,5.
Тут немного путаем стаж и грейд, сеньора-помидора хоть куда возьмут, а джуну тестеру придется поскитаться и высока вероятность наткнуться на тоже самое. Мы в первую очередь растем как специалисты, если вы достигли максимума или хотя бы мидл+, то можно и права покачать.
Один из вопросов на собеседования тестировщика «Что такое баг?»
Хорошим ответом считается «Несоответсвие ожидаемого и фактического результата»
И тут я полностью согласен с вами. Опять же тестирование без требований нельзя назвать тестированием) Но реальность останется реальностью.
Спасибо за комментарий, в статье я поставил акцент на факт того, что разработчик делает функционал по задаче и может повлиять на аналитику функционала, если есть для него явные технические расхождения. Тестировщик тестирует, но также он выполняет тестирование удобства использования. Тут уже вопрос к аналитике, а не к разработчику. И связываться с заказчиком минуя аналитика бессмысленно. Я частично согласен с вами, но если у вас есть опыт и вы как QA можете влиять на продукт путем обеспечения качества, то можно провести аналитику самому путем тестирования и просто согласовать это. Далее идем к разработчику и демонстрируем факт изменения требований. Но если нет требований, то и нет аналитики. Тема моего поста как тестировать без требований, а вы судя по всему говорите о наболевшем.