ClearSQL
ClearSQL 9: Way to a more intuitive UI
ClearSQL 9 came out with a bunch of dramatic changes in the user interface, introducing the dark mode, entirely reorganized menus and toolbars, and a new set of icons, altogether so much affecting user interactions and the overall style of the app. The decision to redesign the UI was based on several reasons:
- Help trial users run their first code analysis in a fewer number of steps.
- Guide the users through the possible workflows, from basic tasks to advanced scenarios.
- Improve the accessibility of the most frequently-used features while replacing or even removing the least popular ones.
- Give more freedom of choice to satisfy the users' visual preferences and habits.
- Refresh the total look of the app.
The last but not the least was the real user feedback, making it absolutely clear that the ClearSQL's UI needs a change.
Instant code analysis
Originally, running a first code analysis was a complex procedure. You had to start a new project, import scripts or database objects, preliminarily connecting to a database, create the project, and eventually run the analysis.
In ClearSQL 8, we added the ability to create a project from the startup screen, but the number of steps stayed the same (Fig.1):
By introducing instant analysis in ClearSQL 9, we reduced the procedure to just 2 steps: first you import the PL/SQL scripts and then wait until the analysis completes (Fig.2). It is perfect for the introductory stage and can be used later to get fast analysis results.
The advanced mode still exists though. It comes in handy when you need to import scripts from a database, link them to sources, or arrange the items in the project tree.
Originally, running a first code analysis was a complex procedure. You had to start a new project, import scripts or database objects, preliminarily connecting to a database, create the project, and eventually run the analysis.
In ClearSQL 8, we added the ability to create a project from the startup screen, but the number of steps stayed the same (Fig.1):
By introducing instant analysis in ClearSQL 9, we reduced the procedure to just 2 steps: first you import the PL/SQL scripts and then wait until the analysis completes (Fig.2). It is perfect for the introductory stage and can be used later to get fast analysis results.
The advanced mode still exists though. It comes in handy when you need to import scripts from a database, link them to sources, or arrange the items in the project tree.
Instant code analysis
Originally, running a first code analysis was a complex procedure. You had to start a new project, import scripts or database objects, preliminarily connecting to a database, create the project, and eventually run the analysis.
In ClearSQL 8, we added the ability to create a project from the startup screen, but the number of steps stayed the same: (Fig.1).
By introducing instant analysis in ClearSQL 9, we reduced the procedure to just 2 steps: first you import the PL/SQL scripts and then wait until the analysis completes (Fig.2). It is perfect for the introductory stage and can be used later to get fast analysis results.
The advanced mode still exists though. It comes in handy when you need to import scripts from a database, link them to sources, or arrange the items in the project tree.
Originally, running a first code analysis was a complex procedure. You had to start a new project, import scripts or database objects, preliminarily connecting to a database, create the project, and eventually run the analysis.
In ClearSQL 8, we added the ability to create a project from the startup screen, but the number of steps stayed the same: (Fig.1).
By introducing instant analysis in ClearSQL 9, we reduced the procedure to just 2 steps: first you import the PL/SQL scripts and then wait until the analysis completes (Fig.2). It is perfect for the introductory stage and can be used later to get fast analysis results.
The advanced mode still exists though. It comes in handy when you need to import scripts from a database, link them to sources, or arrange the items in the project tree.
3. Involving QAs from scratch
Engaging QAs early in the development lifecycle has proved to be a fruitful experience, turning quality assurance into an everyday activity, rather than a "last-on-the-line" step. Widely known as a "shift-left", this approach has revamped the whole testing workflow and included quality checks in every stage of the project.
Involve QAs at the very beginning of the development process, let them participate in planning, contribute to making decisions, join design sessions, and even talk to customers to understand what they are expecting from the product or service being delivered. Working closely with developers allows QAs to sketch possible testing scenarios and find UI&UX flaws at the early stages. By doing so, you let the QA team add value throughout the development process, without idling around until code is written.
Sure such workflow does require a lot of communication and collaboration within the team, but thanks to 21-century wonders we don't need to be sitting in one office to keep in touch throughout the working day.
Engaging QAs early in the development lifecycle has proved to be a fruitful experience, turning quality assurance into an everyday activity, rather than a "last-on-the-line" step. Widely known as a "shift-left", this approach has revamped the whole testing workflow and included quality checks in every stage of the project.
Involve QAs at the very beginning of the development process, let them participate in planning, contribute to making decisions, join design sessions, and even talk to customers to understand what they are expecting from the product or service being delivered. Working closely with developers allows QAs to sketch possible testing scenarios and find UI&UX flaws at the early stages. By doing so, you let the QA team add value throughout the development process, without idling around until code is written.
Sure such workflow does require a lot of communication and collaboration within the team, but thanks to 21-century wonders we don't need to be sitting in one office to keep in touch throughout the working day.
4. Automating what can be automated
Working under the agile methodology presupposes meeting sprint deadlines and requires thoughtful estimation of workload a team can afford. When literally every minute counts, automation of certain procedures comes as a safety ring and frees space for testing areas that need human interference. Typically, in a team there are more developers than QAs, they have a stronger technical background, and can write automated testing frameworks with less effort. Delegate automation of testing to software developers, rather than QAs, and you will receive an upturn in the team's productivity.
Another painkiller in terms of QA automation is code review checks. There is a certain share of bugs in a software that occur due to typos in code or incompliance with project guidelines. Don't let a human factor take its toll on the quality of your software. Running automated code review audits before handing the results of your work to the QA team not only helps purify the code, but allows QAs to focus more on functional testing.
Working under the agile methodology presupposes meeting sprint deadlines and requires thoughtful estimation of workload a team can afford. When literally every minute counts, automation of certain procedures comes as a safety ring and frees space for testing areas that need human interference. Typically, in a team there are more developers than QAs, they have a stronger technical background, and can write automated testing frameworks with less effort. Delegate automation of testing to software developers, rather than QAs, and you will receive an upturn in the team's productivity.
Another painkiller in terms of QA automation is code review checks. There is a certain share of bugs in a software that occur due to typos in code or incompliance with project guidelines. Don't let a human factor take its toll on the quality of your software. Running automated code review audits before handing the results of your work to the QA team not only helps purify the code, but allows QAs to focus more on functional testing.
Evidently, there's much more to say about hardships QA engineers are facing in their routine. Each case is unique and there's no universal remedy. But keeping in mind these four tips will help your team take its best out of quality assurance in an agile workflow.
RELATED PRODUCTS
