This is a simple representation, and the actual workflow might be more complex based on your team's specific requirements and processes. Customize the workflow according to your team's needs, and consider integrating it with your version control system and other tools for a seamless development process.
EXPLORING UNCERTAINTY !!!
Quality Process Analyst | Tools Management | Technology Management | People Management
Friday, December 8, 2023
This is a simple representation, and the actual workflow might be more complex based on your team's specific requirements and processes. Customize the workflow according to your team's needs, and consider integrating it with your version control system and other tools for a seamless development process.
Thursday, December 7, 2023
Calculate Software Automation ROI
Data Calculation parameters:
- Number of test-cases can be automated: (B5 -(B5*B6)/100)
- Automation of the test-cases needs: =(($B$7*$B$11)+B9)/B12
- Time-to-market acceleration: =(B10*B7*B8)/8
Statistics calculation parameters:
Saved manual testing time (accumulated), hrs =
- =$B$10*F21*$B$8*0
- =H21+($B$10*F22*$B$8) ...
Automation costs (accumulated), hrs =
- =D21
- =D22+I21 ...
Autotests run and support cost, hrs=
- 0.00
- =$B$13 ...
Test cases automated =
- =IF((E21/$B$11)*B12 >= $B$7, $B$7, (E21/$B$11)*B12)
- =IF(((E22/$B$11)*$B$12) + $F21 >= $B$7, $B$7, (($E22/$B$11)*$B$12) + F21) ...
Autotests development cost, hrs using standard working hrs/month =
- =IF($B$14 <= $B$18 * $B$12, $B$14, $B$18*$B$12)
- =IF(SUM($E$21:E21)+$B$18 >= $B$14, MAX(0, $B$14 - SUM($E$21:E21)), $B$18*$B$12) ...
Automation costs, hrs =
- =E21+G21
- =E22+G22 ...
Saved manual testing time, hrs =
- =$B$10*F21*$B$8*0
- =$B$10*F22*$B$8 ...
ROI, hrs =
- =H21-I21
- =H22-I22 ...
Total saved in $ (- ve means in loss) =
- =(B45*B17)
Sunday, February 6, 2022
Short Continuous Deployments To Production !
One of my product teams has been successful in deploying to production once every 4 weeks. In the past, our release plan would comprise of an Iterative and incremental development sprint zero, one or three working sprints, one or two alpha or beta sprints, and followed by a hardening sprint.
We were essentially releasing features to end-users once in every six 8 or more. Our product features are critical to the business.
Our product team migrated to a shorter release cycle thereby developing and deploying for each sprint and changed to following into 1 month cycle,
Benefits of Small Releases
As the iterative development process is mastered, the door opens for the team to deliver smaller and more frequent releases to the end-users, and that is one of the prime drivers of agile. The ability to release software more frequently has two primary business benefits: increased responsiveness to the customer amidst changing marketing conditions and reduced risk to the enterprise.
- Frequent deployments to end-user provide a competitive advantage.
- Product requirements could change significantly if deployed to production once every few months. By launching frequently, you could gather data from end-users earlier and apply adjustments accordingly.
- Keep your team energized and motivated.
- Helps in establishing best practices.
- Exposes risks and challenges with design, architecture, and solutions earlier in the process.
Wednesday, December 8, 2021
Upgrade data migration validation !
Purpose: To make sure data consistency in upgraded environment.
Thoughts : Dump data base before and after upgrade and check data diff for these 2 data bases.
Available Tools:
- dbForge Data Compare for SQL Server
- DBDiff
- Pgdatadiff tool
Steps 1: Dump sql file before / after upgrade
docker exec -t
vaidio pg_dump --format=c -U ainvr>
dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql
docker exec -t
your-db-container pg_dump --format=c -U ainvr > dump_`date
+%d-%m-%Y"_"%H_%M_%S`.sql
Steps 2:
Create Empty Database
createdb -U postgres -W ainvr;
createdb -U postgres -W ainvr2;
Steps3 : Restore data to created empty database
psql -h localhost -p 5433 -U postgres -f
D:\dump_18-10-2021_13_23_57_before.sql ainvr
psql -h localhost -p 5433 -U postgres -f
D:\dump_18-10-2021_14_33_09_after.sql ainvr2
2. DBDiff Tool
DBDiff is an automated database schema and data diff tool.
○
It compares two databases,
local or remote, and produces a migration file of the differences
automatically.
○
Command-Line API
Source Code: https://dbdiff.github.io/DBDiff/
Comparison result
Executed Command:
dbdiff postgres://postgres:@localhost:5433/ainvr
postgres://postgres:@localhost:5433/ainvr2
Result:
-- DROP TABLE "public"."scene_object_2021_07_26";
-- DROP TABLE "public"."scene_object_2021_07_27";
-- DROP TABLE "public"."scene_object";
-- DROP TABLE "public"."scene_object_2021_07_28";
3. Pgdatadiff Tool
- Firstly, compares the row count in both tables.
- If the row count is the same, it instructs postgres to create MD5 sums from data.
The MD5 sums are based on the data being cast to varchar.
If you have data types that don't cast to varchar properly then the behavior
probably not reliable.
Source Code: https://github.com/dmarkey/pgdatadiff
Comparison result
Executed command:
pgdatadiff --firstdb=postgres://postgres:@localhost:5433/ainvr
--seconddb=postgres://postgres:@localhost:5433/ainvr2
Future
- Integrate with Jenkins through ssh set up environment
- Execute db diff scripts from Jenkins
Recommdation
- Pgdatadiff Tool
Firstly it compares the row count in both tables.
If the row
count is the same, it instructs postgres to create MD5 sums of
"chunks" of the table in both DBs and compares them. This way no data
is actually read directly by pgdatadiff
, it also means that pgdatadiff
is relatively fast but is puts a moderate amount of
pressure on the DB as it calculates the MD5 sums of large amounts of data.
Sunday, August 8, 2021
If There Isn’t Enough Time To Test !
What to do when there is not enough time for a critical bug fix test just a few days before release?
Partway through your test cycle, everything going smooth and all tasks accomplished at a high success rate but suddenly just before few days to release,Your manage or alpha tester and internal ad hoc tester found a critical issue and without that fix, the release could not make it.
Set up a meeting, Impact Analysis,
It involves analyzing the impact of changes made in features/modules in the application.
- Analyzing modules with the help of impact analysis documents. It will find the risks associated with any kind of changes in a module/product due to a fixed defect.
- It also helps to implement a prototype for the developers and testers to experience the effects in the system.
Conclusion:
1. Find out the critical fix area.
- Point out the responsibility of the fixed function(s) and associations of same fixed function(s) with other functions within the same module i.e. green area.
2. Find out the impacted areas/modules due to the critical fix.
- Point out the how many function(s) are affected due to green area fixed function(s) in orange and purple area and what are the effected function(s) responsibilities.
If area/module(s) are equally impacted;
Impact Analysis is a mandatory phase and crucial point where we can derive our test plan in a limited amount of time to minimize our release risk.
Test plan selection could be changed or customized with the same approach.