Джуны бывают разные, если у кандидатов по году опыта, то всегда уровень владениями навыками разный. Именно поэтому нет предвзятого отношения год или принципиально 2,3 года. Я бы подчеркнул, что кандидатов именно рассматривают на серьёзные позиции, а дальше все зависит от технического интервью.
Я как автор даю свои рекомендации и советую включать более технические навыки, а в опыте работы писать свои обязанности. Профессия тестирования находится на стыке между софтами и хардами, если говорить про скиллы. И да, если это станет шаблонным вариантом резюме, то он вскоре станет нерелевантным. Зато сейчас это первый шаг для джунов собрать структуру в своем CV.
Про статью с разбором хорошая идея, я хочу чаще делать рубрику а-ля найти баги. И это реальные баги, которые были найдены при тестировании. Конечно конфиденциальную информацию изменил.
У тебя талант тестировать верстку! Хорошая работа ❤️
Под полем "Номер счёта" отображается подсказка "Должен содержать 20 цифр", но отсутствует "Должен начинаться на 4XX"
хорошее замечание - здесь был определен принцип релевантности. Две подсказки отображать неудобно, и приятно решение разместить их по приоритету:
Если меньше 20 цифр и счёт не начинается с 4, то после снятия фокуса выводим "Должен содержать 20 цифр" - это важнее, тк банально счёт введен не до конца. А после тапа на поле отображается "Должен начинаться на 4XX" при этом "Должен содержать 20 цифр" пропадает на время ввода. А подсказка "Должен начинаться на 4XX" отображается до тех пор, пока не исправят начало счёта (не зависит от ввода, фокуса поля и тд).
Различные отступы между полями формы (между "Номер счёта" и "БИК" отступ меньше, чем между "БИК" и "Наименование банка"
Хорошее замечание, я бы добавил, что подсказки налеплены на поля и нет отступов между поле - подсказка - поле. Тут либо изначально увеличивать отступ между полями или увеличивать отступ только при появлении подсказки.
Согласен) Представь, а это только 3 поля, обычно на странице более 5 полей может находиться. Это задача на две недели тестирования.
Отвечаю на твой вопрос: вставить данные в поле - выделить все данные в этом поле - нажать вырезать (данные копируются и удаляются) - далее вставляем в другое поле эти данные. По опыту пользователь может ввести данные не в то поле и он может вырезать цифры и вставить в валидное поле.
По логике данного кейса быть не должно, так как это сторонние API банка, которые ищут наименование банка по БИК. Если в БД имеется информация, имя банка отображается. Допускается ситуация, когда мы сначала ввели верный БИК — подтянулось имя, а затем изменили данные в поле БИК. В этом случае старое наименование должно исчезнуть. Если имя банка останется, пользователь может ошибочно предположить, что ввел правильный БИК.
«Не хватает времени? Привлекайте разработчиков и других членов команды»
Как по мне этот совет имеет место быть. На своем опыте могу сказать, что при диком регрессе не остается времени качественно протестировать. Если разработчик отдает вам задачу намного позднее, чем вы ожидали, то можно договориться на дейли при всех и внедрить практику «Если задерживаешь задачу, то будь добр проверить как это работает самостоятельно»
Есть такое понятие как success test - разработчик проверяет то, что по его мнению он и задумывал реализовать. Но это не дает право не перепроверять за разрабом) Это лишь гарантия того, что вы не вернете задачу на доработку в первый час тестирования функционала.
Раздел GIT + IDE + SELENIUM и Раздел DEVOPS действительно не для Джуна, но в разных компаниях по-разному оценивают грейд. Например в Тинькофф набирают только Full Stack тестировщиков и данные разделы необходимы для прохождения тех. интервью. Увы и ах…
Интересная затея, но очень много инструкций, которая ни на что не влияет, я бы убрал всплывающую инструкцию. Еще очень хочется видеть ответы на вопросы в конце
Джуны бывают разные, если у кандидатов по году опыта, то всегда уровень владениями навыками разный. Именно поэтому нет предвзятого отношения год или принципиально 2,3 года. Я бы подчеркнул, что кандидатов именно рассматривают на серьёзные позиции, а дальше все зависит от технического интервью.
Я как автор даю свои рекомендации и советую включать более технические навыки, а в опыте работы писать свои обязанности. Профессия тестирования находится на стыке между софтами и хардами, если говорить про скиллы. И да, если это станет шаблонным вариантом резюме, то он вскоре станет нерелевантным. Зато сейчас это первый шаг для джунов собрать структуру в своем CV.
Спасибо большое, надеюсь сработало ⭐️🎄 🎉🎊❄️☃️
Только такими задачами заниматься не получится, в каждой компании и команде могут быть свои процессы.
Дизайн-ревью проходит дизайнер мобильного приложения.
Тестировщик также будет всегда проверять верстку (UI) и заводить баг репорты.
Если коротко, то вакансия - тестировщик или QA на проект мобильного приложения или web-сервиса.
Хаххаха, идея хорошая!
Отлично, основное ты нашел (8 багов)
Добавлю момент с логотипом:
шрифт не YM Music
кнопка поиска отличается
Самое главное кроется в цвете анимации «Моя волна» - почему песня одна и та же, а цветовая палитра анимации разная? (Проверка 9,10)
Также есть баг в проверке 7 и 8
Все системные аналитики в шоке...Хорошие проверки, просто так не придумаешь такое, все благодаря опыту кажись. Благодарю
Про статью с разбором хорошая идея, я хочу чаще делать рубрику а-ля найти баги. И это реальные баги, которые были найдены при тестировании. Конечно конфиденциальную информацию изменил.
В команде тестировщиков есть практика:
Один пишет чек-лист
Второй проверяет по написанному чек-листу
Хороший программист - тот, кто понимает чужой код и делает свой код понятным для других. Так и у нас)
Это про удобство использования, на некоторых клавиатурах есть вероятность напечатать букву среди цифр.
Кейс:
1) Пожилой человек хранит реквизиты в заметках, он при попытке скопировать добавляет лишнюю букву.
2) Вставляет уже не 20 цифр, а 21 символ.
3) Маска допускает вставку только 20 цифр (убирая лишнюю букву).
У тебя талант тестировать верстку! Хорошая работа ❤️
хорошее замечание - здесь был определен принцип релевантности. Две подсказки отображать неудобно, и приятно решение разместить их по приоритету:
Если меньше 20 цифр и счёт не начинается с 4, то после снятия фокуса выводим "Должен содержать 20 цифр" - это важнее, тк банально счёт введен не до конца. А после тапа на поле отображается "Должен начинаться на 4XX" при этом "Должен содержать 20 цифр" пропадает на время ввода. А подсказка "Должен начинаться на 4XX" отображается до тех пор, пока не исправят начало счёта (не зависит от ввода, фокуса поля и тд).
Хорошее замечание, я бы добавил, что подсказки налеплены на поля и нет отступов между поле - подсказка - поле. Тут либо изначально увеличивать отступ между полями или увеличивать отступ только при появлении подсказки.
По макетам в статье нашел баги?)
Согласен) Представь, а это только 3 поля, обычно на странице более 5 полей может находиться. Это задача на две недели тестирования.
Отвечаю на твой вопрос: вставить данные в поле - выделить все данные в этом поле - нажать вырезать (данные копируются и удаляются) - далее вставляем в другое поле эти данные. По опыту пользователь может ввести данные не в то поле и он может вырезать цифры и вставить в валидное поле.
Супер поиск 🕵️♂️
По требованиям добавил бы еще про кнопку «Далее» отображается как «Дальше»
По логике данного кейса быть не должно, так как это сторонние API банка, которые ищут наименование банка по БИК. Если в БД имеется информация, имя банка отображается. Допускается ситуация, когда мы сначала ввели верный БИК — подтянулось имя, а затем изменили данные в поле БИК. В этом случае старое наименование должно исчезнуть. Если имя банка останется, пользователь может ошибочно предположить, что ввел правильный БИК.
Как по мне этот совет имеет место быть. На своем опыте могу сказать, что при диком регрессе не остается времени качественно протестировать. Если разработчик отдает вам задачу намного позднее, чем вы ожидали, то можно договориться на дейли при всех и внедрить практику «Если задерживаешь задачу, то будь добр проверить как это работает самостоятельно»
Есть такое понятие как success test - разработчик проверяет то, что по его мнению он и задумывал реализовать. Но это не дает право не перепроверять за разрабом) Это лишь гарантия того, что вы не вернете задачу на доработку в первый час тестирования функционала.
Спасибо большое, пытаюсь как раз уделить время на заполнение карты на 100%
На здоровье! Очень приятно ☺️ Активность в тг в виде комментариев приветствуется!
Раздел GIT + IDE + SELENIUM и Раздел DEVOPS действительно не для Джуна, но в разных компаниях по-разному оценивают грейд. Например в Тинькофф набирают только Full Stack тестировщиков и данные разделы необходимы для прохождения тех. интервью. Увы и ах…
Интересная затея, но очень много инструкций, которая ни на что не влияет, я бы убрал всплывающую инструкцию. Еще очень хочется видеть ответы на вопросы в конце