Как передавали задачи в тестирование в текущем проекте

# Как передавали задачи в тестирование в текущем проекте

Этот вопрос касается процесса управления задачами, CI/CD и взаимодействия между разработкой и QA. Вот стандартный процесс.

1. Классический Waterfall процесс

В традиционном подходе:

1. Разработчик завершает задачу и отправляет на code review
2. Code review — коллеги проверяют код
3. Merge в develop/main — код объединяется в основную ветку
4. Deploy в staging — приложение разворачивается на тестовом сервере
5. QA берёт задачу и тестирует
6. Если баги — задача возвращается в разработку
7. Если OK — задача помечается как готовая к продакшену

Dev → Code Review → Merge → Staging → QA Test → (Bug/OK) → Production

2. Agile / Scrum процесс

┌─────────────┐
│   To Do     │ ← Задача в бэклог
└──────┬──────┘
       │ Разработчик берёт
       ↓
┌─────────────┐
│   In Dev    │ ← Разработчик пишет код
└──────┬──────┘
       │ Завершает, создаёт PR
       ↓
┌──────────────────┐
│  Code Review     │ ← Коллеги проверяют
└──────┬───────────┘
       │ Approve
       ↓
┌──────────────────┐
│  Ready to Test   │ ← Отправлено в тестирование
└──────┬───────────┘
       │ QA берёт
       ↓
┌──────────────────┐
│  In Testing      │ ← QA тестирует
└──────┬───────────┘
       │
    ┌──┴──┐
    ↓     ↓
  Bug    OK
    ↓     │
  Back   Ready for
  to     Release
  Dev      ↓
    │   ┌────────────┐
    │   │ Production │
    └──→└────────────┘

3. Использование GitHub Issues / JIRA

Типичный workflow с JIRA:

// Задача в JIRA: PROJ-123
// Статус: "To Do"
// Assignee: null

// Шаг 1: Разработчик берёт задачу
// Статус: "In Progress"
// Assignee: Developer Name

// Шаг 2: Разработчик создаёт PR с меньшим PROJ-123
// PR: "PROJ-123: Implement user authentication"
// JIRA автоматически связывает PR и задачу

// Шаг 3: Code review одобрен
// Статус: "Ready for QA"
// PR merged в staging

// Шаг 4: QA берёт задачу
// Статус: "In QA Testing"
// Assignee: QA Lead

// Шаг 5a: QA нашла баг
// Статус: "Back to Development"
// Comment: "Bug: Login fails with special characters"
// Assignee: Developer Name

// Шаг 5b: QA одобрила
// Статус: "Ready for Release"
// Comment: "Tested and verified. Ready for production."

4. Automated Testing Pipeline

Современный подход с CI/CD:

# .github/workflows/ci.yml
name: CI/CD Pipeline

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [develop, staging, main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Run Unit Tests
        run: mvn test
      
      - name: Run Integration Tests
        run: mvn verify
      
      - name: SonarQube Analysis
        run: mvn sonar:sonar
      
      - name: Build Docker Image
        run: docker build -t myapp:${{ github.sha }} .

  deploy-staging:
    needs: test
    if: github.ref == 'refs/heads/develop'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Staging
        run: |
          aws eks update-kubeconfig --name staging-cluster
          kubectl apply -f k8s/staging/deployment.yml
      
      - name: Run E2E Tests
        run: npm run test:e2e
      
      - name: Notify QA
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text": "New build ready for testing in staging"}'

  deploy-production:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Production
        run: |
          aws eks update-kubeconfig --name prod-cluster
          kubectl apply -f k8s/prod/deployment.yml

5. Процесс с Test Management

// Пример в TestRail или qTest

// Тестовый случай (Test Case):
// TC-001: User Login
// Steps:
//   1. Navigate to login page
//   2. Enter email: test@example.com
//   3. Enter password: Test123!
//   4. Click "Login" button
// Expected Result:
//   User should be logged in and redirected to dashboard

// При закрытии задачи разработчик указывает:
// - Test Case ID: TC-001
// - Build version: v1.2.3
// - Expected Result: Implemented

// QA выполняет тестовый случай:
// - Status: Pass/Fail
// - Defect ID (если fail): BUG-001

6. Модель с Continuous Deployment

Code Commit
    ↓
Automated Tests (Unit + Integration)
    ↓
Code Quality Check (SonarQube)
    ↓
Build Docker Image
    ↓
Deploy to Staging
    ↓
Automated Smoke Tests
    ↓
Manual Testing (QA)
    ↓
Automatic Deployment to Production
    ↓
Monitoring & Alerts

7. Пример Slack интеграции

@Service
public class NotificationService {
    private final RestTemplate restTemplate;
    
    public void notifyQATeam(String taskId, String taskTitle, String stagingUrl) {
        String message = String.format(
            "*New build ready for testing*\n" +
            "Task: <%s|%s>\n" +
            "Staging URL: <%s|%s>\n" +
            "Branch: develop\n" +
            "Please start testing",
            "https://jira.company.com/browse/" + taskId,
            taskTitle,
            stagingUrl,
            stagingUrl
        );
        
        SlackMessage slackMsg = new SlackMessage();
        slackMsg.setText(message);
        slackMsg.setChannel("#qa-testing");
        
        restTemplate.postForObject(
            "https://hooks.slack.com/services/YOUR/WEBHOOK/URL",
            slackMsg,
            String.class
        );
    }
}

8. Трекинг статусов

@Entity
@Table(name = "task_status_history")
public class TaskStatusHistory {
    @Id
    @GeneratedValue
    private Long id;
    
    private String taskId;  // JIRA task ID
    private String previousStatus;
    private String newStatus;
    private String changedBy;  // Developer or QA
    private String comment;    // Bug description or approval
    
    @CreationTimestamp
    private LocalDateTime changedAt;
}

@Service
public class TaskService {
    public void moveToQA(String taskId, String developerId) {
        Task task = taskRepository.findById(taskId).orElseThrow();
        task.setStatus("Ready for QA");
        taskRepository.save(task);
        
        // Логируем переход
        TaskStatusHistory history = new TaskStatusHistory();
        history.setTaskId(taskId);
        history.setPreviousStatus("Code Review");
        history.setNewStatus("Ready for QA");
        history.setChangedBy(developerId);
        historyRepository.save(history);
        
        // Оповещаем QA
        notificationService.notifyQATeam(taskId, "Task ready for testing");
    }
}

9. Метрики качества

-- Среднее время на тестирование
SELECT 
    AVG(EXTRACT(EPOCH FROM (completed_at - moved_to_qa_at)) / 3600) as avg_hours
FROM tasks
WHERE status = 'Completed'
    AND completed_at IS NOT NULL;

-- Процент задач с багами
SELECT 
    COUNT(CASE WHEN has_bugs THEN 1 END) * 100.0 / COUNT(*) as bug_percentage
FROM tasks
WHERE status IN ('QA Completed', 'Back to Dev');

-- Время между отправкой и началом тестирования
SELECT 
    AVG(EXTRACT(EPOCH FROM (qa_started_at - moved_to_qa_at)) / 60) as avg_minutes
FROM tasks;

10. Best Practices

1. Четкие критерии приёмки — определите, когда задача готова к QA
2. Automated tests — как можно больше тестов в CI/CD
3. Staging environment — идентичен production
4. Smoke tests — быстрые проверки при развёртывании
5. Test coverage — минимум 80%
6. Feedback loop — быстрое возвращение багов в разработку
7. Documentation — четкие требования и тестовые случаи
8. Трекинг метрик — SLA на тестирование, процент багов

Резюме

Процесс передачи в тестирование обычно выглядит так:

1. Разработчик закрывает код → code review
2. Merge в develop → автоматическое развёртывание в staging
3. Автоматизированные тесты (unit, integration, E2E)
4. Уведомление QA команде → они начинают тестирование
5. QA находит баги или одобряет → задача закрывается или возвращается
6. Approved → автоматическое развёртывание в production

Модерный подход требует хорошей автоматизации на каждом шаге.