Прослеживается тенденция, что тему ручного тестирования обделяют вниманием все чаще на различных конференциях. Не рассказывают про то, как тестируют новые фичи, с какими трудностями сталкиваются и вообще какие инструменты используют. В своем докладе расскажу про инструмент для ручного тестирования, который мы используем в Юле – Charles Proxy…

В рамках доклада планируется:
1) Осветить используемый в нашей компании подход к разделению логики между базой данных и клиентским приложением, при котором большую часть работы по инвентаризации и осуществлению процессов бизнес-логики выполняет именно БД.

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

Мир интернета вещей растет на 30% каждый год (прогнозируемо до 25 миллиардов(!) устройств к 2025 году), и это всего лишь вопрос времени, когда кому-то из нас придется… вернуться в прошлое. Многие из нынешних тестировщиков очень скоро начнут иметь дело с настоящими аппаратными устройствами.

Как правило, основная задача отраслевой практики тестирования программного обеспечения состоит в том, чтобы разделить нагрузочное тестирование и функциональное тестирование. Разные команды разработчиков с разными навыками и опытом проводят тестирование в разное время, и каждая оценивает результаты по своим собственным критериям.

Регрессионное тестирование может быть долгим и болезненным процессом. Зачем тратить так много времени или полностью отказываться от чего-то, если вы можете выполнить более эффективную регрессию, которая соответствует вашему итеративному процессу? Создание более умных категорий приведет вас к более эффективной регрессии и более быстрому выходу на рынок. И этот доклад именно об этом!

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

Помните в детсаду в группе обязательно был “жадина-говядина”, которого все не любили? Думаете, все эти дети выросли и резко изменились? Маловероятно. Хочу поделится своим опытом: как быть жадиной, как быть с жадиной и что делать с последствиям. Тема будет развиваться исходя из опыта работы в IT сфере и будет интересна тем, кто сталкивается внутри себя с проблемой жадности и тем, кто видит такое поведение снаружи.

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