Что, на ваш взгляд, можно улучшить в процессах тестирования на проекте?

А, слушай, вот сидишь ты, бывает, такой, тестируешь, тестируешь, а потом раз — и понимаешь, что весь процесс устроен так, что волосы дыбом встают. Ну, блядь, как так-то? Я тут подумал, какие бы улучшения в этот цирк с конями, то есть в QA, внести, чтобы не так пиздецово было. Не то чтобы всё плохо, но можно же лучше, ёпта!

Вот, например, первое и самое главное — коммуникация, сука! Ситуация классическая: аналитик накатал ТЗ, разработчик его прочитал, как стихи Есенина в подпитии, и пошёл делать. А ты, тестировщик, получаешь готовую фичу и офигеваешь: «А это, блядь, что за хуйня? Такого же в требованиях не было!». И начинается: «А я думал...», «А мне казалось...». Знакомо? Ага. Так вот, чтобы этого пиздеца не было, надо внедрить короткие, на пять минут, уточняющие встречи перед стартом задачи. Собрались аналитик, разработчик и тестировщик, быстро пробежались по пунктам: «Чё тут делать-то будем? А как это должно работать? А что если юзер нажмёт сюда, а потом сядет на бутылку?». Пиздец как просто, но овердохуища времени экономит и нервов.

Дальше — документация, эта ёбаная бумажная волокита. Писать тест-кейсы на триста страниц, где каждый шаг расписан, как попадание хуем в игольное ушко — это, простите, моветон и зашквар. Все их потом нихуя не читают. Надо переходить на что-то более живое и гибкое. Чек-листы, например. Или вот этот ваш Gherkin, который сценарии описывает почти человеческим языком. Смотри, как красиво:

Feature: User Login
  Scenario: Login with invalid credentials
    Given I am on the login page
    When I enter a valid username and an invalid password
    Then I should see an "Invalid credentials" error message

Всё! Понятно, блядь, даже мартышке. Что дано, что сделать и что должно получиться. Никакой лишней хуйни. И мозг не засоряешь, и покрытие нормальное.

А ещё, блядь, вовлекать QA надо пораньше, а не в самом конце, когда всё уже готово и приехало! Приглашайте тестировщиков на планирование спринтов, пусть они там сидят, бубнят себе под нос и оценивают, насколько та или иная задача — потенциальная банка с пауками. Они же сразу могут сказать: «О, эта херня с интеграцией платежей — там одни грабли, давайте разобьём на части, а то опять всё ебнется». Это ж золотые слова! Но нет, обычно про тестировщиков вспоминают, когда уже пора выпускать в прод, и все начинают суетиться, как тараканы от света.

Ну и куда же без автоматизации, мать её. Даже если ты не гуру программирования, написать простенький скрипт для smoke-теста — это не космос. Вот, смотри, элементарщина:

import requests

def test_main_page_availability():
    """Smoke-тест: главная страница загружается."""
    response = requests.get("https://example.com")
    assert response.status_code == 200

Запустил его перед началом работы — и сразу видно, не накрылся ли твой сервис медным тазом. Не надо вручную тыкать в браузер, как дурак. Экономия времени — просто пиздец!

И последнее, но очень важное — анализ дефектов. Нашли баг, пофиксили, закрыли. И все рады. А через месяц он вылезает снова, потому что причина-то осталась! Это как лечить насморк, затыкая нос ватой. Надо регулярно, блядь, садиться и ретроспективу по багам устраивать. Не просто «тут криво написали», а докопаться: «А почему криво написали? Может, требования двусмысленные? Может, архитектура говно? Может, все устали и нихуя не видят?». Устраняйте корень проблемы, а не просто срезайте верхушку, а то так и будете бегать по кругу, пока терпения ноль ебать не станет.

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