Estamos em busca de um profissional de computação com experiência em Educação e teste de software (avaliação humano-computador) para validar e analisar alguns softwares. O trabalho consiste em aplicar técnicas de análise e gerar relatórios.

Em média, 10 softwares/jogos.

Disponibilidade para concluir o trabalho em até 3 semanas após o início da tarefa.

Envie sua proposta, incluindo sua experiência relevante e métodos que pretende utilizar para a análise.

Todo o contato será feito pela plataforma!

Tenho um servidor de telemetria que hoje trabalha com o Mercado Pago, usando a Point Pro 2. Porém, gostaria de ter uma segunda opção usando a Smart 2 do PagSeguro. Portanto, quero um app simples para colocar na loja da PagSeguro, onde o cliente só seleciona o valor que deseja e realiza o pagamento. É uma solução bem simples para quem já desenvolveu no ambiente da PagSeguro.

# Descrição do projeto

Estamos em busca de um(a) profissional experiente em **QA/Testing/Support** para trabalhar na evolução do nosso sistema de monitoramento de serviços (**Status v2**). O projeto atual está disponível em nosso repositório público do GitHub: [status.orango.io](https://github.com/ORANGO-IO/status). A ideia é implementar novas funcionalidades de testes (ativos e passivos) para garantir a qualidade e o correto funcionamento de diversos serviços que mantemos, bem como modelar adequadamente os dados de **serviços** e **tasks** no sistema.

---

## O que precisamos

1. **Modelagem de serviços e tasks**
- **Serviços:**
- Cada serviço terá:
- **UUID** (chave primária)
- **slug** único (usado em rotas e referências)
- **nome e descrição**
- Informações de configuração e metadados (por ex., endpoints, credenciais, etc.)
- Deve permitir cadastrar múltiplas tasks associadas.

- **Tasks:**
- Cada task terá:
- **UUID** (chave primária)
- **tipo** (crawler, request, E2E)
- **parâmetros** específicos (URL, corpo de requisição, script E2E etc.)
- Associação ao serviço correspondente.

- Precisamos de uma estrutura que facilite **cadastrar, atualizar e remover** serviços e suas tasks, seja **manualmente** (via Typer) ou programaticamente.

2. **Cadastro de serviços via Typer (CLI em Python)**
- Criar ou aprimorar comando(s) em **Typer** para **adicionar e gerenciar serviços** (com slug, UUID etc.) e suas tasks (também com UUID).
- Possibilidade de definir quais tipos de tasks cada serviço terá (crawler, request, E2E).
- Cada task deve conter parâmetros específicos, por exemplo:
- **Crawler**: URL alvo, intervalos de verificação etc.
- **Request**: Endpoint da API, parâmetros de autenticação, payload esperado etc.
- **E2E**: Scripts de automação em Playwright, condições de sucesso/falha etc.

3. **Testes E2E em Playwright (Python)**
- Implementar testes de ponta a ponta usando [Playwright para Python](https://playwright.dev/python/).
- Os testes E2E serão acionados **manualmente via Typer** (ou seja, não rodam em todo ciclo automático).
- Foco inicial em dois serviços: **greenbook** e **lithocenter**, cujos requisitos incluem:
- **Crawler** (estar online/offline),
- **Request** (verificar resposta de API),
- **Fluxos de interface** (E2E).

4. **Testes passivos via Webhook**
- Implementar (ou aprimorar) endpoints que recebam **webhooks** de serviços externos para monitoramento passivo, quando operações específicas ocorrerem.
- **Caso de uso**:
- **ITMPR**: Verificar se o cron de backup foi bem-sucedido. O sistema ITMPR enviará um JSON no formato:
```json
{
"service_id": "itmpr-database_backup",
"status": "online",
"description": "some output string"
}
```
- A aplicação deve registrar e exibir esse status, confirmando o backup ou indicando falha.

5. **Rotas e dashboard (visão única e por serviço)**
- Criação de uma **página raiz** (ex.: `/`) para exibir todos os serviços em **lista**, como no desenho do Figma.
- Rota dedicada a cada serviço usando o **slug** (ex.: `/<service_slug>`), exibindo um **dashboard** específico com o status detalhado das suas tasks, registros de execuções etc.
- Utilização de templates **Jinja2** (ou equivalente) para renderizar essas páginas dinamicamente.

6. **Integração e Pull Request**
- O trabalho final deve ser entregue como um **Pull Request** no repositório [https://github.com/ORANGO-IO/status](https://github.com/ORANGO-IO/status).
- Essa contribuição corresponderá à versão **v2** do projeto.

---

## Requisitos técnicos

- **Linguagem:** Python 3.8+
- **Framework de linha de comando:** Typer
- **Biblioteca de teste E2E:** Playwright (Python)
- **Experiência em QA:** Boas práticas de testes (unitários, integração, E2E), incluindo cenários de CI/CD.
- **Framework web:** Flask ou equivalente para gerenciar rotas (`/<service_slug>`) e a página raiz.
- **Templating:** Jinja2 (ou similar) para renderizar dashboards e lista de serviços.
- **Git e GitHub:** Familiaridade com fluxo de trabalho para criação de branches, commits e pull requests.
- **Desenvolvimento de endpoints (webhooks):** Conhecimento de padrões REST, validação de payload JSON, segurança com tokens etc.
- **Modelagem de dados:** Capacidade de projetar e implementar tabelas/estruturas (SQL ou NoSQL) para representar serviços e tasks (com UUIDs).

---

## Perfil desejado

- Experiência consolidada em **QA**, testes de software e automação (Selenium, Playwright, Cypress ou similares).
- Conhecimento sólido em **Python** e ferramentas de CLI (idealmente Typer).
- Familiaridade com a criação de **endpoints** para recepção de webhooks.
- Competência em desenvolvimento web com Flask (ou framework similar) para criar rotas e renderizar templates.